Foundation

Database Access & ORMs

How your code reads and writes the database — typed queries, schema changes and migrations — once you've picked where the data lives.

Ask your AI about this, with this page as the source:ChatGPT ↗Claude ↗Perplexity ↗

The real choice

Schema-first ORM, SQL-shaped query builder, or the platform's own SDK. A schema-first ORM generates types and migrations from one schema file and hides the SQL; a SQL-shaped ORM or query builder keeps queries close to SQL with full types and a smaller runtime; a backend platform (Supabase, Convex, Firebase) comes with its own client, and adding an ORM on top is often unnecessary.

Pick by situation

Tap the ones that are you — the tools that fit light up below.
  • You want one schema file that generates types, migrations and a readable query APIPrisma
  • You deploy to serverless or edge functions and want queries that read like SQL, fully typedDrizzle ORM
  • You already write SQL comfortably and only want types around it, no schema layerKysely
  • Your backend is Python and not DjangoSQLAlchemy

The contenders

Grouped by the side of the choice they answer, not ranked. Open a row for when to use it, the trade-off and what makers say.

ToolBest for
Schema-first ORM1
Prismalibrary · open source · free tierA schema-first ORM with generated types and migrations.37+111 open source15.9M/wk+1% vs npm

Use it whenYou want to describe the schema in one file and have types and migrations generated from it.

Trade-offA generated client and its own schema language sit between you and SQL; complex queries often drop back to raw SQL.

llms.txtMCPCLI

Used by Chat Thing, documenso, Firecoach AI, FraudLens AI, Hardbook and 32 more · in 111 open-source projects.

Since a year I build all my products with Prisma. It is a huge time saver and I like having the overview in one single file. It's migration just works all the time. Thanks Prisma!
Indie Hacker Stacks, the makerSep 2026 ↗
SQL-shaped ORM2
Drizzle ORMlibrary · open source · free tierA thin, SQL-like TypeScript ORM that runs well on serverless and edge runtimes.10+136 open source18.1M/wk+167% vs npm

Use it whenYou deploy to serverless or edge functions and want queries that read like SQL with full types.

Trade-offCloser to SQL means you need to know SQL, and there are fewer guides and integrations than for Prisma.

llms.txtCLI

Used by EmailCatcher, Flows, Penify, Rybbit, Sonofa and 5 more · in 136 open-source projects.

Drizzle ORM challenges MongoDB's schema-less claim. Schemas are beneficial, provided there's an effective solution for schema delta generation and migration scripts. Drizzle ORM did it.
Sonofa, the makerSep 2026 ↗
SQLAlchemylibrary · open source · free tierPython backends (FastAPI, Flask, scripts) that want an ORM or a SQL toolkit over any relational database.185 open source94.3M/wk

Use it whenYour backend is Python and not Django, which ships its own ORM.

Trade-offA large API with two styles (ORM and Core); migrations come from a separate tool, Alembic.

No maker's product we track shows it for this yet · in 185 open-source projects.

Query builder1
Kyselylibrary · open source · free tierA type-safe SQL query builder for TypeScript, with no schema file or code generation step of its own.39 open source13.8M/wk3.9× vs npm

Use it whenYou like writing SQL and want it typed, without an ORM's model layer.

Trade-offA query builder rather than a full ORM — migrations are basic and relations are joins you write.

llms.txt

No maker's product we track shows it for this yet · in 39 open-source projects.

Who switches to what

Public pull requests on GitHub since Oct 2024 whose title says "X to Y" — real code changes, by developers in general rather than makers only. Pick a flow to see its pull requests.

Prisma → Drizzle ORM: 140 pull requestsDrizzle ORM → Prisma: 27 pull requestsPrisma → Kysely: 10 pull requestsKysely → Drizzle ORM: 6 pull requestsDrizzle ORM → Kysely: 5 pull requestsPrisma 150Drizzle ORM 32Kysely 6Drizzle ORM 146Prisma 27Kysely 15Moving fromMoving to
Prisma → Drizzle ORM140 PRs · Compare →

Before you choose

How to approach it

Keep every schema change in migrations checked into the repo, and run them in CI or on deploy — never by hand in production. If you're on a backend platform, start with its client and add an ORM only when you outgrow it.

Common mistakes
  • Editing tables in the production console instead of writing a migration, so the next deploy's migration fails or silently drops the change.
  • Loading related rows one query at a time in a loop, which feels fine on ten rows and times out on a thousand.
  • Adding an ORM on top of a backend platform's client out of habit, then fighting two sources of truth for types and access rules.

Other options

Real choices most makers here won't need to weigh.

Decided alongside

What the 41 makers' products here chose for their other decisions.