Skip to main content

Why DB-X?

The gap​

Drizzle and Prisma own the application-side experience: query DSL, types, dev migrations. Nobody owns the operations side well — the part that runs in CI, in production, against a real database with users on it.

That's the wedge. For a head-to-head with Atlas, Bytebase, pgroll, Flyway and the ORMs, see DB-X vs the field.

How DB-X relates to your ORM​

DB-X does not ship a query DSL, a connection pool, or runtime data-access helpers. Your application code keeps using Drizzle / Prisma / Kysely / raw SQL — whatever fits. DB-X just owns the schema that those tools read from.

The db-x types command (planned, v0.4) emits the live schema as TypeScript types, optionally Drizzle schema files, or sqlc-style declarations. The intent is to make ORM-side definitions a derived artefact of the deployed truth, not the other way around.

How DB-X relates to Flyway / Liquibase​

Flyway and Liquibase model migrations as ordered SQL files. That's a fine shape for "apply these N scripts in order" but it leaves three things on the floor that DB-X picks up:

  • Drift detection. Flyway doesn't reconcile the live schema against intent — it just records what ran. DB-X diffs the live database against the declared JSX on every preview.
  • Snapshot + restore. Flyway has no first-class snapshot story. DB-X's Time Machine wraps every apply in a structured snapshot pinned to the state revision.
  • AI review. Flyway's diff is a folder of SQL files. DB-X's diff is a structured plan that an MCP server can hand to Claude / Cursor.

How DB-X relates to Infra-X​

A fork, not a distribution. See the architecture for the package layout.

  • Shared model, separate code. DB-X started from Infra-X's runtime and has since vendored it — the JSX reconciler, diff engine, state file and apply/destroy lifecycle now live in @db-x/runtime. There is no @infra-x dependency in either direction.
  • DB-X is the database-focused project for teams whose primary concern is the schema. The db-x CLI ships only the DB libraries plus db-specific subcommands.
  • The contracts still line up. A DB-X <Postgres> / <Table> is the same shape of defineComponent resource as anything in Infra-X, so the mental model transfers — but that alignment is a convention now, not a shared package, and components are not cross-loadable between the two CLIs.

Infra-X remains the general-purpose IaC project; DB-X went its own way to move on database concerns without coordinating releases across two repos.

What DB-X isn't​

  • An ORM. Your query layer keeps doing what it does.
  • A data-migration tool. Backfills happen via explicit <SeedData> or your ORM's scripts; we don't model row-level migrations as a first-class concept.
  • A cross-engine schema differ. v0.x targets one database per apply tree.
  • A new IaC pitch. The general-purpose IaC story belongs to Infra-X.