We are excited to bring Transform 2022 back in-person July 19 and virtually July 20 - 28. Join AI and data leaders for insightful talks and exciting networking opportunities. Register today!
Some people who create a database like to start with a clean slate. PlanetScale, which secured $30 million in series B funding with participation from a16z and SignalFire on Wednesday, took a slightly different approach. The company looked at MySQL, liked what it saw, and wrapped all of its enhancements around it. The core is still MySQL, running the standard engines and responding to the standard queries, but the wrapper handles all of the challenges of sharding and replication, making it possible to create what PlanetScale says is a database that can be started in seconds and scaled “indefinitely.”
Developers can create a new database in seconds that will grow as they grow, with no limitations on scalability, the company said. Developers don’t need to know about the environment, such as new cloud zones, cluster sizes and other “DB-centric minutiae.” The new funding round will be used to scale the team globally and to accelerate exposure and adoption of the platform, the company said in a statement.
To find out a bit more about what is built into these extra layers, VentureBeat sat down with Sam Lambert, the chief product officer at PlanetScale. He tells us that among PlanetScale’s innovations are some based on Vitess, a branch of MySQL that arose out of work at YouTube to scale the globe horizontally. Vitess is being used by hyperscalers such as Slack, GitHub, and Square.
This interview has been edited for brevity and clarity.
VentureBeat: What is the biggest goal for PlanetScale?
Sam Lambert: The problem with pretty much every database out there is that no one building databases is thinking about the daily lives of the people that use them. Plain and simple like that. What’s different about us at PlanetScale is we’re getting into what the daily life of the developer looks like and solving the developer problems as they relate to the database.
VentureBeat: What else does the developer want? Or need?
Lambert: Remember the NoSQL movement? MongoDB marketed themselves as a tool where developers don’t have to look after the schemas they hate, the schemas that are hard to manage — the schemas that are hard to deploy and to use. That was all true, all very real criticisms of any relational database.
What we’ve done is allow branching and deploy requests for the schema changes. You can test your schema and then just push it into production. It rolls in as a non-blocking change that’s completely available. It’s as if you’ve just pushed code. It has that ease of use with none of the problems. So, you get the great MySQL goodness with all developer workflows.
VentureBeat: How is this different from just executing a schema change with SQL?
Lambert: An SQL command would lock the table. That would cause you horrible downtime, your application would slow down, your queries would pile up — it would just be a mess.
VentureBeat: So you’re able to roll in the changes with locking up production?
Lambert: With our way it just asynchronously rolls the changes into production — but if we see a burst of traffic we stop. We just pause what we’re doing and we let that traffic finish and then we carry on migrating it. So it’s like a real safe deployment of code, as if it’s just going out to all of these nodes in the database cluster.
So if you want to do a schema change, you have your table. This is your users table. You want to add a column to track, say, whether a user is subscribed. What we do is we create a copy of the users table that’s empty. Just the schema. We add the subscribed column and then we slowly start to nibble data out of the existing one into the new one. We do it in an online way. So it’s just pulling in any new updates that come in. They get applied and we keep nibbling. When they’re both up to date with each other, we do an instant swap and the new column is live in production. The old table is there and we remove it and the new column is live in production. It’s the same way as when you’re deploying applications: You roll the new pods into production. This is a way of doing things the developers are very familiar with.
VentureBeat: Where does Vitess fit in?
Lambert: Vitess is mega-scale, open source database technology built to power YouTube that powers everything from Slack to GitHub, but it’s complex. It’s tricky to maintain. It’s very hard to take something out of a big company and apply it to mid-market or small companies, much less small teams or individuals. It’s built for Google and YouTube. And they’ve done an immense job leveraging it. It’s for database people. It’s for infrastructure people.
VentureBeat: So it’s married with MySQL?
Lambert: With the new PlanetScale, we’ve done that for you. We just completely remove the complexity. We’re your infrastructure people. We’re your database people. We’re meeting you where you are as a developer, where you don’t understand regions and clusters and servers and all of the things that others require you to choose. But we are built on Vitess and have the power of Vitess.
VentureBeat: You used the word branching along there. Is it like a Git repository?
Lambert: Branching is some real magic sauce. So when you get a branch, get a whole new cluster, it’s a completely isolated cluster away from your current one. It’s a completely isolated environment.
VentureBeat: It’s like a staging cluster?
Lambert: No. I’m sure you know, staging environments are a hellish problem for everybody. We are going to kill the concept of staging environments. They are an unnecessary mess. It’s just another burden to maintain with branching.
We say: Don’t have this monolithic staging environment. Just create a branch per code branch. And that itself is a nice environment. Test it out, push it deployed. Then it goes away. Have as many branches as you want. Have 100 per developer if you want. They’re all environments used for staging, but it’s a generational leap past the old world of staging environments.
VentureBeat: On one project we encountered, the boss didn’t want to pay for too many test clusters.
Lambert: Yes, if your project is big, it’s a huge cost to clone them. If you set up a branch, you don’t end up doubling the number of resources you’re consuming. It’s a light, small subset.
VentureBeat: On some projects I’ve been on, the staging and test clusters would start diverging from the production. We couldn’t keep them in sync. The code would run in staging and fail in production or, worse, run in production but fail in staging. We couldn’t test it. We would just cross our fingers and push it into production because we knew staging was munged.
Lambert: The best I’ve seen with staging environments is they take last night’s backup and they restore it onto a separate cluster. So, it’s slightly stale and it’s just fragile.
We don’t do that. We host PlanetScale’s main database on PlanetScale. When we’re adding a feature, we code it up locally and create a database branch. When we’re done, we push the changes and they’re all caught up.
VentureBeat: So, when the databases start to grow, how do you scale?
Lambert: Horizontal sharding. It is supremely elegant and it breaks the problem down into multiple little chunks.. Sharding is much more elegant instead of stacking your machines. If you split your data into shards on commodity machines, you are not only getting the same amount of CPU cores serving reads as you would in a vertical scale environment, you’re getting more serving writes. Replication delay doesn’t become an issue and you just keep growing.
VentureBeat: What happens when the queries need to touch all of the shards, perhaps to build some aggregated report?
Lambert: It does happen. But you can optimize, and we’ll give you ways to do that. There are definitely cross-shard aggregations, and that is a little bit slower. But when you need it, those are all easy optimizations compared to the conventional consistency problem, which is way, way more difficult to wrap your head around.
VentureBeat: Deep in the core of your product is MySQL. Do you use the stock version?
Lambert: The thing is that MySQL is the best. It’s pretty much the premiere when it comes to storage and storage engines. You just can’t beat it. You have access to all the storage engines — we’re compatible with other MySQL folks. But, for a pure storage engine, which is what we use it for, it’s just spot on.
VentureBeat: And what does serverless mean to you?
Lambert: Look at our competitors. They ask you how many nodes you want. How many server CPUs? How many VCPUs? How much IO? Rubbish! We don’t ask for any of that. When you sign up for our product, we create your database. And we will auto-scale for you, because I just do not believe that information is necessary. We’re the experts. We love databases. We build databases. We handle that problem for you.
Moreover, people are excited about our billing model because people really just hate to feel that they’re being charged for things they don’t use. We charge you per row you read and per row you write, and then how much storage you use. That’s it. No VCPUs. No reserved IO. None of that. Just what you consume and what you do. That is a truly service experience that is awesome.
VentureBeat: A name like PlanetScale means you’ve got to be building out a pretty big cloud.
Lambert: We have a support business that is reserved for, basically, these major scale companies that are our customers. And if you go on our front page or see some of those household name logos, that are our customers. But our main destiny lies in our cloud product. All of this magic of branching and schema changes is powered by the cloud. Our roadmap with some of these extremely cool features that are coming needs the cloud. These are features that you could only provide in a cloud service. It’s what people want. Serverless is winning. Serverless is happening.
VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Learn more about membership.