​
Drizzle vs vanilla SQL

Open Game Backend is designed to use an ORM to be more friendly for game developers & provide type safety out to the database of the box. The only thing better than docs you can build in a tool is an obvious interface & great tab completion. Well-designed ORMs provide this. Vanilla SQL requires a lot of repetition between redefining the model in TypeScript & selecting columns to query. It’s very easy to write hard to find bugs using vanilla SQL because of this repetition.

​
Drizzle vs Prisma

One core goal of Open Game Backend is to make using SQL databases easy for game devs who have no experience with SQL. OpenGB was originally built on Prisma instead of Drizzle, but was later refactored on to Drizzle. Friendliness towards non-SQL users Drizzle is explicitly designed for developers who know SQL well, which makes it slightly more difficult to pick up. Prisma is built primarily to make using SQL databases easy for developers who don’t know SQL, while still providing a powerful API for developers who do know SQL. The API is easy to understand, schemas are easy to write, migrations are buit to be fool-proof, and the entire API is intellisense friendly so you rarely have to read the docs. While Drizzle does have a Queries API intended to work similar to Prisma, designing schemas is still done in an SQL-like manner. We partially improved this by providing objects that have everything you need in one place (Query and Database). This allows devs to type Query.<Tab> and get a full list of everything they can do or Database.<Tab> to get a list of all tables. This prevents the need to hunt through Drizzle docs to find the function you need. There’s a lot of room for improvement here, and we’ll likely write a thin layer on top of Drizzle to help streamline insert & update statements. WASM vs pure TypeScript Prisma depends ona WASM module in order to serialize & deserialize database queries. This is intended to make the client faster, but it makes Prisma (a) harder to run in serverless with larger bundles and (b) requires finnessing to reuse the same WASM engine across multiple generated libraries. Drizzle’s TypeScript-native interface is much more lightweight. Dependency on Node (and therefore Docker) Prisma has a lot of bugs when running under Drizzle. To work around this, we used to ship a copy of both Deno & Node in order to run Prisma commands. Heavy vs lightweight Prisma takes a long time to run commands & generate SDKs. This made running opengb dev take a long time. It also frequently failed for unknown reasons, likely because it had so many network dependencies it had to download and race conditions when running Prisma in parallel. Unnecessary SELECT statement after create & other unoptimized commands See this issue. This has a pretty nasty performance impact when inserting rows frequently. Most use cases won’t notice the impact, but it’s important to be aware of for performance-sensitive modules. No headless migrations CLI Prisma requires a TTY to run development migrations. It took a lot of work to get the Prisma CLI to play nice with the Open Game Backend dev command. It would be nice to have a raw API we can call to run migrations within our own code. Slow builds Prisma takes a long time to build new clients. Open Game Backend caches heavily and parallelizes builds to make this less of an issue, but it’s still a pain point.