What is not a lakebase
Many databases share one or two traits with a lakebase without meeting all four criteria: a live operational workload, storage and compute separated, object storage as the source of truth, and storage in an open format. Here are the common near-misses and why they fall outside the line.
Separates storage and compute, but keeps durability on local disk
These are distributed or serverless databases whose durability still lives on disks attached to their nodes, usually replicated with a consensus protocol. Object storage is not the source of truth, so they are not lakebases.
- CockroachDB replicates data across nodes using Raft over local storage (RocksDB or Pebble).
- PlanetScale runs on locally attached NVMe for latency.
- YugabyteDB uses distributed local storage with Raft.
- TiDB stores data in TiKV on local disks, coordinated by Raft.
They separate compute from storage in the sense of a distributed cluster, but the durable copy is on machine-local disks, not in object storage.
Runs on object storage, but the workload is analytical
These systems do put data on object storage, but they are built for large scans and aggregations, not live operational queries. That makes them lakehouse and warehouse tools, not lakebases.
- ClickHouse Cloud is a columnar analytics engine.
- DuckDB and MotherDuck are analytical query engines.
- Databend is a cloud data warehouse.
If the primary job is analytics over big scans, it is on the lakehouse side of the divide.
Object storage, but not a database
- WarpStream is a Kafka-compatible streaming system on object storage. It is a log or message queue, not a database you query.
Operational, but no storage and compute separation
- TigerBeetle is a specialized, high-performance transactional database for financial accounting. It is operational and fast, but it does not separate storage from compute or use object storage as its source of truth.
Cloud-native, but on proprietary storage
This is the closest boundary. Several cloud databases separate storage from compute and are fully operational. What keeps them out of the category is that their storage layer is a proprietary distributed system internal to one cloud, not open cloud object storage.
- Amazon Aurora and Aurora DSQL separate compute from Amazon's own distributed storage service.
- Google AlloyDB separates compute from a proprietary storage layer.
- Snowflake Unistore and Hybrid Tables add transactional tables inside Snowflake's own storage.
These decouple storage from compute and share much of the lakebase model. The distinction is the storage substrate. A lakebase builds on open, general-purpose cloud object storage such as S3, which gives the category its portability and its economics. Databases on closed, cloud-specific storage engines get many of the same benefits within a single vendor, but they are a different lineage.
Back to what is a lakebase.