devops-engineer
11f15aa86e
Phase 1 scope: molecule-core-postgres-1 docker dev DB only. Phase 2 (Neon staging) and Phase 3 (Neon prod) deferred per CTO 2026-05-19 GO option C on the schema-SSOT memory. Contents: - atlas.hcl: 3 envs (mc-postgres wired, neon-staging/neon-prod stubbed) - mc/schema/schema.hcl: declarative HCL captured from live mc-postgres (30 tables, 1878 lines) - mc/migrations/20260519191337_baseline.sql: initial migration generated from the declarative schema - mc/migrations/atlas.sum: integrity hash - .gitea/workflows/ci-drift-check.yml: PR gate (validate + destructive-op down.sql requirement). Uses OSS `atlas migrate validate` since `migrate lint` was paywalled in v0.38+ — see open question below. - Makefile + README quickstart targets Open questions raised during PoC: 1. Atlas Pro lint vs OSS validate — accept OSS floor, or license Pro for destructive-change/data-loss analyzers? Current workflow uses a grep-based destructive-op check as a stopgap. This commit is the PoC for RFC#549 Phase 1. No live DB was mutated; Atlas plans against an ephemeral docker dev DB. The existing molecule-core/migrations/ and molecule-controlplane/migrations/ directories remain authoritative for their products until cut over.
molecule-ai/migrations
Schema SSOT for Molecule-AI-owned Postgres databases. Implements RFC#549
(unified declarative migration tool — Atlas OSS). Authoritative reference:
memory feedback_schema_ssot_unified_migration_tool.
Status
- Phase 1 (current):
mc-postgres(local docker dev DBmolecule-core-postgres-1) - Phase 2: Neon staging (CP + ws-server)
- Phase 3: Neon prod (CP + ws-server) — manual GO required
Existing molecule-core/migrations/ and molecule-controlplane/migrations/
remain authoritative for their products until cut over per RFC#549 milestone.
Layout
atlas.hcl # multi-env config (mc-postgres / neon-staging / neon-prod)
mc/
schema/schema.hcl # declarative HCL — the SSOT for mc-postgres
migrations/ # versioned SQL (generated by `atlas migrate diff`)
vendor-snapshots/
gitea/ # weekly + on-upgrade pg_dump (visibility, no authority)
infisical/
.gitea/workflows/
ci-drift-check.yml # PR gate: migrate lint + drift diff (fail-closed)
Makefile # convenience targets
Quick start
# 1. Install Atlas (macOS):
brew install ariga/tap/atlas
# 2. Inspect live local DB:
make schema-inspect
# 3. Edit mc/schema/schema.hcl, then generate a migration:
make schema-plan NAME=add_widgets_table
# 4. Refresh integrity hash (required before commit):
make migrate-hash
# 5. Apply locally:
make schema-apply
Drift detection
Each PR that touches mc/** or atlas.hcl runs atlas migrate lint plus a
declarative drift probe (schema.hcl vs. materialised migrations). Drift
fails the check — consistent with the RFC#523 hard-gate philosophy.
High-risk migrations require a down.sql
Per the third RFC#549 answer (CTO 2026-05-19): destructive operations
(DROP TABLE, DROP COLUMN, TYPE changes that lose data) MUST ship with
a reversible down.sql alongside the generated forward migration. Atlas
lint surfaces these via the destructive analyzer.
Operating model
- Single repo, single tool (Atlas OSS) for everything we own
mc-postgresPhase 1 is the canary — proves the tool before Neon- Staging → prod is a manual promote, never an auto-apply
- Vendor DBs (Gitea, Infisical) live under
vendor-snapshots/for drift visibility only — no migration authority
Open
See OPEN.md (if present) for issues raised during the PoC.