PlanetScale on X

Enthusiasm is not pinned to one feature. Praise lands on the writing — technical blog posts called "terrific", the YouTube channel rated among the best — on the team ("most down to earth engs"), and on landing copy one writer reviewing devtool sites holds up as clear technical writing. People also credit steadier response times from dedicated resources, query insights, and zero-downtime reparenting within the cluster.

7 describe moving onto it and being glad: becoming a customer, migrating every project, or leaving Railway and Convex behind — one reports a refactored backend running up to 200x faster on complex queries. 6 praise the MCP with coding agents: its customisation, an agent that signed up for billing and copied a staging database over from Supabase from one prompt, and the guardrails — deletion protection, blocking destructive schema changes, reverting a bad deploy without losing the writes made in between. 4 call it good value, citing SOC2 compliance, Postgres from $5 a month and scaling easier than RDS. 3 are curious and still haven't started.

On cost, 3 people put numbers on it. One lists what the free tiers of Supabase, Neon, Turso, MongoDB and Convex include and notes "planetscale doesn't have a free tier anymore"; another prices a single-region 4-core, 32 GB Postgres setup at about $1200; a third says the only snag in a move to Render was bandwidth between app and database, which they cut by putting AWS Private Link between Render and PlanetScale.

On Postgres behaviour, 3 people warn about side effects of features people reach for by default. Cascade deletes come up most insistently: one explains that dependent tables stay locked while the cascade runs, so an added column waits behind it and inserts pile up into stalled writes, and suggests marking rows deleted to purge later; another says a small-looking parent delete hides a lot of work, and that an explicit deletion workflow shows batch size, progress and recovery. One flags that two identical input rows can still need two different sequence values from nextval().

On D1 (6 people), some describe starting there and switching to PlanetScale once real users arrive; others say "never default to D1" on a Cloudflare project and to use PlanetScale with Hyperdrive to "save yourself the headache (and bill jumpscare)". Some are still deciding: one is weighing whether D1 can be migrated off later or whether to start on Neon or PlanetScale, and one with thousands of users in sight thinks it should look at PlanetScale rather than D1.

Supabase (3 people) is both a place to leave — a staging database copied across to PlanetScale by an agent from a single prompt — and a place to stay: one argues few Supabase apps will ever scale enough to justify the move. Heavier setups (3) cover scaling called "SO EASY compared to RDS", a distributed database called unnecessary when PlanetScale will suffice, and a note that PlanetScale runs its own infrastructure on AWS. 2 weigh in on Railway, 2 on keeping the database off Cloudflare. Neon, ParadeDB, Convex, Lakebase and the open-source version draw one person each.

The defining question (5 people) comes from people outside the product as much as inside it: "What is planetscale? Where is the official plug?", whether it is Postgres underneath, whether a database-as-a-service like it is the same thing as Supabase, what Rails is used for ("control plane doesn't count"), and whether there is a massively parallel database product.

The narrower questions are about capability edges. On Postgres extensions (2 people), whether one is closed source and where the docs on creating them are — one says they have been looking since the TIN launch without finding a good resource. On search and indexing (2 people), what it does for languages Postgres has no stemmer for, where search "turns into ILIKE and hope", and whether multimodal indexes stay aligned when image and text updates must. On cost (2 people), whether the metal tier really is that cheap and how transfer costs compare with AWS. On choosing (2 people), what experience others have had, including one asking what lies behind the repeated "just use PlanetScale" advice about D1.

The requests are practical and specific, and none repeats. One wants Cloudflare's placement to pick the region of a linked PlanetScale database automatically, instead of choosing it by hand, "so it would sync with the DB region automatically".

One wants connection pooling on PlanetScale, pointing at pgdog as the model: through a pooler they no longer need any direct connection to the primary and can do everything through it.

One wants the sharding preview documented with a migration example that covers replica lag and read-after-write behaviour, so teams can see which existing application assumptions carry over — calling the read-only replicas and Postgres compatibility work practical additions alongside it.

Each of the three is a single person's ask, so the section records them as that rather than as a pattern: no theme here has more than one voice behind it, and the three sit level.