Understand your database.

One database per customer

Each customer has a database and a separate application login on a shared PostgreSQL 18 primary/replica pair. Permissions separate database access; CPU, memory, storage, and WAL are shared resources.

The console and API run on Vercel. A separate Neon database stores accounts, jobs, and audit metadata. A worker on the primary processes queued provisioning requests.

Connect your application

Use the connection string provided through the authorized console. It includes your database name, login, and password. Keep it in your server’s secret environment.

postgresql://USER:PASSWORD@pg.dordev.com:6432/DATABASE?sslmode=verify-full

The current pilot endpoint remains pg.dordev.com:6432. Existing issued connections continue using that hostname. A BetterPostgres database-hostname transition will be announced separately after DNS and certificate verification.

Customer SQL travels directly through PgBouncer to PostgreSQL, independently of the web console. Use TLS certificate and hostname verification; do not disable certificate checks.

Application roles and schema migrations

The runtime login can use explicitly granted tables and sequences. Schema ownership is held by a separate NOLOGIN role. An operator currently performs migrations as that owner so new objects receive the intended application grants.

A customer migration credential/workflow is still planned. The runtime login does not receive cluster administration or cross-customer database access.

A replica and a backup serve different purposes

The standby receives asynchronous replication. Encrypted pgBackRest backups and WAL archives are stored offsite in R2. An isolated full restore has been tested; selected-time recovery drills with current customer data remain part of production hardening.

Automatic failover, independent per-customer compute, and a production SLA are not part of this pilot.

What you can use today

• Verified operator sign-in and customer/database provisioning.
• Queued jobs, status, and audit history.
• Encrypted credential storage and deliberate, audited reveal.
• Public TLS connections, restricted database roles, and a streaming replica.

Customer self-service, database billing, credential rotation, and suspension/offboarding are separate roadmap work.