PlanetScale Changelog

The Workflows page for a Vitess branch now lists Materialize workflows alongside MoveTables workflows with the type shown for each, and opening one reveals its stream states, replication lag, and materialized tables with feeding queries. Creating, starting, stopping, and cancelling Materialize workflows remains in the CLI via pscale branch vtctld materialize.

Live connections to Neki routers are now visible in the dashboard under Connections or via pscale branch connections show and top, and you can cancel a session's running query or terminate the session. Cancelling stops the statement and keeps the connection open; terminating closes the client's connection and rolls back any open transaction.

The patroni.slots cluster parameter for Postgres logical replication has been removed and slot names no longer need to be added to cluster configuration, as PlanetScale now detects logical slots automatically. Failover support should remain enabled on slots to preserve them during switchovers and failovers.

The Heroku Migrator now drops secondary indexes on PlanetScale during the initial copy and rebuilds them after data lands, so a single bad index can't restart a multi-hour copy. It also migrates every application schema rather than just public, and adds a Verify Migration comparison after switching traffic.

Neki now supports read-only replicas that copy from the primary and serve reads without taking part in failover, keeping analytics, reports, and exports off live-traffic instances. Set the count (up to 8 per shard) from the Clusters page, then route reads with Query target on the Connect page or by setting __neki.target to rdonly.

Neki on AWS now supports Metal sizes M-10 through M-160, the same locally attached NVMe sizes already available for Postgres. On these sizes, storage capacity is selected separately from vCPU and memory and stays fixed after selection.

Huge pages can now be enabled for Postgres and Neki databases on supported cluster sizes to reduce memory and CPU overhead of managing PostgreSQL's shared memory. Set huge_pages to on in the Parameters tab on the Clusters page for Postgres, or in a configuration profile's Parameters tab for Neki; applying the change requires a restart.

Parameter listings now include a Requires update column for Postgres branches and for Neki configuration profiles, admins, and sidecars, with JSON output adding a requires_update field so scripts can detect the requirement. Maintenance must be run on the branch or Neki configuration profile before changing such a parameter.

Parameter listings now include a Requires update column for Postgres branches and for Neki configuration profiles, admins, and sidecars, and JSON output includes a requires_update field so scripts can detect the requirement. When an update is required, maintenance must be run on the branch or profile before the parameter can be changed.

Terraform provider v1.13.0 adds parameter management to planetscale_neki_router, configurable in Terraform and readable through the router data source; configuring parameters resets omitted customer-configurable parameters to defaults. The planetscale_databases data source now filters by kind, and drift from locked Neki parameters is fixed.

The planetscale_neki_router resource now accepts a parameters block, though configuring it resets omitted customer-configurable parameters to their defaults, and the planetscale_databases data source supports filtering by kind. Postgres bouncer managers should upgrade before PgBouncer timeout parameters report their type as time instead of seconds, since earlier provider versions will fail to read bouncers; the release also stops persistent drift from locked Neki parameters.

Microsoft Azure is now available as a cloud provider, letting users create PlanetScale Postgres and Neki databases in Azure regions with the same features as other clouds, including high availability, branching, Query Insights, automated backups, and Metal clusters. Vitess databases are not currently available on Azure.

Deploy requests can now opt into Vitess aggressive cutover individually via the CLI and API using the --aggressive-cutover flag, changeable any time before the schema change is deployed. pscale deploy-request show and queue now display an aggressive cutover column.

The PlanetScale MCP server can now check database metrics via the planetscale_get_branch_metrics tool, pulling CPU, memory, disk, replication lag, and connections into your AI assistant for Vitess, Postgres, and Neki branches. The default summary covers the last hour, with memory utilization including page cache reported alongside RSS and cache.

Vitess deploy requests now offer a retry option for partially failed migrations: instead of restarting the entire deploy, retry restarts the migration for only the failed tables while tables that already completed keep their existing progress. Available from the deploy request page and via pscale deploy-request retry .

Organization administrators can set MCP query access in organization settings to no query access, read-only, or read and write. The limit applies the next time someone authorizes an MCP client, and already-authorized clients keep their existing access.

PlanetScale Postgres now supports independently configurable dedicated read replicas, created in the primary region or another region from the same cloud provider with their own cluster size, replica count, storage, and Postgres parameters. They can be managed from the dashboard, API, CLI, or Terraform.

The new pscale keyspace parameters command lets you view and change VTTablet and MySQL parameters of a Vitess keyspace from the terminal. pscale keyspace parameters list shows current and default values, pscale keyspace parameters changes list tracks each change as it rolls out, and --reset restores a parameter to its default.

Two new Prometheus metrics track planned and emergency reparents, split by planetscale_reparent_result and planetscale_component labels. The planetscale_vtorc_recovery_type metric now holds recovery names like RecoverDeadPrimary instead of the previously documented planned and unplanned values, so existing queries filtering on those need updating; on Vitess 23 and later, failed and successful recovery counters carry keyspace and shard labels.