Get help on Discord

Where is Sanity's data physically located? Latency concerns for 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! Your concern about latency from Australia is totally valid. Here's the situation with Sanity's data residency:

Primary data location: Sanity's Content Lake stores your data in Belgium (specifically in St. Ghislain, using Google Cloud infrastructure). This is currently the primary data center location for most Sanity datasets.

But here's the good news for performance: Sanity uses a highly optimized global CDN with a Point of Presence (POP) in Australia. The CDN is specifically tuned to minimize latency concerns through several smart strategies:

  1. Stale-while-revalidate: The CDN serves cached content while updating in the background, so even when editors publish updates, end users typically never experience cache misses during sustained traffic
  2. Selective cache invalidation: Only published documents trigger cache updates (not drafts), so your journalists working throughout the day won't constantly invalidate the cache
  3. Global distribution: Query results are distributed worldwide across the CDN network

Real-world Australian experience: Sanity has multiple large customers in Australia already, and according to Sanity's CTO, they haven't received complaints about performance issues. The CDN typically delivers 15-20ms response times for cached queries.

What about uncached queries? If you're doing real-time queries directly to the origin (bypassing the CDN), yes, you'll see that ~350-700ms round trip due to the speed of light between Sydney and Belgium. However, for most production use cases with sustained traffic, the CDN architecture handles this well.

Future plans: Sanity has mentioned plans to offer selectable data regions in the future, but it's not currently on their immediate roadmap since it hasn't been a critical issue for their existing Australian customers in real-world usage.

Bottom line: If you're building mostly static sites (Gatsby, Next.js with SSG/ISR) or sites with reasonable traffic that keeps the CDN warm, latency shouldn't be a blocker. The CDN architecture is specifically designed to handle your high-frequency publishing scenario with multiple journalists.

Show original thread
25 replies
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?