Managed databases

Who can do this

Any member can read the Databases page and each database console. Admin is required to provision, rename, delete, or restore a database. The building work — applying schema, creating database logins, running SQL writes, and enabling replication — is done by Ronja in Build mode, which itself requires Admin plus Build access.

A managed database is a real Postgres database that Ronja provisions and runs for you on its own managed cluster. Unlike the tables that hold your analytics data, it is a live system you can build on — a CRM, an ops queue, application state — not just a place to analyze data. You can also mirror it into a feature so your analytics run on top of the live system.

This is the how-to companion to Managed databases — start there for the concept.

You manage databases from the Databases page (in the Data & Knowledge area of the admin sidebar). All the building happens by asking Ronja in an exploration.

Provision a database

The fastest way is to ask Ronja, but a console path also exists.

Ask Ronja (recommended): Open an exploration in Build mode and ask her to create a database — “Set up a database for our support tickets”. She provisions it and confirms in chat. Asking again with the same name retries the existing database rather than creating a duplicate.

From the console:

1. Open Databases and click New database.
2. In the New database modal, enter a Database name and an optional Description, then click Create.
3. The row appears with a Provisioning status pill and a “Database provisioning started” toast. It flips to Ready on its own — no reload needed.

The Databases page — a managed Postgres database is a system to build on (a CRM, an ops queue, application state), not just a place to analyze data. Every database you provision is listed here with its status.

Caution

An organization is limited to 5 managed databases. This cap surfaces only as an error toast when you try to create the sixth — it is not shown anywhere else. Deleting a database frees a slot.

Build on a database

Once a database is Ready, Ronja does the building. In Build mode you can ask her to:

1. Design and evolve the schema. Each change is applied as a migration — a forward-only schema change recorded in the database’s own ledger. The Migrations timeline on the console shows every one.
2. Create a database login. Ronja creates a read, write, or admin login on demand — just ask her for the level of access you want. The password is server-generated and never shown — it is stored as a secret in a feature, and the login appears in the console’s Connection card as a role pill.
3. Write data. Ronja runs INSERT / UPDATE / DELETE and reads through the write role.

There is no interactive SQL console for people, and no database password ever reaches your browser — a real security property: the write boundary is a governed secret carrying the database’s identity, so writes are only ever mediated by Ronja against a database you own. The console shows the connection details — Host, Port, Database, and SSL mode — plus the role pills, but never a credential.

Mirror a database into a feature with CDC

Change data capture (CDC) mirrors a managed database into a feature so you can build analytics on the live system. It uses log-based replication, so it tracks changes continuously and follows tables added or dropped on the source automatically.

1. Make sure the database is Ready.
2. In Build mode, ask Ronja to enable CDC and name the target feature — “Mirror this database into our Support feature”. (There is no console button for this today; it is enabled by asking Ronja.)
3. The first sync runs a full snapshot of every table, then streams changes once per hour. Each source table appears in the target feature as a table named after it.
4. Manage replication from the console’s Replication card via Manage replication: pause and resume, run a manual Sync, watch health (Live / Snapshotting / Degraded), and Disable CDC.

Every table is mirrored as an append-only changelog; Ronja handles current-state reads for you when you query the mirrored tables. A database can have only one active mirror at a time — to point it at a different feature, disable CDC and re-enable it (which re-snapshots). Disabling CDC stops streaming and keeps the mirrored tables frozen at their last state; you can re-enable later.

Delete and restore

Delete on the console marks a database for deletion — it stays recoverable and nothing is dropped immediately. Restore it from Trash while it is still there. The permanent, irreversible drop happens later on its own; there is no “delete permanently” button for a managed database.

See also

• How Ronja replaces your stack — where managed databases and CDC fit the bigger picture.
• Connect a data source — bring in data from a system Ronja doesn’t host.