Sanity scalability: Migrating 10,000 static pages - build times & limitations?

Sanity can absolutely handle a website with 10,000 static pages - this is well within the platform's capabilities. Let me address your specific concerns about scalability, build times, and share some practical tips.

Dataset Size & Performance

Sanity is built to scale. The platform handles datasets with tens of thousands to hundreds of thousands of documents without issues. Your 10,000 pages is a moderate-sized dataset that should perform very well.

Key scalability features:

• API CDN with unlimited rate: Sanity's API CDN provides unlimited requests for cached content with global distribution, meaning queries stay fast regardless of dataset size
• Optimized queries: Well-written GROQ queries maintain consistent performance as datasets grow. For example, filtered queries like *[slug.current == "my-page"] return at the same speed whether you have 100 or 100,000 documents
• Efficient indexing: Sanity uses internal index structures that optimize common query patterns

Build Time Considerations

Build times depend more on your frontend framework and build strategy than on Sanity itself:

Modern approaches to avoid long builds:

1. Incremental Static Regeneration (ISR): Instead of building all 10,000 pages at once, use ISR with Next.js to generate pages on-demand and revalidate them periodically. This means initial builds are fast, and pages are generated as needed.

2. On-Demand Revalidation: Only rebuild pages when content actually changes, not your entire site

3. Selective builds: If using traditional SSG, consider building only changed pages using your framework's incremental build features

Build time optimization tips:

• Reduce the amount of data returned in queries by selecting only required fields
• Avoid resolving unnecessary references during builds
• Consider parallelizing queries for different content types

Migration Strategy

For importing 10,000 pages, Sanity provides robust tools:

Dataset Import/Export:

• Export/import via CLI using NDJSON format
• Handles documents and assets efficiently
• Can process thousands of documents quickly

# Import your migrated content
sanity dataset import content.ndjson production

Tips for smooth migration:

1. Export before migration: Always backup your current dataset before running migrations
2. Batch processing: Use the CLI's sanity exec command to run custom migration scripts
3. Test on staging: Use separate datasets (dev/staging/production) to test migrations safely

Rate Limits & API Considerations

Good news here: cached content has unlimited rate limits on the API CDN. For uncached requests, Sanity's limits are generous and designed for production workloads. Most sites with 10,000 pages won't approach these limits.

Practical Tips for Your Scale

Query optimization (from Sanity's high-performance GROQ guide):

• Use filtered fetches: *[_type == "page"] is optimized
• Avoid deep pagination with slicing; use cursor-based pagination instead
• Stack filters to reduce search space: *[_type == "page" && defined(slug)]

Content structure:

• Keep your schema simple and focused on what you need
• Use references thoughtfully - avoid over-fetching related data
• Consider denormalizing frequently-accessed fields

Real-World Performance

While specific case studies aren't readily available in the docs, Sanity's architecture is designed for enterprise scale. The platform includes features like:

• Content Lake with global replication
• Automatic scaling of infrastructure
• Enterprise plans with enhanced performance guarantees

Why Sanity Is a Good Fit

For your use case of migrating 10,000 mostly-text pages from manual maintenance:

✅ Scalability: Proven to handle much larger datasets
✅ Performance: Fast queries with CDN caching
✅ Migration tools: CLI and APIs for bulk operations
✅ Flexible builds: Works with ISR, SSG, or SSR strategies
✅ Content modeling: Structure your 10,000 pages however makes sense
✅ Real-time updates: Content changes propagate quickly without full rebuilds

The main consideration is choosing the right build strategy for your frontend - ISR or on-demand generation will give you much better performance than trying to statically generate all 10,000 pages at build time.