We have all experienced the limitations of the relational model and the operational burden of running a large fleet of databases. At PlanetScale, our vision is to build a database developers love without compromising on any of the database features required to run an application that can scale up as needed. To achieve this, we knew we needed a database engine with a track record of powering companies that deal with humongous amounts of data and traffic. That’s why we chose Vitess.
The Power (and Promise) of Vitess
Vitess was created at YouTube over 10 years ago to solve the massive scalability problem that YouTube was facing. Over time, other companies with similar scalability needs adopted Vitess because its power, flexibility and scale outpaced other solutions. This means that Vitess has been powering multiple large-scale production systems for several years now.
Enterprise-grade scalability that can support companies like YouTube and Slack is a key benefit of Vitess. However, there are valuable advantages that Vitess provides to early stage companies. Building on a solid foundation means that you no longer have to worry about needing to migrate to a different data platform once hypergrowth materializes.
Vitess provides an abstraction over MySQL that adds missing functionality while retaining the benefits of a relational database and allows you to automate failure detection and recovery. In addition to this, Vitess provides safety features like automatic row limits, hot row protection, query consolidation and non-blocking schema changes which reduce the likelihood of high load bringing down the database. These are all features that vanilla MySQL cannot and does not provide.
The combination of high-availability and safety means that even a small-scale database deployment can benefit hugely from deploying Vitess over MySQL.
Adopters of Vitess like Slack and JD.com have seen the benefits of a highly-available relational database system. While exact numbers from JD.com are not available, Slack runs 100% on Vitess and their uptime numbers speak for themselves.
A word about Sharding
Sharding is one of the superpowers that comes with Vitess. Vitess allows you to split out the data into multiple shards and have a unified view across them. In addition to this core capability, the maintainer team at PlanetScale has built out the underlying infrastructure in a way that facilitates many more workflows, including but not limited to:
- Materialization of data while redacting sensitive information
- Moving tables around to balance database size
- Migration (copying) of data from one system to another
- Re-sharding with a different sharding key if the initial choice turns out to be sub-optimal
While Sharding is not something we expect early adopters of PlanetScale to need right away, it will be available to use as these systems grow.
All this sounds great, but..
While Vitess reduces the operational burden of managing a large fleet of MySQL instances, it comes with its own operational complexity. There are the typical issues associated with managing any large software deployment ranging from version upgrades and incompatibilities to managing the hardware (or cloud provisioning) required to run Vitess in production.
In addition to these, there is a shortage of Vitess experts who can run such a system in production. There is a steep learning curve associated with acquiring proficiency in Vitess and it is quite likely that many of the people who try it out never end up going into production for this reason.
At PlanetScale, we have set our minds to solving the problem of providing the easiest-to-use database possible that is designed around developer needs. There are two main strands to this theme.
Ease of adoption
Creating a new database for development purposes should be dead simple and take no more than 10 seconds. The PlanetScale onboarding experience is focused on making this as seamless as possible. This also means that we need to be able to deploy a functional Vitess cluster in that short time period and that is just what we did. Vitess’ pre-existing compatibility with Kubernetes facilitated this greatly with the addition of some secret sauce from PlanetScale.
Ease of use
We need to be solving real problems that real developers have. A particular pain point that comes up repeatedly is the difficulty of making schema changes to a running system. The fear of hurting the production environment while pushing these updates has led to schema change processes that can take up to hours, days, or weeks. This slows down the pace of innovation and creates frustrating hurdles for developers.
PlanetScale’s database branching and Deploy Requests make schema changes fast and easy. Developers can ship product updates without having to worry about locking or causing downtime. The non-blocking schema change functionality is a core feature of Vitess and we have built on top of that to automatically check for potential conflicts before a schema change is deployed.
Building on PlanetScale
The combination of PlanetScale and Vitess allows developers to quickly provision a database to use with an application. Once the application is in production, schema changes can still be made in a safe, asynchronous manner without affecting system availability. The database is highly available and any failures are handled by the service. As the application scale grows, Vitess’ sharding capabilities can be leveraged to maintain performance without downtime. All of this functionality provides you with the foundation to start building and scale indefinitely.