Proof
Multiple databases per plan - dev/staging/prod without per-project bills.
For indie devs
Create a database, copy a connection string, run your first query in ~15 seconds.
Proof
Multiple databases per plan - dev/staging/prod without per-project bills.
Proof
PgBouncer pooling with clear connection caps (20 / 50 / 150).
Proof
Daily backups with tier-based restore window (7 or 30 days).
Pain narrative
From Product Docs
The documented pattern is straightforward: keep separate environment databases, rehearse restores on staging, then switch DATABASE_URL only after the target behaves the way you expect.
Dev
disposable
Use a separate database for local work, experiments, and fast iteration.
Staging
rehearse here
Validate migrations, restores, and cutovers before touching production.
Prod
switch deliberately
Freeze writes, run the migration path you trust, then repoint DATABASE_URL.
Migration path
pg_dump -> pg_restore
Fast path for small moves, deliberate cutover for anything important.
How it works
01
Spin up a database from the dashboard and label it by app or environment so you know exactly what it is for.
02
Grab the full DATABASE_URL from the dashboard and move it into your app platform secret store.
03
Use standard Postgres tooling right away, whether you prefer a shell, an ORM, or your normal migration flow.
Explicit tradeoffs
These pages are meant to help someone qualify MVP DB quickly, not discover surprises after signup.
Isolation model
Schema-level virtual database on shared infrastructure. Isolation is logical rather than a dedicated box.
Region
eu-central-1 (Frankfurt).
Billing
Secure billing. Yearly plans include a 14-day trial. Cancel anytime, and contact us if you're not satisfied.
Reliability
No formal SLA. Best-effort reliability for teams optimizing for simplicity and price.
Want the deeper operational details? Read the docs and platform notes before you migrate anything important.