Frequently Asked Questions

  • What is PlanetScale?

    PlanetScale was founded in 2018 by the creators of Vitess - an open source project born at Youtube and hosted by CNCF that runs very large OLTP workloads at companies such as GitHub, Slack and Square. PlanetScale provides enterprise support for Vitess and offers a massively scalable multi-cloud transactional database-as-a-service using Vitess and Kubernetes. PlanetScale is backed by a16z and SignalFire and is based in Mountain View, CA.

  • What does PlanetScale offer?

    At PlanetScale, we are building the operational scaffolding that makes it easy to deploy and operate Vitess clusters at scale. We offer the following paid products and services:

    • PlanetScale CNDb: a multi-cloud database based on Vitess
    • Cluster Manager Software Licenses: (we use PlanetScale Cluster Manager to run our DBaaS)
    • Open Source Vitess Support
    • Professional Services & Training

    Take a closer look here at what we do.

  • What is Vitess?

    Vitess is an open source project born at Youtube and hosted by CNCF that runs very large OLTP workloads at companies such as GitHub, Slack and Square. YouTube used Vitess to run MySQL databases in Borg, the blueprint for Kubernetes, which makes it ideal for running MySQL databases at scale under Kubernetes. Companies like Hubspot and trust their production traffic to MySQL databases running under Vitess on Kubernetes. Vitess is a highly scalable cloud native database.

  • What’s PlanetScale’s relationship with Vitess?

    PlanetScale is committed to Vitess as an Open Source Project. PlanetScale CTO and Co-Founder, Sugu Sougoumarane, is the chief developer and community leader for Vitess. Many PlanetScale engineers contribute to the Vitess Project regularly.

    We are committed to keeping the query serving path (based on Vitess and MySQL) open-source so that our customers will never have to fear vendor lock-in.

    At PlanetScale, we are building a multi-cloud, Kubernetes powered database-as-a-service for Vitess. We offer our customers the tools and support they need to migrate into Vitess and move to the cloud.

  • Why should I use PlanetScale CNDb?

    PlanetScale CNDb is the perfect solution for companies that:

    • Want to store transactional data without having to worry about scaling.
    • Want to move to Kubernetes on premise or on public cloud.
    • No longer want the pain of managing database clusters.

    Let the co-creators and maintainers of Vitess help you get the most out of Vitess.

  • How is a relational database such as MySQL or PlanetScale CNDb different from a key value store?

    Key-value stores allow you to scale your data horizontally by adding more nodes to your database. But, they lack in a number of other features, such as SQL protocol compatibility, secondary indexes, joins, and transactions.

    PlanetScale CNDb allows you to scale your relational data like a NoSQL database; it scales horizontally like a key-value store, but without sacrificing relational features. The PlanetScale CNDb supports out-of-the-box globally scalable, multi-cloud deployments.

  • How does PlanetScale CNDb scale, if it uses a relational database?

    PlanetScale CNDb uses horizontal sharding for scaling MySQL databases. Applications connect to the Vitess databases using a stateless proxy that supports MySQL binary protocol and a full SQL parser (vtgate), which allows the application to perceive the horizontally sharded database cluster as if it were a single monolithic database. So while your application continues to run as if you were using just one database, the data can be spread across numerous database clusters (also called shards).

  • What is sharding? Why does it matter?

    Sharding is a type of database partitioning that splits very large databases into smaller, faster, more manageable parts called shards. Vitess gives you an unprecedented level of control over how each table is sharded, thus allowing you to co-locate relevant data in a single shard. Because of this architectural flexibility, in the majority of cases, a query can be served by a single shard allowing you to keep the benefits of an unsharded system while reaping the scaling and performance benefits of a sharded database.

    There are numerous advantages to this approach:

    • Sharded tables are smaller, so indexes also remain smaller leading to faster search.
    • Your write load is distributed across multiple shards thus increasing your write throughput.
    • Because the size of each shard is smaller, replication lag is reduced and replication across multiple servers is much easier.
  • How easy is it to use PlanetScale CNDb?

    If you are writing a new application, you can start using PlanetScale CNDb right away, as though you are writing to a MySQL database. If you want to migrate from an existing database, we can help through our professional services offering.

    PlanetScale uses MySQL as the storage engine and provides MySQL protocol compatibility, so migration can happen quickly and easily without changes to your application.

    While each NewSQL vendor has their own API, which makes migration difficult, migration into the PlanetScale platform from MySQL is easy. Your application code remains simple, unaware of sharding complexities, and you can still operate at scale.

    If you are migrating from a key-value store or another relational database, you will need to make application changes to support MySQL protocol.

  • How is data stored in PlanetScale CNDb?

    For PlanetScale CNDb, PlanetScale uses MySQL Community Edition 5.7 with the InnoDB Engine as underlying storage for each shard.

    If you are licensing the PlanetScale Cluster Manager Software, you can run it on top of MySQL (Community/Enterprise/Percona), MariaDB, RDS on AWS, or CloudSQL on GCP.

  • How does PlanetScale CNDb ensure high availability?

    For eventually-consistent reads, PlanetScale CNDb provides high availability by load-balancing to a pool of replicas.

    For writes and consistent reads, PlanetScale CNDb send queries to a single master for each shard. For any planned maintenance to the master or its underlying machine, we first perform a planned reparent (graceful failover) to another replica, buffering writes for a few microseconds to ensure no committed transactions are lost in the switch-over.

    The master syncs data to a networked storage device (AWS EBS or GCP Persistent Disk) that is replicated within its Availability Zone. If the machine on which the master runs goes down, we reattach this remote disk to a new machine to bring the master back up. If the master cannot be recovered with this disk, we may initiate a failover to an asynchronous replica at our discretion. If this happens, some committed transactions that occurred on the old master but had not yet been replicated may be lost.

  • Does PlanetScale CNDb support ACID transactions?

    PlanetScale CNDb supports full ACID within a shard. Vitess allows you to colocate relevant data in one shard, thus making a majority of queries and transaction to be single shard and fully ACID compliant. Across shards we support Atomicity and Durability. For cross-shard transactions we allow users to choose between two consistency models: best effort and 2PC. We do not support cross-shard Isolation. Most of our customers, including those in financial industries, find these tradeoffs acceptable.

  • How does PlanetScale CNDb compare to MySQL or PostgreSQL?

    MySQL and PostgreSQL do not scale beyond a single node. PlanetScale CNDb, however, can scale indefinitely using horizontal sharding. The platform is built on top of, which is a sharding middleware layer that sits on top of MySQL.

    We do not support Postgres protocol or the Postgres database as the underlying storage at the moment, but it is on the medium-term roadmap.

  • What languages can I use to work with PlanetScale CNDb?

    PlanetScale CNDb supports the MySQL protocol. As far as your application is concerned, the PlanetScale CNDb, based on Vitess, acts like a monolithic MySQL database. You can continue to use the tools or libraries that you currently use to access your MySQL databases.

  • Didn't find what you were looking for?

    Well, get in touch then.