Configure storage and PostgreSQL

Stratum starts without a database so teams can evaluate it quickly. Production work should use PostgreSQL so architecture history survives restarts.

Stateless mode

When no database is connected, Stratum uses its in-memory storage engine. A persistent banner warns administrators that designs and configuration will be lost after restart.

Connect PostgreSQL

Provide DATABASE_URL at startup or configure and test the connection from Admin console → System settings.

postgres://stratum:strong-password@postgres.example.internal:5432/stratum?sslmode=require

Simple installations can apply embedded migrations at startup with AUTO_MIGRATE=true. Production should use the release image's /migrate status, up, and check commands as a separate deployment job, then start the application with AUTO_MIGRATE=false.

Migration safety

Migrations are ordered, transactional, serialized with a PostgreSQL advisory lock, and recorded with SHA-256 checksums. Never edit an applied migration. Correct a released schema with a new forward migration.

Migrate bootstrap users

If administrators were created while Stratum was stateless, test the database connection first and use the migration action in storage administration. Verify the database user count before restarting.

Operational guidance

• Separate migration and application database roles.
• Require TLS verification outside a trusted development network.
• Back up PostgreSQL, enable point-in-time recovery, and rehearse restoration.
• Upgrade in staging before production.
• Start around 20 application connections per backend replica and tune from measurements.
• Do not place credentials in browser-visible configuration.