Platform

Migrations
three modes, one ledger.

Every app has one migration ledger. Every environment picks a mode — managed (platform applies), export-only (your CI applies), or reconcile (platform reads yours). Schema changes flow through the same review, testing, and release gates as code.
ManagedExport-onlyReconcileIdempotent DDL
app_migrations · customer-success-hub
Migrationdevstagingprod
141_initappliedappliedapplied
142_accounts_renameappliedappliedapplied
143_rls_policiesappliedapplieddrifted
144_health_scoreappliedappliedpending
145_backfill_scoresappliedpending
146_health_rulesapplied

The problem

Most teams do two of these poorly: dev-side schema diffs, CI migration apply, prod drift detection. AlgorithmShift consolidates them into one ledger owned by the platform, so every environment shares the same truth about what's applied, what's pending, and what's drifted — whoever wrote it.
[01]

Managed: platform applies, platform tracks.

For dev and early-stage apps, let the platform do the whole cycle. The schema agent writes DDL, the runner applies it, the ledger records it — all in one orchestrated run.
  • Zero-config default for new apps
  • Generated DDL is idempotent + reversible
  • Every apply is atomic + captured in the audit log
generated DDL — idempotent by constructionsql
-- 144_customer_health_score.sql
-- Generated by schema agent · iter_4f19 · 2026-04-18

BEGIN;

CREATE TABLE IF NOT EXISTS customer_health_score (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  customer_id  UUID NOT NULL REFERENCES customer(id) ON DELETE CASCADE,
  score        SMALLINT NOT NULL CHECK (score BETWEEN 0 AND 100),
  recorded_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX IF NOT EXISTS ix_chs_customer_id
  ON customer_health_score(customer_id);

COMMIT;
[02]

Export-only: we generate, your CI applies.

For staging and prod, most teams already own a migration pipeline. Export-only mode keeps them in control: the platform emits a signed release bundle; your CI replays it through whatever tool you already trust.
  • Release-scoped SQL bundles (per app + version)
  • Works with Flyway, Liquibase, Atlas, raw psql — anything
  • Checksummed manifest for audit / compliance
release bundle manifestyaml
# release-bundle.yaml  ·  Release v2.8.0
release_id: rel_8f12
generated: 2026-04-18T14:22:00Z

sql:
  - 144_customer_health_score.sql
  - 145_backfill_scores.sql
  - 146_health_rules_table.sql

checksums:
  144_customer_health_score.sql: sha256:a91f...b303
  145_backfill_scores.sql:       sha256:5c82...9e11
  146_health_rules_table.sql:    sha256:12ab...e7f0

apply_order: [144, 145, 146]
replayable: true       # idempotent DDL, safe on re-run
rollback_plan: pr_notes.md#rollback
[03]

Reconcile: you apply, we follow.

Already have prod changes shipping outside the platform? Point reconcile mode at your existing ledger — the platform reads, never writes, and highlights drift you can investigate.
  • Reads existing migration tables (Flyway / Liquibase / Rails / custom)
  • Surfaces drift: ours vs. theirs, by revision
  • Upgradeable — flip an env to managed once trust is established
reconcile — flyway_schema_history · prod
RevisionOur ledgerTheir ledgerState
V0145__add_scores.sqlappliedappliedin sync
V0146__health_rules.sqlappliedappliedin sync
V0147__hotfix_idx.sqlapplieddrift
V0148__nullable_email.sqlapplieddrift
2 migrations landed outside the platform — review in ops / drift-review
[04]

Idempotent DDL, on every run.

Generated migrations use `IF NOT EXISTS`, `DO` blocks, and predicate-guarded updates. Re-running the same migration is a no-op. Crash mid-apply? Re-run. No duplicate columns, no duplicate indexes, no silent failures.
  • Structural DDL guarded with `IF NOT EXISTS`
  • Data migrations guarded by predicate
  • `BEGIN` / `COMMIT` wrap every file
idempotency contract — platform-enforcedyaml
# Every generated migration satisfies:
- structural:  IF NOT EXISTS on CREATE/ALTER/DROP
- data:        WHERE guards on UPDATE/INSERT
- wrapping:    BEGIN / COMMIT transaction
- reversible:  rollback.sql emitted alongside
- checksum:    content-addressable filename
[05]

Drift detection — hash check, not diff ritual.

Every applied migration is hashed at apply time. Next time the environment syncs, mismatched hashes flag as drift in the dashboard. You see exactly which migration diverged and can reconcile before the next release ships.
  • SHA-256 per migration file at apply time
  • Drifted rows highlighted in red on the status matrix
  • One-click 'show diff' against the ledger record
drift check — Apr 18 · 09:14 UTC
Migrationdevstagingprod
141_initappliedappliedapplied
142_accounts_renameappliedappliedapplied
143_rls_policiesappliedapplieddrifted
144_health_scoreappliedappliedapplied
[06]

Release-scoped bundles.

Every release carries the exact set of migrations it needs, pinned by checksum. You can rebuild a staging environment from any past release, or export the bundle for compliance review.
  • Migrations attach to a release at cut time
  • Version-pinned checksums prevent silent upgrades
  • Export-ready zip for ops handoff
attach migrations to releasebash
# From the release page, pick migrations to attach:
$ algo release:attach-migrations rel_8f12 \
    --ids 144_health_score,145_backfill_scores,146_health_rules

✔ attached 3 migrations to rel_8f12
✔ manifest regenerated
✔ bundle written to releases/rel_8f12/sql/

3 modes

Per-env migration modes

managed · export · reconcile

Idempotent

DDL safe to re-run

structural + data

Hashed

Drift detection built-in

SHA-256 per file

Pinned

Release-scoped bundles

deterministic replay

FAQ

Common questions

Does this replace Flyway / Liquibase?
Only if you want it to. In managed mode the platform owns the ledger. In export-only mode we generate migrations for your existing tool to apply. Reconcile mode treats your existing ledger as source of truth.
How are rollbacks handled?
Each migration emits a `rollback.sql` alongside the `apply.sql`. Rollback is a new forward-applied migration (your history stays immutable); platform-generated rollbacks cover DDL by inversion, data by snapshot where feasible.
What if a generated migration breaks production?
Export-only mode gates the apply on your CI pipeline — run tests against staging first. For managed mode, the run is atomic + rollback.sql ships with every migration. Drift detection flags the issue before the next release.
Can I use the platform without connecting my database?
Yes — the platform can generate SQL bundles as artifacts without ever connecting to your DBs. You'd apply them manually or via your existing pipeline. That's export-only mode without any DB credentials on our side.

Stop choosing between dev velocity and ops trust.

Pick a mode per environment. Keep the same ledger across all of them.