The Platform Database
The single Aurora cluster that is the platform's system of record, how the platform reaches it, and how it is encrypted, backed up, and restore-tested.
The platform's system of record is one Aurora PostgreSQL cluster, reached through RDS Proxy and encrypted with a customer-managed key. It backs up continuously in its home region, copies daily to a second region, and gets restore-tested every week.
#What Lives Here
Every platform record: workspaces and members, users, apps and their releases, the manifest of every release, the catalog of an app's databases and tables, secrets (encrypted), API keys, interface sessions, cron and webhook definitions, request logs, method metrics, usage metrics, billing ledgers, audit-log indexes, the counterparty settings a workspace has chosen, and the state of every long-running process the platform runs.
App data does not live here. Each app's tables live in that app's own SQLite database, described in App Databases. The platform database holds the catalog entry for those databases and nothing of their rows.
#The Cluster
Aurora PostgreSQL 17, in provisioned mode with Serverless v2 instances, so capacity follows load within configured bounds rather than being sized by hand. A writer and a reader instance across availability zones. Storage is encrypted at rest with a customer-managed KMS key. TLS is enforced at the database by the cluster parameter group, so a connection to the cluster without TLS is refused.
| Property | Setting |
|---|---|
| Engine | Aurora PostgreSQL 17 |
| Instances | Serverless v2 writer and reader |
| Encryption at rest | Customer-managed KMS key |
| Encryption in transit | TLS enforced at the cluster by the parameter group |
| Authentication | Password with SCRAM-SHA-256 through the proxy; IAM authentication enabled on the cluster |
| Audit | pgaudit logging DDL and role changes, exported to CloudWatch Logs |
| Observability | Performance Insights, lock-wait and temp-file logging |
| Deletion protection | On, with a final snapshot required on any destroy |
| Maintenance | Automatic minor version upgrades in a fixed weekly window |
pgaudit records schema and permission changes and deliberately not statement text, so customer data never lands in a log stream.
#The Proxy
The platform connects through RDS Proxy rather than to the cluster directly. The proxy holds the connection pool, absorbs the connection churn of many short-lived pods, and presents two endpoints: the default read-write endpoint and a read-only endpoint. The platform's configuration points the writer pool at the first and the reader pool at the second.
Every role opens three pools: a writer, a reader, and a report reader with a longer statement timeout for analytics queries. Writes always go to the writer. Reads go to the reader unless a DAO needs read-your-writes consistency and asks for the writer explicitly.
#Backups and Recovery
Three layers, each answering a different failure.
Continuous backups within the cluster's home region, with point-in-time recovery to any second in the retention window. This is the answer to an operator error or a bad migration.
A daily snapshot copied to a second AWS region through AWS Backup, retained for 28 days in the DR vault. This covers regional loss: the system of record survives losing its home region. Retention is 28 days rather than 30 by design: the platform's deletion commitment is that a deleted app's rows are purged from backups within 30 days, and the last snapshot that can contain them must expire inside that window.
A weekly automated restore test. Every Sunday, AWS Backup restores the week's newest recovery point into a throwaway cluster inside the VPC and reports the result. The restore plan is the data-restore test of record, and a failed restore job raises an alert through EventBridge.
#Schema Changes
The schema is changed only through migrations, written as raw SQL and run by a Kubernetes Job before each rollout; every Deployment waits on that Job. Migrations are written for a large live database: indexes are created concurrently, and operations that would take an exclusive lock on a large table are avoided.