Cloud Parts

CedarDB

A PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.

What it is
Relational databases,Real-time analytics databases
Type
Commercial product
Made by
CedarDB GmbH
License
Proprietary; the free Community Edition comes under CedarDB’s own terms (64 GiB data limit, no modification or redistribution)
Facts checked
6 October 2026
Website

What it is

CedarDB is one server binary for Linux (or a Docker image) that speaks the PostgreSQL wire protocol, SQL grammar and system catalog, so psql, JDBC, ORMs and Grafana’s PostgreSQL data source connect unchanged. None of the code comes from PostgreSQL. Each table is a single copy in a hybrid row and column format: fresh writes land in a write-optimized area and are visible at once, and in the background they are compressed into columnar blocks that are fast to scan. A table can keep its cold, compressed data in S3 or an S3-compatible store while metadata and hot rows stay on the local SSD. Every query is compiled to machine code, starting fast and recompiling with more optimization while it runs, and is split into small morsels that all CPU cores pick up in parallel. A buffer manager built for fast SSDs keeps the working set in RAM and reads the rest from disk, and transactions are ACID.

There are three editions. Community is free, needs no sign-up and may run in production, but its terms cap persisted data at 64 GiB (the database turns read-only above that) and forbid modifying, reverse engineering or passing on the software. Enterprise removes the cap and adds role-based access control, monitoring and priority support; pricing is usage-based on compute and set by sales, with a 90-day self-service trial. CedarDB Cloud, a managed service on AWS in Europe and the US, has a waitlist and a price calculator ($300 a month for the smallest 2 vCPU / 8 GiB instance, plus storage billed per GiB-hour) but has not opened yet. CedarDB runs on one server: replication, automatic failover, point-in-time recovery and automatic backups are on the roadmap as planned.

Why teams pick it

  • One engine and one copy for transactions and analytics: dashboards read the rows the application just committed, with no CDC pipeline or second database to run
  • PostgreSQL wire protocol, SQL dialect and system tables, so existing drivers, ORMs and tools such as DBeaver and Grafana work
  • Uses the whole machine: every query runs on all cores as compiled code, there is no process per connection and no autovacuum to tune
  • The free Community Edition is allowed in production up to 64 GiB, with no limits on cores, connections or running time
  • Its internals come from more than a decade of published TU Munich research (HyPer, then Umbra), so the papers explain how it works

Watch out for

  • Not open source: binaries only, under terms that forbid modification and redistribution, let CedarDB refuse downloads in some regions, and are legally binding only in German
  • A single server with no replication, failover, point-in-time recovery or automatic backups yet; high availability is up to you
  • PostgreSQL-compatible, not PostgreSQL: PostgreSQL extensions don’t load, XML is not planned, savepoints arrived only in September 2026, and range types and full-text search are still in progress or planned
  • Past 64 GiB you need Enterprise, whose price is not published, and the managed cloud is still a waitlist
  • A young product from a small Munich start-up; claims such as “the world’s fastest database” come from CedarDB’s own benchmarks

Alternatives

What all relational databases have in common →
Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

Transactions and a dashboard query on the same table · sql

-- docker run --rm -p 5432:5432 -e CEDAR_PASSWORD=test cedardb/cedardb
-- PGPASSWORD=test psql -h localhost -U postgres
CREATE TABLE orders (
  id          bigint PRIMARY KEY,
  customer_id bigint NOT NULL,
  region      text NOT NULL,
  total       numeric(10,2) NOT NULL,
  created_at  timestamp NOT NULL DEFAULT now()
);

-- history loaded from the old warehouse export
INSERT INTO orders SELECT * FROM 'orders_2025.parquet';

-- the application's transaction
BEGIN;
INSERT INTO orders (id, customer_id, region, total) VALUES (100001, 42, 'EU', 129.00);
COMMIT;

-- the dashboard reads the same table, including the row just committed
SELECT region, date_trunc('hour', created_at) AS hour,
       count(*) AS orders, sum(total) AS revenue
FROM orders
WHERE created_at >= now() - interval '24 hours'
GROUP BY region, hour
ORDER BY hour, region;

Community, Enterprise and Cloud#

All three run the same engine. What changes is the data limit, the features around it and who operates the server.

Checked 6 October 2026CommunityEnterpriseCedarDB Cloud
PriceFreeUsage-based on compute, quoted by sales; 90-day free trialCalculator shows $300/month for 2 vCPU / 8 GiB, storage per GiB-hour (16 GiB minimum, $6/month), 3 backups included
Data limit64 GiB of persisted data, then read-onlyNoneNone
Extra featuresNoneRole-based access control, monitoring, priority supportEnterprise features plus management UI and scheduled backups
Where it runsYour Linux machines, Docker or cloud imagesYour Linux machines, Docker or cloud imagesAWS, Europe and US regions at first
StatusAvailableAvailableWaitlist, not yet open
  • When an Enterprise trial expires the database falls back to Community: Enterprise features switch off and it becomes read-only above 64 GiB, but no data is lost. Only one trial is allowed per database.

See it in a real stack

No architecture uses CedarDB yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

WebsiteThe Umbra Database SystemThomas Neumann’s group, Technical University of MunichThe research site for Umbra, the successor to HyPer and the basis of CedarDB: a feature overview and the full publication list with PDFs, from the CIDR 2020 paper “Umbra: A Disk-Based System with In-Memory Performance” onwards. You can try queries in the browser or pull a Docker image, but its terms allow only evaluation, not production use.
All resources →

Benchmarks

Benchmark · ClickHouse Inc.ClickBenchHow fast analytical databases run 43 SQL queries over one 100-million-row table of web analytics events, on the same cloud machines.Includes CedarDB · 7 caveats to read first
How to read a benchmark →
Where it came from2008–2026

In 2008 Alfons Kemper and Thomas Neumann started HyPer at the Technical University of Munich, a main-memory database meant to run transactions and analytics on the same data. Its compiling query engine, which turns each query into machine code, influenced many later systems. Six researchers founded a HyPer start-up in 2015, and Tableau bought it in March 2016; HyPer became Hyper, the engine inside Tableau.

Pure in-memory systems need all data in RAM, which stayed expensive while SSDs became fast and cheap. Neumann’s group built Umbra as HyPer’s successor, described by Neumann and Michael Freitag at CIDR 2020 as “a disk-based system with in-memory performance”: a low-overhead buffer manager with variable-size pages keeps the cached working set as fast as HyPer while reading the rest from SSD.

In 2024 Umbra researchers including Moritz Sichert, Lukas Vogel, Christian Winter, Dominik Durner and Philipp Fent spun off CedarDB in Munich, starting on a German EXIST start-up grant. They released the free Community Edition in May 2025, together with a €5.3 million seed round led by Amplify Partners, and in 2026 pitched CedarDB as a single-engine HTAP system for teams running PostgreSQL next to a separate analytics database. Umbra continues as a research project at TUM.

Why it’s built this way

Start from scratch but keep PostgreSQL’s interface
The founders argued that PostgreSQL still carries 1990s assumptions such as 4 KB pages tuned for spinning disks and mostly single-threaded queries. A new engine fixes those, while wire protocol and SQL compatibility keep existing tools and drivers working.
SSD-backed buffer management instead of all data in RAM
HyPer needed every byte in memory. Umbra’s buffer manager, with variable-size pages and pointer swizzling instead of a global lock, keeps in-memory speed for hot data and lets the database grow past RAM.
Compile every query, adaptively
Compiled queries avoid interpretation overhead, but compiling takes time. A custom low-level language that compiles quickly lets a query start at once and get recompiled with heavier optimization only if it runs long.
One hybrid row and column storage format
Row stores are good at updates and column stores at scans. Keeping hot data write-optimized and compressing it to columns in the background lets one copy serve both workloads.

Timeline

  1. 2008

    Kemper and Neumann start HyPer at TU Munich

  2. 2016

    Tableau acquires the HyPer start-up in March

  3. 2020

    Umbra paper at CIDR: a disk-based system with in-memory performance

  4. 2024

    CedarDB spins off from TUM, announced with “Ode to Postgres” in May

  5. 2025

    Free Community Edition and a €5.3 million seed round in May

  6. 2026

    Relaunched as a single-engine HTAP database in June

Sources16 · facts checked 6 October 2026

Improve this page on GitHub