Concerns about Sanity.io data location and latency for Australian users

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.

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!

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 🙁

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 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!

i mean't 😅

It’s nice to be appreciated 😂