| TL;DR: Companies have spent years connecting different databases and moving data between them. AI agents put new pressure on that setup because they can search, analyze, and act on changing data at the same time. We spoke with RegattaDB CEO Boaz Palgi about why that is making an old database problem harder to ignore. |
A company’s data does not necessarily live and work in one system.
One database might process transactions, such as recording a payment or updating an account. Another might analyze that data. More recently, vector databases, which help AI find information based on meaning rather than exact words, have been added to the mix. Pipelines often move data between these systems.
That separation becomes harder to manage when AI agents need to do several of those jobs at once. An agent might search for information, analyze it, and update a record, while other agents are working with the same data.
RegattaDB was built around a different idea: handle transactions, analytics, and vector search in the same distributed database rather than relying on separate systems linked by pipelines.
We spoke with CEO Boaz Palgi about why the company built it this way, and what the rise of AI agents has changed.
The Problem Starts When Agents Act on the Same Data
Separating transactional, analytical, and search workloads made sense long before AI agents arrived. Each system was built to do a different job well. The trade-off was that, in many architectures, information had to move or be synchronized between them.
That becomes more important when software starts acting on the information rather than simply showing it to a person.
Imagine several agents working with the same customer account. One updates a subscription. Another analyzes the customer’s activity before recommending an offer. A third searches previous conversations for relevant context.
Palgi sees the problem as one of coordination.
His point is that an agent may need more than one type of database operation. It might search for context, analyze current information, and then make a transaction. Other agents could be doing the same thing against the same records.
The problem is what happens when those actions overlap. One agent could change a record while another is still using the earlier version to make a decision. The database has to keep those operations coordinated so agents are not acting on conflicting information.
Regatta Started With Concurrency, Not Agents
That distinction matters because Regatta’s work on the problem predates the current agent boom.
At the center of RegattaDB is its approach to concurrency control. Put simply, concurrency control determines what happens when multiple operations try to work with the same data at the same time.
Regatta Data’s U.S. patent for its concurrency control protocol lists a March 2023 priority date. The patent describes a protocol for maintaining the consistency and correctness of transactions running concurrently.
Regatta says its approach is designed to provide strong ACID guarantees across a distributed database. ACID refers to properties that help keep database transactions reliable even when multiple operations are happening at once.
That concurrency model became the foundation for Regatta’s attempt to run transactional, analytical, and vector workloads against the same data.
According to Regatta’s technical documentation, its model provides serializable isolation across different nodes. In simple terms, the database is designed to keep concurrent transactions consistent even when the data is spread across multiple machines.
Regatta therefore did not begin with the question, “What database do AI agents need?”
The company was already working on how different workloads could safely operate against the same data. Agents gave that work a new use case.
“When we started building Regatta, we had no idea the agent movement would become the next major wave in computing,” Palgi said when the company launched RegattaDB for general availability in July.
Replacing the Database Still Has to Be Worth It
A different architecture does not automatically make an enterprise replace something as fundamental as its database.
Applications and processes may already depend on the systems a company has in place. A new database therefore has to solve a problem important enough to justify the disruption.
Palgi says several pressures are starting to come together.
Businesses want to operate in real time. Infrastructure costs for servers, power, cooling, and space are rising. At the same time, companies are adding AI workloads without necessarily getting much larger IT budgets.
There are signs outside Regatta that agent workloads are changing the infrastructure conversation. In September, Google announced a new agentic architecture for AlloyDB, arguing that agents need access to fresh operational data while bringing unpredictable bursts of database activity. Google’s answer is different from Regatta’s: it isolates agent compute from the primary database rather than unifying transactional, analytical, and vector workloads in one database engine.
That difference is useful. Database vendors are not necessarily arriving at the same architecture, but they are responding to the same new pressure.
Regatta’s business case is also about consolidation.
Palgi told SaaSTake that RegattaDB can deliver four to five times the workload density of legacy databases such as Postgres. Regatta’s current website uses a lower three to four times estimate, which the company describes as conservative. Its launch benchmarks also claim 20 times the performance per footprint of other distributed SQL databases, meaning more database performance for the infrastructure being used. These figures reflect Regatta’s own performance measurements.
But Regatta is not arguing that an enterprise has to remove its existing databases on day one.
Its current guidance suggests starting with net new AI agent applications, testing the architecture there, and expanding from that point rather than beginning with a large migration.
That is an important part of the proposition because it acknowledges the very problem Palgi is trying to overcome: replacing established database infrastructure is difficult.
The company has raised $68 million from investors including Lightspeed Venture Partners, 83North and TPY Capital, alongside Salesforce, Comcast and Amdocs.
Their involvement does not tell us which approach to agent data will ultimately prevail. It does suggest that the infrastructure underneath AI has become strategically important to companies already operating large enterprise systems.
Removing the Pipeline Changes the Database Question
The architectural difference becomes clearer when we return to the systems we started with.
When transactions, analytics, and vector search happen separately, the engineering challenge includes moving or synchronizing the data those systems need.
RegattaDB is designed to change that question.
Its architecture puts those workloads against the same underlying data. An agent could analyze current information, retrieve relevant context, and make a transactional change without first waiting for data to pass through a separate analytical or vector system.
The engineering problem then shifts.
Instead of asking how quickly several systems can be kept in sync, Regatta has to prove that one engine can safely handle those different workloads together at the scale enterprises need.
That distinction also explains why agents matter so much to the company’s timing. The harder infrastructure question begins as agent activity moves from isolated experiments into continuous business operations.
At that point, a familiar infrastructure choice becomes harder to postpone: keep adding integration around the systems already in place, or reconsider the foundation underneath them.
RegattaDB is betting that AI agents will make that decision arrive sooner.
