CedarDB: One Database for Transactions and Analytics, as AI Agents Drive New Database Demands

Traditional databases have long faced an either-or choice: either optimize for transactional workloads (OLTP), pursuing high-concurrency, low-latency writes and updates, or serve analytical workloads (OLAP), excelling at complex queries and aggregations over massive datasets. Running two systems in parallel means complex data pipelines, high costs, and poor real-time performance. Germany's database engine CedarDB aims to break that dividing line by supporting both workload types with a single system. With the rise of Agentic AI, the value of this unified architecture is being re-examined.

Why Transactions and Analytics Have Long Been Separated

Decades of engineering practice in the database field have largely followed the philosophy of "dedicated databases for dedicated purposes." Transactional systems demand row-based storage, fine-grained locking, and ACID transaction guarantees, with each operation touching only a small number of records; analytical systems favor columnar storage, vectorized execution, and batch scans, where a single query can involve millions of rows. The two are almost diametrically opposed in storage layout, execution engine, and optimizer strategy.

The result is that enterprises build ETL pipelines between two systems, periodically moving transactional data to analytical warehouses. Data latency is measured in hours or even days, operational costs double, and consistency is hard to guarantee. The concept of HTAP (Hybrid Transactional/Analytical Processing) has been proposed for a long time, but few products truly achieve the best of both worlds.

HTAP (Hybrid Transactional/Analytical Processing) was formally introduced by Gartner around 2014, referring to using a single system to handle both OLTP and OLAP workloads, avoiding data movement between transactional and analytical databases. Its technical difficulty lies in the fact that: transactional workloads require row storage, short transactions, and strong consistency; analytical workloads require columnar storage, long scans, and vectorized execution—the storage formats and execution models of the two are inherently in conflict. Early HTAP solutions mostly adopted compromise approaches such as "dual-engine splicing" or "in-memory row store + disk-based columnar replica," often conceding on freshness, consistency, or performance on one side. Whether a system qualifies as true HTAP is usually judged by whether it can achieve near-real-time consistency between analytical results and transactional writes on the same data, without relying on additional ETL synchronization.

CedarDB's Unified Approach

CedarDB positions itself as a unified database engine with native support for both workload types. Rather than stitching two engines together, it has designed everything from underlying storage to query execution in a unified way, attempting to satisfy both high-throughput transactions and complex analytics on the same copy of data.

The direct appeal of this architecture for enterprises is that it eliminates redundant data movement, enabling analytical results to be derived from the latest transactional data while reducing system complexity and overall costs. For scenarios with high real-time data requirements, the benefits of a unified engine are especially pronounced.

Vectorized Execution is a key technology in modern analytical engines, referring to processing data in "batches"—applying the same operator to hundreds or thousands of values at once, rather than row-by-row interpreted execution. Its value lies in significantly reducing function call and branch prediction overhead, fully utilizing CPU pipelines and SIMD instructions, thereby boosting analytical query throughput by multiple times. It is complemented by columnar storage—data of the same column stored contiguously, which facilitates compression and batch scanning. Traditional transactional engines use row storage and row-by-row execution, which are naturally unsuited to such optimizations. A unified engine serving both workload types needs to accommodate both row-based short paths and columnar batch paths at the executor level, or adopt a storage design that can efficiently switch between the two layouts—this is precisely the core technical challenge for systems like CedarDB.

Why Agentic AI Raises the Stakes

The rise of Agentic AI imposes new workload characteristics on databases. When AI agents execute tasks, they frequently read and write state, query knowledge, and record decision trails. These operations have both the high-frequency write characteristics of transactional workloads and the aggregation query needs of analytical workloads, and often require millisecond-level response times.

If the underlying infrastructure remains a combination of transactional and analytical databases, every "think-act-observe" loop of an agent requires cross-system data retrieval, making latency and consistency bottlenecks. Unified engines like CedarDB thus gain new relevance: they allow agent state management and data queries to reside in the same system, reducing pipeline friction and supporting real-time decision-making.

The industry has long debated whether "one database can do both jobs well." The opposing view holds that transactional and analytical requirements differ too greatly at the physical level, and a unified architecture will inevitably compromise on one end; the supporting view argues that modern hardware (large memory, NVMe, multi-core parallelism) and new execution technologies have already blurred the physical boundaries. Whether CedarDB can answer this debate through actual performance is the core test it faces.

Agentic AI refers to AI systems capable of autonomously planning, invoking tools, and cyclically executing "think-act-observe" steps to complete complex tasks, with typical examples including various tool-invoking agents and multi-agent collaboration frameworks. At runtime, they generate large amounts of state data: session memory, intermediate task results, tool invocation logs, decision trail tracking, and so on. This data requires both high-frequency, low-latency writes (recording every action) and fast aggregation and backtracking (querying historical tasks, retrieving relevant memories)—a workload profile that spans both OLTP and OLAP. If state is scattered across transactional and analytical databases, each agent loop requires cross-system data retrieval, making it difficult to meet the latency and consistency requirements of real-time decision-making. Therefore, a unified underlying data engine is seen as an important infrastructure direction for supporting efficient agent operation.

Implications for Developers and Enterprises

For developers, a unified database means a simpler tech stack and less data synchronization code. For data teams, it may change the role of the data warehouse—no longer the sole analytical entry point, but a real-time data layer integrated with transactional systems.

Of course, selection still depends on specific scenarios: workload scale, latency tolerance, ecosystem compatibility, and migration costs are all real constraints. CedarDB represents an architectural direction, not a one-size-fits-all answer. The proliferation of Agentic AI is turning this unified path from "optional" to "worth serious evaluation."

One-line Summary

CedarDB supports both transactional and analytical workloads with a unified engine, regaining attention due to Agentic AI demands.

Paragraph Summary

Traditional databases have long forced a choice between OLTP and OLAP, compelling enterprises to use ETL pipelines to move data between two systems, resulting in high latency, doubled costs, and difficult consistency guarantees. Germany's database engine CedarDB takes a natively unified approach, designing from storage to execution layer in a unified way, attempting to satisfy both high-throughput transactions and complex analytics on the same copy of data. The rise of Agentic AI further elevates the value of this architecture: agents in their "think-act-observe" loops need both high-frequency state writes and aggregation queries, plus millisecond-level responses, and cross-system data retrieval becomes a bottleneck. The industry remains divided on whether a unified architecture can achieve the best of both worlds, with skeptics emphasizing the conflicting physical requirements of transactions and analytics, while supporters pin their hopes on modern hardware and execution technologies. For developers and enterprises, this represents an architectural direction worth evaluating.