Preview environments changed how teams review code. Instead of "it works on my machine," you share a live URL. But there's always been a gap: most preview tools deploy your frontend just fine, then leave you pointing at a shared staging database — or worse, no database at all.

That's a problem. A preview of an e-commerce checkout that can't actually query products isn't much of a preview. A CMS demo that reads from a shared database where three other developers are also testing migrations? That's a bug waiting to happen.

Today we're launching Managed Databases for prev. It's the missing piece: real, isolated database instances that attach to your preview environments with a single flag.

The Shared Staging DB Problem

If you've worked on a team with a shared staging database, you've experienced at least one of these:

  • Running a migration that breaks someone else's preview
  • Test data from one developer leaking into another's demo
  • A client seeing "John Doe test user" instead of real seed data
  • Two developers running conflicting schema changes at the same time
  • A staging DB that nobody dares to reset because "someone might be using it"

These problems all stem from the same root cause: sharing mutable state across isolated environments. Preview environments solved the "shared frontend" problem. Managed Databases solve the "shared database" problem.

How It Works

The workflow has three steps:

Step 1: Create a Database in the Dashboard

Go to Dashboard → Databases, click Create Database, pick a name, engine (PostgreSQL, MariaDB, or MongoDB), and region. The database is ready in about 30 seconds.

Step 2: Attach It to a Preview

prev --db my-app-db .

That's the only change to your deploy command. The --db flag tells prev to resolve the database credentials and inject them into your preview container as environment variables.

Step 3: Use Standard Environment Variables

Your application reads credentials from environment variables like DATABASE_URL or the more specific DB_MY_APP_DB_HOST, DB_MY_APP_DB_PORT, etc. No prev SDK, no configuration files, no code changes. 

// Node.js / Prisma - just works
// prisma/schema.prisma already uses DATABASE_URL
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
# Django - just works
# settings.py already reads DATABASE_URL via dj-database-url
import dj_database_url
DATABASES = {
    'default': dj_database_url.config(default=os.environ['DATABASE_URL'])
}
# Rails - just works
# config/database.yml already reads DATABASE_URL
production:
  url: <%= ENV['DATABASE_URL'] %>

Real-World Use Cases

Agency Client Demos

You're building a property listing site for a client. Each demo preview needs the same schema but different seed data — one for residential, one for commercial. Create two databases, seed them differently, and deploy two previews: 

# Residential demo
prev --db listings-residential --subdomain acme-residential .

# Commercial demo
prev --db listings-commercial --subdomain acme-commercial .

Both previews are fully functional with isolated data. The client can browse properties, filter, and search — all with real database queries.

PR Previews with Migrations

A developer opens a pull request that adds a new tags column to the posts table. In a shared staging DB, this migration might conflict with other developers' work. With Managed Databases, the PR preview gets its own database: 

- name: Deploy PR Preview
  run: |
    prev --db dev-postgres \
         --subdomain pr-${{ github.event.number }} \
         .
  env:
    PREV_API_KEY: ${{ secrets.PREV_API_KEY }}

The migration runs against the preview's own database. No conflicts, no stepping on toes.

Multi-Database Applications

Some applications use multiple databases — a PostgreSQL primary store and MongoDB for search or analytics. Attach both: 

prev --db main-postgres --db analytics-mongo .

Each database gets its own set of environment variables (DB_MAIN_POSTGRES_URL, DB_ANALYTICS_MONGO_URL), so there's no collision.

Template-Driven Deployments

If you use Deployment Templates (Business plan), save the database configuration once and reuse it across all deploys: 

# Template "fullstack-app" is configured with --db staging-postgres
prev --template fullstack-app .

Team members don't need to remember which databases to attach. The template handles it.

Three Engines, One Workflow

We support the three most popular database engines for web applications:

  • PostgreSQL — the default choice for most web frameworks. Works with Prisma, TypeORM, Sequelize, Django ORM, ActiveRecord, and more.
  • MariaDB — MySQL-compatible. Drop-in for any MySQL-based application.
  • MongoDB — document database for flexible schemas. Works with Mongoose, PyMongo, and the native drivers.

All three engines are available in every region and use the same --db workflow. The engine type is set when you create the database in the Dashboard — prev handles the rest.

Daily Backups Included

Every managed database is backed up daily at 3:00 AM UTC with 7-day retention. This isn't something you need to configure or pay extra for — it's built in.

Backups use engine-native tools (pg_dump, mysqldump, mongodump) for maximum compatibility. If you ever need a restore, contact support and we'll handle it.

Simple Pricing

Managed Databases cost $5 per database per month, billed as a Paddle add-on. There's no per-query pricing, no compute-hour billing, no surprise overages.

  • 1 GB soft storage limit per database
  • Available on Individual and Business plans
  • No limit on the number of databases
  • Daily backups included at no extra cost

For most preview environment use cases — seeded demo data, development testing, client reviews — 1 GB is more than enough.

Getting Started

If you're already on a prev plan:

  1. Go to Dashboard → Databases
  2. Create a database (name, engine, region)
  3. Add --db your-db-name to your next deploy

That's it. Your preview now has a real, isolated database with automatic credential injection.

Full documentation is in the Managed Databases guide. If you have questions, reach out at hello@prev.sh.