Apparently, Nothing Happened in Database History Between 1986 and Monday

First, about the “physics”

Databricks begins with a valid engineering tradeoff and, somewhere between premise and conclusion, promotes it into destiny. Row-oriented storage favors selective transactions, while columnar storage favors broad scans and aggregations. Those access patterns demand different optimizations; they do not demand separate systems.

SingleStore’s Universal Storage work attacked those tradeoffs directly. Columnstore tables became seekable and highly concurrent through hash indexes, subsegment access, and row-level locking. Instead of scanning a million-row segment to retrieve one record, SingleStore could identify the row position and read only the necessary portion. Instead of locking an entire segment during an update, it could lock at the row level. In a benchmark published with the original Universal Storage post, a lookup on an unsorted column in a table containing more than a billion rows fell from 271 milliseconds to 2.54 milliseconds.

That was in 2019. Since then, Universal Storage has added selective joins and upserts on columnstore tables, so the same table that handles large analytical scans also performs the selective reads and fine-grained updates traditionally assigned to rowstore.

Then the agents arrived

Databricks argues that agents finally broke the old arrangement because they need live operational data and historical context at the same time. A fraud agent, for example, cannot make a useful decision from a copy of transaction data that is minutes or hours behind reality. It needs the transaction happening now and the patterns buried in years of history.

On this point we agree so completely that SingleStore was built around it.

Agents have made the need more visible and the query volume more violent, but they did not invent the requirement to analyze current data. Fraud detection, trading, logistics, and customer-facing applications have always depended on current data. Any application expected to react to the world before the world changed again needed it.

Nearly any system can eventually analyze operational data once the data has been escorted through enough pipelines, replicas, and format conversions. Agents operate in the interval before “eventually” arrives, when the latest committed write must already be available to operational queries, analytical queries, vector search, and the application acting on the result.

In SingleStore, it is.

An agent can examine the transaction that just arrived, compare it with historical behavior, search related vectors, join structured and semi-structured data, and write the next action back—all through one engine. There is no interval in which the system must wait for the present to be converted into history before it can understand it.

Agents did not break a 40-year-old rule. They made the penalty for obeying it impossible to ignore.

Good Hypotheticals. Here Are the Production Numbers.

Customers buy the interval between an event and their ability to act on it, then spend years eliminating whatever makes that interval longer.

Databricks asks us to imagine agents examining live events against years of history without overwhelming the systems processing transactions. Those requirements also describe SingleStore deployments where the hypotheses have already acquired latency targets, audit requirements, and seven-figure infrastructure bills.

The fraud example has a close production relative at ServiceNow (Armis), where the object under surveillance is every device wandering through an enterprise network. Its platform ingests 100 billion events and 1.2 billion sessions each day, loading roughly one million complex rows per second into customer environments as large as 30 terabytes. SingleStore powers AI-driven threat prediction, real-time anomaly detection, and search. The team specifically cited having rowstore and columnstore in the same database as a reason for its choice.

Before SingleStore, its largest workload sprawled across more than 400 PostgreSQL databases and a 160-node Elasticsearch cluster, followed by Kafka buffers, EKS resources and an EMR process that periodically hauled updated records back from the data lake for reindexing. Moving the largest dataset to SingleStore cut pipeline costs by 70% while allowing users to search, aggregate, and drill into streaming data as it arrived.

The financial version of the same story is already running at one of the world’s largest banks. Its private wealth platform calculates portfolio performance across more than 20 years of data while delivering query results in 10 to 20 milliseconds to more than 40,000 concurrent users without contention. Its equities trading platform manages another 600 terabytes in SingleStore, processes billions of market events each trading day, and supports transactions, analytics, and vector search alongside Kafka and HDFS. Clients can inspect current positions, cut across decades of portfolio history, and act while the market is still moving.

Agents will increase the traffic and compress the acceptable delay, but they have not conjured a new class of workload from the void.

But what about a herd of agents?

Databricks is also right that a herd of agents can flatten an operational system. One well-behaved agent is a workload; hundreds are weather.

They arrive in bursts, fan out across tools, issue queries no capacity planner anticipated, and consume resources with the tranquil confidence of software that has never personally received a cloud bill. Let them all collide with the production workload and eventually someone will rediscover the circuit breaker.

This is why SingleStore separates storage and compute without separating transactions and analytics into different database engines.

With SingleStore’s Zero-Copy data fabric and Smart Attach, a database can have one read-write attachment and many read-only attachments across isolated compute clusters. Each cluster has its own compute resources, settings, cache, and endpoint. Analytical applications, inference workloads, and fleets of agents can scale independently without creating a full duplicate of the underlying database.

The primary cluster can continue ingesting and transacting. Dedicated clusters can absorb agent queries and analytical workloads. New writes are streamed to those read-only attachments in near real time, while the shared object storage remains the durable source underneath them. If another hundred agents show up at the gate, carrying elaborate plans and no sense of proportion, another workload does not require another full copy of the database.

Governance is essential. It is not a time machine.

Databricks also argues that LTAP brings operational and analytical data under a common catalog and governance boundary. Good. Enterprise data should not lose its policies and lineage every time it crosses a pipeline.

A catalog can tell you where data lives, who may see it, and how it got there. A catalog cannot make a transaction immediately available to every kind of query, turn two execution engines into one, or remove the latency hidden inside a format transition merely by placing everything under the same administrative roof.

SingleStore also recognizes that not all enterprise data will originate inside one database. Its third-generation cluster architecture and Zero-Copy data fabric support direct access to open Apache Iceberg data, allowing applications to work with governed lakehouse data without first manufacturing another proprietary copy. The same HTAP engine can combine that open historical data with current operational data, vector search, full-text search, and application state.

Open storage and unified governance matter, but agents need more than permission to inspect data. They need an engine capable of acting on it while it is still current.

The missing entry in the timeline

In 2019, SingleStore described Universal Storage as a continuing effort to erase the apparent difference between rowstore and columnstore tables. The stated destination was equally clear: one table type for transactions and analytics on datasets much larger than memory.

Now agents are making that architecture more consequential. By multiplying queries and combining access patterns, agents turn every seam in the data stack—and every moment of stale context—into additional latency, infrastructure complexity, and tokens.

Welcome. We have been here for a while.