Recommended way to separate local/dev/staging/prod data in Sanity.io

Good news - there are several approaches depending on your plan level!

The Standard Approach: Multiple Datasets

The most common way to separate environments is to use multiple datasets within the same Sanity project. You'd typically have separate datasets like development, staging, and production.

How it works:

• All datasets share the same schema (defined in your Studio code)
• Each dataset has completely separate content
• Developers can work in development without affecting production
• You deploy the same Studio/schema code to all environments, but connect to different datasets

Setting this up:

In your sanity.config.ts, you can use environment variables to switch datasets:

export default defineConfig({
  projectId: 'your-project-id',
  dataset: process.env.SANITY_STUDIO_DATASET || 'production',
  // ... rest of config
})

Then each developer can set SANITY_STUDIO_DATASET=development locally, or you can have separate Studio deployments for each environment.

For schema changes during development: When you're actively changing schemas, each developer can either:

1. Work in a shared development dataset (content might get messy but that's okay)
2. Create personal datasets like dev-alice and dev-bob
3. Use the CLI to export/import data between datasets when needed

Enterprise Option: Hot Swapping

If you're on an Enterprise plan, Advanced Dataset Management offers "hot swapping" - you can create dataset aliases that seamlessly switch between datasets. This is perfect for testing migrations and CI/CD pipelines where you want to validate changes before promoting to production.

Workflow Recommendation

For early-stage projects with multiple developers:

1. Start with at least 2 datasets: development and production
2. Schema changes: Make schema changes in your code, test in development first
3. When stable: Deploy the schema changes to production (schemas are code, so this is just a deployment)
4. Content stays separate: Each dataset keeps its own content completely isolated

The key insight is that schemas are code (they live in your repo), so you version control them like any other code. The datasets just hold the content that conforms to those schemas. When you change a schema, you're just deploying new code - the content in each dataset adapts to the new schema structure.