Get help on Discord

Discussion on latency concerns for Sanity.io data storage in Australia

25 replies
Last updated: Feb 17, 2021
Where is sanity's data located? As in, physical city/region? We're located in Australia and just concerned about latency if it's not stored in a local datacentre.
AI Update

Great question about data location and latency! I totally understand the concern when you're based in Australia.

Primary Data Storage Location

Sanity's Content Lake data is stored in St. Ghislain, Belgium, using Google Cloud Platform infrastructure (specifically Google Compute Engine and Google Container Engine). Currently, you can't select a different region for your primary dataset storage, though Sanity has mentioned plans to offer regional data residency options in the future.

But Here's the Good News About Latency

While the primary storage is in Belgium, Sanity has specifically optimized for global performance, including Australia:

  1. API CDN with Australian POP: Sanity's API CDN includes a point of presence (POP) in Australia, which dramatically reduces latency for content delivery. The CDN serves cached content with unlimited rate limits.

  2. Stale-While-Revalidate Strategy: This is a game-changer. Sanity's CDN uses a "stale-while-revalidate" approach, meaning it serves cached content to users while updating in the background. Even if your editors are frequently publishing, end users typically never experience a cache miss during sustained traffic.

  3. Real-World Australian Performance: Sanity has multiple large customers in Australia who haven't reported latency issues. One Melbourne-based developer in the community thread mentioned they don't notice lag in local dev and have been building with Sanity for over a year.

  4. Where CDN Really Helps: For most use cases, especially if you're building with static site generation (Next.js SSG/ISR, Gatsby, etc.) or caching renders on your side, the CDN handles the majority of your traffic from the Australian POP with 15-20ms response times.

Performance Considerations

  • Uncached queries: If you're making direct API queries that bypass the CDN, you'll see the Belgium roundtrip (350-700ms as noted by one Australian user testing). However, with sustained traffic, the CDN's stale-while-revalidate keeps content fresh without users experiencing those delays.
  • Studio editing: The Sanity Studio is coded to hide latency by recording edits locally and reconciling with the server behind the scenes, so editors won't feel the distance.

Bottom Line

For most Australian use cases, especially with the API CDN's Australian POP and smart caching strategies, latency shouldn't be a dealbreaker. If you're concerned about your specific architecture, I'd recommend doing some real-world performance testing with sustained traffic patterns rather than isolated queries, as the CDN behavior is quite different under actual load.

Sanity uses Google Cloud. https://cloud.google.com/customers/sanity
Looks like there are locations in Sydney with plans for Melbourne.
https://cloud.google.com/about/locations
Thanks for the info. Though doesn't mean they actually make use of the Sydney datacentre. Couldn't see anything there that mentions which one they use. Obv the CDN will help, but initial requests would still be a concern.
Those are good points. I don't know enough about server load balancing to be able to comment, though I did find that they do use use the Australia location: https://www.sanity.io/docs/api-cdn (bottom of the page).
Right that's for the CDN, which is great to know, but not necessarily for the dataset's origin.
If you build static sites it won’t matter, the data is only requested at build time. So Gatsby, Gridsome etc is fine or Next with SSG/ISG.
I’m based in Melbourne, built with Sanity for over a year. I haven’t run any live queries to Sanity in any sites so far so can’t say from a user’s perspective. But in local dev I don’t notice a lag, though that’s purely anecdotal. So it depends if you will request data on request from visitors.
We store data in Belgium, but full cdn with pop in Australia for speed on cdn. (Over time we also have plans to distrivute where data is located.)
Ok, thank you!
user S
Thanks. It'll be about half static half dynamic.
You can still use the cdn although it's not a static site
Yeah we definitely will opt for the CDN. Not sure if I remember correctly, but I recall reading that the whole CDN cache is purged whenever there's any document update. Is that right? Or am I way off there?We have a team of about 10 journalists that are constantly working throughout the day and a night team, so I imagine even if we're using the CDN it'll have to hit the origin fairly often. Unless I'm way off on that cache purging? If it's specific documents only that are purged that'd change things a lot.
Tbh I haven't run latency testing yet, but the speed of light puts an absolute minimum 100ms round trip for Sydney <> Belgium.
Not any document update. Only non-draft. People would mainly work in drafts so should be when you publish.

https://www.sanity.io/docs/api-cdn
👍 Thanks!
People would mainly work in drafts so should be when you publish.
the people I know hit publish every other second 🙃
AFAIK Sanity only has the 1 data center (either US or EU) and the published content is cached across the CDN but not the queries themselves? Most of the CMS offer just the 1 datacenter though 🙁
user A
regarding what you said above:
(Over time we also have plans to distrivute where data is located.)
Do you know what a timeline for this would be? If it's not on your current timeline do you have a rough idea of where it'd be priority wise? Would it be months? A year? More than that?
So far I haven't found any hosted CMS (that didn't have some other dealbreaker) that lets us choose a data store location. Unfortunately this probably means I'll have to go with some self-hosted solution for the time being, such as strapi.
Hi User, its not something imminent (not sure how much I can say, will do some checking internally)Is there a legal/regulatory reason you cannot use a hosted service, or are you sceptical of performance (and if so what performance aspect?) We have multiple large customers in Australia alreaday.
Thanks for the reply User. 100% performance related. I'm not sceptical of hosted solutions in general at all, if it were hosted in Australia (again for performance reasons) I probably would have signed up for the Advanced plan already. (though we would like SSO and custom domains so we'd probably have to enquire regarding enterprise)One query is reliably 350ms-700ms roundtrip. Though that's without the CDN (with CDN is 15-20ms) as the majority of our queries will be uncached due to the frequency of our team publishing articles vs the number of articles we have. We'll be caching renders on our side where possible so the CDN won't play a big role for us as far as I can see.
If we need to have 2 queries on a page that's going to make it fail the TTFB core web vital. 1 query potentially has the ability too.
We may still sign up but we'll have to rearchitecture a lot of stuff. Knowing that there may be a Sydney based data origin option in the future would make that easier to bare for a bit.
Our CDN is also tuned to the teeth. We serve stale records for a couple fractions of a second while we reload new content behind the scenes (aka “stale while revalidate”), so even if your editors keep smashing that publish button, end users will typically never see a single miss, given that you are seeing generally high traffic.
The studio is also coded to hide any lag-related problems, basically recording your edits, then reconciling them with the server behind the scenes carefully merging them with the concurrent changes of other people. We have big clients in Australia and have afaik never heard a complaint.

We are moving towards you being able to also choose the primary location of your datasets, but it turns out that it has not been very important to anyone in real use, so it is not top of our lists.
If you are validating page speed in a super calm environment your cache-records may be evicted after an edit, but this should not happen during sustained traffic (if it does, let me know, but we power some incredibly high traffic sites across another huge pond and have spent plenty of time getting this tuned right).
Thank you
user S
that's amazing information to know. Wasn't aware you implemented SWR, that's super encouraging. Yes I've just been testing in my own environment that only I would be accessing, so no sustained traffic. I'll take a deeper dive into some performance testing that's more reflective of our real world usage. Cheers!
Err ... no problem 😅
haha sorry!
user A
i mean't 😅
It’s nice to be appreciated 😂
😉

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?