Databases
Last updated
There is no managed database service. You have three options, and for a lot of applications the first one is genuinely the best.
Option 1: SQLite on a volume
For a single-process app — a bot, a worker, a small web app — SQLite on a volume is a real production choice, not a compromise:
- No second application, so nothing extra comes out of your resource allocation.
- Nothing exposed to the internet: it's a file, not an endpoint.
- Volumes are local disk, which is exactly what SQLite's locking expects.
- Backups are a file you can download from the Files tab.
The limitation is mechanical rather than a matter of scale: a volume belongs to exactly one application, so two apps can never share one SQLite file. If a second app needs the same data, you need a real database server.
Option 2: Run a database as its own app
Deploy Postgres, MySQL, Redis or MongoDB as a separate application from its official image, with a volume for its data.
Before you do, read the next section — this is where the platform's shape matters most.
Option 3: Use a database hosted elsewhere
A managed database from another provider, reached over the internet. You get backups, upgrades and failover as someone else's problem, at their price.
The thing to understand before running your own
There is no private networking. Every port binding gets a public DNS name, so your app reaches its database over a publicly reachable endpoint, with credentials as the only boundary.
There is no internal hostname, no VPC, and no way to mark a port as internal-only. Plan for that:
- Use a long random password. It is the entire protection.
- Remove the port binding when nothing external needs it. If only your own app connects and you're not using a local client, the exposure buys you nothing.
- Use TLS if your client supports it, since the connection crosses the public internet.
- Set connect timeouts and expect reconnects. This is a real network, not a socket to localhost.
Some database images are actively unsuitable for a public endpoint. Redis in particular is designed to sit on a trusted network — its own documentation advises against exposing it to the internet — so think carefully before binding a port for it, and see whether you need it at all.
Which to choose
| Situation | Choice |
|---|---|
| One process owns the data | SQLite on a volume |
| A second app needs the same data | A database app, or a hosted one |
| A database outage would be a business problem | Hosted elsewhere |
| You want the cheapest thing that works | SQLite on a volume |
Costs and limits
A database app draws CPU, RAM and disk from the same account limits as everything else — the app count itself isn't billed, the resources are. And its data counts toward your disk limit, which stops every app in the account if exceeded, so prune backups and logs.
Nothing is backed up for you. Whatever you choose, arrange your own backups and store them off the platform.