We run Lakebase in client projects in auto refinance, auto equity mining and real estate, and two ceilings shape how we design on it: thirty days of history and twenty concurrently active computes. Neither of those is a Postgres problem. Both are storage engine problems, which is why a team that spent four years building log-structured storage on object storage is the most interesting thing Databricks could have bought this month.
Responsive is joining Databricks to accelerate development of Lakebase and Neon (announcement).
So the question worth asking isn't about the deal. It was which of the ceilings we currently build workarounds for are likely to move, and which ones we should keep designing around anyway.
Why index design is the bottleneck, not Postgres
Lakebase already took the two things a monolithic Postgres keeps on one machine's disk, the write-ahead log and the data pages, and pushed them into separate services called SafeKeeper and PageServer, with the durable copy in cloud object storage (Databricks on the architecture). Once the Postgres compute is stateless, every feature you add on top needs a data structure whose natural home is object storage instead of RAM. That is the hard engineering, and it is the part that gates how fast Lakebase closes the gap with a conventional Postgres estate.
Lakebase Search is one such feature, and Databricks says it took a purpose-built index designed for tiered cloud object storage to make it economical. Every remaining gap between "Postgres has an extension for this" and "Lakebase has an index for this" is the same kind of work; for 100 million vectors, Databricks reports pgvector HNSW needs a 512 GB instance while lakebase_vector runs on a 192 GB one. More people who have shipped it shortens that queue. That is the whole reason this acquisition matters to our roadmap.
Where Lakebase sits in our client builds
The shape repeats across all three industries. An application or an agent reads and writes an operational slice at low latency, lakehouse history sits beside it, and nobody wants to maintain a sync pipeline between the two. Lakebase holds the live slice, Unity Catalog governs it, and an agent's conversation state lives in the same Postgres as the rows it is reasoning about.
The friction never shows up in the SQL. It shows up at the edges, in the limits, and the limits are where a design decision gets made.
The feature gap that changes an architecture
An auto refinance lender buys leads from aggregators, scores each application against a bureau pull and a collateral valuation, and has to answer while the borrower is still on the page. Six weeks later the credit policy changes, so a tier moves, a mileage cut-off moves, and a stipulation gets dropped. Underwriting wants last quarter's declines re-scored under the new policy, against the data exactly as it stood when each decision was made. Auto equity mining asks the same question with a portfolio scan in place of the lead file.
Lakebase can't answer that from its own history. Maximum history retention is 30 days (project limits), so a decision from six months ago is gone and no date picker brings it back.
That single number decides the architecture. Every scored decision is written through to Delta with the feature values it read, and the lakehouse is the system of record for anything an auditor, a regulator or a model-risk reviewer will ask about later.
Build the backtest against Delta and the 30-day ceiling never bothers you. Build it against branches and you find the ceiling in the week somebody asks for a six-month lookback, which in lending is roughly every quarter.
Branch per agent runs out of computes long before branches
Branching is the feature everyone demos, and it earns the attention. Branches share their parent's storage through copy-on-write, so they appear instantly whatever the database size, and creating one has no performance effect on production (branches).
Then you hand a branch to every coding agent, every nightly policy backtest and every developer. The default branch is exempt, so production stays reachable, and computes with scale to zero suspend after idle time and stop counting. The resource you are managing is wakefulness, not branch count.
Two settings keep it honest. Put an expiration on anything ephemeral, because an expiring branch is billed only for the data that changes on it, while a permanent branch is billed for its full data size even if it differs from its parent by a megabyte (manage branches). And set scale to zero aggressively, anywhere between 60 seconds and 7 days, because an idle compute that never suspends is one of your twenty.
A serious per-agent branch strategy wants hundreds of short-lived computes, and twenty with a support ticket for more isn't that. This is the limit I most want the Responsive engineers pointed at.
What I'm hoping this buys our clients
History that lives in object storage at object storage prices, so the restore window stops being a cost dial that tops out at 30 days. Lift the retention ceiling and a chunk of the evidence pipeline I described above becomes optional instead of mandatory, which takes work out of a lending build.
A concurrency model that matches how agents use databases. Not a higher number behind a support request, but computes cheap and fast enough to start that nobody counts them.
Today we decide where the record of truth lives at every project kickoff, and the answer is Delta, every time, for good reasons. I would like that decision to get boring.
None of that is promised. The announcement names no API change, no limit change and no date, and I wouldn't plan a quarter around it. What it does tell you is where the engineering effort is going, and the direction matches the two limits that shape how we build on Lakebase today.
Write the decision record to Delta before you lean on branching
If you are standing up Lakebase this quarter, start there. Pick the schema that holds your scored decisions, have a workspace admin enable the Change Data Feed preview and set REPLICA IDENTITY FULL on its tables so every change to every row lands in Delta, and treat branches as what they are today, which is instant, cheap, excellent for development and recovery, and good for 30 days. Then put expirations on every ad-hoc branch and count your active computes before you promise anyone a database per agent. More on how we build this: /databricks.
Frequently asked questions
What is Databricks getting from the Responsive acquisition?
How far back can Lakebase restore?
Anything older has to come from the lakehouse, which is why decision records belong in Delta instead of in Postgres history.
How many Lakebase branches can be active at once?
Computes with scale to zero suspend after idle time and stop counting against it.
Does Lakebase replace a vector database?
For agent workloads that already keep their state in Postgres, Lakebase Search can serve retrieval from the same database, though Databricks notes that for fully managed search with ingestion, embedding, reranking and quality tuning, Databricks AI Search may be a better fit. lakebase_vector and lakebase_text, in Beta on AWS and Azure, run semantic, keyword and hybrid search in the same database as the operational rows, fused with reciprocal rank fusion in one SQL query.