Databases
A managed Postgres per app — how it is created, backed up, restored and browsed.
Turn a database on when you create an app, or any time afterwards, and Roar creates a Postgres database for it and hands the app the connection string. There is nothing to install, size or connect.
How your app gets it
The connection string arrives as an ordinary environment variable, DATABASE_URL. Almost every framework reads that name already, so most apps need no code at all — and an app that already ran against Postgres somewhere else usually needs no change.
DATABASE_URL=postgres://…
Never paste this into your code. Read it from the environment. It is rotated when the database moves, and a copy hardcoded in a repository is a copy that stops working — and one that anybody with the repository can read.
The database lives in the same region as the app. That is an architectural constraint rather than a setting: an app and its database on opposite sides of the world would pay the round trip on every query, and a database in another country is a different answer to a question about where your data is.
Schema changes
Roar looks in your repository for the migration command your framework uses and shows you what it found before running anything.
You choose when it runs:
| Setting | What happens |
|---|---|
| Leave it to me (default) | Nothing runs automatically. You press the button when you want it. |
| Apply on deploy | The migration runs as part of every deploy, before the new version takes traffic. |
Off by default on purpose — applying a schema change to live data is a decision an owner should make once, deliberately, rather than discover.
Backups
Twice a day, at 02:30 and 14:30, and every backup is copied off the machine that made it. A backup that only exists on the server it came from does not survive the case you keep backups for.
So the most you can lose is the work since the last one — up to twelve hours. If that is too much for what you are building, tell us before you rely on it rather than after.
Restores
You can see every point your database can be restored to, in the app's Database tab. Starting a restore is a request, not a button that acts immediately — you ask, and one of our engineers runs it.
That is deliberate, and worth understanding rather than working around: the key that decrypts your backups exists on no Roar server. Nothing running in our platform can read your backup archive on its own, which is the property that makes an off-box backup worth having. A one-click restore would mean putting that key somewhere a machine could reach — and then a compromise of the platform would be a compromise of every customer's history too.
Two people, on purpose. In exchange, a restore is a conversation and not instant.
Browsing your data
The Database tab lets you look at what is actually in there without a client, a tunnel or a password:
- Tables and columns, read from the live database rather than from your code — so it is what is there, not what you meant.
- Read queries, run against it and returned as rows.
- Row edits, for fixing one wrong value without writing a migration.
Every edit is recorded — what changed, from what, to what, and who did it. A change to live customer data should be answerable afterwards, and asking six weeks later is not the time to discover nobody wrote it down.
Reading and writing are separate permissions. An API key can be granted data:read to query and browse; editing rows, dropping a database and starting a restore cannot be done with a key at all — they are console actions by a signed-in person. A key that may deploy your app can never rewrite what is inside it.
Removing one
Deleting an app's database is a console action, and it is not undoable from our side beyond the restore points that already exist. If you are clearing up, take an export first.