{"id":5950,"date":"2026-08-17T18:33:15","date_gmt":"2026-08-17T18:33:15","guid":{"rendered":"https:\/\/www.odbms.org\/blog\/?p=5950"},"modified":"2026-08-17T18:33:16","modified_gmt":"2026-08-17T18:33:16","slug":"why-enterprise-ai-needs-a-different-data-layer-david-flower-on-agents-acid-and-the-honest-state-of-production-ai","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2026\/08\/why-enterprise-ai-needs-a-different-data-layer-david-flower-on-agents-acid-and-the-honest-state-of-production-ai\/","title":{"rendered":"Why Enterprise AI Needs a Different Data Layer: David Flower on Agents, ACID, and the Honest State of Production AI<\/strong>"},"content":{"rendered":"\n

“ACID was, and will always be, the right answer to concurrent state access. Agentic AI just made ignoring it expensive instead of theoretical.”<\/em><\/em><\/p>\n\n\n\n

Q1.<\/strong> When we last spoke in December 2017, you had just repositioned VoltDB around “translytics” \u2014 the combination of real-time transactions with real-time analytics \u2014 and you were seeing early adoption in fraud detection, telecoms, and mobile gaming. Eight years later, Volt Active Data is positioning itself squarely around AI infrastructure. Walk us through the honest version of that journey: what changed in the market, what changed in the product, and what stayed fundamentally constant about the core problem you are solving?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  <\/strong>Eight years is a lifetime in this industry, so let’s be precise about the timeline. AI wasn’t a mainstream market disruptor until late 2022, when ChatGPT changed the conversation overnight. Back in 2017, translytics (the fusion of transactions and analytics) was itself early in both development and adoption. That trend hasn’t gone away; look at where every major data platform provider, including Databricks and Snowflake, is now heading. There has always been a desire to interact with data, whether in stream or table form, to extract value or act on it in real time. AI simply added another dimension to that same objective.<\/p>\n\n\n\n

So we didn’t pivot to AI. The fundamentals we’re built on, which have always been about deciding correctly the instant a transaction happens, went from a niche requirement to a universal one. That shift made those fundamentals more necessary, not less relevant.<\/p>\n\n\n\n

What we have done, however, is expanded our capabilities to meet market requirements. We added cross-data-center replication (XDCR), elastic scaling, zero-downtime upgrades, and now integration with AI through MCP-tool access, so agents can query us directly instead of hitting a stale replica.<\/p>\n\n\n\n

In 2017, the problem was closing the gap between a transaction and its analysis. Today it’s closing the gap between an agent’s reasoning and an authoritative answer. It’s the same gap. It’s just that a lot more people have it now.<\/p>\n\n\n\n

Q2. <\/strong>Volt has been positioning itself around AI, but you are a database company. Critics would say this is just another vendor jumping on the AI bandwagon \u2014 that the category label has changed but the product has not. Make the case against that criticism. What has genuinely changed in Volt Active Data’s architecture and capability since 2017 that makes it a different product for a different era, not just a rebranded one?<\/strong><\/em><\/em><\/strong><\/p>\n\n\n\n

David Flower:  <\/strong>It’s a fair generalization to make about this market. We’ve all watched companies bolt the word “AI” onto their name or their elevator pitch. The difference is that we’re demonstrating AI’s value inside our product, not inside a slide deck. We built on our own foundations, but added new capabilities designed specifically for how agents behave differently from humans, and differently from the ML scoring workloads we served before.<\/p>\n\n\n\n

Here’s the concrete version. The world has moved a long way since 2017, notably toward streaming and Kafka as the de facto way to move events around, rather than building complex native database applications to handle every transaction. Volt evolved with that shift, expanding from a pure transactional database into a data platform that ingests from many sources at once, including streams and traditional database clients. That makes us appropriate for deployments that need both working against the same dataset simultaneously.<\/p>\n\n\n\n

That matters specifically for agents, because an agent reasons on whatever context it’s given, and the most current, real-time view of the world is typically whatever’s held in memory, which is exactly what Volt maintains. MCP is the protocol agents natively use to reach out to external systems like Volt and pull real-time context into their reasoning. Building clean, fast, structured access to live operational state for that purpose, and not just for storing data faster, is what’s genuinely new here.<\/p>\n\n\n\n

Q3.<\/strong> You talk about ACID compliance as critical for AI agents. Most people associate ACID with traditional transactional databases, not AI infrastructure \u2014 and many of the most prominent AI data platforms deliberately trade off consistency for speed and scale. What is your reasoning for why ACID matters for agentic AI specifically, and what actually goes wrong in an AI agent workflow when the underlying data layer is eventually consistent rather than fully ACID-compliant?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  <\/strong>First, it’s worth saying that “transactions” aren’t only financial. A transaction is any multi-step business operation that either fully happens or fully doesn’t. That idea applies just as much to a network capacity allocation as it does to a payment.<\/p>\n\n\n\n

Take a non-financial example, such as an agent managing capacity for a network slice. The agent reads current available bandwidth, reasons about it, and recommends granting a new slice to a customer. If another process commits a competing allocation in the milliseconds between the agent’s read and the action executing, the agent’s recommendation was made against a fact that is no longer true by the time it matters. That’s a classic dirty read, and isolation (the “I” in ACID) exists specifically to prevent it.<\/p>\n\n\n\n

Another shift is the read\/write ratio. Early AI workloads were read-heavy: ask a model a question, get an answer back. Multi-agent systems are read-write. Agents are constantly writing traces, checkpoints, and intermediate decisions, often concurrently with other agents touching the same state. That reintroduces every classic concurrency problem distributed systems theory already solved.<\/p>\n\n\n\n

And real business transactions are rarely as simple as “add to this, take from that.” They’re often many conditional steps forming a single logical operation. An agent reasons with whatever state it sees at the moment it looks. It doesn’t wait around to see how a complex transaction eventually resolves. So the state it sees must be meaningful. From the business’s perspective, a complex transaction either fully happened or it didn’t. A half-completed mess isn’t a valid state to reason from, which is exactly why it should be completed or rolled back, never left in between. ACID’s atomicity, consistency, and durability guarantees are what ensure an agent is always reasoning from a state that actually means something.<\/p>\n\n\n\n

ACID was, and will always be, the right answer to concurrent state access. Agentic AI just made ignoring it expensive instead of theoretical.<\/p>\n\n\n\n

Q4.<\/strong> Volt claims sub-10ms latency with full ACID compliance at scale. Google Spanner and Amazon Aurora are widely considered the benchmarks for distributed consistency at cloud scale, and CockroachDB and YugabyteDB are both well-funded and technically serious. Where does Volt genuinely lead, where does it genuinely trail, and what is the architectural reason for each \u2014 not the marketing answer, but the honest engineering one?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  <\/strong>The honest starting point is that none of these systems are doing our job better or worse than us. They’re solving different problems, with different trade-offs made at different points in the stack.<\/p>\n\n\n\n

Spanner’s own published numbers are roughly 10ms reads, and 50ms writes. That’s their number, not a knock. It’s the cost of TrueTime coordinating a globally consistent clock across continents, and it’s a genuine engineering achievement for that specific problem. We’re not trying to do what Spanner does. Spanner, CockroachDB, YugabyteDB, and Aurora all pay for their scale and geographic reach by trading away some degree of consistency. Each makes a slightly different trade, but none of them operates at the same strict ACID level Volt does.<\/p>\n\n\n\n

Volt pays for that consistency at design time instead of at query time. You declare partition keys up front and express transactions as deterministic stored procedures. That changes what a latency comparison even means. Comparing a 1\u20132ms round trip in Volt to a several-millisecond round trip elsewhere isn’t comparing like for like. In Volt, the entire business transaction executes as one unit, server-side, inside that 1\u20132ms. In the other systems, a single round trip is often just a fragment of the logic (one read, one write, one loop iteration), so accomplishing the same business transaction usually takes several round trips strung together on the client side, not one.<\/p>\n\n\n\n

Where we clearly lead beyond raw latency is tail predictability. No locks, no latches, and fully deterministic execution mean no long-tail latency spikes, meaning results stay predictable at the 99th percentile, not just on average. Our active-everywhere replication (XDCR) is also more predictable from a transaction-latency standpoint than the multi-region approaches the others use.<\/p>\n\n\n\n

If we’re going to be honest about where we trail, it’s multi-partition transactions. Volt asks you to architect your data and transactions to run against a single partition wherever possible. That constraint doesn’t fit every business use case cleanly. That’s a genuine trade-off. Our lane is bounded. It’s high-value operational state \u2014 balances, sessions, entitlements, network capacity \u2014 where being wrong has a real cost. We don’t try to win on unbounded data volume or general-purpose SQL surface area. For those needs, one of the other three is probably the right call.<\/p>\n\n\n\n

Q5.<\/strong> In 2017 you described VoltDB’s sweet spot as applications where “the window of opportunity is available in the fast data stream process and once passed the opportunity value diminishes.” That description fits fraud detection perfectly. How well does it fit the emerging agentic AI use cases you are now pursuing \u2014 and are there categories of AI agent application where that real-time decisioning model does not actually apply, and where a different architectural approach would serve better?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  T<\/strong>hat philosophy has never been more important, and it now reaches well beyond fraud or financial transactions. It’s become the basis of value extraction from real-time data generally, alongside the validation and accuracy of the decision or recommendation itself.<\/p>\n\n\n\n

It still holds true for most of what has rapidly become the agentic market. However, there’s a growing slice where it genuinely doesn’t. It fits fraud, charging, and entitlement checks, where a late “allow” is a wrong “allow” regardless of how smart the thing that produced the recommendation was. It doesn’t fit a research agent spending an hour synthesizing an analysis, a planning agent working through a multi-step remediation, or overnight document reconciliation. Nothing there closes in milliseconds. Being a few minutes late costs nothing.<\/p>\n\n\n\n

The deeper point is less about speed and more about validity. What matters most is ensuring the data an agent reasons from is as current and consistent as it can possibly be. Reasoning from a half-executed transaction (a state that isn’t valid from the business’s perspective) is a bad outcome whether the agent takes a millisecond or an hour to act on it.<\/p>\n\n\n\n

Q6.<\/strong> In 2017 you told me that most enterprise AI and ML was still post-transaction \u2014 analytics on the back end rather than decisions in the stream. That was eight years ago. Today, there is enormous pressure on enterprises to move AI inference into the critical path of real-time operations. What is your honest assessment of where most enterprises actually are in that journey in 2026 \u2014 and what is the biggest gap between where they think they are and where they actually are?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  <\/strong>I’d strongly agree that every company is facing enormous pressure to move AI inference into the critical path. But those decisions and recommendations must be accurate. There is no value in being fast but wrong, and for a lot of these use cases, being fast but wrong could be genuinely catastrophic for the business.<\/p>\n\n\n\n

Most “AI in production” today is still the 2017 pattern with a much smarter model attached to it: insight gets generated, and a person or a batch process still has to act on it. The gap between where enterprises think they are and where they actually are comes down to context and determinism. In other words, whether the outcome an AI system produces can actually be trusted.<\/p>\n\n\n\n

Concretely: pilots are deliberately run on clean, curated data. Production data is live and messy. MIT’s 2025 “GenAI Divide” research found that the overwhelming majority of generative AI pilots fail to show measurable results once they move to production. The consistent finding across that research and others like it is that it’s rarely the model. When accuracy drops after go-live, teams tend to blame the model. Usually the model is fine. This is the first time we’re reasoning against stale or inconsistent state, because production data was never as clean as the pilot dataset it was built and tested against.<\/p>\n\n\n\n

That’s the gap: enterprises think they have an AI maturity problem. Underneath it, most of the time, they have a data problem that existed before the AI project ever started, and was invisible right up until an agent began acting on it continuously instead of a person glancing at it once a day. To be fair, we have also seen a real, encouraging uptick in enterprises adopting ML models specifically for anomaly detection, and that’s one place the maturity curve is genuinely moving in the right direction.<\/p>\n\n\n\n

Q7<\/strong>.<\/em><\/strong> <\/em><\/strong>Most research still shows that the majority of enterprise AI deployments are in pilot mode rather than production. You are selling infrastructure for production AI. What do you actually hear from enterprises about why pilots stall \u2014 and what does that tell you about what the market genuinely needs that it is not yet getting from the AI infrastructure category as a whole?<\/strong><\/em><\/em><\/strong><\/p>\n\n\n\n

David Flower:  <\/strong>What we generally hear isn’t “the data layer failed” in those words. It’s “the model got worse in production” or “we can’t explain a decision after the fact.” Those are the same root cause stated differently.<\/p>\n\n\n\n

I’d add that fear is a major factor too, particularly for mission-critical, production environments. A good example is autonomous networks in the mobile CSP market. Every operator is chasing the silver bullet, but very few are actually ready to let AI run the most critical assets of their business unsupervised. That’s where proven performance fundamentals and evidence-based validation become essential. Trusted AI outcomes need a deterministic foundation underneath them, not just a confident-sounding model.<\/p>\n\n\n\n

There are plenty of numbers to back this up. Deloitte’s 2025 research found only 11% of enterprises have agentic AI actively running in production, and MIT’s 2025 research found the overwhelming majority of generative AI pilots never show measurable results. That’s a significant gap given the level of investment in the space.<\/p>\n\n\n\n

We see the trust question play out directly with customers. In telecom, we’ve seen customer care agents get replaced by AI specifically because the outcome is auditable. A customer complains their calls always drop driving home past a certain location; the AI agent reviews the network data and call records, determines the pattern is real, applies a goodwill credit (and can see and audit exactly how often this has happened for that subscriber), and triggers a network engineering ticket to review capacity at that location. It’s contained, and every step of it is auditable. Now compare that to letting the same agent autonomously go fix the network itself, allowing it to add capacity, spend on additional trunk routes and interconnects, with no human in the loop. The cost to the operator, and the stakes if it gets something wrong, get a lot scarier very quickly. AI has to be auditable, and it has to earn trust before it’s let loose on more critical, more autonomous tasks. That’s exactly the gap the AI infrastructure category as a whole isn’t yet closing: plenty of tooling for storing and orchestrating agents, very little built for agent-paced, auditable decision authority on live operational data.<\/p>\n\n\n\n

Q8.<\/strong> You work with partners across the data ecosystem \u2014 streaming platforms, AI frameworks, cloud providers. The honest question is: does Volt fit alongside other data platforms as a complementary layer, or is your strategic goal ultimately to consolidate and replace them? And if the answer is “complement,” where exactly is the boundary \u2014 what does Volt do that you would tell a customer not to try to do with Kafka, Flink, Snowflake, or a vector database?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  <\/strong>We absolutely act as a complementary layer, and the boundary is concrete, not a vague “we play nicely together” answer.<\/p>\n\n\n\n

Don’t ask Kafka or Flink to own a decision. They move and process events extremely well, but they were never built to be the authority, and they don’t offer a full decision audit trail on their own. Don’t ask Snowflake “what should happen right now.” It answers “what happened” and “what’s the pattern.” It’s worth noting we’ve seen several major data lake and warehouse vendors investing in, acquiring, or exploring real-time transactional technology recently. That’s a clear sign they recognize the same gap we’ve been pointing at for years. And don’t ask a vector database to decide anything: similarity search finds a plausible match; it doesn’t apply business logic.<\/p>\n\n\n\n

A good, live example of the complementary model is our partnership with Ocient<\/a>. Volt holds live operational state, such as current balance, active session, and real-time network state. Ocient holds petabyte-scale historical pattern data. An agent reasoning from both can say, in effect, “here’s what’s happening right now, in the context of what’s historically normal.” The result is a meaningfully better answer than either platform could produce alone.<\/p>\n\n\n\n

Q9.<\/strong> You have been running Volt Active Data \u2014 including through a rebrand from VoltDB \u2014 for nearly a decade. That is a long time to lead a company in a market that has changed as dramatically as data infrastructure has changed. What has been the hardest strategic decision you have had to make in that period \u2014 the one where you were most uncertain, where the data did not give you a clear answer, and where you had to lead from conviction rather than evidence?<\/strong><\/em><\/p>\n\n\n\n

David Flower:\u00a0\u00a0<\/strong>First, we haven’t changed our core DNA or the class of problems we solve. Volt was created by one of the world’s smartest technical minds in this field, Mike Stonebraker<\/a>, specifically to solve complex, mission-critical problems. The strength of our global enterprise customer base is the evidence that the thesis was right.<\/p>\n\n\n\n

Given that, the hardest decision hasn’t been what to build. It’s been when to make a strategic shift. AI is the obvious recent example: it was hyped for years, but with not much substance underneath it in the early days. Move too early on a wave like that, and you waste a huge amount of valuable capital chasing noise. Move too late, and you miss the boat entirely. On balance, I think we made the right calls at the right time, and we’re seeing that pay off now. But we have to stay agile, because you genuinely never know what the next wave is going to be.<\/p>\n\n\n\n

The judgment call underneath all of it is telling the difference between noise and real business value before the market has made it obvious. AI and streaming both turned out to be real. Plenty of other trends haven’t been. The metaverse comes to mind. It never ended up being particularly relevant for what we do. Knowing which one you’re looking at, before the evidence is in, is the actual hard part.<\/p>\n\n\n\n

If I had to point to a cultural anchor through all of it: one of our earliest customers told us, “it just works.” We’ve been told since that we’re so reliable we’re almost boring. Our best customers, such as the fraud and billing teams who can’t afford to be wrong, are the ones who keep pulling us back to that narrow, deterministic story whenever the market pressure says we should be broader. That pull has been more useful to me than any market data.<\/p>\n\n\n\n

Q10.<\/strong> Looking at the database landscape in five years, given the trajectory of agentic AI \u2014 where every agent needs safe, fast, consistent access to operational data at machine speed \u2014 where does Volt Active Data sit in that picture, and what would have to be true for that future to play out in your favor rather than in the favor of the cloud hyperscalers or the next wave of purpose-built AI data platforms?<\/strong><\/em><\/p>\n\n\n\n

David Flower:  <\/strong>I’ll be honest. This question feels like it was written for us to show off our own positioning, so let me try not to overdo it.<\/p>\n\n\n\n

The landscape will split further before it consolidates. The operational tier, the analytical tier, vector stores, and artifact\/trace stores are genuinely different problems. That’s not one problem that collapses into a single vendor, no matter how good that vendor is. What I do expect to matter more everywhere is atomic decision recording. Regulators are moving toward mandatory explainability for automated decisions, which means the same discipline that’s been required in regulated industries for fifteen years is going to be expected far more broadly as agents take on more consequential work.<\/p>\n\n\n\n

In answer to the “what has to be true for us” question, it’s that enterprises need to keep hitting the wall where “good enough” consistency breaks the moment it’s an agent, not a person, reading and acting on the data. Hyperscaler bundled options will keep being the right, cheaper choice for a lot of workloads, and we don’t need to win that fight. We need to keep being the correct answer where correctness is genuinely non-negotiable, and that slice of the market is growing, not shrinking.<\/p>\n\n\n\n

Qx <\/strong>Anything you wish to add?<\/strong><\/em><\/strong><\/p>\n\n\n\n

David Flower:\u00a0\u00a0<\/strong>Just that none of this is new to us. Fraud, telco, and network teams have needed correct, immediate, explainable decisions for the fifteen years we’ve been around. Agentic AI didn’t invent that requirement, but it did expose it to a much bigger audience and made the cost of getting it wrong visible overnight.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Resources<\/strong><\/p>\n\n\n\n

Facing the Challenges of Real-Time Analytics. Interview with David Flower<\/a>, ODBMS Industry Watch, December 19, 2017<\/p>\n\n\n\n

\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026..<\/strong>……………………..<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

David Flower<\/strong>, President & CEO, Volt Active Data<\/p>\n\n\n\n

David Flower brings more than 30 years of experience within the IT industry to the role of President and CEO of Volt Active Data. David has a track record of building significant shareholder value across multiple software sectors on a global scale through the development and execution of focused strategic plans, organizational development, and product leadership.<\/p>\n\n\n\n

\u2026\u2026\u2026\u2026\u2026\u2026\u2026.<\/p>\n\n\n\n

Follow us on X<\/strong><\/a><\/p>\n\n\n\n

Follow us on LinkedIn<\/strong><\/a><\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

“ACID was, and will always be, the right answer to concurrent state access. Agentic AI just made ignoring it expensive instead of theoretical.” Q1. When we last spoke in December 2017, you had just repositioned VoltDB around “translytics” \u2014 the combination of real-time transactions with real-time analytics \u2014 and you were seeing early adoption in fraud […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[6,1881,990,1886,97,1210,139,1179,1883,1887,1885,1780,1884],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/5950"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=5950"}],"version-history":[{"count":8,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/5950\/revisions"}],"predecessor-version":[{"id":5959,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/5950\/revisions\/5959"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=5950"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=5950"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=5950"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}