Refactoring organizational tool with new pricing scheme

I understand your frustration with the pricing changes - this is definitely a challenging situation when your architecture was built around a specific feature set. Let me help you think through your options.

First, I want to clarify something important: while datasets are commonly used for staging environments, the official datasets documentation actually does list additional use cases beyond just dev/staging/production. The docs specifically mention:

• Multi-tenant applications: "Different datasets can be used to separate content for different clients or tenants within a single project"
• Testing and validation: For bulk migrations and building integrations

So your original approach of using datasets for regional separation wasn't necessarily contrary to Sanity's intended use cases. However, you're right that the pricing changes indicate a shift in how Sanity is positioning the platform.

Your Options

Option 1: Separate Projects Per Region

Creating separate projects for each region is a legitimate architectural pattern, especially given your regions are truly independent. This gives you:

• Complete isolation - stronger than datasets
• Independent billing and usage tracking per region
• Simpler queries - no filtering needed
• Natural content boundaries preventing cross-region mistakes
• Flexibility - different regions can evolve independently

Implementation approach:

• Keep a single codebase for your Studio configuration
• Use environment variables to point to different project IDs
• Deploy the same Studio to different URLs, or use Workspaces (available on Growth+ plans) to switch between projects in a single Studio interface
• Automate deployments with CI/CD to avoid manual management overhead

This is similar to how agencies manage multiple client projects from shared codebases.

Option 2: Single Dataset with Region Filtering

Stay in one project and add a region field to every document type:

Studio-side:

• Use custom desk structure to create region-specific views
• Add default region values using document actions
• Implement GROQ filters in all document lists: *[_type == "article" && region == $currentRegion]
• Use Workspaces (Growth plan+) to create distinct workspace views per region
• Implement document-level permissions to prevent accidental cross-region edits (note: content resources for filtered permissions require Enterprise plan)

Frontend:

• All queries need && region == "your-region" filters
• More complex but keeps everything in one Content Lake

The challenge: This requires significant refactoring and ongoing discipline. Without Enterprise plan features like content resources, you can't truly enforce region boundaries at the permissions level.

Option 3: Contact Sanity About Your Use Case

Given that you have multiple regions and your original architecture made sense for your needs, I'd strongly recommend reaching out to Sanity sales to discuss your specific situation. The Enterprise plan supports a custom number of datasets, and they may have solutions or pricing structures that aren't publicly documented for multi-region setups like yours.

My Recommendation

Given your regions are truly independent (different content, different editors, different sites), I'd lean toward separate projects, but with an important caveat: talk to Sanity first about your use case before committing to a major refactor.

The separate projects approach aligns well with your isolation needs and keeps implementation simple, but if you have many regions, the cost implications might be significant. Sanity may have enterprise solutions or custom arrangements that could work better for your specific scenario.

If separate projects is the path forward, the deployment overhead is manageable with automation, and you're still working from a single codebase - just different configuration pointing to different project IDs.

Hope this helps you navigate the transition!