Sanity pricing concerns: API usage costs vs fixed-price CMS alternatives

12 replies
Last updated: Jan 28, 2026
i’m evaluating CMSs for a project and i like the look of sanity but am a bit wary of the pricing.
specifically, i’ve seen various discussions in here about people unexpectedly burning through all their API usage due to e.g. the studio making lots of API calls when editing, and when i checked the stats for my test account a while ago they were definitely much closer to the usage limit than i would expect, given the small amount of testing i had done

i know its tricky as every site is different, but was wondering if anyone could say whether they were surprised by the costs of sanity compared to what they expected? basically i am comparing to fixed price solutions like Storyblok and Dato, but its hard to advise the client without really understanding how much usage editing specifically will generate
AI Update

I completely understand your concern about Sanity's usage-based pricing versus fixed-price alternatives. This is a really common question, and you're smart to investigate before committing a client to the platform.

The Reality of Studio Editing and API Usage

First, the good news: Studio editing is rarely the main cost driver in Sanity projects. The Studio does make API calls when editing - it uses listen queries for real-time collaborative updates and sends mutations when saving - but in practice, these editing operations typically represent a small fraction of total API usage unless you have dozens of editors working constantly.

Where Usage Actually Comes From

The surprise costs people encounter usually come from:

  1. Frontend queries not using the API CDN - This is the critical piece. The API CDN provides unlimited rate for cached content. If your public website queries use useCdn: true, that traffic won't count against your API request limits.

  2. Poorly optimized queries - Inefficient GROQ queries running too frequently on your frontend

  3. Webhooks or automation - If these create loops or run excessively, they can consume API requests quickly

Understanding Sanity's Pricing Structure

According to the current pricing page, the Growth Plan is $15 per user/month and includes features like private datasets, AI Assist, Content Releases, and pay-as-you-go for higher usage. There's also an "Increased Quota" add-on for $299/month that extends limits to 50k documents, 5M API CDN requests, 1M API requests, 500GB bandwidth, and 500GB assets.

The Free plan has much tighter limits, which is probably why your test account usage surprised you. The Free plan is really only suitable for very light testing or hobby projects.

Comparing to Fixed-Price Solutions

Versus Storyblok and Dato's fixed pricing:

Sanity's advantages:

  • No artificial limits on content types, locales, or schema complexity
  • The API CDN means properly cached frontend queries essentially don't count
  • You only pay for actual usage beyond base limits
  • Much more flexibility in how you structure content

The tradeoff:

  • Less predictable costs if you don't implement caching properly
  • Requires monitoring, especially during initial launch
  • Need to be more technical about optimization

Practical Recommendations for Your Client

  1. Budget for the Growth plan - The Free plan isn't realistic for production. Growth plan gives you the features you'll need.

  2. Implement proper caching from day one - Use useCdn: true for all public-facing queries. This is absolutely critical and will keep the vast majority of your traffic off the metered API requests.

  3. Monitor during soft launch - Set up usage monitoring in Sanity Manage and watch patterns during a soft launch period.

  4. Optimize queries - Use GROQ projections to fetch only the data you need. Avoid overfetching.

  5. Take advantage of the Growth Plan trial - New projects get a free trial of Growth Plan features, which gives you access to all the features without automatic charges so you can test realistic usage.

Real-World Usage Patterns

From what I've seen in the community:

  • Studio editing typically accounts for a small percentage of total API usage
  • A properly optimized production site with good caching often stays well within plan limits
  • Problems arise when developers don't implement the API CDN properly or have inefficient queries

Bottom Line

Sanity's costs are very reasonable if you implement caching correctly. For most projects with proper optimization, Sanity ends up cost-competitive or cheaper than fixed-price alternatives, especially when you factor in the flexibility and lack of artificial limits.

However, you're right that it requires more technical diligence than a truly fixed-price solution. If your team isn't comfortable with that optimization work, or if cost predictability is absolutely critical, a fixed-price CMS might be safer.

The key question: Does your team have the technical expertise to implement proper caching and query optimization? If yes, Sanity is likely a great choice. If no, the usage-based pricing could be risky.

I'd recommend:

  1. Start a new test project and use the Growth plan trial (free with no automatic charges)
  2. Build a realistic prototype with proper caching (useCdn: true for public queries)
  3. Monitor actual usage patterns in Sanity Manage
  4. Extrapolate costs based on expected production traffic

This will give you much more accurate data than testing on the Free plan, and help you make a confident recommendation to your client. The trial lets you test without risk, and you'll see exactly how your actual usage patterns translate to costs before committing.

Show original thread
12 replies

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.

Was this answer helpful?