Your models are the source code.
SQL is the output.
dbwarden compiles SQLAlchemy models into reviewable SQL migrations. Your models are the source code. The generated SQL is the output. Upgrade, rollback, safety analysis, and schema verification come built in. Fully open source.
class User(Base): id = Column(Integer, primary_key=True) email = Column(String, unique=True)- username = Column(String(50))- bio = Column(String)+ bio = Column(Text)-- upgradeALTER TABLE users DROP COLUMN username;ALTER TABLE users ALTER COLUMN bio TYPE TEXT;-- rollbackALTER TABLE users ADD COLUMN username VARCHAR(50);ALTER TABLE users ALTER COLUMN bio TYPE VARCHAR;The schema lives
in the models.
Most migration workflows describe the schema twice (once in the models, once in the migration scripts), and the two drift unless someone keeps reconciling them. The disagreement usually turns up in production.
SQLAlchemy models describe what the schema should be. dbwarden compiles the migration SQL, the rollback, and the checks from that one definition.
Revision scripts describe how to get from one schema version to the next. The script chain becomes the schema's effective definition.
Models, not migration scripts
Describe the database with SQLAlchemy models and typed metadata. That's the whole schema.
Review the SQL
dbwarden make-migrations produces a versioned SQL file with upgrade and rollback, ready for the pull request.
Check the database
Snapshots and live comparisons tell you whether "migration succeeded" actually means the schema matches.
How the loop
is verified.
The checks on this page run in CI and in a harness against real databases. Each one has a page or a repository you can read.
CI replays the full migration history on an empty database and fails the build if the resulting schema differs from the models.
How it works ↗A harness applies each migration and its rollback in sequence, and confirms the schema ends up where it started. Rollbacks actually run in CI, instead of existing only on paper.
Read the docs ↗The harness runs against live PostgreSQL, MySQL, and ClickHouse instances, the same engines the generated SQL targets.
dbwarden-harness ↗The comparison pages state where each tool fits, including the cases where dbwarden isn't the right answer.
The comparisons ↗Which migration tool
should you use?
Deciding between migration tools? The comparisons live on this site: where schema truth lives, what gets reviewed, and where each tool fits. The docs are for people who already chose.
Revision scripts versus derived SQL, with honest tradeoffs and a six-step migration path.
↗vs AtlasLanguage-agnostic HCL schemas versus a SQLAlchemy-native declarative workflow.
↗Compare migration toolsModels as authority, plain SQL as the artifact, and where it doesn't fit.
↗FastAPI migrationsSessions, health checks, and migrations for FastAPI + SQLAlchemy.
↗Migrate from AlembicSix steps, none destructive, from revision chain to models.
↗CorrectnessConvergence, rollback verification, and real database testing.
↗Does dbwarden work with an existing database and schema?
Yes. generate-models reverse-engineers the current schema into SQLAlchemy models, and recover-model-state rebuilds model state when the revision chain is gone. Your database is never rebuilt; you replace the migration workflow, not the schema. The Migrate from Alembic page walks through the six-step path.
Which databases are supported?
PostgreSQL, MySQL, MariaDB, SQLite, and ClickHouse. Each backend has typed metadata options and its own feature matrix, and dev mode runs the same loop against SQLite. The Databases page lists what each backend supports.
How is dbwarden different from Alembic?
Alembic keeps schema truth in a hand-maintained chain of revision scripts. dbwarden keeps it in the models and derives plain SQL migrations from them, so the migration file is reviewable output rather than the source of truth. The comparison page shows the difference with code.
Can migrations be generated without a database connection?
Yes. make-migrations works from committed model state, so it runs anywhere: locally, in CI, or in a sandbox. Snapshots and live checks can run against a real database when you want them to.
How are migrations verified?
Checksums pin each migration to the model state it was derived from, a harness replays upgrade and rollback round-trips against real databases, and the convergence gate replays the full history on an empty database and fails the build on any drift. See the Correctness page.
Is dbwarden tied to a framework?
No. It works with any SQLAlchemy 2.0 stack. The optional dbwarden-fastapi plugin adds sessions, health checks, and @auto_schema request models for FastAPI apps.
Open source,
MIT licensed.
The code lives on GitHub. Read it, report a bug, or build a plugin with the template.