The technical angle I'm most excited about: it's built local-first using LiveStore (event-sourced, SQLite on-device), which means zero loading delays for user data and full offline support. Sync to the cloud happens in the background for cross-device usage. The stack is TanStack Start (web), Expo (mobile), and it runs entirely on Cloudflare.

Features in the current beta:

- Puzzle trainer with community submissions

- Guided lessons for openings and endgames

- Game import and analysis from Lichess & Chess.com

- Opening explorer based on your own game history

- Stockfish running on a dedicated Hetzner server (faster than in-browser WASM)

- AI coaching integrated directly in the analysis board

- Coordinate training, beginner track, leaderboards, ...

Available on web, iOS (TestFlight), and Android (nearly ready).

Would love your feedback — both on the product and the architecture choices!

Comments URL: https://news.ycombinator.com/item?id=47287155

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46634820

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44354455

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42948944

Points: 7

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=42267620

Points: 5

# Comments: 0

First off: Thanks for your feedback and questions, we're trying to create a meaningful comparison of ORMs and will be iterating on the benchmark setup and re-run them at some point, so your input is very much appreciated!

> It's not clear how many records were generated in the sample dataset for these benchmarks.

To clear the confusion: We've indeed used a sample size of 1000 records for the benchmark. If you click on the hyperlinked "real-world infrastructure" in the intro paragraph on benchmarks.prisma.io, the pop up shows you this information.

> I'm more interested in what latency and resource consumption look like for each query under any type of load.

This is great feedback and we were already considering adding this kind of information to the next iteration of the benchmarks. Thanks for this input!

> The issues that we were seeing with Prisma [3] were latency in acquiring a connection and executing a query when many queries were running simultaneously (with idle connections available in the pool and a high connection limit on Postgres).

That sounds like something our Engineering team may want to look into! Did you by any chance create a GitHub issue for this? It would be super helpful for the team to have more context on the issues you're describing here, so they can get fixed.

> I'd also be curious about the difference in performance for something like a nested `updateMany` where depending on how the query is generated, could deadlock or place a lock on more rows than necessary -- and where the generated queries actually matter.

This is something that hasn't been on our radar yet but I'm taking a note off for the next benchmark iteration as well!

Thanks again, please let us know if you have any further questions about Prisma or the benchmarks.

We charge for query volume, not for compute!

We believe that ultimately this is a more intuitive way for developers to think about database cost.

Generally, our goal is that developers need to only think about _queries_ — we'll take care of everything else to make sure those queries can run efficiently. Developers shouldn't need to worry about compute, scaling, downtime, etc.

Neon is a lot more feature-rich right now (since PPG just came out) and has awesome stuff like branching.

On the long-run, we expect to have a similar feature set. Additionally, our underlying tech has the benefits of avoiding cold starts and likely being more cost-effective.

That being said, I see it as a major benefit that with Prisma you not only get a DB but an entire data layer (incl global caching and real-time DB events) thanks to the first-class integration of our other products like Accelerate and Pulse [2].

[1] https://x.com/nikolasburk/status/1851522983346532669

[2] https://www.prisma.io/blog/announcing-prisma-postgres-early-...

- Graphcool: A GraphQL BaaS written in Scala.

- Prisma 1 (see [1]): A GraphQL proxy server between DB and app server. This was essentially the "GraphQL engine" of Graphcool that we ripped out and made it available as an open-source component. However, its auto-generated CRUD GraphQL API never was meant to be consumed by a frontend. Instead, it was the abstraction layer for the app server to interact with the DB (at first only for GraphQL APIs on the app server via `prisma-binding`, then the first version of Prisma Client that worked with any API layer — both of these were thin JS/TS layers that talked to the GraphQL proxy server where the actual DB queries were generated).

- Prisma 2+ aka Prisma ORM (see [3]): We realized that with Prisma 1, we were essentially competing with ORMs but that our architecture was way too complex (devs needed to stand up and manage an entire server where other ORMs could be used with a simple `npm install`). So, we rewrote the Scala "DB-to-GraphQL" engine in Rust to be able to provision it via a download during `npm install` and run it as a sidecar process on the app server, added a migration system and Prisma ORM was born. That being said, it has evolved a lot since then. We dropped GraphQL in favor of a way more efficient wire protocol [4] and have continuously reduced the footprint and responsibility of the query engine (e.g. you can now use Prisma ORM with standard Node.js DB drivers [5]).

If you want more details, I talked more about this evolution on Twitter [6] a while ago.

This launch is a huge milestone for us and it's definitely one of the most exciting launches I've been a part of at Prisma!

[1] https://www.prisma.io/blog/prisma-raises-4-5m-to-build-the-g...

[2] https://github.com/prisma-labs/prisma-binding

[3] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

[4] https://www.prisma.io/blog/prisma-5-f66prwkjx72s

[5] https://www.prisma.io/docs/orm/overview/databases/database-d...

[6 ] https://x.com/nikolasburk/status/1384908813069869058

Comments URL: https://news.ycombinator.com/item?id=40874204

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=40500806

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38026297

Points: 14

# Comments: 0

It uses tRPC [2] for type-safe API calls and Prisma [3] for your DB. There's lots of content out there teaching how to use this stack to build sophisticated apps (e.g. this in-depth tutorial teaching how to build a social media app [4]).

Disclaimer: I work at Prisma and am also a huge fan of type-safety, so T3 is basically my dream stack.

[1] https://create.t3.gg/

[2] https://trpc.io/

[3] https://www.prisma.io/

[4] https://www.youtube.com/watch?v=jqVm5_G1ZEE&ab_channel=WebDe...

Comments URL: https://news.ycombinator.com/item?id=34079407

Points: 5

# Comments: 1

To be honest, I think the most comprehensive resource for this is a Twitter thread [1] that I posted from my personal account that explains the different turns we took in the product direction :D

Otherwise, there's yhr blog post "How Prisma & GraphQL fit together" [2] that also touches on the same topics but might be a bit dated since it was published before we released the Prisma ORM for production use.

> And now the likely removal of graphql as wire protocol. What are the key reasons to remove the use of graphql query language?

The short answer is that it would allow us to make us more optimizations for the bridge between JS- and Rust-land in Prisma Client. However, this is not an urgent issue for us at the moment so very likely won't become a priority in the near/mid-term future.

[1] https://twitter.com/nikolasburk/status/1384908813069869058

[2] https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c