Migrations workflow

Treat SQL files in Git as canonical. flux push applies them to the tenant database and triggers PostgREST reload.

What you will learn

  • Why schema naming matters on v2
  • Idempotency habits
  • How to validate after push

The idea

On v2 shared, create objects in your t_<shortId>_api schema (name from the platform—not the marketing slug). Creating only in public often yields permission errors at request time.

To move an entire project from v2 shared to v1 dedicated (engine change, not a SQL file), use flux migrate—see Pooled → dedicated migrate.

After push, wait briefly for reload before assuming new tables exist in PostgREST’s cache.

How it works

Every push must resolve a project. From your machine, pass --project and --hash from flux list (example values—use yours):

bash
flux push db/migrations/0001_moods.sql --project percept --hash b915ec8flux push db/migrations/002_indexes.sql --project percept --hash b915ec8

In CI, use non-interactive tokens, pinned FLUX_API_BASE, and either the same flags or a checked-in flux.json with slug + hash so pipelines do not drift.

Example

Wrap breaking changes in transactions where appropriate; test dumps on a scratch project before production.

Next steps