Introducing New Cloud Regions and How We Choose Them

We are pleased to announce that Timescale has launched the ability to create services in four new regions: 

• 🏴󠁧󠁢󠁥󠁮󠁧󠁿 London (eu-west-2)
• 🇯🇵 Tokyo (ap-northeast-1)
• 🇧🇷 São Paulo (sa-east-1)
• 🇨🇦 Canada Central (ca-central-1)

Users can now enjoy the full suite of Timescale Cloud features in these regions! 

Some readers might be curious why we choose the regions we do and why we don’t just offer as many regions as possible. After all, we get requests from customers about support for their closest region every day. Regions represent an easy way for us to bring TImescale to more users around the world. To answer why we are deliberate about the regions we support, let’s dig into what a Timescale Cloud region entails. 

How we create a new cloud region

Our multi-region cloud offering runs on a hub-and-spoke model. We have a central cluster (which is, of course, highly available, multi-AZ, and fault tolerant with precise disaster recovery mechanisms) that manages certain control plane elements necessary for all other regional clusters. This includes inter-region networking/communication, certain metadata services, and single-pane-of-glass views into metrics across our cloud and other observability elements. 

Beyond those central control plane features, we try to keep regional clusters as independent and self-sufficient as possible, localized to a private network in the region they operate in. This carries many benefits, including:

• Speed: All of the crucial database management operations we perform happen as close to the database as possible, with orchestration services living in the same region that their databases live in. This ensures that our system is able to make the changes necessary for smooth database operations with as little latency as possible. 
• Compliance: By ensuring customer data never leaves the region the customer is operating in, we ensure we are complying with various data governance frameworks like GDPR. 
• Blast radius reduction: Databases can continue normal operations even when our central region experiences degraded performance. They are also not exposed to turbulence in other regions. This significantly limits the blast radius of failures on the central control plane and ensures smooth operations for our customers even when we encounter trouble on our home turf. 
• Operational flexibility: With each region its own standalone component, we can choose what we deploy and when to each region. This helps us roll out certain complex functionality in a phased manner, quickly release hotfixes for regions experiencing problems, and debug issues in a controlled manner. 

With those benefits come significant overhead. Specifically, our system runs on Kubernetes, and in order to achieve this independence for each region, we have to run a Kubernetes control plane per regional cluster. To achieve the performance, high availability, and redundancy that we require from our clusters, this entails a significant amount of compute resources. This control plane layer also includes various pieces of software that facilitate cross-network communication where needed, which demand additional overhead. 

Additionally, the various orchestration services for managing the lifecycle of Timescale instances require some overhead just to run. And our observability stack—logs, traces, metrics, internal statistics we trace using tools like eBPF—has a decent footprint per cluster. 

Finally, every regional cluster needs a bit of “headroom.” This gives us buffer capacity for when regions experience unexpected spikes in growth and helps ensure that user instances can get provisioned nearly instantly. The last thing we want is for a customer to get excited about trying out Timescale and then wait way longer than expected for an EC2 instance in their region to get spun up. This is a built-in extra cost per region, but we believe it’s worth it for the engineering magic of the initial Timescale cloud experience. 

How we choose cloud regions

With that context, let’s return to the four regions we’re launching today. Why did we choose them? We weighed the overhead discussed earlier against the amount of interest we have for those regions. Our indicators of interest include requests directly from our Timescale Cloud console (anyone can, and is encouraged to, do this in the service creation dialogue in the regions dropdown), sales discussions with customers, and regional analysis of our customer base. 

Based on that, we’re very confident that we will be serving a thriving new group of customers in these regions, and the value we get from that will instantly outweigh the operational overhead of running these new regions. Hopefully, some of what we’ve outlined above will illustrate that we take serious care in running each region and ensuring it provides as robust of a Timescale cloud experience as possible. 

So, hi, oi, kon’nichiwa! Welcome to Timescale!

To check out all our available regions, head to our docs. If you haven’t tried Timescale yet, sign up for a free trial today.