Operational data is where a business becomes real. An order moves from pending to confirmed. Inventory is allocated. Money changes hands. A claim is approved. Behind each event is data that has to be correct, available when needed, recoverable when something fails, and served with enough performance for the systems around it to do their job.

Enterprises have spent decades getting good at this. Mature databases enforce transactional correctness. Clustering and replication improve availability. Backup and recovery protect against failure.

Redgate’s 2026 survey found that 84% of organizations manage two or more database platforms. Different applications arrived at different times. Acquisitions brought their own systems. Every large database estate feels like a snowflake, and in practice, it probably is. But underneath the variety, there is a common problem worth naming clearly: Infrastructure has become very good at executing configuration and much less good at continuously proving that the resulting state still satisfies the intent originally attached to it.

I spend most of my time thinking about persistence for critical business applications. What follows is where I have landed on what a persistence layer needs to do for these systems today, and where I think it has to go next.

Configuration correctness is not outcome correctness

Operational systems carry requirements. A database has to recover to a certain point within a certain time. It has to remain available. It has to hold its performance envelope. It has to be protected in a certain way. Those requirements exist above the individual infrastructure objects and are usually satisfied by many of them working in combination.

Each of those objects can be independently configured to look correct. That is what infrastructure teams and administrators are trained to do, and what most tooling helps them do well. Protection policies are configured. Replication topology is defined. Backup jobs are scheduled. Performance policies are set. Each piece checks out.

The gap opens when the environment changes. A volume is added. A workload is consolidated. A dependency moves. A component is upgraded. Each change is itself valid at its own layer, and each is applied through the correct process. But the higher-level requirement was not being continuously re-evaluated as the underlying state changed.

Intent belongs to the data

The reason the gap opens is simpler than it looks. Intent is encoded in the wrong place.

A protection group, replication relationship, QoS policy, or backup schedule is how a requirement is satisfied at a particular point in time. It is not the requirement itself. When the implementation changes, the requirement has to survive independently of it. If applications, infrastructure, and consumers can all change, the requirement needs to remain attached to the thing those systems are ultimately serving: the data.

The application can change. The consumer can change. The infrastructure can change. The data and the requirements attached to it are the one thing that has to endure those changes. That is data primacy.

The data carries the intent, and every layer that serves it has to prove it is still honoring its part.

That means intent should be encoded with the data, not with the infrastructure that happens to serve it. Performance, protection, recovery, retention, placement, and access requirements are not properties of the infrastructure. They’re properties of the data, expressed as machine-understandable commitments that persist as applications and infrastructure change around them.

Every layer does not need to own the entire business outcome. It does need to understand which part of that intent it is responsible for and continuously prove that it is honoring it.

When intent lives in the wrong place

When intent is encoded in infrastructure configuration rather than with the data, each configuration can be individually correct while the commitment it was supposed to satisfy has quietly stopped being met.

Let’s look at two examples:

In a large financial services environment, an annual disaster recovery (DR) test revealed that the recovery site could no longer support the full mission-critical workload it was expected to carry. Whatever series of individually valid changes accumulated to that point, the DR test was the moment the gap between configuration and outcome became visible.
In a large database environment, backup jobs had grown beyond 24 hours and were routinely overrunning the window they were supposed to fit within. The backup requirement had not disappeared. The environment had simply evolved to the point where the existing configuration could no longer satisfy it.

Neither story proves that any specific layer is the wrong place to manage. Both point at something more general: Configuration correctness is what much of today’s operational stack is optimized to validate. Outcome correctness—whether the changing set of configurations still adds up to what the business was promised—is what it is not yet designed to prove continuously.

To ground this in specifics: consider an Oracle database using ASM. ASM can absorb changes inside the disk group. As disk groups expand, it rebalances data across the new storage automatically. What it does not automatically prove is that external snapshot, replication, or recovery policies still cover everything the database now depends on. What is missing is a continuous way to check whether the protection and recovery state still matches what the database now depends on.

Figure 1: Change request impact.

Correctness ultimately comes down to which component can commit to which guarantee. Storage systems work in terms of volumes, LUNs, protection groups, consistency groups, and similar constructs. These are necessary. But they are not the level the business made a commitment at.

The commitment lives above the individual infrastructure object, at several layers of the stack. Take an online banking service with a 30-minute recovery objective. That requirement translates down through its applications, its databases, and the persistence underneath. Each layer legitimately owns part of the answer.

The persistence layer does not need to claim ownership of the top-level outcome. It needs to be much better at answering a narrower question:

Given the intent that concerns the data I am responsible for, is my part of the system still delivering what it needs to?

It does not require the database to be the ultimate business abstraction. It requires the persistence layer to know enough about the workload to be accountable for its own part of the answer. That accountability is what we’ve been building toward.

Everpure reduces change friction for business-critical applications

For a decade, Everpure has supported business-critical applications by absorbing change underneath the workload so infrastructure events do not automatically become business disruption events. The best changes are often the ones the workload never has to notice.

We give databases performance and capacity headroom so growth does not automatically become a migration project. We reduce and consolidate data so multiple workloads can share footprint without creating new silos.
We make copies fast and space-efficient enough that your development teams can test at real scale without multiplying storage footprint every time. We make recovery work at the size your database has actually reached, not the size it started at. That matters more than it used to. Uptime Institute’s 2026 outage analysis reports that 57% of surveyed organizations said their most recent major outage cost more than $100,000, and one in five said it cost more than $1 million. Continuity is not a soft requirement.
We refresh underlying technology without forcing the operational data to move, so an infrastructure lifecycle event does not automatically become a database project. We give teams fleet-level tools to apply and maintain consistent policy across a portfolio of environments.
When the same operational data becomes valuable to fraud models, forecasts, analytics, vector search, and AI agents, we make it available for those new uses without forcing the source database to absorb every new access pattern directly. Databricks notes an important constraint: CDC itself can add load to production databases, which is one reason some teams use snapshot cloning workflows instead.

These are different ways of keeping changes in scale, use, and infrastructure from creating unnecessary change in the database environment itself.

Figure 2: Everpure decouples infrastructure change from business change.

Meanwhile, operational databases themselves are taking on new work, with vector types, embeddings, and semantic search increasingly sitting alongside transactional workloads. The challenge is no longer only keeping operational data available to the application that created it. It’s making that data useful to more consumers, including AI, without compromising the system that still depends on it to run the business.

From absorbing change to proving outcomes

Absorbing change is where much of the value comes from today. The next step is making persistence aware of whether the workload is still getting what it needs.

The persistence layer that serves a database should:

Know which infrastructure is serving which data and workload, so the requirements associated with that data can be evaluated against the complete set of dependencies rather than isolated infrastructure objects.
Continuously check whether the current state still satisfies those requirements.
Surface drift before an event forces it into visibility.
Over time, help close the gap rather than just report it.

None of that is a break from what persistence already does. It’s the same architectural instinct applied to what the database actually needs, not just what its underlying storage is configured to do.

Data primacy for operational databases

Everpure already absorbs much of the change that would otherwise reach the workload. The question is what changes architecturally when that principle is taken further. The answer starts from a simple idea: The data is the durable asset.

For persistence, data primacy means becoming accountable not only for whether storage is configured correctly, but for whether the data it serves is still receiving what it requires. That is a shift in what success is measured against.

This was always the right principle. AI makes it urgent. As operational data feeds more consumers, as databases take on vector search and semantic workloads alongside transactions, and as applications and infrastructure change faster, the number of things that change around the data accelerates while the requirements attached to it still have to hold. That is the practical case for treating the data as the durable thing and organizing the architecture around it.

The underlying mechanics do not disappear. What changes is the organizing principle. Instead of building upward from infrastructure objects and inferring that the workload must therefore be fine, persistence starts from the requirements attached to the data and continuously evaluates whether the layers underneath still satisfy them.

Figure 3: From infrastructure-up to data-out.

Once intent is durable and machine-understandable, the storage implementation can progressively disappear from the workload owner’s view. New consumers can arrive and infrastructure can change without requiring the workload owner to redesign around storage primitives. The persistence layer can reconcile those changes underneath the data while continuously proving that the requirements attached to it still hold.

That is a direction, not a destination. It’s what separates infrastructure that executes what you asked for from infrastructure that keeps proving what you asked for is still happening.

What would have to change?

Pick one critical operational database. Not the newest one. Pick one that has been running for several years and has changed a few times since it went live.

Ask what must be true about it today:

Its RPO
Its RTO
Its performance envelope
Its availability
Its retention period
Its protection and resilience requirements
Where copies are allowed to exist

Then ask a harder question.

Can you prove, right now, that the actual state of the environment still satisfies each of those requirements?

If that is difficult, the problem may not be that anything is misconfigured. It may be that no part of the system is continuously proving that the ensemble of correct configurations still adds up to the outcome you asked for.

The estate will keep changing. So will the business. The important question is whether the architecture can continuously tell when actual state has stopped matching intent. If that question is uncomfortable for a database that matters, start there.