Database qualification and migrations

Production URL: https://asi-database-node-api.arybit.co.ke

The PostgreSQL 16+ stream contains tenant/user/referral/audit and ledger foundations. It is experimental and does not implement legacy product parity. Root SQL files belong to a separate MySQL stream; all its manifest migrations are disabled pending compatibility, dependency and tenant-isolation validation. Do not run install.sql or concatenate legacy files against production.

Offline validation checks exact file coverage, order and SHA-256 checksums:

python Database/migrate.py validate --engine postgresql
python Database/migrate.py validate --engine mysql

After isolated qualification and a verified backup, an operator can apply the PostgreSQL stream with a separate protected migration credential file:

DB_MIGRATION_ENV_FILE=/secure/migration.env python Database/migrate.py apply --engine postgresql --confirm

The file requires ENV (test, staging or production), DB_HOST, DB_PORT, DB_NAME, DB_USER and DB_PASSWORD. Use a local database or prepared loopback SSH tunnel. Production also requires DATABASE_CONFIRM_PRODUCTION_MIGRATIONS=1. Do not set this gate until target and backup are reviewed.

The runner holds an advisory lock and commits each migration and its history atomically. Earlier successful migrations remain applied if a later migration fails. History must match a manifest prefix. Never edit already applied migrations or retry failed DDL blindly. MySQL apply is blocked by the runner.

Qualify fresh install, upgrade, rollback behavior, tenant isolation, least-privilege grants, backup restoration and application behavior separately. SQL catalog pages describe source files, not production acceptance.