Side-Stepping The Data Movement Tax: How Fragmented Data Stacks Are Converging Back Onto Postgres

The first real audits of enterprise AI spend are surfacing a line item that has nothing to do with models: the compounding overhead of moving data between systems that were never designed to share state. Every additional data store in the stack means another pipeline to maintain and another version of the truth owned by another team.

For years, the overhead has been tolerable. Legacy architectures separated OLTP from OLAP, bolted on specialized stores for vectors and time series, and accepted the pipeline sprawl as a cost of doing business. The latency showed up in the product but disappeared on the balance sheet, spread across engineering hours that nobody aggregated. The data movement tax was always there. It just didn't have a name until the workloads changed.

Varun Dhawan has spent years watching that tax accumulate. As a Principal Product Manager at Microsoft, he talks to hundreds of Postgres customers every month, most of them migrating off legacy systems that baked fragmentation into the architecture from the start. His recent talk on the data movement tax gave the pattern a framework: start with Postgres, use its extensibility, and only introduce another data store when the value clearly outpaces the movement cost.

Adrien Obernesser sees the same dynamic from the consulting floor. As an Open Infra Consultant at dbi services and an organizer of the PostgreSQL community track at PGConf Europe, he's spent the last three years helping traditional enterprises build AI workflows on Postgres. Most of his work now centers on what teams aren't building: AI observability and the governance instrumentation that stochastic workloads demand.

Sprawl as infrastructure

"Your data is never in one single place," Dhawan told The Read Replica. "If you're using time series, that information sits over there. If you're using vectors, that data sits in vectors. You can't have a transactional database without having an analytical database, and half of your data sits in analytics."

The compounding is what kills you. Syncing those stores requires pipelines and ETL jobs. Pipelines require monitoring. Monitoring surfaces multiply with every store you add. And when multiple systems claim to hold the latest version of the same data, nobody can say which version is current. Dhawan calls this the "quantum state of the data."

His go-to example is banking. Open most banking apps and the last ten transactions show up instantly. Ask for six months of statements and you're waiting five minutes while a separate tab spins. "You can almost make out that these are clearly two different systems," Dhawan said. The customer notices the seam. The bank doesn't fix it, because the seam has been reclassified as infrastructure.

"They've kind of accepted that this data movement tax is just the cost of running business," he said. "It's just COGS." That's the thing about the tax. It doesn't feel like a problem until someone tries to build on top of it.

Consolidate by default, fragment deliberately

Dhawan's counter is a design principle: don't fragment your data stack before you have to. "You always start with Postgres and use its extensibility wherever it fits," he said. "Then you only introduce another data store when the value of adding it clearly outpaces the data movement tax."

Most premature fragmentation starts earlier than the data store decision. Teams reach for specialized data types that require specialized systems when simpler designs would hold. "Sometimes teams are just using many different data types which ask for different data stores when they don't need them. You can just keep things relationally together."

Obernesser arrived at a similar position through an unlikely set of clients. Swiss banks, which are not exactly early adopters, are now moving to Postgres as a primary platform. "Even organizations that are pretty traditional, like banks, are moving away from traditional RDBMS and going full on PostgreSQL nowadays," he told The Read Replica. "Swiss banks are not generally known for being high tech."

His prescription is simple. "Just use Postgres and try to simplify your stack," Obernesser said. The extensibility supports it. A single Postgres instance can serve as a data source for transactional applications and as a data mart on the other side of the lake. That doesn't mean it replaces everything. It means the default should be consolidation, and fragmentation should require a justification that accounts for the full cost of the movement it creates.

The logic extends further than infrastructure. Obernesser draws on the "second brain" concept from personal knowledge management, the idea that an individual can run a productive workflow with one LLM and a few files. Scaling that to the organizational level requires a database with governance and policy on top. "Whether we're going one way or the other, the database is going to be there at some point," he said.

Where allow-or-deny breaks down

Consolidation reduces the surface area, but it doesn't solve governance. And governance is where the gap between traditional workloads and AI workloads gets hardest to paper over.

Traditional database security was binary; a role either had access or it didn't. Allow or deny. That model assumed deterministic outcomes. You connect to your bank account, you see your bank account, you wire money somewhere, it lands where you expected. AI workflows break that assumption entirely.

"In LLM workflows, you could end up with datasets from another company that you shouldn't have access to, that are still in the same database," Obernesser said. The risk isn't unauthorized access in the traditional sense. It's relevance contamination: noise from the wrong data sources degrading model output without triggering any existing alert.

The tooling gap is stark. RAG pipelines offer a deterministic path for controlling what data reaches the model. Agent frameworks don't. "MCPs and skills, the governance layer is close to nothing," said Obernesser. "The only way to implement governance is through RAG processes."

Anonymization makes it worse. Organizations that apply it for compliance also degrade the relevance of their documents for the LLM. And measuring that degradation requires metrics most database teams have never instrumented. "You need to understand whether you're getting more noise than anything else," Obernesser said. Tracking that means bringing information retrieval metrics like NDCG, precision, and recall into database operations, a domain where they've never lived before.

Obernesser sees AI observability as a precondition for production deployment, not something teams can bolt on after shipping. The shift from deterministic to stochastic workloads means the old binary of allow-or-deny is structurally incapable of catching the failure modes that matter.

Batch won't cut it

Even with governance instrumented, the data has to arrive on time. Stale embeddings are a governance problem, because versioning and policy enforcement depend on freshness.

"Streaming of data is going to be a requirement," Obernesser explained. "You're going to need embeddings that are refreshed, that are versioned, that are fed throughout the policy." He points to CDC pipelines built on Debezium and Kafka as the infrastructure that makes embedding freshness operationally viable. Teams still running batch ETL are building on a lag they can't afford once the LLM is in the loop.

The token economics sharpen the case. Dhawan sees tokenmaxxing as a forcing function for architectural simplification. Teams that consolidate their data can tier their workloads: tasks that don't need an LLM at all, tasks that work with cheaper models, and edge cases that justify frontier-model spend. That tiering only works when the data is consolidated enough to make routing decisions at the application layer.

"Not everything needs AI to begin with," Dhawan said. "And not everything needs your highest model doing everything. You can have things done without an LLM because they're just basic intelligence derived from your data when your datasets are together."

The forcing functions are converging. Streaming keeps embeddings fresh enough for governance to hold. Consolidation keeps the architecture simple enough for token economics to work. "Simplification of architecture has to happen," Dhawan said. "You just cannot accept this to be cost of doing business any longer."

The next bill is already running

The data movement tax was invisible when every workload was deterministic and every system spoke only to itself. AI made it visible by demanding freshness, governance, and observability from infrastructure that was never wired to provide them.

Consolidating on Postgres by default and fragmenting only when the value clearly outpaces the cost is becoming the operational baseline. Agent workflows and MCP-driven architectures are proliferating faster than the governance tooling can follow. Teams that skip the instrumentation, the streaming pipelines, and the observability layer before deploying agents into production are running up the next tab. The difference is that this time, nobody will be able to claim they didn't see the bill coming.