PlanetScale: Vitess Foundations & Sharding Concepts

PlanetScale is a serverless database platform built on Vitess -- the MySQL-compatible, horizontally-sharding clustering system originally created at YouTube, later CNCF-graduated and adopted by Slack, GitHub, and others beyond PlanetScale itself.

Horizontal Sharding: Keyspaces & Vindexes

• Horizontal sharding splits a dataset across multiple database instances (shards), each holding a subset of the data -- scales total capacity/write throughput beyond one machine's limit.

• A keyspace is Vitess's logical database -- may span multiple physical shards, but applications interact with it as one unified database.

• A vindex maps a column's value (e.g. hashing user_id) to the shard that should hold matching rows -- Vitess uses this to route queries without the application knowing the physical sharding layout.

• Read replicas (full copies of a shard's data) scale read throughput; sharding scales total data volume/write throughput -- typically combined together.

MySQL Compatibility

// Standard MySQL-wire-protocol compatible -- existing drivers/ORMs
// work with just a connection-string change
import { drizzle } from 'drizzle-orm/planetscale-serverless';
import { connect } from '@planetscale/database';

const connection = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});

const db = drizzle(connection);
const users = await db.select().from(usersTable);

// Historical caveat: Vitess's sharded architecture made traditional
// cross-shard foreign key constraints hard to enforce efficiently --
// a known early gotcha migrating schemas that relied heavily on FKs
// (PlanetScale has since expanded FK support for appropriate cases).

Serverless Connection Handling

• Serverless/edge runtimes (Vercel Functions, Cloudflare Workers) open/close many short-lived connections rapidly -- unlike a traditional server's stable connection pool.

• PlanetScale provides an HTTP-based database driver suited to this pattern, rather than requiring a persistent raw TCP connection.

• Same general problem (and similar solution shape) as Neon's HTTP driver for Postgres.