Home / Tutorials / Share Database States Across Environments

Share Database States Across Environments

Develop on test data, test on production data, and move database states between dev, test, UAT, and production environments instantly

The Story: When Environments Don't Match Reality

Meet Sam, a developer working on a feature that needs to handle complex user interactions. The development database has only a few test users, but the feature needs to work with real-world data patterns.

⏰ Monday, 10:00 AM - The Development Challenge

Sam is developing a new search feature. The dev database has 10 users with simple data. But the feature needs to handle:

  • Complex user relationships
  • Edge cases from real user behavior
  • Performance with realistic data volumes
  • Real-world data patterns and edge cases

Sam can't properly develop or test without realistic data.

⏰ Monday, 2:00 PM - The Testing Dilemma

Meanwhile, the QA team needs to test a critical bug fix. They need production-like data to verify the fix works correctly, but:

  • The test environment has outdated data
  • Production data can't be copied directly (privacy, security)
  • Setting up realistic test data manually takes days
  • The bug only appears with specific data patterns

⏰ Monday, 4:00 PM - The Traditional Solution (The Hard Way)

Without Quemsi, teams typically resort to:

  • Manual SQL dumps: Export from one environment, sanitize data, import to another (hours of work)
  • Complex scripts: Write custom scripts to transform and migrate data (error-prone, time-consuming)
  • Third-party tools: Expensive tools that require data to leave your infrastructure
  • Doing without: Developing and testing with unrealistic data (leads to bugs in production)

The Solution

With Quemsi, you can instantly share database states between environments while keeping all data within your infrastructure. Create a snapshot in one environment, restore it to another—it's that simple. No manual exports, no complex scripts, no data leaving your network.

Common Use Cases

💻

Develop on Test Data

Use realistic test data in your development environment to build features that work with real-world scenarios

🧪

Test on Production Data

Test critical fixes and features against anonymized production data to catch issues before deployment

🔄

Sync UAT with Production

Keep UAT environment synchronized with production for accurate user acceptance testing

📊

Performance Testing

Use production-like data volumes in staging to test performance and scalability

Develop on Test Data

Problem: Your dev database has only a few test users, but you need to develop features that handle complex real-world scenarios.

Solution: Create a snapshot of your test database (which has realistic test data), then restore it to your dev environment. Now you can develop with data that matches what users will actually experience.

Time saved: Hours of manually creating test data vs. 2 minutes to restore a snapshot.

Test on Production Data (Anonymized)

Problem: A critical bug fix needs testing, but it only appears with specific production data patterns. Your test environment has outdated or unrealistic data.

Solution: Create a snapshot of production data (after anonymizing sensitive information), then restore it to your test environment. Test the fix against real-world data patterns.

Time saved: Days of trying to reproduce the issue vs. minutes to restore production-like data.

Sync UAT with Production

Problem: Your UAT environment is out of sync with production, making it hard for stakeholders to test new features accurately.

Solution: Regularly create snapshots from production (anonymized) and restore them to UAT. Keep UAT synchronized without manual data migration.

Time saved: Weekly manual syncs taking hours vs. automated snapshots taking minutes.

Performance Testing with Real Data Volumes

Problem: You need to test performance, but staging has only a fraction of production data volume.

Solution: Create a snapshot of production data (anonymized), restore it to staging, and run performance tests against realistic data volumes.

Time saved: Weeks of generating synthetic data vs. minutes to restore real data volumes.

How It Works: Step-by-Step Guide

1

Create a Snapshot in Source Environment

In the environment that has the data you want to share:

  1. Open Quemsi web UI
  2. Navigate to your source database (e.g., test environment)
  3. Click "Create Backup"
  4. Tag it descriptively: test-data-2025-01-15 or prod-anonymized-v2
  5. Add a description explaining what the snapshot contains
# Example: Create snapshot from test environment quemsi backup create \ --database test_db \ --tag "test-data-realistic-users" \ --description "Test database with realistic user data for development"
2

Restore to Target Environment

In the environment where you need the data:

  1. Open Quemsi web UI
  2. Find the snapshot you created in the timeline
  3. Click "Restore"
  4. Select your target database (e.g., dev environment)
  5. Confirm the restore

The database state is now available in your target environment in minutes.

# Example: Restore to dev environment quemsi restore execute \ --backup-id "test-data-realistic-users" \ --target-database dev_db
3

Work with the Shared Data

Now you can:

  • Develop features with realistic data
  • Test against production-like scenarios
  • Run performance tests with real data volumes
  • Verify fixes with the same data that caused issues

✅ The Quemsi Advantage

With Quemsi, sharing database states between environments is:

  • Fast: Minutes instead of hours or days
  • Secure: All data stays within your infrastructure
  • Simple: No complex scripts or manual exports
  • Reliable: Exact database state, no data loss or corruption
  • Repeatable: Share the same state multiple times, to multiple environments

Best Practices for Cross-Environment Sharing

🔒 Always Anonymize Production Data

Before sharing production data to other environments:

  • Anonymize personally identifiable information (PII)
  • Remove sensitive data like passwords, API keys, payment info
  • Use data masking or transformation scripts
  • Tag snapshots clearly: prod-anonymized-2025-01-15

Tip: Create a restore flow that includes anonymization steps as part of the restore process.

📋 Use Environment-Specific Tags

Tag your snapshots to indicate source and purpose:

  • test-to-dev-2025-01-15 - Test data shared to dev
  • prod-anonymized-to-uat - Production data (anonymized) for UAT
  • staging-performance-test - Staging data for performance testing

This makes it easy to track what data is in which environment.

🔄 Establish Regular Sync Schedules

For environments that need to stay synchronized:

  • Set up automated snapshots from source environment
  • Schedule regular restores to target environments
  • Use Quemsi's timer feature to automate the process
  • Document the sync schedule in your team wiki

Example: Weekly sync of anonymized production data to UAT every Monday morning.

📝 Document Data Lineage

Keep track of where your data came from:

  • Include source environment in snapshot descriptions
  • Note any transformations or anonymization applied
  • Document the date and purpose of the snapshot
  • Link to related tickets or features
# Good snapshot description: "Production data (anonymized) from 2025-01-15. Anonymized: emails, phone numbers, addresses. Purpose: UAT testing for Q1 release. Related: JIRA-1234"

🧪 Test Your Restore Process

Before relying on cross-environment sharing:

  • Test the restore process in a non-critical environment first
  • Verify data integrity after restore
  • Check that anonymization worked correctly
  • Ensure application works with the restored data

🔐 Respect Environment Boundaries

Follow your organization's policies:

  • Never restore production data directly to production (use staging/UAT first)
  • Always anonymize before sharing to lower environments
  • Get approval before sharing sensitive data
  • Document all cross-environment data movements

Real-World Workflow Examples

Example 1: Developer Needs Realistic Test Data

Scenario: Sam needs to develop a feature that handles complex user relationships, but dev database only has 5 simple users.

Solution:

  1. QA team creates snapshot from test environment: test-realistic-users-2025-01-15
  2. Sam restores this snapshot to dev environment (2 minutes)
  3. Sam develops with realistic data patterns
  4. Feature works correctly when deployed to test

Time saved: 4 hours of creating test data manually vs. 2 minutes to restore.

Example 2: QA Needs Production-Like Data for Testing

Scenario: Critical bug fix needs testing, but only appears with specific production data patterns.

Solution:

  1. DevOps creates anonymized snapshot from production: prod-anonymized-2025-01-15
  2. QA restores snapshot to test environment (3 minutes)
  3. QA tests bug fix against real-world data patterns
  4. Bug fix verified before production deployment

Time saved: Days of trying to reproduce vs. 3 minutes to restore production data.

Example 3: UAT Synchronization

Scenario: UAT environment needs to be refreshed with latest production data for stakeholder testing.

Solution:

  1. Automated snapshot created from production (anonymized) every Monday
  2. Automated restore to UAT environment
  3. UAT always has current production-like data
  4. Stakeholders test against realistic scenarios

Time saved: 4 hours weekly manual sync vs. fully automated process.

Security and Privacy Considerations

🔒 Data Privacy with Quemsi

Quemsi is designed with privacy in mind. All data movement happens within your infrastructure:

  • No data exfiltration: Data never leaves your network
  • Agent-based: Quemsi agents run in each environment, coordinating data movement
  • Storage control: You control where backups are stored (your S3, your Azure Blob, your local storage)
  • Metadata only: Quemsi SaaS only manages metadata—never your actual database content

This means you can share data between environments while maintaining complete control and compliance.

Anonymization Best Practices

When sharing production data to other environments, always:

Tip: Create a Quemsi restore flow that includes anonymization steps, so the process is automated and repeatable.

Ready to Simplify Cross-Environment Data Sharing?

Start using Quemsi to share database states between environments instantly. Keep all data within your infrastructure while enjoying the convenience of easy data movement.

Get Started Free

Next Steps