Console
Sign in
Docs for Application developer
On this page
  1. What you own
  2. Start here
  3. Common tasks
  4. Reference
  5. When the database is the problem

Database administrator

You own the PostgreSQL that the platform keeps its lasting state in: Access's tables, Data's records with their audit, events and version history, and, when the gateway is configured for it, the gateway's shared state. This page lists what you are responsible for, what to read first and where each database task is documented.

Read the documentation as Database administrator → The sidebar, the home and the previous and next links then follow this page.

What you own#

DatabaseWho connectsConnection variableWhat it holdsRules
AccessAccess replicasACCESS_DATABASE_URLEight tables: tenants, principals, permissions, grants, groups, roles and the two role link tablesAccess spec §3
DataData replicas and workersDATA_DATABASE_URL, DATA_REGISTRY_DATABASE_URL, DATA_DELIVERY_DATABASE_URLWorkspace records, audit, events, deliveries and version history, kept apart per workspace by row-level securityData spec §6.4, §7
Gateway shared state (optional)Gateway replicas and gateway-controlGATEWAY_SESSION_URL, GATEWAY_SHARED_STATE_URL, GATEWAY_CONTROL_STATE_URL with a postgres:// URLSessions, rate-limit windows, cached decisions and route-table revisionsGateway spec §12.8

Each service connects with its own non-superuser role. Access refuses a superuser or a BYPASSRLS role in production, because row-level policies would not bind it (Access spec §3.10).

Start here#

  1. Platform overview, for where each database sits.
  2. Access operations: database role and Data operations: database roles, to create the roles.
  3. Data configuration: database, for the three Data connections and what each role may do.
  4. Gateway operations: shared state, if the gateway uses PostgreSQL rather than Redis.
  5. Back up and restore, before the first production write.

Common tasks#

TaskWhere
Create the roles and databases of a first deploymentDeploy the platform
Run migrations and detect driftData: migrations and drift, Access spec §3.8
Back up, restore and rehearseBack up and restore
Apply retention and remove a workspace's dataData: retention, Data: remove a workspace
Clean up failed event deliveriesData: failed deliveries
Size pools and timeoutsData configuration: budgets, Access operations: tuning, Gateway configuration: shared state
Upgrade with new migrations, or roll backUpgrade and roll back
Rotate database passwordsRotate secrets

Reference#

QuestionPage
What does each Access table hold, and which indexes serve decisions?Access spec §3, §8.5
Which fields does Data maintain itself, and how does a collection change?Data spec §7
How does Data scope every statement to one workspace?Data spec §6.4
What does Data keep, and for how long?Data spec §15.4
Why does Data's SQL look the way it does?Data decisions: implementation decisions
How do the two gateway backends compare?Gateway spec §12.6

When the database is the problem#

SymptomWhere to look
Data answers 503 DATABASE_UNAVAILABLEData troubleshooting
Data's readiness probe answers 503Data troubleshooting
Access refuses to start because of its database role or schemaAccess troubleshooting: start refusals
Gateway sessions or limits fail with the shared-state backendGateway troubleshooting: startup and readiness

The rules a request follows are not yours to change; the schema they run on is. When the two meet, as in an index Data needs or a migration Access refuses, the owning spec decides.