Dealing with distributed database performance issues? Let’s talk about CDNs. Even though they’re at different levels of your tech stack, distributed databases and content delivery networks often share a similar goal: improving the availability and speed between your service and your user.

I once went to a website that had “hours of operation,” and was only “open” when its brick and mortar counterpart had its lights on. I felt perplexed and a little frustrated; computers are capable of running all day every day, so why shouldn’t they? I’d been habituated to the internet’s incredible availability guarantees. However, before the internet, 24/7 high availability wasn’t “a thing.” Availability was desirable, but not something to which we felt fundamentally entitled. We used computers only when we needed them; they weren’t waiting idly by on the off-chance a request came by. As the internet grew, those previously uncommon requests at 3am local time became prime business hours partway across the globe, and making sure that a computer could facilitate the request was important.

Kubernetes adoption has massively accelerated, leading the way to a new, cloud-native approach to building and delivering the software that businesses need to make users happy and employees successful. Slow and heavy lifting has been replaced with interchangeable, self-contained software objects that can be configured by a simple configuration and scaled through automated replication. If an object fails, it is replaced. To deliver new software, objects are replaced while still in motion.

Many databases -- including Amazon Aurora and CockroachDB -- claim to be "global." While there is no official definition of the term "global database", it deserves to be unpacked. For those who prefer to watch or listen, we explore Aurora's architecture in depth during this webinar: "CockroachDB vs Amazon Aurora: Battle of the Cloud Databases". ### What is a global database? A global database promises global capabilities. At a bare minimum, it should satisfy these three requirements:

Since January 28, 2020, the EU has issued $192 million (€158.5 million) in fines for GDPR (General Data Protection Regulation) violations (DLA Piper, Engadget). Although companies have had years to become fully GDPR compliant, compliance is not easy. After the GDPR took effect in 2018, we had a conversation with Cockroach Labs co-founder and CEO Spencer Kimball on the topic, who detailed the nuances of the law and what companies should do to comply within the context of their databases. This is a recap of that conversation from 2018.

If you’re reading this, you’re surely familiar with the arguments for high availability: services are only useful when they’re online. Unavailable services not only lose money, but also deteriorate your credibility in customers’ eyes. This could lead to immeasurable costs to your company in the future. Given that CockroachDB got its name because of its ability to survive failures, we thought we would cover some architectural considerations when building high availability services on top of Cockroach.

Many inky, black pixels have been rendered over GDPR. It dramatically shifts the landscape for businesses with any EU users, so there are a lot of questions about what it means in general, as well as what it takes to actually comply with it. In this post, we’ll cover how Cockroach Labs conceives of GDPR’s major tenants (known as Data Subject Rights, which translates to “things you must do for your users”), as well as some considerations as to what it actually means for your company’s database.

Over the past year, Kubernetes––also known as K8s––has become a dominant topic of conversation in the infrastructure world. Given its pedigree of literally working at Google-scale, it makes sense that people want to bring that kind of power to their DevOps stories; container orchestration turns many tedious and complex tasks into something as simple as a declarative config file.

In tech, we hear the importance of “scale” all the time. People plan for it, try to work around not having it, and build companies to help others achieve it. But when it comes time to scale something yourself or integrate a scalable solution with your app, it’s difficult to find practical guides to help you understand what it takes. Why’s that? Well, it’s kind of hard. Actually scaling a database beyond a single availability zone takes considerable planning and engineering investment––but that being said, it’s an incredibly powerful tool to delight your users with low latencies and high availability.