Pretty sure LinkedIn these days exists solely for the data platform wars. Databricks has LTAP, Snowflake has CoCo, and apparently we all need strong opinions about which storage format will ultimately win.

The short version of the latest front in this war: Snowflake and Databricks are both pitching some version of “Postgres plus lakehouse,” while using similar words to describe very different things.

LinkedIn has no shortage of data engineers with strong technical opinions here, and it probably isn’t surprising that data engineers will focus on those details to the point of either occupational hazard or over-complication, depending on where you sit.

I’m not going to rehash those arguments here. I want to talk to the person who has to sign the contract.

Two Platforms, Two Completely Different Bets

Snowflake’s approach with pg_lake leaves the underlying Postgres database engine largely untouched. It adds a foreign data wrapper above Postgres, so you can define tables that live as Parquet files in object storage without fundamentally changing the OLTP engine underneath it. It’s additive and relatively non-invasive, and your transactional workload doesn’t suddenly need to understand that anything changed.

The Databricks approach with Lakebase is a much bigger architectural bet. The SQL surface still looks like Postgres, with the same locking concepts, familiar planner behavior, and the same general developer experience – but the database storage architecture underneath is different. The transaction log doesn’t behave like it would in a normal Postgres deployment, pages aren’t tied to local disk in the same way, and compute becomes effectively stateless.

It’s interesting engineering, which only means you shouldn’t be surprised which model data engineers are going to find more exciting because, well, complex tools have historically been very good for DE salaries.

Both vendors call it Postgres, and both are technically justified in doing so. The more useful question is where it stops behaving like the Postgres you think you’re buying, because that’s the boundary you don’t want to discover at 2am when something breaks.

Again, go read LinkedIn if you want the engineering debate. Plenty of people have strong opinions on which architecture is better, cooler, more scalable, more elegant, or more whatever.

I’m interested in the layer above the engineering.

Why Would You Run OLTP on Either of These?

Seriously.

Let’s stop and ask the question that tends to disappear while everyone is marveling over the architecture, because it’s probably the first question a data leader should actually be asking.

Snowflake and Databricks grew up as consumption-priced analytical platforms. The basic economic model makes sense for episodic analytical workloads: a data team refreshes transformations, a finance team runs month-end reporting, a data scientist trains a model, or users hit dashboards throughout the day.

You provision compute, use what you need, let it scale back down, and pay for the capacity you consumed. Fair enough.

OLTP is a very different kind of workload. Billing, inventory, maintenance records, customer lookups, orders, payments, and all of the other boring things that actually run the business are usually made up of thousands of small transactions arriving constantly, often concurrently, and with much less tolerance for latency or interruption.

Once you put that kind of workload onto a consumption model, you have changed the economics of your operational environment, because your core business activity now starts looking a lot more like a metered service.

Data engineers can marvel at the architecture all they want, but it gets a lot less interesting when your EBITDA becomes a function of your organization’s SQL query hygiene.

The Bad Query Problem

And let’s drop the facade here.

Every organization has that analyst – you know, the one who writes a Cartesian join against a ten-million-row table, or the query with 18 nested CTEs, and then walks away for lunch.

In SQL Server, Postgres, MySQL, or Oracle, that’s mostly an operational problem. Your DBA gets paged, somebody finds the query, kills it, conversations are had, and life goes on.

On a consumption-priced platform, the same mistake can become a financial problem too.

Now your CFO is suddenly very interested in SQL syntax, and your explanation is going to be some version of “someone wrote a bad join”.

From a leadership perspective, that’s a terrible place to sit, because the data leader is now stuck somewhere between throwing a team member under the bus or taking responsibility for a cost event caused by an operational mistake.

Neither option is especially attractive, and more importantly, this is not a conversation you want to have with your CFO, executive team, or board.

Predictable Cost Is a Feature

Traditional RDBMS infrastructure – SQL Server, Postgres, MySQL, Oracle – tends to be capacity-based. You generally pay for the server or infrastructure whether it’s sitting at 20% CPU or 80% CPU, which also means you’re paying for idle compute and usually carrying some amount of capacity buffer that you may never fully use.

That can sound terribly inefficient in a vendor meeting, particularly when everyone is nodding along to the Liberty Mutual-ish sales pitch of “only pay for what you need.”

But here’s what you’re actually buying: a known, fixed, and budgetable number.

Most mid-market companies value predictable cost structures far more than technology vendors like to admit. Your CFO can model a fixed infrastructure expense, they can model planned increases in capacity, and they can budget for licensing changes over time.

What they cannot meaningfully model is “how bad will our SQL developers and analysts be this quarter?”

Capacity pricing also creates a useful economic separation between application growth and infrastructure cost, because transaction volume can grow materially before you necessarily have to increase infrastructure proportionally. And, a bad operational month doesn’t automatically become a finance event.

The idle compute objection is legitimate, but I think it’s usually presented without enough nuance. There are absolutely cases where a consumption model is the right choice, but there are also cases where paying some (fixed) delta above expected usage isn’t waste at all.

Sometimes that premium is really just insurance against ugly surprises.

Wait, So You’re Saying Don’t Use Snowflake or Databricks?

Hold up there. Not what I’m saying.

This really isn’t complicated. It’s just not as interesting as what the vendors would prefer to sell you, because they need to grow and these days that seems to mean eating into your transactional data workloads.

Use SQL Server, Postgres, MySQL – pick one – for traditional OLTP workloads. Stable, predictable, operationally mature, and full of failure paths that people have already spent decades understanding. (Yes, even Oracle if you’re allergic to money but really want somebody to answer the phone at 2am.)

Then put Snowflake or Databricks downstream as your analytical platform, because that’s where their economic model actually makes sense. Analytical workloads really can be episodic. They can be scheduled, isolated, scaled independently, governed with workload controls, and tuned based on your organization’s tolerance between latency and cost.

The architecture then becomes pretty straightforward: operational systems run the business, analytical systems analyze the business, and data moves deliberately between them.

Your operational environment isn’t paying a metered tax on every business transaction, while your analytical environment gets the elastic compute model that actually benefits from it.

Boring architecture, clear separation of concerns, and completely defensible to your CFO, executives, and board.

Yes, It’s Your Job To Ask Upfront

When Snowflake or Databricks shows up – and they will show up – the useful question isn’t whether their new database offering is Postgres-compatible, because both of them can answer yes to that question and be technically correct.

Your job is to figure out where the platform stops behaving like the Postgres you think you’re buying, and whether that boundary actually makes sense for your workloads – because assumptions around storage, transaction processing, durability, state management, failover, recovery, and operational behavior can change in ways that aren’t especially obvious.

And then ask the question your CFO will actually care about:

What’s our worst-case monthly bill if something goes wrong?

Not the happy-path estimate, or the one that assumes perfectly optimized architecture. The bad month with the runaway workload, the unexpected traffic spike, the poorly written query, the configuration mistake…or all of them.

Because once you get past the cool engineering, you have to decide what kind of problem you actually have when something goes wrong, and then how to limit that downside.

As data leaders, our job is to keep failures in the operational layer, where fixing them is a technical discussion. We shouldn’t let interesting engineering turn the mundane into a finance event.

–Scott