DATABASE INFRASTRUCTURE

DBWarden

Declarative schema compiler that derives deterministic database migrations from SQLAlchemy models.

Your models are the source code. SQL is the output.

Python 3.12+ SQLAlchemy 2.0 PostgreSQL MySQL MariaDB SQLite ClickHouse
SQLAlchemy Models │ ▼ Model Discovery & Import │ ▼ ┌─────────┴─────────┐ ▼ ▼ Table/Column Snapshot Load Metadata (.schema.json) │ │ └─────────┬─────────┘ ▼ Schema Diff │ ┌───────────┼───────────┐ ▼ ▼ ▼ Type/Null Rename Constraint Changes Detection Changes │ │ │ └───────────┼───────────┘ ▼ Statement Ordering │ ┌─────────┴─────────┐ ▼ ▼ Upgrade SQL Rollback SQL │ │ └─────────┬─────────┘ ▼ Migration File + .plan.json │ ▼ Verification Gate

Problem

Schema management tools fall into two camps. Imperative tools have you author changes: revision scripts that describe how to get from one schema version to the next. Declarative tools have you author the desired state and derive the changes for you. Most imperative tools ask you to maintain two representations of your schema: your ORM models and your migration files. When they drift, you find out at deploy time.

Why it's hard

Schema drift is the core enemy. Most tools ask you to maintain two representations of your schema: ORM models and migration files. When they diverge, you find out at deploy time. Making this deterministic requires: a diff engine that handles renames, type changes, constraint changes, and ordering across 5 database backends with different DDL dialects. Every migration must carry both upgrade and rollback SQL, and the rollback must be tested against the actual database.

Workflow

01

Point at existing models

dbwarden reads your SQLAlchemy models as the single source of truth.

02

make-migrations

Generates a baseline schema or diffs against the current database state.

03

Commit generated SQL

Plain SQL files: reviewable, committable, executable anywhere.

04

migrate

Applies pending migrations with convergence verification.

05

Optional: impact analysis, offline mode, plugins

AST-based breaking change detection, CI without a database, seeds/RBAC/FastAPI integration.

Constraints

  • ·No migration runtime to install or version
  • ·No generated Python scripts that quietly do the wrong thing
  • ·No schema drift discovered in production
  • ·Migrations that can be generated in CI without a database connection

Key decisions

SQL-first output

Migrations are plain SQL files. No runtime, no generated Python. Reviewable, committable, executable anywhere.

Deterministic diff

Same models + same snapshot = same migration. Always. No hidden state, no ordering dependencies.

Strict rollback contract

Every migration carries upgrade + rollback SQL. Placeholder rollback refused by default.

Plugin architecture

8 official plugins for seeds, RBAC, FastAPI, sandbox testing, and PostgreSQL/ClickHouse extensions.

Test harness

dbwarden Test Harness is a standalone black-box validation suite. It installs dbwarden as a consumer, invokes its public CLI, creates disposable real database instances via Testcontainers, and verifies the compiled SQL produces the correct schema. This is not a unit test suite; it is a release certification boundary.

Harness coverage
PyPI installationPASS
CLI contractPASS
5 DB providersPASS
Migration applicationPASS
Constraint enforcementPASS
Regeneration silencePASS
Rollback/recoveryPASS
Plugin discoveryPASS

Ecosystem

wlite

CLI + bindings
C++ Rust Python Go C# Zig

Declarative SQLite schema management without the Python overhead. Same philosophy as dbwarden, stripped to what SQLite and C can do alone.

GitHub ↗

libwlite

C library
C11 SQLite3

dbwarden's SQLite3 engine extracted as a standalone C library. Parses .wlite model files, manages SQLite databases, compares schemas, generates migrations. The core runtime for wlite.

GitHub ↗

dbwarden-harness

Test suite
Python Docker Testcontainers

Standalone black-box validation suite. PyPI installation checks, CLI contract checks, real migration application across all 5 DB providers, rollback/recovery, and plugin discovery.

GitHub ↗

Results

DB backends
5
CLI commands
14
Plugins
8
Harnessed
FULL

Tradeoffs

  • ·Requires SQLAlchemy 2.0+ (not compatible with legacy models)
  • ·Schema compilation adds a build step vs. runtime migration
  • ·Declarative approach means less control over migration ordering