Masked Postgres sandboxes

Writable, prod-like Postgres for developers and AI agents. Source from prod, a read replica, or staging.

Trusted by world class organizations

HOW IT WORKS

From your Postgres to a masked sandbox in three steps

1

Point Baseshift at your Postgres

Production, a read replica, or staging: it's just a connection string. RDS, Aurora, Cloud SQL, or self-hosted. No migration, no new database cloud.

postgres://ro:••••@replica:5432/billing
2

Masking happens during the copy

Columns are anonymized as data streams from your source, so every clone is already masked the moment it starts. There's no post-copy scrub job to run, audit, or forget.

ann@co.io → x7@msk.io

3

Start a clone

A writable sandbox in seconds. Connect with psql or your ORM, run your migrations, break things, throw it away, start another. No tickets, no waiting on a shared staging environment.

$ baseshift clone start

Branch-like sandboxes,
without moving to a new DB cloud

Sandboxes shouldn't require re-platforming your production database.

Keep your RDS

Your Postgres stays exactly where it runs today, on RDS, Aurora, Cloud SQL, or your own servers. Baseshift copies from it; it never asks you to move it. And the sandboxes you get back are the same plain Postgres you started with.

Masked during copy

Anonymization is part of the copy itself, not a separate scrub step someone has to remember. Every clone starts masked; compliance is the default, not a checklist item.

Writable and disposable

Every clone takes real writes: DDL, migrations, deletes. When it's dirty, stop it and start a fresh one in seconds instead of cleaning up.

Standard Postgres. Not a fork.

Your clones behave like production because they are Postgres, not a rewrite and not a "Postgres-compatible" engine.

PostgreSQL 9.6 – 18

Every version you're actually running, including the ones you're embarrassed about.

Any source

Production, a read replica, or staging. RDS, Aurora, Cloud SQL, self-hosted. A connection string is all it takes.

Your extensions

The most common Postgres extensions are supported; schema comes through intact.

Flexible subsetting

Pull one or more tenants, a time window like last month, or another slice of the database. Available in self-serve SaaS.

Full SQL, real writes

psql, your ORM, your migration tool. Clones are writable Postgres instances, not read-only views.

Start free. Stay free until it's useful.

The free tier includes 150 GB of snapshots, enough to clone a real database and put it to work. Pro from $30/month when you need more.

Get started for freeSee pricing →

FAQ

Can I host Baseshift on prem/BYOC?

Yes, and the data never leaves your network.

Will copying data affect my production database?

Point Baseshift at a read replica and production never serves sandbox traffic. That's the recommended setup; a connection string to any source works.

Is this a Postgres fork or a "compatible" database?

Neither. Clones are standard PostgreSQL, versions 9.6 through 18. psql, your ORM, and your extensions behave exactly as they do in production.

How is masking configured?

With column-level rules and policy templates: you decide how each sensitive column is anonymized, and templates cover the common cases so you're not writing rules from scratch. Automated PII scanning is also available.

Can I clone a subset of the database?

Yes. Flexible subsetting is built into the self-serve product. Pull one or more tenants, a window like last month, or another slice (masked) instead of copying the whole database.

Do you support my extensions?

The most common Postgres extensions are supported and your schema comes through intact. If a source database uses an extension Baseshift doesn't support, you get a warning, not a silent skip and not a hard failure.

What permissions does Baseshift need on my database?

A read-only role. Baseshift copies from your source; it never needs write access to your production database.