Your analytics vendor now sells your database too

For twenty years the transactional database and the analytics platform were different purchases. Different vendors, different budget lines, different failure modes. That boundary is now a product strategy, and it is being dissolved from the analytics side.

Lakebase reached general availability on AWS in February: a serverless Postgres running inside Databricks, with branching, point-in-time recovery and Unity Catalog governance. Azure followed, and since March every new instance autoscales by default. Snowflake is walking the same road from its own direction. The pitch is one platform, one governance model, no pipeline between the app and the analysis.

The pitch is not wrong. It is simply not addressed to you. It is addressed to the vendor's revenue line, and it happens to overlap with a real architectural benefit. Both things are true, and a selection process has to hold both.

what this changes in a review

Two of our standing review questions get new answers this year.

"How does operational data reach the warehouse" used to be a pipeline discussion: CDC, connectors, sync lag, a vendor in the middle. If the operational store is inside the platform, that pipeline shrinks to a catalog entry. Real simplification, measurable in headcount hours. We have watched teams spend a quarter of an engineer on exactly this plumbing.

"What is the blast radius of leaving" gets worse by the same amount. When the platform holds your analytics, your semantic layer and now your application databases, the exit is no longer a data migration. It is a re-architecture. Price that before signing, not after. Ask for the day-one exit story in writing, per workload class.

the order that doesn't hurt

Nobody should migrate their core transactional system into an analytics platform as a first move. The workloads that belong first are the ones born next to the analytics: agent and application state for AI features, internal tools, the operational stores that already sync into the warehouse daily anyway. They are low-risk, they remove real pipelines, and they teach you the platform's operational behavior while the stakes are small.

The core OLTP, the one processing orders at 2 a.m., moves last or never. "Never" is a legitimate architecture. Postgres compatibility claims deserve their own verification against your actual extension list, not the vendor's compatibility page, and transactional latency SLAs deserve a load test with your write pattern, not theirs.

the procurement note

Converged platforms convert an architecture decision into a renewal lever. Every workload you move in strengthens the vendor's position at the table; that is neither good nor bad, it is a price, and it belongs in the business case next to the pipeline savings. Our rule of thumb: the convergence discount is real for the first two workload classes and imaginary after that, because by the third one you have stopped comparing alternatives.

The deliverable version, one week of work: inventory the operational stores that feed analytics today, with the pipeline cost of each in hours per month. Mark the ones the analytics platform could absorb this year. Load-test one candidate, agent or internal-tool state, against the platform's serverless tier. Take the results and the written exit story into the next renewal. Walk in knowing which workloads move, which stay, and what the difference is worth in dollars. The vendor has done this math already. Do yours.