fraiseql-confiture 0.18.0

PostgreSQL schema evolution with built-in multi-agent coordination 🍓

Confiture 🍓

PostgreSQL migrations, sweetly done.

Build from DDL. Adopt on day one against a database that already has migrations applied. Preflight every deploy against a parallel database with structural diff. Sync production data with PII anonymization.

---

In 30 seconds

# 1. You already have a database at migration 004 (applied by hand or by another tool).
#    Tell Confiture about that history without re-running the SQL:
$ confiture migrate baseline --through 004 -c db/environments/production.yaml
  ✅ 001 create_users (marked as applied)
  ✅ 002 create_orders (marked as applied)
  ✅ 003 add_user_email (marked as applied)
  ✅ 004 add_user_preferences (marked as applied)
✅ Marked 4 migration(s) as applied, skipped 0 already applied

# 2. Machine-readable proof that the tracking is healthy:
$ confiture migrate status -c db/environments/production.yaml --format json | jq '.applied | length'
4

# 3. Preflight: replay pending migrations on a parallel DB, emit a structural diff vs. db/schema/.
$ confiture migrate preflight --against "$PREFLIGHT_URL" -c db/environments/production.yaml
▸ Replaying pending migrations on preflight DB …
  ✓ 20260520143015_add_user_bio                 applied in 24 ms
▸ Comparing resulting schema vs. db/schema/ …
  ✓ No drift — preflight matches db/schema/
✓ Preflight passed. Safe to deploy.
exit 0

That's the loop. Baseline once → status to confirm → preflight every deploy.

---

Already have migrations?

The single biggest reason migration tools fail adoption is the day-one cliff: existing tables already exist, so any tool that tries to apply migrations from scratch crashes on the first CREATE TABLE. Confiture's answer is migrate baseline:

confiture migrate baseline --through <last-applied-version>

The walkthrough — including failure modes, the integration test that backs the recipe, and what tb_confiture ends up looking like — is in docs/guides/legacy-bootstrap.md.

---

No db/schema/ directory? That works too.

confiture migrate up, down, status, baseline, and preflight are the migration runner — they don't require a db/schema/ directory. The "Build from DDL" pitch above the fold sells one of confiture's four strategies; the other three (incremental migrations, production sync, schema-to-schema FDW migration) work against a project whose only source of truth is the migration chain itself.

If you're evaluating confiture against Flyway / Alembic / dbmate / sqlx-cli as a pure migration runner, skip confiture build and use everything else. Walkthrough: docs/guides/02-incremental-migrations.md.

---

When to use Confiture?

Capability	Confiture	Flyway	Alembic	dbmate	sqlx-cli	plain psql
Source of truth	DDL files or migration chain	migration chain	model classes	migration chain	migration chain	DDL files
Tracking table	yes	yes	yes	yes	yes	no
Rollback (down.sql)	yes	paid	yes	yes	yes	no
Preflight against a copy DB	yes (structural diff)	no	no	no	no	no
Build from scratch in <1s	yes	no	no	no	no	yes (manual)
Production sync + anonymization	yes	no	no	no	no	no
Zero-downtime via FDW	yes	no	no	no	no	no
Multi-agent coordination	yes	no	no	no	no	no
Ecosystem maturity / stars	early	very mature	mature	mature	mature	n/a

Note on "source of truth": confiture can run as a pure migration tool against a project that has no db/schema/ directory — the DDL workflow is opt-in. See No db/schema/ directory? above.

Confiture wins on build-from-DDL, structural-diff preflight, production sync, and multi-agent coordination. It loses on ecosystem age — Flyway and Alembic have a decade of community knowledge. Pick honestly.

Adoption checklist

Situation	Recommended tool
1 environment + 1 contributor, schema rarely changes	plain psql
2+ environments, schema changes weekly	Confiture, Flyway, Alembic, or dbmate
Multi-agent / AI-driven development on shared schemas	Confiture
You have a migration chain (no db/schema/) and want preflight + tracking	Confiture (use everything except confiture build)
You want db/schema/ to be source of truth, not a migration chain	Confiture
You need zero-downtime schema swaps with postgres_fdw	Confiture (Medium 4)
You're committed to SQLAlchemy ORM	Alembic
You're committed to a JVM stack	Flyway

---

CI integration

A migrate preflight gate on every PR, a migrate up step on deploy. Exit codes are semantic, so the CI configuration stays simple:

# .github/workflows/db.yml
name: DB

on:
  pull_request:
    paths:
      - 'db/**'
  push:
    branches: [main]

jobs:
  preflight:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env: { POSTGRES_PASSWORD: x }
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready --health-interval 10s
          --health-timeout 5s --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv pip install --system "fraiseql-confiture[ast]"
      - name: Restore production snapshot to preflight DB
        run: ./scripts/restore-snapshot.sh   # your own; pg_restore from S3/GCS
      - name: Confiture preflight
        env:
          PREFLIGHT_URL: postgresql://postgres:x@localhost:5432/preflight
        run: |
          confiture migrate preflight \
            --against "$PREFLIGHT_URL" \
            -c db/environments/preflight.yaml \
            --format json --output preflight.json
      - uses: actions/upload-artifact@v4
        with:
          name: preflight-report
          path: preflight.json

  deploy:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv pip install --system "fraiseql-confiture[ast]"
      - run: confiture migrate up -c db/environments/production.yaml
        env:
          DATABASE_URL: ${{ secrets.PROD_DATABASE_URL }}

Exit codes: 0 success, 2 config error, 3 SQL failure, 6 lock contention, 7 structural drift. See the dry-run guide for what each one means.

Migrations that open their own SAVEPOINTs, use psycopg's conn.transaction(), or wrap DO $$ … EXCEPTION WHEN … $$ blocks are supported under all three modes. The rules a migration body must follow for the SAVEPOINT-based rollback to stay clean are documented in the transaction & SAVEPOINT contract.

---

Python project snippet

Add Confiture as a dev dependency. The [ast] extra pulls in pglast for full PostgreSQL parsing — recommended for schemas with bulk seed data.

# pyproject.toml
[dependency-groups]
dev = [
  "fraiseql-confiture[ast]>=0.9",
  "pytest>=8",
]

# justfile
default:
    just --list

db-build:
    confiture build --env local

db-up:
    confiture migrate up

db-status:
    confiture migrate status

db-preflight:
    confiture migrate preflight --against "$PREFLIGHT_URL"

Or as a Makefile:

db-build:
	confiture build --env local

db-up:
	confiture migrate up

db-status:
	confiture migrate status

---

Library API

Confiture is a CLI first, but the migrator is fully usable from Python:

from confiture import Migrator

with Migrator.from_config("db/environments/prod.yaml") as m:
    status = m.status()
    if status.has_pending:
        result = m.up()
        print(f"Applied {len(result.applied)} migrations")

---

The Four Strategies

Strategy	Use Case	Command
Build from DDL	Fresh databases, testing, CI	confiture build --env local
Incremental Migrations	Existing databases, production	confiture migrate up
Production Sync	Copy data with PII anonymization	confiture sync --from prod --anonymize users.email
Zero-Downtime	Complex migrations via FDW	confiture migrate schema-to-schema

---

Documentation

Start here

• Getting started — first 5 minutes.
• Legacy bootstrap guide — adopting on an existing database.
• Prerequisites — PostgreSQL version, roles, secret stores.

Guides

• Build from DDL
• Incremental Migrations — up, down, rollback.
• Production Data Sync
• Zero-Downtime Migrations
• Dry-Run + Preflight
• Bootstrap — confiture bootstrap for one-shot env ownership setup.
• Superuser Migrations — requires_superuser = True + migrate apply-as recovery workflow.
• Function Uniqueness — func_001 catches duplicate CREATE FUNCTION across DDL files.
• Named Schemas
• Hooks
• Multi-Agent Coordination

Reference

• Tracking table (tb_confiture)
• Transaction & SAVEPOINT contract — what migration bodies may and may not do under the wrapping transaction.
• CLI
• Configuration YAML
• Complete feature list

For agents and tooling

• Every machine-readable CLI output has a published JSON schema under docs/reference/json-schemas/ — see docs/reference/json-schemas.md.
• confiture migrate validate --list-patterns --format json exposes the full idempotency-detection catalog (read-only, no DB / config / migrations directory needed).
• Quiet-success ambiguities surface advisory hints in payload["hints"] (or on stderr in text mode) — exit codes are unaffected.

---

Contributing

git clone https://github.com/fraiseql/confiture.git
cd confiture
uv sync --all-extras
uv run pytest

See CONTRIBUTING.md and CLAUDE.md.

---

Author & License

Vibe-engineered by Lionel Hamayon 🍓

MIT License — Copyright (c) 2025 Lionel Hamayon

---

Making jam from strawberries, one migration at a time. 🍓→🍯