Modernize your database workflows without a migration (code with real data)

Ask any team: moving a production database is one of the most stressful things you can do.

It doesn’t matter how polished the new database platform is, or how nice the UI and developer experience look. If the migration path involves downtime, heavy script refactoring, or any risk to data integrity, the answer from the CTO is usually “no.”

This effect is often called Data Gravity: the more data you have, the harder it is to move.

At Xata, we realized that asking teams to swap out their AWS RDS or Aurora production databases purely for a better developer experience is a non-starter. The migration risk is simply too high.

So, we built a solution that acknowledges this reality. We call it the "code with real data".

Don't move production

The core philosophy is simple: Keep your production database where it is.

If you are happy with the stability of AWS Aurora or RDS, stay there. You don't need to uproot your infrastructure to get modern tooling. Instead, you can use Xata as an extension of your existing stack.

By setting up Xata as a logical replica of your production database, you can unlock features like instant branching and PII anonymization for your development environments, without ever touching the primary node serving your customers.

Here is the architecture of a "code with real data" workflow.

The Bridge: Logical Replication

We utilize standard Postgres logical replication (WAL) to stream data from your primary provider (AWS, Google Cloud, Azure, or self-hosted) directly into Xata. Under the hood, we use pgstream, our open-source Change Data Capture (CDC) tool tailored for this exact purpose.

This offers two massive advantages over a "vanilla" replication script:

1. Automatic DDL Replication: Standard Postgres logical replication breaks on schema changes (Data Definition Language). If you run ALTER TABLE on production, your downstream replicas usually crash. Xata’s implementation uses event triggers to capture these schema changes and automatically applies them to your staging environment, keeping the streams healthy without manual intervention.
2. Fast initial snapshot: The pipeline handles the initial backfill (snapshot) and seamlessly transitions to streaming WAL events. Your Xata database stays in sync with production in near real-time, ensuring developers debug against live data patterns, not stale backups.

The Firewall: On-the-Fly Anonymization

Here is the catch with using production data in staging: PII (Personally Identifiable Information).

You cannot simply replicate your raw production database into a developer environment. Doing so is a compliance nightmare (GDPR, SOC2, HIPAA). Even when PII is not involved, using prod data directly is a security and reputation risk risk. As our CTO Tudor Golubenco put it:

"You don't want that data to end up in the developer branches... maybe you are emailing everyone in your list by mistake. That's just embarrassing."

Xata handles this at the replication layer. You define Anonymization Rules that transform data as it enters the Xata platform.

• Real emails are transformed to .
• Real phone numbers are masked.
• Names are randomized.

The result? Your developers get a dataset that preserves the shape, volume and complexity of production data, but with zero sensitive risks.

The Payoff: Copy-on-Write Branching & Preview Environments

Once your anonymized data is inside Xata, you can build safer workflows on top of it. Because Xata is built on a serverless, decoupled architecture, we offer Copy-on-Write (CoW) Branching.

In a traditional setup, if a developer wants to test a schema migration, they have to spin up a new RDS instance (which takes 20 minutes) or run it on a shared staging DB (and break it for everyone else).

With Xata, a developer can run:

xata branch create fix-billing-bug

In seconds, they get an isolated database branch with a full view of the anonymized production data. They can drop tables, change columns, and wreck the data it won’t affect the main staging branch, and it certainly won't touch production.

Automated Preview Environments

You can take this a step further by hooking Xata into your CI/CD pipeline (e.g., GitHub Actions, Vercel). Imagine creating a dedicated database branch for every Pull Request. Your QA team can test new features against real-world data volumes in an ephemeral environment that is automatically deleted when the PR is merged.

This approach changes the conversation from "migration risk" to "workflow augmentation."

• No Production Impact: Your production workloads remain on your existing provider (AWS/RDS), and you can set this up without downtime.
• Cost Efficiency (Scale-to-Zero): Unlike traditional staging databases that bill you 24/7, Xata branches scale to zero when not in use.
• Compliance by Default: PII never sits at rest in your developer environments.
• Flexibility: We support "Bring Your Own Cloud" (BYOC) deployments, so if you have strict data residency requirements, you aren't locked into a SaaS black box.

The Modern Stack is Hybrid

The future of database infrastructure isn’t about a single vendor. It’s about tools that interoperate cleanly.

You can keep the reliability of your production infra and use Xata for developer workflows around it. In practice, that means no big-bang migrations, and a smoother path to better tooling.

If you’d like to try this out, connect an existing Postgres database to Xata and start with a staging replica. No production changes required.