PostgreSQL Readiness

Vorliq production storage is still hardened JSON. PostgreSQL is documented here as the preferred future managed database target, not as an active production backend.

Why PostgreSQL Later

PostgreSQL is the best future managed database option for Vorliq because it supports durable relational constraints, JSONB compatibility for legacy payloads, strong indexing, transactional imports, backups, replication, and mature managed hosting. That lets Vorliq keep immutable chain records while scaling public reads and operational state.

Why Not Now

The current JSON layer has atomic writes, backups, storage health checks, audit exports, and derived read indexes. Switching too early would add risk without enough migration rehearsal. The next safe step is validation, simulation, parity testing, and rollback planning.

Preparation Artifacts

database/schema.sql maps future tables.
database/indexes.sql drafts future read indexes.
database/constraints.sql documents future safety constraints.
blockchain/storage_adapters/postgres_adapter.py provides experimental shadow reads.
tools/postgres_schema_check.py checks files without connecting to PostgreSQL.
tools/simulate_postgres_import.py simulates import ordering without database writes.
tools/run_shadow_migration_rehearsal.py --check-adapter runs a guarded local or CI-only PostgreSQL shadow import, parity check, and adapter read parity check.

Adapter Flags

VORLIQ_STORAGE_BACKEND=json is the default and production setting. PostgreSQL runtime selection is blocked in production. Non-production tests require VORLIQ_ALLOW_EXPERIMENTAL_POSTGRES=true and VORLIQ_POSTGRES_SHADOW_ONLY=true, and write attempts remain disabled unless VORLIQ_POSTGRES_WRITE_MODE=shadow_test is explicitly set for a shadow test.

Immutable History

Block hash, previous hash, nonce, timestamp, miner address, proof data, transaction order, and raw block JSON must be preserved. Confirmed transactions keep raw JSON so legacy entries without tx_id remain compatible.

Operator Checks

Check /api/migration/readiness, /api/readiness, and the live Migration Readiness page. Run schema validation and the shadow rehearsal locally before any future migration rehearsal window. Production should continue to report active_storage_adapter: json, postgres_active: false, postgres_adapter_enabled: false, and postgres_write_mode: disabled.