Neon is now a Databricks product. Should you still use it?
Most database acquisitions ruin the product. The Neon one didn't, at least not yet. Databricks announced the deal in May 2025 for around $1 billion, closed it, and then quietly made Neon cheaper. Storage dropped from $1.75 to $0.35 per GB-month. The Launch plan compute went from $0.16 to $0.106 per CU-hour. The free tier doubled from 50 to 100 CU-hours.
That is not the price chart of a company about to fleece its existing customers. So why am I still seeing "Neon alternative" climb in search?
Three reasons, none of them dishonest about Neon today.
Databricks is not a developer-tools company
Databricks sells AI and data-lakehouse infrastructure to enterprise data teams. Their median customer is a Fortune 500 data engineering org with a Snowflake contract they want to leave. That is a very different audience from the solo developer building a side project who picked Neon because it had a free tier and a psql URL in under a minute.
The Neon team is now inside that org. The roadmap eighteen months from now is going to be steered by what Databricks customers want, which is going to be tighter integration with Unity Catalog, Mosaic AI, and MLflow. Those integrations are useful if you are already paying Databricks for the rest of it. If you are not, they are weight you carry without benefit.
The free tier doubled, which is great. The center of gravity moved, which is the part to watch.
Pre-IPO repricing is a real risk
Databricks has been telegraphing an IPO for a while. Pricing decisions inside a pre-IPO company are made to make the IPO look good. Pricing decisions inside a public company are made to make the next quarter look good. Those are not the same incentive.
This does not mean Neon prices will go up tomorrow. It means the durability of today's pricing past the IPO is not something you should bet a roadmap on.
The vendor surface area got bigger
If you adopted Neon in 2024, you were adopting a focused serverless Postgres company. If you adopt Neon today, you are adopting a feature of a $60B AI data platform. That is a different kind of dependency, with a different exit cost if you decide later you do not want it.
For some teams that is upside. Databricks has muscle. They are not going to disappear, get acqui-hired, or pivot to crypto. For other teams it is downside. The bigger your vendor's surface area, the more places they can decide to be opinionated about your stack.
Should you migrate today?
Honestly, no. If you are happy on Neon, the prices are good and getting better, the product is good, the integrations work. Stay.
You should care if:
- You are building something where the database is a strategic dependency and you want a hedge that you can swap to in a weekend.
- You depend on Neon's branching workflow but worry that the product will drift toward Databricks-customer concerns.
- You are a hobby or solo developer and you have been burned before by acquired tools getting deprioritised for their non-strategic users (Heroku, the entire pre-Microsoft GitHub Actions wishlist, half of what Google has bought).
A plain hedge
If you want a managed Postgres that is not a strategic asset of an enterprise data platform, Layerbase Cloud hosts Postgres without any of that. No AI lakehouse agenda. No pre-IPO pricing model. Same Postgres wire protocol, same SQL, same drivers, same pg_dump flow you already know. Free dev tier with no card.
Migration is the standard Postgres path. pg_dump from Neon, psql into the new instance for one-shot moves. Logical replication if you want zero downtime. There is nothing Neon-specific about a normal Postgres workload, so it ports clean.
Short version
Neon today is fine. Neon eighteen months from now is going to be a Databricks product through and through, and the question is whether that fits your stack. If it does, keep using it. If you want a Postgres that stays Postgres and does not slowly turn into a feature of someone else's platform, the alternatives are easy to swap to and cheap to try.
Create a free Postgres on Layerbase Cloud and keep it as a fallback. You do not need to migrate to find out you have an option.