Where does the OLTP boundary belong now?

For two decades the OLTP/OLAP boundary drew itself: different engines, different vendors, a pipeline between them. That era is ending as a product strategy. Databricks' Lakebase reached general availability in February: serverless Postgres inside the analytics platform, with branching, autoscaling and the catalog's governance. The compatibility documentation is honest about the edges, and the direction across the industry is unmistakable. The wall now has a door, and someone in your organization is already proposing to walk through it.

The architecture question is not whether the door is real. It is which workloads belong on which side, and the answer follows from a distinction the marketing collapses: transactional workloads differ enormously in what they demand from their substrate.

what would have to be true to move a workload through?

Three conditions, checkable per workload. Its latency requirements are ordinary: interactive-tool latency, not payment-path latency, because a platform's serverless tier is engineered for elasticity first. Its extension and feature surface fits the platform's documented compatibility, verified against your actual schema and libraries rather than the checklist ("Postgres-compatible" is a spectrum, and capacity models fail at exactly these seams). And its coupling to analytics is real: the workload's data feeds the warehouse today through a pipeline someone maintains, so moving it deletes an operational cost rather than relocating one.

Workloads that pass all three, agent state, internal tools, the operational stores born to feed dashboards, gain from the move: one governance model, no sync pipeline, and state that lives where it is analyzed.

what stays behind the wall?

The core transactional path, on current evidence. Not because the new engines are Postgres in name only (they are closer than the skeptics say) but because the failure domains differ. Your order path's availability math should not inherit the analytics platform's maintenance calendar, billing model or region strategy, and a boundary that isolates failure domains is doing architecture's oldest job. The tradeoff priced both ways: keeping the wall costs a pipeline and a second operational surface; removing it entirely couples your revenue path to a platform optimized for a different physics. We have yet to review an estate where that coupling priced out favorably, and we have reviewed several where nobody had priced it at all.

The review deliverable, one page: your transactional workloads in three columns, moves-now, moves-when-verified, stays-on-purpose, each row with the failing or passing condition named. The door in the wall is genuinely useful. So is knowing, in writing, why the ledger is not walking through it.