Neon's whole backend goes GA as Postgres platforms race on search and branching

Neon stops being just a database

The week's biggest story is Neon's backend reaching general availability — branching now covers far more than the schema. Every PR, preview, or agent session gets a full copy of the backend: Postgres plus object storage, auth, and functions, so schema, storage, and code can evolve together on an isolated branch before touching production. Function Triggers add schedule- and object-created-event invocation, and a declarative neon.ts config applied with neon deploy gives the whole thing a single source of truth. The same GA wave is framed on the blog as a suite of composable primitives — Lakebase Postgres, Object Storage, Functions, Managed Better Auth, and an AI Gateway — all production-ready and deliberately built on standard interfaces, with the explicit goal of letting agents wire up an entire backend through one interface. Read together, the message is that the database was never the finish line: the backend is now the unit of branching.

Postgres full-text search, done two ways

PlanetScale introduced TIN, a full-text search extension for Postgres that behaves like Postgres should — create an index with CREATE INDEX, query it with WHERE column ==> 'terms...', rank with BM25, and expect backups, transactions, and row writes to keep working. PlanetScale claims 3–30x faster than competing Postgres full-text search indexes. Because that extension lives on PlanetScale, the team also open-sourced Lead, a feature-equivalent extension for CI, dev, and staging, runnable fully offline. Lead is explicitly testing-only: past a few megabytes of indexed text it slows down, so production stays on TIN.

Vitess gets finer-grained controls

The rest of PlanetScale's week was about operating large keyspaces with less bluntness. Existing MySQL databases can now be attached as external keyspaces on a Vitess production branch — PlanetScale runs an external tablet against the source so you can query through Vitess without importing data first. Per-shard VTTablet sizing lets one hot shard get more CPU, memory, or Metal local storage without resizing the whole keyspace, and shard rollout concurrency is now tunable per keyspace from 1 to 32 so wide keyspaces can finish configuration rollouts faster. Tablet throttlers can be toggled per keyspace with a configurable replication-lag threshold, pausing migrations and VReplication while lag is high. Neki extensions are now manageable by name in Terraform and the CLI in a single update. The CLI followed along: MoveTables workflows now run from pscale branch vtctld, and a batch of updates added external keyspace creation, rollout concurrency settings, and throttler flags while fixing a SQL injection in D1 import CHECK expression parsing and a Neki role lookup failure on routers and shards.

Supporting cast

Supabase's CLI continued its steady churn — config releases dropped local-only paths from ProjectConfig, moved schema-tooling shadows onto stack EphemeralPostgres, and added experimental stack status — alongside a long run of v2.118.0 beta builds and a stream of Auth release candidates. On the client side, signInWithPasskey now forwards the mediation option to navigator.credentials.get, a small but welcome bit of control over passkey prompts.