CedarDB Wants One Database for Transactions, Analytics and AI Agents
CedarDB, a Munich-based database company, wants one PostgreSQL-compatible engine to handle both transactional and analytical workloads, with AI agents as the defining use case. TechCrunch
The pitch is consolidation without pipelines. Cofounder and CEO Moritz Sichert said the combined approach has gained relevance with the rise of agentic AI. CedarDB is a Technical University of Munich spinout based on the Umbra research project. It was listed as a TechCrunch Disrupt 2026 Startup Battlefield company.
At the storage and execution layer, CedarDB states it runs transactions and analytics on the same data. CedarDB New writes are immediately available to dashboards and reports, removing the extract, transform and load step between operational tables and analytic queries. That step is the copying and reformatting work that usually moves data from one system to another. The company states it runs analytical queries alongside transactions using parallel execution, which splits large queries across cores, while preserving ACID guarantees, the standard promises that keep data correct. Compatibility is PostgreSQL, which for practitioners means existing drivers, tooling and SQL dialects carry over.
The agent layer sits on top of that engine. CedarDB offers what it calls an Agent-Native Database that lets users create, control and monitor AI agents working directly on live data. CedarDB The company states users decide what agents can touch while the agents handle the rest. In implementation terms, AI agents can write and execute SQL, and database roles and row-level policies, rules that limit what each agent can read or change, constrain what each agent can read or change. The company states the system scales from small writes to handling billions of rows.
On performance and cost, all figures to date are vendor claims. CedarDB claims to be 200% faster than leading analytical databases and 18x faster than Postgres on mixed workloads. It also claims 61% lower LLM-SQL pipeline cost, the cost of turning language model requests into database queries, and describes itself in company materials as the world's fastest database.
The broader context here is why agents change the tradeoff. Traditional separation kept OLTP systems, the databases tuned for fast everyday writes, fast for writes and shipped data elsewhere for analysis. That works when analysis tolerates delay. Agents that query, reason and then write back do not tolerate it well. They need fresh reads and safe writes in the same transaction boundary, with permission enforcement that survives generated SQL.
In my view, the interesting claim is not raw speed. It is permissioned, live SQL execution at scale. Vendor benchmarks rarely survive contact with production schemas, skewed data and concurrent load. Throughput numbers without query mix, hardware, isolation level and dataset size tell an operator little. What matters for this architecture is predictable latency under mixed load, correctness under concurrency, and whether row-level policies hold when the client is non-deterministic.
Looking at what this means for teams, the operational question is simpler. If one engine can absorb dashboards and agent traffic without replica lag or dual-system governance, it reduces surface area. Fewer copies, one access model, one audit path. The risk moves elsewhere, to noisy-neighbor contention between long analytical scans and short transactions, and to agent behavior itself. Guardrails help, but scoping an agent to least privilege and observing what it actually touches in production will decide whether the model is workable.
Looking longer term, that is a useful direction even if consolidation is incomplete. Databases that assume machine-generated query volume look different from those built only for human-written SQL. CedarDB is betting that difference starts with unifying the data, then controlling the agent. If the bet holds, teams spend less time moving data and more time using it.
