Managed databases

A managed database is a real Postgres database that Ronja provisions and runs for you on its own managed cluster. It’s a live system you can build a whole application on: a CRM, an ops queue, application state. You can still ask questions of it in chat — Ronja can read it live alongside your tables. A question you ask every week belongs in a workflow that joins it, and analysis over large tables in a mirror of it in a feature (both below). 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.

One database, many systems

A managed database is the home of your organization’s operational systems, not of one of them. A new tracker, register or queue is usually new tables in the database you already have. That way its rows can point at the rows of the systems beside it — a non-conformance report at the supplier it is against — and there is one database to change, copy and mirror into a feature. A different topic is not a reason for a second database, so name the first one for the area it will hold (“Operations”) rather than for the first thing you put in it.

When you ask Ronja for a new system and your organization already has a database, she adds the new tables to it. A second database is the right call when someone outside your organization gets a login to it, or when its data must be restored, copied or handed over on its own; a different team or department is not a reason. When she does make one, she tells you which of those it was for. There is no approval step for a second database. Where data lives explains how she decides, and what she asks you.

Any login an app holds reaches every table in the database — the read login can see every table and the write login can change every one. A custom login names its tables, so something that only ever runs against your production database can be limited to the tables it needs. A custom login cannot reach a dev copy, though, so anything you test on the copy — an app’s Use test data, a draft run under Require a dev copy for draft work — needs the read or write login, which reaches every table.

What you can do with one

Four things. You do the first three by asking Ronja in an exploration; the fourth runs on its own, whenever a workflow that joins it runs:

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 database logins on demand — read / write / admin for the whole database, or a custom login scoped to the tables you name, each delivered as a secret, never a visible password — and writes rows at runtime. A custom login can never change the schema, whatever it is scoped to, which is what makes one safe to hand to a workflow, an app or a Saved Agent; it is also the only kind that can be revoked on its own, from the console. 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 (under Admin → Data & Knowledge → Databases) is a read-mostly control panel — schema, migrations, connection roles, and health — plus a thin surface to create, rename, or delete a database, to give one a dev copy, and to promote a copy’s migrations onto production.

Mirror it into a feature. Ronja can connect a managed database to a feature using change data capture (CDC) — log-based replication that copies the database’s changes into the feature once an hour. 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.

Ask about it in chat. For a one-off question, you don’t need a mirror. In an exploration, Ronja can join a managed database with your tables in a single query — “Which of last month’s orders came from customers our CRM marks as enterprise?” — reading the database live. The question only reads, and she uses the read login when there is one. It’s meant for analysis in the conversation: each question reads the live database again, and a chart she draws from it is shown in the conversation only, never saved as a chart. When the same question will be asked every week, have Ronja build a workflow that joins the database (below); when the tables are large, mirror the database instead. See Ask about a database in chat.

Join it in a workflow. An automated workflow can also join a managed database with your tables in a single query when it runs, so a question you ask every week can run on a schedule and feed a table, an email or an app. Ronja writes the query when she builds the workflow, and the workflow reads the database with a login it was given when it was saved. The query only reads, and it returns at most 100,000 rows: a bigger answer is refused rather than cut short, so filter or summarize the database side. See Limits.

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). A managed database also turns up in Search (⌘K) — matched on its name and its description, for every member — so you can reach one by name without going through the Databases page; Dev copies are left out. Asking about a database in chat isn’t tied to a role: anyone who can use one of the database’s logins — that is, who has access to its secret — can ask Ronja to join it.

An organization can provision up to ten managed databases; dev copies are not counted.

Because a managed database is the thing your business runs on, you can also give it a dev copy — a second database to try a change against before it reaches production. A dev copy has the same structure as the original, and either none of its rows or all of them, depending on which kind you make. See Dev copies.

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