Dataset vs Studio: Do I need separate Sanity projects for each environment?

I understand your confusion! Let me clarify what's happening and how Sanity workspaces actually work.

What's Actually Happening

You have one Sanity project with one Studio deployment at companyname.sanity.studio. When you configured workspaces, you set up four different environments (Dev, QA, Stag, Prod) that you can switch between using a dropdown in the Studio.

Here's the key thing to understand: Each workspace CAN have its own independent schema, configuration, and plugins. The workspaces feature is specifically designed to provide "isolated Studio configurations" within a single codebase. However, you're deploying all of these configurations together as one Studio deployment.

Why Changes Affect All Datasets

When you run sanity deploy, you're deploying your entire Studio codebase to companyname.sanity.studio. This means:

• All workspace configurations get deployed together
• Any schema changes you make in your code affect all workspaces when you redeploy
• You can only have one hosted Studio per project on the *.sanity.studio domain

So while each workspace can have different schemas and configurations in your code, when you deploy, you're deploying all of them at once. If you change a schema definition and redeploy, that change goes live for all workspaces simultaneously.

Two Approaches to Solve This

Option 1: Self-Host Separate Studio Instances

If you need to test Studio/schema changes in isolation before they hit production:

• Keep your one Sanity project with multiple datasets
• Deploy separate Studio instances to different hosting providers (Vercel, Netlify, etc.)
• Example: studio-dev.yourcompany.com → Dev dataset, studio-prod.yourcompany.com → Prod dataset
• Each deployment can have different code/schema versions

Note: You can only have one Studio on *.sanity.studio, so additional environments must be self-hosted elsewhere.

Option 2: Use Workspaces as a Dataset Switcher (Most Common)

Most teams actually want schema consistency across environments. The typical workflow:

1. Develop schema changes locally
2. Test thoroughly in your Dev workspace
3. Deploy once to companyname.sanity.studio
4. All workspaces get the updated schema simultaneously
5. Content flows through environments: Dev → QA → Stag → Prod

This ensures your production environment has the exact same schema you tested in development.

Do You Need 4 Separate Projects?

No, definitely not. Separate projects are for completely different applications or clients. One website with multiple environments should use one project with multiple datasets—which is exactly what you have.

The Real Question

Do you need to test Studio code changes in Dev before deploying them to Prod? Or do you just need to separate content between environments?

• Just separating content? Your current setup is perfect. Understand that schema/Studio changes deploy to all workspaces together.
• Need to test Studio changes in isolation? You'll need to self-host separate Studio deployments pointing to different datasets.

For most teams, having consistent Studio configuration across all environments (with only content being different) is actually the desired and recommended approach.