Switch Between Schema States for Urgent Tasks

The Story: When Urgency Meets Long-Running Work

Meet Jordan, a backend developer working on a major feature that requires significant database schema changes. The work involves:

Restructuring the user authentication system
Adding new tables for a multi-tenant architecture
Migrating existing data to the new structure
Updating all related application code

⏰ Monday, 9:00 AM - The Long Task Begins

Jordan starts working on the multi-tenant feature. It's a complex change that will take several days. The database schema is already partially modified, with some new tables created and data migration in progress.

Jordan has been working for 2 days and the schema is in an intermediate state—not fully migrated, but not the original schema either.

⏰ Wednesday, 2:30 PM - The Urgent Task Arrives

A critical production bug is discovered. The fix requires testing against the original schema—the one that existed before Jordan started the multi-tenant work.

Jordan faces a dilemma:

The current database has the partially-migrated schema
The bug fix needs the original schema to reproduce and test
Reverting the schema changes would lose 2 days of work
Creating a new database from scratch would take hours

⏰ Wednesday, 2:45 PM - The Panic

Without a snapshot of the original schema, Jordan has limited options:

Option 1: Manually revert all schema changes (risky, time-consuming, error-prone)
Option 2: Set up a completely new database and restore from an old backup (if one exists, and it's from days ago)
Option 3: Ask a teammate to test the fix (but they might not have the right environment)
Option 4: Delay the bug fix until the feature is complete (not acceptable for a critical bug)

All options are painful and time-consuming.

The Solution

With Quemsi, Jordan could have taken a snapshot before starting the work, and another snapshot of the current progress. Then switching between schemas would take just 2 minutes—restore the original schema, fix the bug, test it, then restore back to continue the feature work.

How It Should Be Done: The Quemsi Way

Here's the workflow that saves you from this nightmare scenario:

📸

Step 1: Snapshot Before Starting

Before beginning any long-running task with schema changes, create a snapshot of your current database state. Tag it clearly, like before-multi-tenant-work or baseline-schema-v1.

↓

⚙️

Step 2: Work on Your Feature

Make your schema changes, migrate data, update code. Work normally, knowing you have a safety net.

↓

📸

Step 3: Snapshot Your Progress

Periodically snapshot your progress. Tag it with something like multi-tenant-wip-day2 or mid-migration-checkpoint. This lets you resume from where you left off.

↓

🚨

Step 4: Urgent Task Arrives

When an urgent task requires the original schema, simply restore from your baseline snapshot. Your current work is safely stored in the progress snapshot.

↓

✅

Step 5: Fix Urgent Task

Work on the urgent task with the original schema. Test, deploy, and complete the fix.

↓

🔄

Step 6: Resume Your Original Work

Restore from your progress snapshot to get back to exactly where you were. Continue your feature work without losing any progress.

✅ The Better Way

With Quemsi snapshots, here's what Jordan's timeline would look like:

Monday 9:00 AM: Create snapshot before-multi-tenant (30 seconds)
Monday-Wednesday: Work on feature, create checkpoint snapshots
Wednesday 2:30 PM: Urgent bug arrives
Wednesday 2:31 PM: Restore from before-multi-tenant snapshot (2 minutes)
Wednesday 2:33 PM - 4:00 PM: Fix and test urgent bug
Wednesday 4:01 PM: Restore from multi-tenant-wip-day2 snapshot (2 minutes)
Wednesday 4:03 PM: Resume feature work exactly where it was left off

Total time lost: 4 minutes instead of hours or days.

Step-by-Step Guide

1

Create Baseline Snapshot

Before starting any long-running task with schema changes:

Open Quemsi web UI
Navigate to your database
Click "Create Backup"
Tag it with a descriptive name like baseline-before-[feature-name]
Add a description: "Snapshot before starting [feature] work"

# Example: Create baseline snapshot
quemsi backup create \
  --database dev_db \
  --tag "baseline-before-multi-tenant" \
  --description "Original schema before multi-tenant feature work"
        

2

Create Progress Checkpoints

As you make progress, create checkpoint snapshots:

After completing major milestones
At the end of each day
Before making risky changes

Tag them clearly: multi-tenant-day1, multi-tenant-day2, multi-tenant-after-migration

3

When Urgent Task Arrives

To switch back to the original schema:

Open Quemsi web UI
Find your baseline snapshot in the timeline
Click "Restore"
Select your database (or create a temporary one for testing)
Confirm the restore

Your database is back to the original schema in 2 minutes.

4

Work on Urgent Task

Now you can work on the urgent task with the correct schema. Test, fix, and deploy as needed.

5

Resume Your Original Work

When the urgent task is complete, restore from your most recent progress snapshot:

Open Quemsi web UI
Find your progress snapshot (e.g., multi-tenant-day2)
Click "Restore"
Select your database
Confirm the restore

You're back to exactly where you were, with all your work intact.

Best Practices for Schema Switching

📋 Use Clear, Consistent Naming

Establish a naming convention for your snapshots:

Baseline: baseline-[date] or before-[feature-name]
Checkpoints: [feature]-day[N] or [feature]-checkpoint-[description]
Milestones: [feature]-after-[milestone]

This makes it easy to find the right snapshot when you need it.

🔄 Create Checkpoints Regularly

Don't wait until the end of the day. Create snapshots:

After completing each major step
Before making risky changes
After successful migrations
At natural break points in your work

The more checkpoints you have, the more flexibility you have to switch contexts.

🏷️ Use Descriptive Tags and Descriptions

Make your snapshots self-documenting:

# Good snapshot tags:
- "baseline-before-multi-tenant"
- "multi-tenant-after-table-creation"
- "multi-tenant-day2-before-data-migration"
- "multi-tenant-day3-after-migration-complete"

# Include descriptions:
"Baseline schema before starting multi-tenant feature work"
"Checkpoint after creating new tenant tables, before data migration"
"Progress after completing day 2 of multi-tenant work"
        

🧪 Consider Using Separate Databases

For complex scenarios, you might want to:

Keep your feature work on a separate database
Restore the baseline to a different database for urgent tasks
Switch between databases in your application configuration

This gives you even more flexibility and reduces the risk of accidentally overwriting work.

📝 Document Your Workflow

In your commit messages or PR descriptions, mention your snapshots:

feat: multi-tenant architecture (WIP)

- Created new tenant tables
- Started data migration process

📸 Snapshots:
- Baseline: baseline-before-multi-tenant
- Current progress: multi-tenant-day2-wip

To resume work: Restore from multi-tenant-day2-wip snapshot
        

Real-World Scenarios

Scenario 1: Hotfix Requires Old Schema

You're in the middle of a major refactor when a critical production bug needs fixing. The fix requires the old schema. With snapshots, you restore the baseline, fix the bug, test it, then restore your progress and continue the refactor.

Scenario 2: Need to Compare Behavior

You want to verify that your new schema produces the same results as the old one. Restore the baseline to a separate database, run the same queries on both, and compare the results.

Scenario 3: Team Member Needs Your Schema

A teammate needs to test something against your current work-in-progress schema. Share your checkpoint snapshot with them—they can restore it to their environment instantly.

Scenario 4: Experimentation Without Risk

You want to try a different approach to the schema changes. Create a checkpoint, experiment, and if it doesn't work, restore the checkpoint and try a different approach.