PlanetScale vs CockroachDB Serverless: Branch Limits, Scale-to-Zero, and True Costs

You've picked a serverless database to avoid managing infrastructure, but now you're staring at a pricing page that requires a spreadsheet to decode. PlanetScale and CockroachDB Serverless are two of the most-discussed options in this space, and they're genuinely different products underneath the "serverless" label. Choosing the wrong one for your workload doesn't just cost money — it can force a painful migration later.

• How PlanetScale and CockroachDB Serverless actually bill you
• What "scale-to-zero" means in practice for each platform
• How branch and region limits affect real development workflows
• Where each platform's free tier runs out faster than you'd expect
• Which workloads belong on which platform

The Short Version

PlanetScale is a MySQL-compatible database built on Vitess. It's optimized for high-throughput OLTP workloads and leans heavily into a Git-like branching model for schema changes. CockroachDB Serverless is a distributed SQL database with strong consistency guarantees and PostgreSQL compatibility. The serverless tier auto-scales and charges on a resource-unit model.

Both platforms offer a free tier. Both scale down when idle. But they make different trade-offs in how they structure limits, and those trade-offs compound once you leave the free tier.

PlanetScale Pricing: How It Actually Works

PlanetScale's billing is built around rows read and rows written per month, plus storage. This sounds intuitive until you realize that a single SELECT with a missing index can read tens of thousands of rows and eat through your monthly allocation in one bad query.

The Hobby (free) plan gives you one database, a fixed number of reads and writes per month, and 5 GB of storage. The Scaler plan unlocks more resources and adds production branches, but the jump in cost between Hobby and the first paid tier is significant.

Branch limits are a real constraint on the free plan. You get one production branch and one development branch. If you're running a team workflow where every feature branch needs a database branch, you'll hit that ceiling quickly. Paid plans unlock additional development branches, but you're still capped — it's not unlimited branching.

The Row-Read Trap

The row-read model punishes unoptimized queries more than a traditional per-query or per-hour model would. If your ORM generates a query that scans a full table instead of using an index, you'll see it immediately in your usage dashboard. This is actually useful for catching performance issues early, but it means your costs are coupled to your query quality in a way that's hard to predict upfront.

PlanetScale's query insights dashboard makes this visible, which is more than most databases give you. Still, budget forecasting is harder when a single deploy with a regression can spike costs.

CockroachDB Serverless Pricing: How It Actually Works

CockroachDB Serverless bills in Request Units (RUs), which are a composite measure of CPU, memory, and I/O consumed. Storage is billed separately per GiB-month. The free tier gives you a fixed RU budget per month and 10 GiB of storage, which is generous enough to run a real side project.

Unlike PlanetScale, CockroachDB Serverless offers spend limits at the account level. You set a maximum monthly spend, and the database throttles rather than charges beyond that. For cost-sensitive projects this is a meaningful safety net.

The RU model is less intuitive than rows read/written. A write consumes more RUs than a read. A cross-region read costs more than a single-region read. You'll want to run your workload for a few days and watch the RU consumption before you can forecast reliably.

Multi-Region and Its Cost Implications

CockroachDB Serverless supports multi-region deployments, but accessing data from a non-home region costs more RUs. If you deploy globally but most of your traffic is regional, you can end up paying a premium for replication you don't need. Be explicit about your primary region and only add more if you have a genuine latency or durability requirement.

Scale-to-Zero: What It Means for Each Platform

Both platforms scale to zero when there's no traffic. But the cold-start behavior is different and matters for your use case.

PlanetScale's scale-to-zero on the free Hobby plan is aggressive. After a period of inactivity your database is paused and must be manually or automatically resumed. On paid plans this behavior changes, but on the free tier it's a real operational consideration for any project that gets sporadic traffic.

CockroachDB Serverless scales to zero automatically and resumes on the next connection. The resume latency is typically under a second for a warm cluster, but you may notice a delay on the first query after a long idle period. For a user-facing app that might mean one slow request when the cluster wakes up.

Neither platform is ideal for workloads that demand sub-millisecond cold starts. If your API has strict p99 latency SLAs, a provisioned (always-on) tier is worth the extra cost on either platform.

Branching: PlanetScale's Core Differentiator

Schema branching is where PlanetScale pulls ahead of CockroachDB Serverless for teams doing frequent schema changes. Each branch is a full copy of your schema (not your data, by default) and you can open a deploy request — PlanetScale's equivalent of a pull request — to merge schema changes into production without locking tables.

This is genuinely useful. Traditional ALTER TABLE on MySQL blocks reads and writes on large tables. PlanetScale handles schema migrations online using Vitess's internal tooling, which means you can add a column to a 100-million-row table without a maintenance window.

The branch limit on the free plan is the catch. You get one development branch. On a solo project that's fine. On a team with multiple features in flight simultaneously, you'll hit that limit and need to either serialize your schema work or upgrade.

PostgreSQL vs MySQL Compatibility

Your existing codebase likely drives this decision more than anything else. If you're using Postgres features — window functions, JSONB, full-text search, advisory locks — CockroachDB Serverless is the more natural fit. Its SQL dialect is PostgreSQL-compatible, and most Postgres client libraries connect without modification.

PlanetScale is MySQL-compatible. If you're coming from a MySQL background or using an ORM that targets MySQL (like some configurations of Prisma or Laravel's Eloquent), PlanetScale will feel familiar. One important caveat: PlanetScale does not support foreign key constraints by default, because Vitess's sharding model makes cross-shard FK enforcement impractical. You enforce referential integrity at the application layer instead.

CockroachDB does support foreign keys. If your data model relies on them and you don't want to rewrite enforcement logic, that matters.

Free Tier: What You Actually Get

Both free tiers are legitimately useful for side projects. CockroachDB's spend cap gives you more predictability; PlanetScale's row-based model is easier to reason about for simple workloads.

Common Pitfalls

Missing indexes on PlanetScale. Every unindexed query hits your row-read budget hard. Run EXPLAIN on your slow queries before deploying. PlanetScale will also block queries that perform full-table scans above a certain size on production branches, which is a good guardrail but can surprise you at 3 AM.

Cross-region reads on CockroachDB Serverless. If you don't pin your tables to a primary region, CockroachDB may route reads across regions for consistency, burning RUs faster than you'd expect. Use SET PRIMARY REGION explicitly.

PlanetScale's no-FK policy. This isn't just a feature gap — it's a design philosophy. If you generate migrations with a tool that creates foreign keys, those migrations will fail. You need to strip FK declarations from your migration files or configure your ORM to skip them.

CockroachDB's transaction semantics. CockroachDB uses serializable isolation by default, which is stricter than the read-committed default on most MySQL and Postgres deployments. You may encounter transaction retry errors (40001) that your application needs to handle explicitly. Most client libraries have retry logic you can enable, but it requires deliberate setup.

Free tier pausing on PlanetScale. If you're demoing a project to a client and your database is paused, that's an embarrassing moment. Set a reminder to keep the database active, or budget for the first paid tier if availability matters.

Which One Should You Pick?

Pick PlanetScale if you're building a MySQL-compatible app, you have a team that does frequent schema changes, and you want online schema migrations without table locks. It's particularly strong for high-throughput OLTP workloads where row-level billing aligns with how you think about performance.

Pick CockroachDB Serverless if you need PostgreSQL compatibility, foreign key support, a spend cap for cost predictability, or you're building something that might eventually need multi-region distribution. The RU model has a learning curve, but the safety rails are better for projects where costs are hard to predict upfront.

If you're starting a greenfield project with no existing codebase constraints, CockroachDB Serverless's spend cap and PostgreSQL compatibility give it a slight edge for most web applications. If you're migrating a MySQL app and schema migrations are your biggest pain point, PlanetScale's branching model is hard to beat.

Wrapping Up

Both platforms are genuinely good at what they do. The "serverless" label covers meaningfully different products, and the decision comes down to your SQL dialect, your schema change workflow, and how you want to manage cost risk.

• Audit your existing ORM and migration tooling for foreign key usage before committing to PlanetScale.
• Run a load test against CockroachDB Serverless for a few days and watch RU consumption before estimating monthly costs.
• Set a spend cap on CockroachDB Serverless the moment you create your account — don't wait until you need it.
• If you're on PlanetScale's free tier and relying on it for anything user-facing, build in a health check that keeps the database from pausing.
• Read the migration guides for your ORM (Prisma, Drizzle, SQLAlchemy, ActiveRecord) on the platform you choose — there are platform-specific gotchas in nearly all of them.