Your Lakehouse Vendor Is Now Selling You Postgres. The Workload Is Real, the Bundle Is Optional

On 16 July 2026, Databricks announced it had signed a term sheet for a strategic funding round at a $188 billion valuation, led by existing investor Coatue and expected to close later in the summer. The Wall Street Journal reported the raise at roughly $3 billion; Databricks has not confirmed that figure, and no IPO was signalled.

The number is not the interesting part. The allocation is. The company named three destinations for the capital: Unity AI Gateway, Genie, and Lakebase — which its own press release describes as “a serverless Postgres database built for AI agents.”

Read that again with an architect’s eye. The company that spent a decade telling you to stop running analytics on your operational database is now selling you an operational database.

That is either a genuine architectural correction or a moat. It is worth working out which, because the answer changes what you build.

The case for: agents produce a workload OLAP engines are bad at#

Start with the honest version of the argument, because it is stronger than the cynical read allows.

An analytical engine — Databricks SQL, Snowflake, ClickHouse, any of them — is built around a specific bet: read a lot of rows, touch few columns, amortise the cost over a big scan. Columnar storage, vectorised execution, large immutable files. That bet is correct for the workload it was designed for and badly wrong for the one agents generate.

Watch what an agent actually does over a single task. It reads its own memory for the session. It writes a scratch record after each tool call. It appends to a trace log. It checkpoints state before a risky step so it can resume. It looks up one entity by primary key, then another, then another. It holds a conversation across ten minutes and forty writes, most of them tiny, all of them needing to be visible to the next read immediately.

That is a few hundred single-row reads and writes, each wanting to return in under 10ms, each needing read-your-own-writes consistency. On a warehouse this is close to pathological: metadata overhead per query that dwarfs the work, small-file accumulation that degrades every subsequent scan, compaction fighting your write path, and a bill priced for scans you are not doing. Teams that try it end up building a write-buffer in front of the warehouse — a slow OLTP database with extra steps.

So the split is real. Agent state is an OLTP workload and belongs in an OLTP engine. Anyone telling you otherwise is selling you their scan engine.

The second half of the argument is subtler and better. Agent state is not scratch data. Tool-call logs are audit evidence. Checkpoints contain whatever the agent read to make a decision — which, in a regulated setting, is the record of why the system did what it did. Memory tables accumulate customer data by accretion, quietly, without anyone declaring a schema.

In most deployments this lands in a side database nobody governs — no lineage, no column-level access control, no retention policy, not in the catalog. Then someone asks which systems hold patient identifiers and the answer is wrong, because the agent’s memory table was never on the list.

Putting agent state behind the same catalog as everything else fixes a real problem. That is the strongest thing you can say for Lakebase, and it is not nothing.

The case against: this is Postgres, and it has been available for thirty years#

Now the other side.

Postgres is not scarce. You can run it on RDS, Aurora, Cloud SQL, Neon, Supabase, or a machine you own, and every one of those will serve an agent’s point lookups at single-digit milliseconds without any assistance from a lakehouse vendor. Branching, autoscaling, scale-to-zero — the features usually cited as the differentiator — shipped in the serverless Postgres market before this and are converging fast.

The engine was never the interesting part. The governance boundary was. And a governance boundary is a design decision, not a product you must buy from one supplier: catalog registration, a lineage graph that includes your operational stores, column policies that apply wherever the data sits. Several routes get you there and some do not involve moving your transactional system.

Then there is the part nobody puts on a slide. Integration is the value proposition and integration is the switching cost — those are the same sentence. Once your agents’ operational state lives inside your analytics vendor’s catalog, with their identity model, their branching semantics, and their pricing meter, you have coupled the system-of-record path of your product to the commercial decisions of a company whose main business is something else. That is a real dependency and it is the kind that surfaces at renewal, not at design time.

The competitive read is also plain enough. Snowflake is pushing on transactional and app-hosting surfaces. The serverless Postgres vendors are pushing up into analytics. Everyone is trying to be the single catalog, because whoever owns the catalog owns the account. Lakebase is a good product move in that fight. That does not make it your architecture.

Where we land#

The workload split is real. The vendor consolidation is the weaker half of the argument.

Our decision rule, in three lines:

Put agent state in Postgres. Memory, checkpoints, session scratch, tool-call logs, queues. Row-level transactions, sub-10ms lookups, immediate consistency.

Put analytics in the lakehouse or the columnar engine. Aggregates, historical trend, model training sets, everything scan-shaped. For most of our Data Platforms work that is ClickHouse with Airflow and dbt around it — fast, cheap per query, and no ceremony to move data out when you want to.

Decide the vendor question separately, on one criterion: do you need a single catalog to span both? If your compliance surface genuinely requires that the agent’s memory table and the warehouse fact table live under one lineage graph and one policy engine, the bundle earns its price. If you are buying it for convenience, you are paying a coupling cost for a problem you could have solved with a catalog integration and a retention policy.

Most teams we work with are in the second group and have not asked the question.

The concrete version: a ward and an analytics team#

Take a Hospital Management System, because it makes the boundary impossible to fudge.

The operational database serves the ward. Admissions, bed state, medication administration, order status. Writes are small, constant, and must be correct at the moment a nurse reads the screen. That is Postgres. It has always been Postgres.

The lakehouse serves the analytics team. Readmission rates by cohort, theatre utilisation, staffing models, twelve months of history scanned in a dashboard. Columnar, batch-loaded, tuned for scans.

Now add an agent that drafts discharge summaries and flags follow-up risk. It needs both — the live record for this patient right now, and the historical model output computed overnight. And it produces a third thing: its own state. Which documents it read, what it drafted, which clinician amended it, where it stopped and resumed.

That third category is where the architecture is decided. It is operational in shape and audit-critical in consequence. It goes in Postgres, next to the record it describes, inside the same transactional boundary — so when a clinician amends a draft, the amendment and the agent’s trace commit together or not at all. Then it replicates to the analytical side on the same schedule as everything else.

The same shape holds in a School ERP: attendance and timetabling in the transactional store, five years of outcomes in the columnar engine, and the agent that drafts parent communications keeping its state with the transactional side. This is not a new pattern. It is the pattern, with a new writer.

Where legacy vendors get this wrong is not the topology — it is that their operational stores are hard to read out of and their analytics stores are hard to leave. You end up with data trapped in two places at once and an integration bill in the middle. Any AI implementation worth deploying assumes the agent’s state will outlive the tool that wrote it.

The SQL converter is a different problem than it looks#

The same week, Databricks shipped an agentic code converter in Beta — T-SQL, Snowflake, Redshift, Oracle, BigQuery and Teradata into ANSI SQL, powered by Genie Code, analysing each script, validating syntax and semantic intent, and iteratively fixing errors. (July also brought Scala and Java UDFs registrable in Unity Catalog to GA, and a Veeva Vault connector in Lakeflow Connect Beta using Veeva’s Direct Data API.)

Migration teams will read the converter as a translation tool. It is not. Translation was never the hard part of a warehouse migration — a competent engineer can rewrite Teradata SQL, slowly. The hard part is proving the rewrite returns the same answers, and no amount of model quality removes that obligation. A converter that is right 97% of the time on ten thousand scripts hands you three hundred silently wrong reports.

So the engineering that matters is the harness around it, and it is unglamorous: pin a fixture dataset that exercises your actual edge cases — nulls, ties in window functions, implicit casts, timezone-sensitive dates, division by zero, the dialect-specific empty-string-versus-null behaviour that bites every Oracle migration. Run both the original and the converted query against it. Compare full result sets row by row, with deterministic ordering, not row counts and not spot checks. Fail the build on any divergence and route it to a human.

Do that and the converter is genuinely useful — it removes the tedium and leaves you the judgement. Skip it and you have automated the production of plausible SQL, which is the worst possible artefact. This is the general shape of good Operational Automation: the model does the volume, the harness owns the correctness, and the two are built by different people.

---

Agents need transactional state; that is settled. Who sells you the database is not. We design the boundary between operational and analytical stores so it survives your next vendor decision. Tell us what your agents are writing.