Managed databases

A managed database is a real Postgres database that Ronja provisions and runs for you on its own managed cluster. It isn’t a place to analyze data — it’s a live system you can build a whole application on: a CRM, an ops queue, application state. You own it; Ronja stands up the real database and keeps it running.

This makes a managed database a different kind of building block from everything else in Ronja. Most resources — tables, workflows, notes — describe or transform data you’ve brought in. A managed database is operational: rows are written to it at runtime as your system runs, and it’s the source of truth for that system rather than a copy of one.

Want the step-by-step — provisioning, building, mirroring, deleting? Jump to Managed databases (how-to). Read on for the concept.

How it differs from analytics tables

The tables that hold your analytics data live inside a feature and exist to be queried and reported on. A managed database is the opposite end of that spectrum:

• It’s live and operational. You read from and write to it continuously — inserts, updates, deletes — the way any application uses its database, not a snapshot that gets rebuilt.
• It belongs to your organization, not a feature. A table is owned by the feature it sits in. A managed database belongs to your whole organization and stays running for the long haul — it stands on its own, and features connect to it rather than contain it.
• You build a system on it. The point isn’t to answer a question once; it’s to run something — an app, a workflow, an internal tool — that keeps writing and reading over time.

An organization can provision up to five managed databases.

What you can do with one

Two things, both driven by asking Ronja in an exploration:

Build on it. In Build mode, Ronja does the building for you. She designs and evolves the schema (each change recorded as a forward-only migration), creates read / write / admin database logins on demand — each delivered as a secret, never a visible password — and writes rows at runtime. There’s no interactive SQL console for people: the building is mediated by the agent against a database you own, so credentials never reach the browser. The Databases console (in the admin sidebar’s Data & Knowledge area) is a read-mostly control panel — schema, migrations, connection roles, and health — plus a thin surface to create, rename, or delete a database.

Mirror it into a feature. Ronja can connect a managed database to a feature using change data capture (CDC) — log-based replication that continuously copies changes out of the live database. Every source table shows up as a table inside the feature, so your analytics and reports run on top of the live system without touching it. New tables and columns on the source are picked up automatically. This is how an operational database and your analytics estate meet: the system keeps running, and its data becomes something you can query alongside everything else.

A managed database is admin-managed. Any member can view the Databases page and a database console; provisioning, renaming, deleting, and the building work all require Admin (and the building itself needs Build access, since it happens in Build mode).

See Managed databases for the step-by-step: provisioning a database, building on it, mirroring it into a feature, and deleting one.