Databases

A database whenever you need one

Create real PostgreSQL in a command, branch a copy of it for every pull request, and roll it back when a migration goes wrong.

databases
volcano cloud databases create app --region us-east-1 --pg-version 16app  active  postgresql 18  volcano-db-xsvolcano cloud databases migration up --all -d app001_schema.sql  002_policies.sql  okvolcano cloud databases branches create app pr_482 --ttl 72h✓ Branch 'pr_482' of database 'app' created# one command to fork, and it deletes itself in three days
Overview

Environments get rationed because databases are a project

When a new database means a provisioning step and someone else's calendar, teams end up sharing one staging environment. Pull requests queue behind each other, a load test poisons someone else's data, and the honest answer to whether a migration is safe is that nobody tried it on real data in isolation.

Volcano databases are created in one command, and any of them forks into a copy-on-write branch of its schema and rows in under a minute. When a copy of production is that cheap, a database per pull request stops being an indulgence. And when a change does go wrong, a restore puts the database back without changing its connection string.

On demand

One command, not a provisioning ticket

Name it, pick the Postgres version and the tier, and it is ready to connect to. It is ordinary PostgreSQL on port 5432 over TLS, so Prisma, Sequelize, TypeORM, psql and pg_dump work against it without anything to work around.

  • Six tiers, volcano-db-xs through volcano-db-2xl
  • Compute moves with load inside the tier
  • 1 database on Hobby or up to 10,000 on Superagent
volcano.dev/dashboard/database
A project's databases, each with its own region, version and tier
Branches

A copy of production per pull request

A branch forks a database's schema, rows, roles and policies behind its own connection string and password. It shares pages with its parent, so it is charged only for what it changes, and it expires on a deadline so nobody has to remember to clean it up. Reset it before each CI run instead of creating a new one.

  • Usually forked in under a minute
  • Reset to the parent's current data in one call
  • Up to 10 branches on Hobby or 25 on Superagent
volcano cloud databases branches list app
# name        status   storage    expires inpr_482      active   12.0 MiB   2dpr_487      active   0 B        6dnightly_ci  active   4.0 MiB    23h# each has its own password; none can reach the parent
Access

The connection knows who is asking

Volcano establishes the caller's identity on the connection before your first statement, so auth.uid() resolves inside your policies. One connection string covers migrations, queries on behalf of a signed-in user, and anonymous reads — you choose the access mode when you connect.

  • Full access for DDL, migrations and backfills
  • As a signed-in user, with policies enforced
  • As an anonymous visitor, for public reads
one string, three modes
# same database, same query, different callerfull access       → migrations, adminuser 8f1c…        → auth.uid() = 8f1c…anonymous         → auth.uid() is NULLpolicies do the rest
Path to production

How it works

  1. 01

    Create it

    Name it, pick the Postgres version and the tier, and apply plain .sql migrations from volcano/migrations.

  2. 02

    Protect it

    Turn on row-level security and write policies against auth.uid() before you expose it.

  3. 03

    Branch it

    Fork a branch per pull request or test suite, run the migration there first, and let it expire when you are done.

  4. 04

    Back it up

    On Superagent, schedule backups and restore in place, to a backup or to any point in the seven-day restore window.

Code

Create, branch, migrate, secure, query

Shell
volcano use my-project # --region and --pg-version are required; 16 through 18 are available volcano cloud databases create app --region us-east-1 --pg-version 18 # The string works with psql, your ORM, anything speaking the wire protocol volcano cloud databases get app --show-connection-string # A copy for the pull request: its own credentials, gone in three days volcano cloud databases branches create app pr_482 --ttl 72h volcano cloud databases branches get app pr_482 --show-connection-string # In CI, rewind the same branch before each run instead of forking a new one volcano cloud databases branches reset app nightly_ci --yes # On Superagent, schedule a nightly backup or restore within seven days volcano cloud databases backup-schedule set app --frequency daily --hour 3 volcano cloud databases restore app --to 2026-09-22T09:30:00Z
Return

What changes when a database takes seconds

< 1 minto branch a database

A copy-on-write fork, charged only for what it changes, so one per pull request is affordable.

7 daysof restore on Superagent

Roll back to any moment in that window without having taken a backup first.

6 tiersfrom xs to 2xl

Size staging and production independently instead of sharing one instance.

What you get

A database per pull request

Branches fork in under a minute and expire on their own.

Migrations you rehearse

Run each migration on a branch before production sees it.

A way back

Restore in place when a change goes wrong, with the same connection string.

Platform

Built on Volcano

Databases and vector
  • The database

    PostgreSQL 16 through 18 on autoscaling compute, with branches, extensions and direct connections, plus backups on Superagent.

Authentication
  • Who auth.uid() returns

    Sessions Volcano applies to the connection before your first statement.

Functions and agents
  • Server-side access

    Functions read DATABASE_URL from a project variable and query as the caller or as an admin.

Realtime
  • Changes as they happen

    Subscribe to row events on any table, filtered per subscriber by the read policy.

Frequently asked questions

Read the docs
Is this real PostgreSQL?

Yes — version 16, 17 or 18, chosen when you create the database, with 18 as the default. It listens on port 5432 over TLS, so psql, pg_dump and ORMs like Prisma, Sequelize and TypeORM connect to it the way they would to any Postgres. Querying over HTTP with the SDK is an option, not the only door in.

Can I connect from my laptop or from CI?

Yes. The string from volcano cloud databases get --show-connection-string works anywhere that can reach the internet over TLS, so local development, CI jobs and GUI clients connect the same way your deployed functions do.

How do I run a long backfill?

As a durable function that updates one batch per step. A failed batch retries on its own, a crash resumes at the next batch, and a finished batch is never run twice. Migrations themselves are .sql files under volcano/migrations, applied in alphabetical order by volcano cloud databases migration up, so write them to be safe on a second run.

How many databases can I create?

One database per project on Hobby or up to 10,000 on Superagent, each sized on its own tier from volcano-db-xs to volcano-db-2xl. Branches are counted separately, with up to 10 per database on Hobby or 25 on Superagent.

Are there automatic backups?

Yes, on Superagent. Set a daily, weekly, or monthly schedule per database, and take a backup by hand whenever you want one. Restoring is in place: the database keeps its connection string, and you can restore to any point in the seven-day window rather than only to a backup you took. Hobby does not include backups or point-in-time restore.

Can I branch a database from production?

Yes. volcano cloud databases branches create makes a copy-on-write fork of the schema, rows, roles and policies, usually in under a minute. The branch has its own connection string and password, lives for one hour to 30 days, and can be reset to the parent's current data whenever you need a clean slate.

Ready to create a database?

Build, deploy, and scale on Volcano's global platform — free to start, with no infrastructure to manage.

Explore more solutions