Database addon or database server: the difference that actually matters
By default, a new app’s database runs as an addon on the app’s own server — cheap, fast, and exactly right for getting started. The thing worth understanding before it matters in production: if that server is lost, the addon’s data has only your backups to fall back on. A database server is the other option — one of your own servers that holds data and nothing else, with a meaningfully different failure story.
What a database server actually changes
Moving data to a database server isn’t just a bigger box. It changes what protects the data:
- It gets no web proxy and no build tools, and no app is ever deployed to it — it exists for exactly one job.
- Its datastore ports are open only to the app servers that use it, not generally reachable.
- Backups, verified. Every app database on a database server gets a daily backup, and each one is checked by actually restoring it — not assumed good because the job reported success.
- A standby, on Pro and Team. Also create a standby provisions a second database server of the same size that keeps a live copy of Postgres, MySQL and Redis, checked every 5 minutes.
- Automatic failover. If the primary stops answering for 3 minutes and the standby has independently lost contact too, the standby takes over on the usual ports, every app using it redeploys against it, and you get a notification listing exactly what moved.
An addon on the app server has none of this by construction — it was never meant to be the durability layer, just the convenient default.
Moving an existing app over
Settings → Resources → Move data to a database server on the app, which lists exactly what will be copied and what starts empty before you press the button:
- The app stops.
- Postgres and MySQL are dumped and restored on the database server.
- Redis, MongoDB, object storage, RabbitMQ definitions and ClickHouse are copied too — an Elasticsearch used only by this app comes along as well.
- The app redeploys.
If any step fails, the app goes back to its old data — read-only, never overwritten — so a failed move doesn’t risk the thing it was trying to protect.
When the default is still the right call
Not every app needs this on day one. A low-stakes internal tool, a staging environment, anything where losing a day of data to a backup restore is a shrug rather than an incident — the addon default is correctly sized for that, and moving it is one settings page away whenever the calculus changes. The point isn’t “always use a database server.” It’s knowing which one you’re actually running before an outage is the moment you find out.
Full reference, including connection pooling and Postgres upgrades: Database servers.