SUMM

The creator switched all infrastructure to Postgres due to persistent recommendations.
Previously preferred using PlanetScale for MySQL because of its ease, speed, and scalability.
Had to move away from PlanetScale initially for better synchronization features in T3 Chat.
Attempted to encourage collaboration between Convex and PlanetScale.
Unexpectedly, PlanetScale announced support for Postgres, already in use by companies (including Convex).
Not a sponsored segment for the database portion of the video.

PlanetScale is built around Vitess, which provides sharding and scalability for MySQL databases.
Vitess is described as “Kubernetes for databases,” allowing MySQL to scale efficiently.
MySQL's modular design aided PlanetScale's earlier focus, whereas Postgres is more tightly integrated.
Vitess was originally built at YouTube, then further developed at GitHub, and eventually became the backbone of PlanetScale.

No full Vitess equivalent for Postgres exists yet for PlanetScale or Supabase (efforts are ongoing but early).
Major performance improvement stems from using local NVMe drives on the database nodes for storage (PlanetScale Metal).
Local NVMe storage directly connects to the CPU and avoids network latencies, enabling high-speed IO.
Most cloud providers separate compute from storage for reliability, but this reduces speed; PlanetScale tolerates node failures using replication and redundancy.
PlanetScale rapidly creates and resets databases, with each replicated and able to recover from node failures, reducing reliance on persistent networked storage.

PlanetScale’s Postgres shows substantial performance improvements over competitors like Neon, Aurora, Supabase, Heroku, etc., in queries per second and latency.
Example benchmark: PlanetScale achieves about 50% more queries per second than Neon with lower latency, while costing $400/month versus Neon's $3,000/month.
Aurora is outperformed by PlanetScale (almost three times better latency, cheaper too).
Supabase and Heroku are significantly behind PlanetScale in both speed and reliability; Heroku lags by an extreme margin in QPS and latency.
Real-world migration by Convex (from MySQL on Aurora to Postgres on PlanetScale) yielded a 5x drop in write latency P99.9 from 100+ms to 20–40ms.

Convex was already proficient in MySQL but chose Postgres mainly because of Postgres's standardization and multi-tenancy support.
PlanetScale's MySQL offering provides one DB per instance; Postgres on PlanetScale supports multiple DBs per instance, crucial for Convex's needs and customer offerings.
PlanetScale does not offer a free tier for Metal/MySQL due to dedicated instance requirements and associated costs.
The Postgres move enables Convex to serve multiple databases per instance, vital for customer scaling and cost efficiency.

Convex migrated from Aurora to PlanetScale for improved cost, reliability, and especially speed—commit latency significantly reduced after the switch.
Now every new Convex project runs on PlanetScale’s Postgres, with substantial P99 and P50 latency improvements for write operations.
Convex open-sources its core, allowing self-hosting on MySQL or Postgres; guides are provided.

Databases have three main subsystems: query engine, relational model/schema, and storage layer.
Convex replaces the top two layers (query engine and relational/model), leaving storage to providers like PlanetScale.
Most Convex improvements focus on ease of development and syncing, not on innovating at the storage layer (which is handled by PlanetScale).
The two companies complement each other: PlanetScale focuses on performance and reliability of storage and distribution; Convex on developer experience and application logic.

Convex avoids overextending; focuses on non-database aspects, relying on PlanetScale for robust storage.
PlanetScale now offers a free tier via Convex.
The presenter is satisfied to use Postgres again, primarily because the database backend is now so reliable and efficient that it requires minimal attention.
Recommends PlanetScale for performance and Convex for app development ease.

I finally switched to Postgres.