Get help on Discord

Can Multiple Datasets Have Different Schemas?

12 replies
Last updated: Jun 27, 2022
so if i have a project, with multiple datasets, can the datasets have different schemas?
is it as simple as having different branches in git for each dataset? or i guess even just different 
studio
repos?
AI Update

Yes, datasets in a Sanity project can absolutely have different schemas! Since Sanity is schemaless at the database level, each dataset can store completely different document types and structures.

How to Manage Different Schemas

You have a few approaches:

1. Single Studio with Workspaces (Recommended for most cases)

Workspaces let you configure multiple isolated Studio environments in one codebase. Each workspace can connect to a different dataset and display only the relevant schema for that dataset. This is the most maintainable approach because:

  • You share one codebase but have different configurations
  • You can switch between datasets with a dropdown in the Studio
  • All schemas are defined in one place, but you conditionally show what's relevant per workspace

The catch is that all possible schemas need to be defined in your Studio config, and you'll want to use conditional desk structures to only show schema relevant to the active dataset.

2. Separate Studio Repos

You can totally have different Git repos (or branches) with completely different Studio configurations pointing to different datasets in the same project. This gives you:

  • Complete schema independence
  • Simpler individual codebases
  • More deployment overhead (you'll need to deploy each Studio separately)

If you go this route, you'd just configure each Studio with a different dataset value in sanity.config.ts but the same projectId.

3. Git Branches (Less Common)

Using Git branches for different datasets is possible but generally not recommended for production setups. It works better for temporary scenarios like testing schema changes before applying them to production.

Which Should You Choose?

  • Workspaces: Best when datasets share similar structure or you want centralized management
  • Separate repos: Best when datasets are completely different projects (different brands, products, etc.) or when different teams need full independence
  • Branches: Best for development/staging/production workflows with the same schema

The multi-tenancy guide has great examples of how companies use these patterns in practice!

You can have as many Studios as you'd like for a given project and since the backend is schemaless different datasets can have completely different content models.
The issue arises when you try to have datasets with different schema shown in a single project. You need to do something like set up a conditional desk structure to only show schema relevant to the current active dataset. Note that your 
schema.js
would need to have all possible schema defined in it though!
hmm k. so maybe i need to go refresh on all the different parts of how sanity is put together.
but what would be the point of multiple datasets if they all have the same schemas?

im trying to setup a project with my staging and production datasets.

but if i make a schema change and deploy it on staging to test. won't that break production dataset. i understand the data will be available without breaking, but if a content writer goes into the studio, they will see errors about the data not being correct, no?)
Speaking for myself, I think one point would be seeing what effects certain actions would have on the live data without the data being live.
Maybe you'd like to run a script that iterates over documents to substitute fields or change values before/after changing a schema in place, maybe you want to test locally writing new components that patch the data in a specific way but don't want the results to possibly botch everything if you don't get it perfect right out of the gate, etc.
but what would be the point of multiple datasets if they all have the same schemas?
Many reasons. Access control, separation of concerns, multi-tenant Studios.

but if i make a schema change and deploy it on staging to test. won't that break production dataset. i understand the data will be available without breaking, but if a content writer goes into the studio, they will see errors about the data not being correct, no?)
Publishing changes to a staging dataset wouldn't have any effect on a production dataset. They're separate datasets.
Publishing changes to a staging dataset wouldn't have any effect on a production dataset. They're separate datasets.
but if i run 
sanity deploy
it will change the schema for both studios, right?
Ah, those are two different things. If you are using the same Studio for both staging and production, then yes, deploying your schema changes would effect production. However, if you're just changing content in a separate dataset, no, it will not effect the other dataset unless you migrate those changes.
right, ok thanks for clarifying
This guide will walk you through using spaces within a single Studio to switch between your production and staging datasets. That may be enough for your use case here!
so if i'm building a site for my company and we want
dev -> staging -> production datasets/schema

we will need multiple projects under our organization:


MyCompanySite - Dev

MyCompanySite - Staging

MyCompanySite - Prod

and then any schema changes would need a 
sanity deploy
ok thanks, i will take a look
Got it! So you will want to use spaces to switch between datasets. In terms of your Studio, I would go ahead and use separate branches for each dataset so that you can merge changes as you see fit. Then I'd only run 
sanity deploy
from the 
prod
branch.
Note that you'd need to upgrade to the Team plan to get access to three datasets, though.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?