Drizzle or Kysely? ORM-style schema vs query-builder purity

The verdict up front

Picking a database client is one of the quieter, longer-lived decisions in a SaaS codebase. The library you choose will shape how you write every query, how you manage migrations, how your types flow through the app, and how AI assistants like Cursor and Claude Code generate code in your repo. In 2026, the two TypeScript-native options that solo founders consistently shortlist are Drizzle and Kysely. Both are excellent. They’re also philosophically different in ways that matter.

This guide walks through what each library is, where they overlap, and where they diverge — so you can pick the one that fits your stack rather than the one that’s loudest on Twitter this month.

What Drizzle is

Drizzle is a TypeScript-first ORM, founded in 2022 and developed by the team at Drizzle Team. The pitch on orm.drizzle.team is “the headless TypeScript ORM” — meaning it gives you ORM ergonomics (declarative schema, migrations, relational queries) without the heavy runtime abstractions associated with traditional ORMs like TypeORM or Sequelize.

Drizzle has three main pieces:

• Drizzle ORM — the runtime library. You define your schema in TypeScript using helpers like pgTable, mysqlTable, or sqliteTable, and Drizzle gives you a typed query API.
• Drizzle Kit — the migration tool. It diffs your schema definitions against your database state and generates SQL migration files automatically.
• Drizzle Studio — an in-browser data explorer that lets you browse and edit table contents without leaving your local dev workflow.

The schema lives in TypeScript files like this:

import { pgTable, uuid, text, timestamp } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: uuid('id').primaryKey().defaultRandom(),
  email: text('email').notNull().unique(),
  createdAt: timestamp('created_at').defaultNow(),
});

From there, Drizzle Kit handles migrations and Drizzle ORM gives you typed access to the table. The mental model is closer to Prisma than to a pure query builder, but with a much smaller runtime surface and no extra schema language to learn.

What Kysely is

Kysely is a type-safe SQL query builder for TypeScript, founded in 2021 by Sami Koskimäki. The project name is the Finnish word for “query.” The pitch on kysely.dev is bluntly “the type-safe TypeScript SQL query builder” — deliberately not an ORM.

Kysely’s philosophy is that SQL is already a great language for talking to a database, and most ORM abstractions hurt more than they help. What you actually need from a TypeScript library is type safety on the query inputs and outputs, plus IntelliSense that knows your schema. Kysely focuses on that and nothing else.

A Kysely query reads like SQL with a fluent API:

import { Kysely } from 'kysely';

const user = await db
  .selectFrom('users')
  .select(['id', 'email', 'created_at'])
  .where('id', '=', userId)
  .executeTakeFirst();

What Kysely does not do is manage your schema. There’s no pgTable helper, no schema-definition DSL, no migration generator. You bring your own schema (typically by writing raw SQL or using a separate tool like Atlas or Squawk), and you generate TypeScript types from the live database using kysely-codegen or write the type interface manually. Kysely’s migration support exists but is intentionally minimal — you write up/down functions in TypeScript and Kysely runs them in order.

The fundamental philosophy

The split between these two tools is genuinely about worldview, and it’s worth naming clearly:

Drizzle’s philosophy: define your schema once, in TypeScript, and let the tool give you migrations, types, and a query API for free. The schema is the source of truth, the database mirrors it, and your application code is generated against it. This is the modern-ORM playbook, executed without the bloat that made earlier ORMs unpleasant.

Kysely’s philosophy: the database is the source of truth, SQL is the language for talking to it, and a TypeScript library’s job is to give you type-safe SQL — nothing more. Schema management is a separate concern that should live in dedicated migration tooling. This is the “query builders are good, ORMs are leaky” school of thought.

Neither philosophy is wrong. They map to different developer preferences and different codebase shapes. If you’ve ever found yourself fighting an ORM’s query DSL because it can’t express the SQL you actually want to write, you’ll appreciate Kysely. If you’ve ever found yourself drifting into schema chaos because no tool owns the schema definition, you’ll appreciate Drizzle.

Schema definition

Drizzle treats schema definition as a core concern. You define tables, columns, indexes, and relationships in TypeScript using its helpers, and those definitions are the canonical record of what your schema looks like. The same definitions feed into Drizzle Kit’s migration generator and into the query API’s type inference.

Kysely doesn’t define schemas. The way you typically work with Kysely is to use kysely-codegen, which connects to a live database and emits a TypeScript interface that mirrors your schema:

export interface Database {
  users: {
    id: string;
    email: string;
    created_at: Date;
  };
  posts: {
    id: string;
    user_id: string;
    title: string;
  };
}

This generated interface is what gives Kysely its types. The implication: in a Kysely setup, your migration tool defines the schema (in raw SQL or via something like Atlas), the live database holds the schema, and the codegen step propagates that schema into your TypeScript types. It’s a longer chain than Drizzle’s, but each step does exactly one thing.

Migrations

This is one of the clearest divergences between the two.

Drizzle Kit auto-generates migrations by diffing your TypeScript schema against the current database state. You change a column from text to varchar(255), run drizzle-kit generate, and Drizzle Kit emits a new SQL file with the appropriate ALTER TABLE statements. drizzle-kit migrate applies pending migrations to your database. The workflow is essentially “edit schema, generate migration, apply,” and the tool keeps the database in sync with your TypeScript definitions.

Kysely’s migration support is deliberately bare. You write migration files by hand (in TypeScript or SQL), each exporting up and down functions, and Kysely runs them in order. There’s no auto-generation. Many teams using Kysely reach for a separate migration tool altogether — Atlas, Squawk, or Postgres-native pgroll — and treat Kysely purely as the runtime query layer.

For solo founders, Drizzle’s integrated migration story removes friction at the cost of locking you into Drizzle’s schema DSL. Kysely’s decoupled story gives you flexibility in exchange for assembling more pieces yourself.

Query syntax compared

Both libraries are typed, fluent, and chainable. The difference is in shape and naming. Compare a basic select:

Drizzle:

const user = await db
  .select()
  .from(users)
  .where(eq(users.id, userId));

Kysely:

const user = await db
  .selectFrom('users')
  .selectAll()
  .where('id', '=', userId)
  .executeTakeFirst();

Drizzle uses imported column references (users.id) and operator helpers (eq, and, or). Kysely uses string column names with operator strings. Drizzle leans toward expressing queries as TypeScript values; Kysely leans toward expressing them in shapes that mirror SQL keywords (selectFrom, innerJoin, orderBy).

Both produce parameterized SQL underneath, both prevent injection, and both give you full IntelliSense on column names and result types. Neither is harder to write once you’ve internalized the API.

Relational queries

Drizzle ships a relational query API that lets you traverse joins declaratively:

const usersWithPosts = await db.query.users.findMany({
  with: {
    posts: true,
  },
});

This compiles to a single query with a join (or to a multi-query batch, depending on the dialect) and returns nested JavaScript objects. It’s the closest Drizzle gets to feeling like a traditional ORM, and it’s genuinely useful for B2B SaaS shapes where you’re always loading users-with-organizations or projects-with-tasks.

Kysely has no relational query helper. You write joins explicitly:

const usersWithPosts = await db
  .selectFrom('users')
  .leftJoin('posts', 'posts.user_id', 'users.id')
  .select(['users.id', 'users.email', 'posts.title'])
  .execute();

This produces a flat result set, and if you want nested objects you reshape the data in application code. That’s on-brand for Kysely — explicit, SQL-shaped, no magic — but it means more boilerplate for join-heavy queries. If your app traverses three or four levels of relations regularly, Drizzle’s relational API saves real keystrokes.

Performance and bundle size

Both libraries are essentially zero-overhead at runtime. They build SQL strings, send them to the driver, and return rows. There’s no row hydration into class instances, no proxy objects, no lazy-loading magic. Public benchmarks consistently show negligible differences between Drizzle, Kysely, and raw SQL for simple queries.

Bundle size is similar too. Drizzle’s core sits around 7KB minified-and-gzipped depending on which dialect you import; Kysely is in the same range. Both are designed to be tree-shakeable, both work on serverless and edge runtimes, and neither will be the reason your bundle bloats. For comparison, a traditional ORM like Prisma ships a much larger runtime — if bundle size is part of your evaluation, both Drizzle and Kysely beat Prisma comfortably.

Database support

Drizzle officially supports PostgreSQL, MySQL, and SQLite, plus several Postgres-flavored variants (Supabase, Neon HTTP, PlanetScale on the Postgres side, Vercel Postgres, Cloudflare D1 for SQLite, Turso for SQLite). Each comes with a dedicated dialect that adapts schema syntax and connection handling to the underlying engine.

Kysely supports PostgreSQL, MySQL, and SQLite out of the box, with a plugin system that adds dialects for MS SQL Server, Cloudflare D1, PlanetScale’s serverless driver, and others. The plugin model means new dialects ship faster, but it also means you may need to install a separate adapter package for your specific runtime.

If you’re weighing Postgres hosts, our Supabase vs Neon comparison covers the leading platforms, both of which work with Drizzle and Kysely.

Edge runtime support

Both libraries run on edge runtimes (Vercel Edge, Cloudflare Workers, Deno Deploy) when paired with an HTTP-based driver. Drizzle has first-class support for Neon’s HTTP driver, Vercel Postgres, PlanetScale’s serverless driver, and Cloudflare D1. Kysely has equivalent support through dedicated dialect packages. For solo founders building on the modern serverless stack, neither library is a constraint.

Ecosystem and tooling

Drizzle ships its own tooling: Drizzle Kit handles migrations, Drizzle Studio gives you an in-browser data explorer, and the team maintains an active CLI. The integrated tooling is part of the value proposition — you get a complete database workflow in one project.

Kysely’s ecosystem is thinner by design. There’s kysely-codegen for type generation from live databases, plugin packages for additional runtimes, and community plugins for things like kysely-paginate and kysely-postgres-js. If you want a data browser or a richer migration workflow, you compose with external tools.

For most solo founders, Drizzle’s batteries-included story removes setup friction. For founders who already have opinions about migration tooling and data browsers, Kysely’s lightness is a feature.

TypeScript ergonomics

This is where the two libraries diverge in subtle ways. Kysely is famous in the TypeScript community for the precision of its types. Result types are inferred down to the column level, including nullability and type narrowing through where clauses. The community generally regards Kysely’s types as among the strictest available in any TypeScript SQL library.

Drizzle’s types are intentionally a bit more “ergonomic” — meaning they prioritize being easy to read and easy to work with over being maximally strict. In day-to-day use this is rarely a problem; in edge cases (complex joins, conditional selects), Kysely will sometimes catch a type mismatch that Drizzle lets through.

If you’re a TypeScript purist who wants the compiler to flag every possible bug, Kysely has a slight edge. If you’re happy with “types good enough to catch the common mistakes”, Drizzle is fine.

When Drizzle wins

When Kysely wins

Full comparison table

Verdict

Once you’ve picked a query layer, the next decisions are where to host the database (our Supabase vs Neon guide covers the two leading managed-Postgres options) and how to model multi-tenant data (the SaaS database schema patterns guide walks through the common shapes). If you’re still mapping the wider toolchain, our best SaaS tools for developers roundup puts Drizzle and Kysely in context with everything else a solo founder ships in 2026.

For the broader ORM landscape — including Prisma, the third name that always comes up — see our Prisma vs Drizzle comparison. If you’re newer to the ORM concept entirely, what is an ORM explains the core idea, and how to set up Supabase RLS for multi-tenant SaaS shows how the database client interacts with row-level security policies on the storage layer.

The good news for once: this is a decision you can revisit. Both Drizzle and Kysely are thin enough that migrating between them — or migrating to Prisma later — is a few days of mechanical refactoring rather than a quarter-long project. Pick the one that fits your current taste and ship.