What is a lakebase?

A lakebase is an operational database built on the lakebase architecture: it separates storage from compute and uses cloud object storage as its durable source of truth, while serving live, low-latency queries for applications and AI agents.

The word borrows from lakehouse. A lakehouse put analytics directly on cheap object storage and decoupled the query engines from the data. A lakebase applies the same move to the operational side of the house, the databases that serve live traffic rather than run overnight reports. Databricks introduced the term for exactly this idea: an operational database that separates compute and storage, is built on open standards, and lives natively alongside the lakehouse.

Lakebase criteria

A database is a lakebase when all four of these hold:

The workload is operational. The database answers live, low-latency queries for apps and agents. That separates a lakebase from a lakehouse or a warehouse, which run analytical queries over large scans.
Storage and compute are separate. Compute is stateless and ephemeral. It can be started, stopped, scaled, or replaced without losing data, because it owns no durable state of its own.
Object storage is the source of truth. Durability lives in cloud object storage (S3, GCS, and the like), not on a disk attached to one machine. Local NVMe and RAM are used as caches for speed, never as the only copy.
Storage is in an open format. Data sits in open formats that other services can read directly. That keeps it portable, makes recovery fast, and removes the batch exports and data pipelines you would otherwise build.

The first criterion is deliberately broad. It admits transactional (OLTP) databases, but also vector search, full-text search, and streaming systems, as long as they serve live traffic and meet the other three. What they share is the architecture underneath.

Why the architecture matters

Tying durability to a single machine's disk creates a chain of problems that databases have spent decades working around. If the disk is the source of truth, then the machine has to stay on, replicas need their own full copies, backups mean copying everything, and cloning a database for a test means provisioning new hardware and waiting.

Move the source of truth to object storage and those problems become cheap metadata operations:

Scale to zero. Idle compute can suspend entirely, because nothing durable is lost when it stops. A mostly idle database costs almost nothing.
Instant branching. A clone is a pointer into shared history using copy-on-write, so it is instant and nearly free. A fleet of thousands of branches shares one underlying store.
Instant point-in-time recovery. History is already retained in object storage, so restoring to an earlier moment is a metadata operation, not a data copy.
Elastic compute. Compute scales up and down independently of stored data, because the two are no longer welded together.

Why now

The category is arriving now for two reasons. First, object storage got fast and cheap enough that it is a credible foundation for a live database, not just for backups and data lakes. Second, AI agents and app-generation platforms created a workload that punishes the old model. These platforms create huge fleets of small databases, one per user, per agent, or per preview, most of them idle most of the time, and many of them cloned constantly. Paying for always-on hardware per database does not work at that scale. Scale to zero and instant branching do.

Lakebase vs lakehouse

The names are close, but the workloads are opposite. A lakehouse serves analytics: large scans, aggregations, and reporting over columnar data on object storage. A lakebase serves operations: small, fast reads and writes for the live application. Both put data on object storage. They sit on opposite sides of the workload divide, and a growing number of systems now sync between the two so that operational data flows into the lakehouse for analysis.

See the examples for real databases in the category, and what is not a lakebase for the boundary cases that sharpen the definition.