Should I use Lakebase for Postgres?

We build a competing product (Layerbase), so the bias is on the table. We are going to be fair anyway, because Lakebase is a genuinely good database and the honest comparison is more useful than a takedown. If you are weighing Lakebase for a new Postgres project, here is what it actually is, what it costs in ways the pricing page does not lead with, and where a flat-rate multi-engine platform like Layerbase is the better fit.

What is Lakebase?

Lakebase is Databricks' managed Postgres. To understand it you have to start with the acquisition.

In May 2025, Databricks agreed to acquire Neon, the serverless Postgres company, for around $1 billion. The reason Databricks paid that much is buried in one statistic: over 80 percent of the databases provisioned on Neon were created automatically by AI agents, not by humans. Databricks sells AI infrastructure to enterprises. A serverless Postgres that spins up in under 500 milliseconds is exactly the operational layer an agent platform wants underneath it.

A month later, in June 2025, Databricks announced Lakebase: a fully managed Postgres "built for AI," running on Neon's separated compute-and-storage architecture, wired into the Databricks lakehouse so operational tables sync with Unity Catalog and Delta tables. It is now generally available and runs Postgres 17 with pgvector.

So when you ask "should I use Lakebase," you are really asking three questions:

1. Is the underlying database good? Yes. It is Neon, and Neon is excellent Postgres.
2. Do I want my database to be a feature of an enterprise data platform? That is the real decision.
3. Do I understand what it will cost? That is where most people get surprised.

It is one more Postgres provider, with a bigger logo on it

There are dozens of good managed Postgres providers: Neon, Supabase, Render, Railway, Crunchy, RDS, PlanetScale (now with Postgres), and on and on. Postgres is a commodity wire protocol. Almost everyone hosting it is hosting the same database.

Lakebase does not change the database. It changes the owner. The Postgres inside Lakebase is the same Postgres you would get from a dozen other places. What you are buying with Lakebase is a Databricks relationship: the lakehouse sync, the Unity Catalog integration, the Databricks billing account, and the Databricks roadmap.

If you are already a Databricks customer with a lakehouse and an analytics team, that is real, compounding value. If you are a developer who just needs a Postgres URL for an app, you are adopting a feature of a $60B AI data platform to get a database you could get anywhere, and you inherit that platform's priorities whether you use them or not.

The hidden costs

Lakebase's pricing reads simply until you look at the meters. It is metered, usage-based billing with several independent dimensions, which is the model that produces surprise bills.

Lakebase Autoscaling bills on at least three separate meters:

• Query compute, charged in Databricks Units (DBUs) per second of active capacity.
• Sync compute, billed separately from query compute, for keeping operational data in sync with the lakehouse.
• Storage, charged in Databricks Storage Units (DSUs) per GB-month.

On top of that there is the Always-On versus Autoscaling distinction: baseline capacity bills at one rate, spikes above baseline bill at another, and whether scale-to-zero is on changes the math again. This is the Databricks DBU consumption model applied to an operational database, and the DBU model is famous for being hard to forecast. You are not paying for "a database." You are paying for capacity units, storage units, and sync units, each on its own clock.

Then there is the part that bites web apps specifically: bandwidth. Lakebase runs on Neon, and Neon bills public network transfer, the total volume of data your database sends over the public internet. The free tier includes 5 GB per month, and if you exceed it your compute gets suspended until the next cycle; paid tiers include 100 GB and then charge $0.10 per GB.

Here is why that matters more than it sounds. Egress is driven by reads. Every uncached page render, every API response, every analytics tool pulling rows, and every bot or crawler that hits your site and triggers a database read, all of it counts against your transfer allowance. You do not control how much bot traffic finds your app, but you pay for the database reads it causes. Teams running data-heavy apps or bulk exports on Neon-style pricing have learned this the expensive way.

One honest caveat, because it cuts the other way: right after the acquisition, Neon got cheaper. Storage dropped from $1.75 to $0.35 per GB-month and the free tier doubled. That is real. But the most credible analysis is that the drop came from Neon merging into Databricks' AWS account and inheriting their volume discount, not from a new pricing philosophy. A discount that comes from a parent company's cloud contract is a discount that the parent company can unwind whenever the incentives change. Which brings us to the pattern.

The pattern: what happens when a developer tool becomes an enterprise feature

We have seen this movie. Salesforce bought Heroku, the developer platform a generation of apps launched on. For years it coasted. Then in 2022, Salesforce killed every Heroku free tier, blamed "fraud and abuse," and steered everyone toward Heroku Enterprise and Private Spaces that start in the thousands of dollars per month. One industry observer put it bluntly: Heroku "hasn't been invested in, from a Salesforce perspective, for the last eight years." The free tier was the on-ramp for hobbyists and solo developers, and those were exactly the users the company decided it no longer needed to serve.

The shape is always the same:

1. Acquire a beloved developer tool with a generous free tier.
2. Keep prices low while you capture the market and the goodwill carries.
3. Discover that the small users are expensive to support and do not drive enterprise revenue.
4. Cut the free and low tiers, raise prices, and point the roadmap at the enterprise accounts that actually pay.

Lakebase is at step 2, with the prices low and the goodwill carrying. The tell is the roadmap. The Neon team now sits inside an enterprise company whose median customer is a Fortune 500 data org. The features being built are lakehouse sync, Unity Catalog integration, and agent provisioning for Databricks workloads. Those are great if you live in that ecosystem and dead weight if you do not. The eighteen-month roadmap answers to Databricks customers, not to the solo developer who picked it for the free tier and the fast psql URL.

None of this is a prediction that Lakebase will be bad tomorrow. It is fine today. It is a prediction that its center of gravity has already moved, and that the durability of today's pricing and today's free tier past a Databricks IPO is not something to bet a roadmap on.

Where Layerbase is different

Layerbase is the opposite bet. It is not a database company that got absorbed into an analytics platform. It is a multi-engine serverless database cloud, built for developers who want their data layer to stay a data layer.

One platform, more than 20 engines. Lakebase is Postgres, on purpose, and that is the whole product. Databricks itself confirms it supports Postgres exclusively. Layerbase runs more than 20 database engines today, not as a someday roadmap. Your main relational database (PostgreSQL, MySQL, MariaDB, CockroachDB), your cache (Redis, Valkey), your full-text search (Meilisearch), your vector and AI search (Qdrant, Weaviate), your document store (MongoDB-compatible FerretDB, CouchDB), analytics (ClickHouse, DuckDB), time-series (InfluxDB, QuestDB), and more, all provisioned and managed from one account. A typical AI app needs Postgres plus a vector store plus a cache. On Lakebase that is one vendor and two more. On Layerbase it is one create flow.

Branching on most engines, not just Postgres. Neon's branching is a clever trick built on the Postgres write-ahead log, which is exactly why it only works for Postgres. Layerbase branches at the filesystem level, using copy-on-write, so an instant zero-copy branch works across most of our engines, including ones nobody else branches: Redis, Valkey, MySQL, MariaDB, libSQL, DuckDB, and MongoDB-compatible FerretDB. You can spin a full copy of a real database for a preview deploy or a test run in seconds, and it is not limited to Postgres.

Flat-rate, predictable billing. This is the direct answer to the metered-meter problem above. Layerbase plans are a flat monthly price, not a stack of usage meters. You are not separately billed for query compute, sync compute, storage units, and public network transfer, and you are not exposed to a surprise bill because a crawler discovered your site. You know the number before the month starts.

It stays a database platform. There is no lakehouse agenda, no Unity Catalog you have to think about, no enterprise pivot waiting for an IPO. The product exists to host your databases and get out of the way. Layerbase is one of the fastest-growing multi-database serverless platforms on the web precisely because that focus is rare right now: almost everyone else is either single-engine or busy becoming a feature of something larger.

Side by side

Try it in a couple of minutes

If you want to feel the multi-engine part rather than take our word for it, the Layerbase CLI runs the same engines locally with no Docker. (What is SpinDB?)

npm i -g layerbase   # the Layerbase CLI (local + cloud bridge)
npm i -g spindb      # the open-source engine runner underneath

Stand up a real Postgres locally in one command, with a connection string any tool can use:

spindb create my-app -e postgresql --start --connect

CREATE TABLE notes (
  id SERIAL PRIMARY KEY,
  body TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

INSERT INTO notes (body) VALUES ('first note');
SELECT * FROM notes;

Swap -e postgresql for valkey, mongodb, qdrant, libsql, or any of the others to feel how little the workflow changes between engines. When you are ready for a managed instance, the CLI bridges the same workflow to the cloud, and branches come along for free.

When Lakebase is the right call

To be fair, there is a real case for it. If you are already a Databricks shop, your analytics live in the lakehouse, and you want your operational Postgres to sync into Unity Catalog without building ETL, Lakebase is a strong, well-engineered choice and the integration is the whole point. If your databases are an extension of a Databricks data strategy, buy the thing that is built to plug into Databricks.

If your databases are the foundation of your product, that calculus flips. You do not want your data layer to be a feature of someone else's platform, billed on four meters, scoped to one engine, with a roadmap pointed at an enterprise you are not part of.

The short version

Lakebase is good Postgres with a big company attached. The database is fine. The bet you are making is on Databricks' priorities and Databricks' billing model, and history says that bet gets less friendly to small developers over time, the same way Heroku did once Salesforce stopped needing the free tier.

Layerbase is the developer-first version: more than 20 engines instead of one, branching across most of them instead of Postgres only, and a flat monthly rate instead of a meter for every kind of byte. No lakehouse agenda, no surprise egress bill, no enterprise pivot waiting in the wings.

Create a Postgres database on Layerbase, branch it, and add a cache or a vector store next to it from the same account. You can decide which platform you trust with the rest of your stack after you see how the first one feels.