Apply database changes

Migrations are versioned under supabase/migrations. The required forward set depends on the target’s actual schema and recorded migration history.

Before applying anything

Identify the authorized target, inspect its version and take the appropriate backup. Compare the intended application revision with the existing RPCs, ownership policies and table shapes.

A newly built app is not a reason to replay every historical SQL file against a populated database.

Apply forward changes

Apply required approved migrations sequentially. Review dependencies and destructive effects. Do not run parallel DDL or historical bootstrap scripts to work around a missing function.

If a step fails, keep the error evidence and inspect the actual resulting state before continuing. A reported SQL failure or success alone is not a complete state description.

Verify the result

• Confirm required function signatures and service permissions.
• Check ownership and row-level access policies.
• Verify no financial transaction is unbalanced per currency.
• Test the affected owned API command and fresh read.
• Align generated types with the verified schema.

Use exact scoped synthetic data for tests and preserve unrelated records. Migration verification and browser acceptance serve different purposes.

See deployment for coordinating schema, provider and application versions.