Cloud Parts

Lakekeeper

An open-source Apache Iceberg REST catalog written in Rust: a stateless server, backed by PostgreSQL, that tells every engine where each table’s current metadata is, checks permissions, and hands out short-lived storage credentials.

What it is
Lakehouse catalogs
Used for
Lakehouses
Type
Open source
Made by
Vakamo
License
Apache 2.0
Facts checked
9 October 2026
Website Source code

What it is

Lakekeeper is one Rust binary, built on the iceberg-rust library, that serves the Iceberg REST catalog API at /catalog and its own management API at /management for everything the spec leaves out: projects, warehouses, users, roles and permissions. It keeps no local state. Catalog state lives in PostgreSQL 15 or newer, so you can run several instances behind a load balancer. Objects nest as server, projects, warehouses, then nested namespaces holding tables and views. Each warehouse points at one storage location through a storage profile (AWS S3 or an S3-compatible store such as Cloudflare R2 or Alibaba Cloud OSS, STACKIT, Azure Data Lake Storage Gen2, Microsoft OneLake or Google Cloud Storage) plus a storage credential. Lakekeeper keeps that credential encrypted in PostgreSQL or in a Vault-style KV2 store. An engine needs only the catalog URL and a warehouse name. When it loads a table, Lakekeeper either vends temporary credentials scoped to that table’s location (STS for S3, SAS tokens for Azure, downscoped tokens for GCS) or, on S3, signs each request itself (remote signing). It refuses table locations that overlap, so one table’s credentials can’t reach another table’s files. Each change can also go out as a CloudEvent to NATS or Kafka.

Users sign in through any OpenID Connect provider or as Kubernetes service accounts. Every access decision goes to one authorizer. In the open-source build that is OpenFGA, a separate service that stores grants such as ownership, select and modify and inherits them down the namespace tree. A bridge for Open Policy Agent lets Trino enforce the same permissions. You can also write your own authorizer as a Rust trait. Neither engine does row filters or column masks. Beyond Iceberg, generic tables register Lance, Parquet or CSV data under the same permissions and credentials, but Lakekeeper doesn’t coordinate their writes. A HANSETAG team in Germany started the project in 2024 as “TIP” and renamed it Lakekeeper in October 2024. It is now built by Vakamo, founded by Viktor Kessler and Christian Thiel. Vakamo sells Lakekeeper+, which adds Cedar policies, automatic snapshot expiry and orphan-file removal, LDAP, Okta and Entra ID role providers, support and long-term-support releases. A managed Lakekeeper Cloud is in private beta. The latest release is 0.14.0 (7 October 2026), and versions are still 0.x.

Why teams pick it

  • One Rust binary with no local state: PostgreSQL is the only required dependency, instances scale horizontally, and each lakekeeper migrate runs in a single transaction
  • Credential vending or remote signing on AWS S3, S3-compatible stores (it is tested with Silo and SeaweedFS), Cloudflare R2, STACKIT, ADLS Gen2, OneLake and GCS, so on-premise lakes get the same protection as cloud ones
  • Fine-grained permissions in the free build: OpenFGA grants with owners who can share their own objects, an OPA bridge for Trino, and OAuth2 token exchange for shared engines
  • Table names are case-insensitive but keep their case, so a table PyIceberg creates as Monthly Revenue is still found by Spark (which lowercases) and Snowflake (which uppercases)
  • Soft deletion, deletion protection, change events to NATS or Kafka, and an open-source web console that queries tables in the browser with DuckDB WASM

Watch out for

  • Still 0.x, and minor releases break things: 0.10.0 changed the OpenFGA schema, 0.11.0 switched S3 to vended credentials by default, and 0.12.0 changed the log format. Every upgrade needs lakekeeper migrate before serve
  • Open core: Cedar policies, automatic snapshot expiry and orphan-file removal, and LDAP, Okta or Entra ID role providers are Lakekeeper+ only. The free build only deletes old metadata files, and neither edition compacts data files
  • Permissions in the free build need OpenFGA 1.11 or newer as an extra service with its own database, ideally on the same node as Lakekeeper; without it, the only other built-in authorizer is AllowAll, which enforces nothing
  • Every table is managed: external tables aren’t supported yet, and a drop purges the files unless the client sends purgeRequested=false. Spark’s DROP TABLE … PURGE deletes files itself and gets around soft deletion
  • One young company, Vakamo, maintains it, with no foundation behind it, and PostgreSQL is the only supported database

Alternatives

What all lakehouse catalogs have in common →
Apache PolarisOpen sourceAn open-source Iceberg REST catalog: one server that every engine asks where a table’s current metadata is, with role-based access control and short-lived storage credentials per table.Cloudflare Basin CatalogRenamedCommercialCloudflare’s managed Apache Iceberg REST catalog built into R2 buckets, called R2 Data Catalog until it became generally available as Basin Catalog on 1 October 2026, which also compacts tables and expires old snapshots for you.Project NessieOpen sourceAn open-source catalog for Apache Iceberg with Git-like branches, tags and commits that span every table at once, so a set of changes to many tables can be tested on a branch and then merged in one atomic step.Unity CatalogCommercialDatabricks’ catalog and governance layer for tables, files, functions and models, with managed and external tables, an Iceberg REST endpoint and credential vending; a separate Apache 2.0 open-source server lives at LF AI & Data.

How it fits with other technologies

What Lakekeeper uses

Bootstrap Lakekeeper, create a warehouse, then write with PyIceberg and read with DuckDB · python

# pip install "pyiceberg[pyarrow]" duckdb   (pyiceberg 0.12, duckdb 1.5)
# Fresh, unsecured Lakekeeper 0.14 at lakekeeper:8181; Silo (S3 with STS) at silo:9000
import json, urllib.request
import duckdb, pyarrow as pa
from pyiceberg.catalog.rest import RestCatalog

LK = "http://lakekeeper:8181"

def post(path, body):
    req = urllib.request.Request(LK + path, json.dumps(body).encode(),
                                 {"Content-Type": "application/json"})
    with urllib.request.urlopen(req) as r:
        return r.status, r.read()

# 1. Management API: bootstrap once, then create a warehouse on a bucket
print(post("/management/v1/bootstrap", {"accept-terms-of-use": True})[0])  # 204
status, body = post("/management/v1/warehouse", {
    "warehouse-name": "lake",
    "storage-profile": {"type": "s3", "flavor": "s3-compat", "bucket": "lake",
                        "region": "local-01", "endpoint": "http://silo:9000",
                        "path-style-access": True, "sts-enabled": True},
    "storage-credential": {"type": "s3", "credential-type": "access-key",
                           "access-key-id": "silo-root-user",
                           "secret-access-key": "silo-root-password"},
})
print(status)  # 201

# 2. Iceberg REST API: the client knows only the URL and the warehouse name
catalog = RestCatalog("lakekeeper", uri=LK + "/catalog", warehouse="lake")
catalog.create_namespace("sales")
orders = catalog.create_table("sales.orders",
                              pa.schema([("id", pa.int64()), ("amount", pa.float64())]))
orders.append(pa.table({"id": [1, 2], "amount": [9.5, 20.0]}))
orders.append(pa.table({"id": [3], "amount": [4.25]}))
print(orders.metadata_location.split("/")[-1][:5])  # 00002: two commits after create

# The S3 key PyIceberg wrote with is a temporary one vended by Lakekeeper
print(orders.io.properties["s3.access-key-id"] != "silo-root-user")  # True

# 3. A second engine reads the same table through the same catalog
duckdb.sql("INSTALL iceberg; LOAD iceberg;")
duckdb.sql("CREATE SECRET lk (TYPE iceberg, TOKEN 'dummy')")  # no auth configured
duckdb.sql(f"ATTACH 'lake' AS lake (TYPE iceberg, ENDPOINT '{LK}/catalog', SECRET lk)")
print(duckdb.sql("SELECT count(*), sum(amount) FROM lake.sales.orders").fetchall())
# [(3, 33.75)]

Lakekeeper and Lakekeeper+#

The open-source catalog and Vakamo’s commercial editions, checked 2026-10-09.

LakekeeperLakekeeper+Lakekeeper Cloud
Who runs itYou: binary, Docker image or Helm chartYou, on your cloud or on premisesVakamo, fully managed (private beta)
LicenceApache 2.0Commercial, built on the open-source release of the same versionCommercial service
AuthorizationOpenFGA, AllowAll, or your own Rust authorizer; OPA bridge for TrinoAdds Cedar policies with per-decision tracesAs Lakekeeper+
IdentityOpenID Connect and Kubernetes service accountsAdds roles from Okta, Entra ID and LDAP, and an external admission checkAs Lakekeeper+
Table maintenanceDeletes old metadata files on commitAdds automatic snapshot expiry and orphan-file removalAs Lakekeeper+
PriceFree; you pay for servers, PostgreSQL and OpenFGAQuote, by reserved capacity and data volumeQuote, by API calls and processed data volume

See it in a real stack

No architecture uses Lakekeeper yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2024–2026

By 2024 the Iceberg REST protocol had become, in the words of TIP’s first README, “the standard for catalogs in open Lakehouses”. A team at HANSETAG, a company in Germany, began its own implementation in Rust on top of iceberg-rust and called it TIP, for “The Iceberg Protocol” and “the tip of the Iceberg”. Its first README said they started it because existing catalogs lacked customizability, support for on-premise deployments and other features they needed. The repository was created in April 2024 and 0.1.0 shipped in June 2024.

The early design made everything a company might swap into a Rust trait: the database, the secret store, the authorizer, event publishing and a hook that can veto changes that break data contracts. Clients got S3 access through remote signing instead of shared bucket keys, and every change could be emitted as a CloudEvent. Release 0.4.0 in October 2024 renamed TIP to Lakekeeper. 0.5.0 in December 2024 added OpenFGA permissions, an embedded web UI, projects, nested namespaces and Kafka events, and moved the default port to 8181.

Vakamo, co-founded by Viktor Kessler and Christian Thiel, now builds and maintains Lakekeeper and sells Lakekeeper+ on top of it; the published Lakekeeper+ release notes begin with 0.12.0 in April 2026. Release 0.11.0 in January 2026 made vended credentials, not remote signing, the S3 default. 0.14.0 in October 2026 added a Grants API that works with every authorizer, governance tags and namespace moves.

Why it’s built this way

Rust, as one binary with no local state
The first README promised a single 30 MB binary with no JVM or Python environment, which could be scaled horizontally and updated without downtime because all state sits in PostgreSQL.
Extension points as Rust traits
The authors wanted a catalog companies could adapt: plug in their own access management, secret store or event stream, or block changes that would break a data contract, by implementing a handful of methods.
Never hand clients the bucket keys
S3 remote signing came first, then vended credentials scoped to one table. Lakekeeper also refuses overlapping table locations, because a credential for one table must not reach another table’s files.
OpenFGA instead of plain roles
The README said simple role-based access wasn’t enough. OpenFGA, based on Google’s Zanzibar paper, stores grants as relationships and inherits them both ways through nested namespaces.

Timeline

  1. 2024

    HANSETAG releases TIP 0.1.0, a Rust Iceberg REST catalog, in June

  2. 2024

    0.4.0 renames TIP to Lakekeeper in October and adds GCS and soft deletion

  3. 2024

    0.5.0 in December adds OpenFGA permissions, an embedded UI and projects

  4. 2026

    0.11.0 in January makes vended credentials the S3 default

  5. 2026

    Vakamo’s first published Lakekeeper+ release, 0.12.0, in April

  6. 2026

    0.14.0 in October adds the Grants API, governance tags and namespace moves

Sources22 · facts checked 9 October 2026

Improve this page on GitHub