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.

Running a geographically distributed database has a lot of benefits. We see enterprise companies, startups, and students choose distributed databases for reliability, scalability, and even security. But many distributed databases come at a serious cost: latency. Distributing nodes across the globe means your data will need to travel from one node to the other. By its very definition, distribution creates latency. Geo-partitioning your data in CockroachDB makes it easy to minimize that latency. We believe you shouldn’t have to sacrifice the benefits of a distributed database to achieve impressive throughput and low latency. With geo-partitioning, we can minimize latency by minimizing the distance between where SQL queries are issued and where the data to satisfy those queries resides.

If you use a database, at some point you’ll need to modify your schema design. Maybe you need to store new kinds of information. Perhaps you’ll add a field to a table or even need to change a primary key. Regardless of the reason, application requirements tend to change over time - and you’ll need to migrate. We know how important schema modification is, which is why we’ve built zero-downtime online schema changes and online primary key changes into CockroachDB.

About 75 percent of container orchestration is done in Kubernetes. But the popularity of the k8s platform doesn’t mean it’s easy to use in all scenarios. Kubernetes can have a steep learning curve, especially when it comes to managing state and storage. In a recent episode of “The Cockroach Hour”, Director of Product Marketing Jim Walker sat down with Keith McClellan, one of Cockroach’s Solutions Engineers, to chat about the storage and data challenges that you’ll encounter deploying Kubernetes, and how running it with CockroachDB can simplify those challenges.

CockroachDB is designed to deliver bulletproof resilience. But even the world’s safest boat needs to carry life jackets. The same principle applies to your data, which is why we’ve baked a breadth of Backup and Restore capabilities into CockroachDB.

What you build and how you build it should not be dictated by your database. The tools and frameworks that you’re familiar with should be compatible with your database of choice. This is why modern database solutions have implemented support for third part tools like Pony ORM, Hibernate, GORM, jOOQ and others. Developers are beginning to expect to be able to bend the database to their will. And they should - because the flexibility leads to better applications.

When you’re working with distributed systems, data storage and retrieval aren’t as straightforward as they are in legacy monolithic databases. This comes with advantages like resilience and high availability, but it means that performance monitoring of a given transaction can be challenging. Query execution is often an extremely complex web of interactions. Following and analyzing performance bottlenecks in this environment can be difficult and sometimes frustrating to get to the root cause. For this reason we added distributed tracing to our UI and made an accompanying tutorial below.

Back in the bygone era of meeting in person, shaking hands, and clapping enthusiastically for the brave souls who are willing to stand in front of their peers to do live demos, Elasticsearch held a meetup in Boston at Bose headquarters. Chris Chambers, Cloud Engineer at Bose, spoke to the crowd about how his team built a platform as a service using a number of open source tools, including CockroachDB, Elasticsearch, and Kubernetes. Bose really requires no introduction but it bears mentioning that Chris works on a specific team within Bose called Galapagos. The mission of Galapagos is to bring Bose’s software into the 21st century - In the past, Bose was focused on embedded software (software that runs on speakers and headphones) and now that they’ve mastered the art, they have started to modernize so that they can bring cloud-connected experiences to all our devices.

With millions of customers to serve, a major cable company needed to build a virtual customer support agent to scale their customer requests. The app had to provide 24/7 help to users across the United States, and store metadata about customer conversations. The first version of the application was built on Amazon Aurora, in a single cloud region on the east coast of the United States. However, this deployment was vulnerable to failures, and when a networking failure in an AWS region knocked the entire service offline, the team realized that Aurora’s single-master architecture was not sufficient to attain the always-on customer experience they wanted. They needed to explore other options in hopes of migrating the app.