PlanetScale shipped something significant: serverless Postgres now runs on the same platform that handles millions of queries per second for Vitess-sharded MySQL deployments. Combined with the new Database Traffic Control™ feature and an unlimited IOPS storage layer, this release redraws PlanetScale's competitive map entirely. It is no longer a "better MySQL with branching." It is a dual-engine cloud database platform built to challenge Aurora, AlloyDB, Neon, Supabase, and CockroachDB simultaneously. If you are an engineering leader currently evaluating database platforms, your shortlist just changed. Here is what shipped, what it means, and what you should do about it.

Three distinct additions define this release:

Each of these is independently meaningful. Together, they represent a coherent platform bet: that the future of managed databases is not a single engine but a unified control plane with enterprise-grade isolation and data-center-class hardware performance.

PlanetScale built its reputation on Vitess, the MySQL sharding system that powers YouTube and Slack. That heritage is a genuine competitive moat for high-scale MySQL workloads. But it also capped the addressable market. The Postgres ecosystem has grown faster than MySQL's in developer mindshare over the past several years, and most greenfield application development in 2026 defaults to Postgres. By adding serverless Postgres, PlanetScale can now pitch a single vendor relationship to an organization that runs sharded MySQL for its core transaction database and Postgres for analytics, user-generated content, or newer microservices. That is a real consolidation argument. The operational overhead of managing two database vendors, two sets of credentials, two monitoring integrations, and two runbooks is non-trivial at scale. Eliminating it has budget-committee appeal that purely technical arguments often lack. The competitive pressure this creates is direct. Neon and Supabase are the current leaders in serverless Postgres developer experience. Both have strong branch-on-demand features and generous free tiers. PlanetScale is not trying to outcompete them on free-tier ergonomics. It is competing on what happens when your Postgres database starts handling serious load, and the gap between a developer-friendly product and a production-grade database becomes operational debt.

This is the feature most coverage will underestimate. Database Traffic Control™ introduces per-workload resource budgets at the database layer. Instead of applying rate limits at the API gateway or setting coarse per-cluster limits and hoping for the best, teams can define exactly how much query traffic a specific consumer, a reporting job, an analytics pipeline, a tenant tier, can generate against a shared Postgres cluster. The implications for multi-tenant SaaS architecture are substantial. The noisy-neighbor problem in shared database clusters is one of the oldest and most expensive operational problems in backend engineering. The typical solutions are blunt instruments: separate clusters per tenant (expensive), aggressive application-layer rate limiting (incomplete, misses background jobs), or reactive alerting after latency degrades (too late). None of these put the budget where the contention actually happens: the query scheduler and I/O path. What PlanetScale is doing with Traffic Control is essentially bringing SLO budget thinking into the database layer itself. Product teams already own API rate limits and error budgets. There is no principled reason they should not also own database traffic budgets for their services. This changes the conversation in platform engineering from "we need to isolate this tenant to protect performance" to "we can define and enforce isolation as a product feature without provisioning separate infrastructure." For platform teams building internal developer platforms, this is worth prototyping immediately. The chargeback and showback models that FinOps teams apply to cloud compute and storage have historically been difficult to apply at the database layer because there was no granular signal. Per-workload budgets at the query level change that.

The phrase "unlimited IOPS" sounds like marketing copy. In this case, the underlying architecture is the point. Managed cloud databases on AWS RDS, Aurora, Cloud SQL, and comparable services are ultimately constrained by the IOPS limits of the underlying EBS or persistent disk volumes. Aurora's io2 volumes cap at 256,000 IOPS. Reaching that ceiling requires specific instance families and carries significant cost. For workloads with spiky, write-heavy, or latency-sensitive I/O patterns, these caps create either performance cliffs or expensive over-provisioning. PlanetScale's storage layer is built on NVMe drives with what the company describes as data-center performance semantics in the cloud. The practical meaning: I/O throughput is not gated by a per-volume IOPS quota that you negotiate at provisioning time. For the Vitess-scale deployments PlanetScale already supports, customers doing hundreds of terabytes of data with millions of queries per second, this is not a differentiator. It is a prerequisite. You cannot run that workload on standard managed cloud storage. For teams currently running self-managed MySQL or Postgres clusters on bare metal or custom NVMe-backed EC2 instances specifically to escape cloud storage IOPS limits, this is a direct argument for re-evaluating managed hosting. The operational cost of maintaining a self-managed fleet is real: patching, failover testing, capacity planning, SRE on-call burden. If PlanetScale's unlimited IOPS claim holds under benchmark conditions comparable to your workload, the total cost of ownership analysis shifts.

Here is where PlanetScale stands against the major alternatives as of mid-2026:

Neon and Supabase have better developer onboarding experiences today. Their free tiers are more accessible, their documentation is polished, and their ecosystems have accumulated integrations and community content that PlanetScale is still building on the Postgres side. For a solo developer or early-stage team optimizing for time-to-first-query, that matters. For a team running at scale, the calculus inverts. Neon and Supabase have not demonstrated Vitess-level throughput or a credible path to per-workload isolation at the database layer. Aurora and AlloyDB are credible at scale but are deeply hyperscaler-native, carry vendor lock-in risk, and are constrained by the same IOPS architecture they have always been constrained by. PlanetScale's bring-your-own-cloud option also changes the compliance conversation. For Fortune 500 teams with data residency requirements, strict network segmentation policies, or FedRAMP aspirations, a BYOC deployment that runs in their own cloud account while PlanetScale manages the control plane is a meaningful architectural option that pure SaaS database vendors cannot match.

This release requires action at three different levels depending on your current situation:

If you are evaluating databases for a greenfield Postgres project:

PlanetScale now belongs on your shortlist alongside Neon and Aurora. The specific evaluation criteria should be: branch-and-deploy workflow fit for your team, tail latency at your expected p99 load, and whether per-workload traffic isolation is a near-term requirement. If you anticipate multi-tenant SaaS architecture within 12 months, weight Database Traffic Control™ heavily. Most Postgres-native startups do not have an equivalent answer.

If you are running a self-managed Vitess or MySQL fleet:

Re-benchmark against PlanetScale's managed offering. The specific numbers to compare: cost per million queries, p99 latency under your peak write load, and SRE hours per month attributable to database operations. PlanetScale's unlimited IOPS claim is worth stress-testing directly. Request a proof-of-concept environment and run your actual query mix against it before making a decision.

If you are an existing PlanetScale Vitess customer:

The Postgres addition is immediately relevant if any of your services currently run on a separate Postgres provider. The consolidation argument is strongest here because your team already understands PlanetScale's deploy workflow, and your operations team already has the monitoring and runbook infrastructure in place. Evaluate whether migrating a lower-criticality Postgres service to PlanetScale makes sense as a pilot before committing higher-stakes workloads.

PlanetScale's move to a dual-engine platform is a bet that the future of cloud databases is not won at the engine layer. Postgres and MySQL are both mature, stable, and well-understood. The differentiation is in the control plane: how you deploy schema changes without downtime, how you isolate workloads from each other, how you get data-center hardware performance without managing data-center hardware, and how you maintain the compliance posture that enterprise security teams require. Database Traffic Control™ is the clearest signal of where PlanetScale's product thinking is heading. The companies that will pull ahead in multi-tenant SaaS infrastructure over the next three years are the ones that treat database capacity as a first-class product resource, not a shared utility that engineers argue about in incident retrospectives. PlanetScale is building the tooling to make that possible at the database layer, where it actually matters. The platform war for cloud databases is no longer about which managed service has the most compatible Postgres dialect. It is about which platform can handle millions of queries per second, enforce workload isolation at the query scheduler, and do it inside your compliance perimeter. PlanetScale is now one of the very few vendors with a credible answer to all three questions simultaneously.

Want to start building with PlanetScale? Here's a quickstart: