ENGINEERING ★ 95 upvotes 2025

Why We Migrated from Neon to PlanetScale

Retrospective Overview & Key Insights

Distilled analysis of the business dynamics, operational challenges, and strategic takeaways:

In this technical retrospective (2025), @anthonyronning shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.

Core Principles for Independent Builders:
1
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
2
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
3
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:

HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.

Community Discussions & Critical Reviews

High-signal perspectives, counter-arguments, and peer founder insights debated on Hacker News (69 total discussions):

IN @Insanity Peer Contributor

We're experimenting with Lakebase now (Databricks' name for Neon).

Initial results are actually pretty cool when using the UI to spin it up. The API leaves some things to be desired (bad error messages that obfuscate the actual error, undocumented rate limiting, ..).

Plus, there's been quite a number of strange bugs we ran into, like tables that don't recreate correctly because of dangling resources.

Overall, I'm pretty excited about the product because it makes life a bit easier, but it's not really 'production quality yet'.

(Alternatively, maybe we're just doing things in a bad way while we're learning to use it, so it could be a PEBKAC type of issue, rather than a Lakebase issue).

GR @gr4vityWall Peer Contributor
We have thousands of users generating thousands of chats daily. Lawyers discussing sensitive cases. Executives planning strategy. Developers working on proprietary code. They trust us because their data is mathematically guaranteed to be private. But that trust evaporates quickly when the service is unavailable.

And 250 dollars/month was considered expensive for the infrastructure handling that? My first impression is that based on the stakes alone, that would warrant a full time dedicated engineer.

Not gonna lie, although I appreciate the comparison and that they shared their experience publicly, this post sounds like half a technical write-up, half an ad for both companies.

JM @jmull Peer Contributor

I realize this wasn't the main reason they switched, but from my perspective, $156/mo and $250/mo for db is essentially the same number:

Way too much for a project without a budget, and approximately zero for a project with a budget.

BE @beoberha Peer Contributor

What exactly is PlanetScale Postgres? Is it plain managed Postgres ala RDS or something more bespoke like Neon? I know PlanetScale is working on a Vitess-like sharded Postgres (Neki?) but I’m guessing that is not yet running in the cloud?

AS @asib Peer Contributor
Beyond reliability, we faced other challenges:
- Usage-based pricing that punished our success, the more users chatted, the more we paid

This is such a strange position on usage-based pricing and seems telling.

HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE ★ 95 points
TOTAL DISCUSSIONS 69 comments
TOPICS & TECH STACK: