Neon vs Supabase vs a gateway DB API for preview environments

Three different products solve preview databases. Which fits depends on whether the database is your platform or one dependency among several.

By infrai-platform-engineeringPublished 2026-09-21API verified 2026-09-21

All three will give you a throwaway Postgres per pull request. The difference is what else comes with it: Neon sells branching as the product, Supabase sells a whole backend around the database, and Infrai’s POST /v1/db/branch/create sells a database that happens to sit on the same credential as your storage, queues, email and inference.

Pick on what your preview environment actually needs, because the database is rarely the only thing a PR has to stand up.

What the gateway version looks like

curl -sS -X POST "https://api.infrai.cc/v1/db/branch/create" \
  -H "Authorization: Bearer ${INFRAI_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"project_id": "dbp_7Uu2kQxWvR4mBn8d", "branch_name": "pr-1482", "from_branch": "main"}'

{
  "ok": true,
  "data": {
    "db_id": "db_9wQ1zV6pLkS3dHyB",
    "branch_name": "pr-1482",
    "parent": "main",
    "created_at": "2026-09-21T02:58:11Z",
    "state": "ready"
  }
}

One call, a real database cloned from main, state: ready when it’s usable. Teardown is DELETE /v1/db/branch/delete/{project_id}?branch_name=pr-1482.

No dashboard step, no Git app to install, no webhook to configure.

The comparison that matters

What you need	Neon	Supabase	Infrai db
Copy-on-write branch per PR	yes, the core product	yes, per-branch environment	yes, `db.branch.create`
Git integration that opens it for you	yes	yes	no — you call the API from CI
Connection pooling included	yes	yes	no — bring your own pooler
Point-in-time recovery	yes	yes on paid plans	no — discrete snapshots only
Auth, storage, realtime in the same product	no	yes	yes, plus queues, email, SMS, inference
Preview needs more than a database	separate vendors	Supabase’s own set	same key
Cost model	compute + storage	plan tiers	one-time fee + GB-month rent

Two rows decide most cases. If the PR environment needs a database and nothing else, the specialists are further along and you should use one. If it needs a database and an object store for fixtures and a queue for the worker and somewhere to catch the emails the tests send, then the number of accounts starts to matter more than the depth of any single one.

The honest case for each

Neon if branching is the feature you’re buying. Its integrations open and close the branch for you, the pooler is included, and point-in-time recovery covers the migration failure a snapshot doesn’t. A team whose main pain is preview databases should start there.

Supabase if you want the surrounding backend too and you’re happy inside its ecosystem. Auth, storage and realtime in one product with a good local development story is a real advantage, and per-branch environments fork the whole stack rather than only the data.

Infrai db if the database is one dependency among several. The limitations are worth stating plainly: no Git integration, no built-in pooler, and no point-in-time recovery — only snapshots you take deliberately. What you get instead is that the rest of the preview environment is already on the key.

What “the rest of the environment” means concretely

#!/usr/bin/env bash
# One script, one credential, a whole preview environment.
set -euo pipefail
API="https://api.infrai.cc"
PR="${1:?pull request number}"
PROJECT_ID="${INFRAI_DB_PROJECT_ID:?}"
AUTH=(-H "Authorization: Bearer ${INFRAI_API_KEY}" -H "Content-Type: application/json")

# 1. the database
curl -sS -X POST "${API}/v1/db/branch/create" "${AUTH[@]}" \
  -d "{\"project_id\": \"${PROJECT_ID}\", \"branch_name\": \"pr-${PR}\", \"from_branch\": \"main\"}"

# 2. a bucket for this PR's fixtures and artefacts
curl -sS -X POST "${API}/v1/storage/bucket/create" "${AUTH[@]}" \
  -d "{\"name\": \"preview-pr-${PR}\"}"

# 3. a queue the PR's worker drains
curl -sS -X POST "${API}/v1/queue/create" "${AUTH[@]}" \
  -d "{\"name\": \"preview-pr-${PR}\", \"max_retries\": 3}"

Three resources, one key, one bill.

Teardown is the same three calls in reverse, and because they share a credential you can put them in one workflow step with one secret rather than three jobs each holding a different vendor’s token. The naming convention carries across all three too — preview-pr-1482 is a database branch, a bucket and a queue, so a sweep that lists stragglers in one namespace can check the others without a mapping table.

With three specialists that’s three tokens in your CI secrets, three sets of rate limits and three cleanup jobs — and cleanup is where multi-vendor preview environments actually rot, because each vendor’s stragglers are invisible from the others’ consoles.

Cost, compared honestly

Neon and Supabase price on compute and plan tiers, so an idle branch mostly costs storage. Here a branch is a one-time create fee plus standing rent by occupied gigabyte, with the live figures in GET /v1/discovery/db.branch.create and your actual accrual in GET /v1/account/usage — both verified 2026-09-21, both free reads, both more current than any comparison table including this one.

Which is cheaper depends on how long your branches live and how large they are, so measure it. The structural point that survives any repricing: a branch you forget to delete costs money on all three platforms, and the nightly sweep is what actually controls your bill.

How to choose in an afternoon

Wire one PR end to end on your real repository with whichever option you’re leaning toward. Count the accounts you had to create, the secrets you added to CI, and the cleanup jobs you wrote.

Then ask the question nobody asks during evaluation: if a branch is forgotten, where does it show up? GET /v1/db/branch/list plus a nightly job on POST /v1/cron/create is the answer here; Neon and Supabase have their own, and any of the three beats no answer at all.