Nothing reads your data until Lakekeeper says yes.

Lakekeeper is an open-source Apache Iceberg REST Catalog written in Rust that enforces your data access policy on every request. Because engines must ask the catalog before they can read, Lakekeeper is the one place a policy can be written once and applied everywhere — it resolves the caller's identity, evaluates the request, issues short-lived scoped credentials, and records what happened. A catalog that only describes your data can't stop anything; this one sits on the request path. Apache 2.0, single binary, no JVM.

Any client that speaks the Iceberg REST Catalog protocol. Spark, Trino, Starburst, StarRocks, PyIceberg and DuckDB all work, and Spark, PyIceberg, Trino and StarRocks are integration-tested in CI on every commit. Because the protocol is the open standard rather than a Lakekeeper-specific API, new Iceberg-compatible engines generally work without changes.

No. Iceberg tables are native, and Generic Tables let you register non-Iceberg formats — Parquet, Delta and Lance vector datasets — as governed objects in the same namespace. They inherit the same credential vending and access control without being converted, so the documents, files and AI-native formats your models read sit under the same policy as your tables.

Lakekeeper is built and maintained by Vakamo and licensed under Apache 2.0 — around 500,000 downloads a month. The open core is production software, not a trial: run it in production for as long as it serves you. Lakekeeper+ is a separately licensed edition on top.

Both implement the Iceberg REST Catalog specification, so on the protocol they're interchangeable. The differences are runtime and enforcement: Lakekeeper is Rust rather than Java — a single binary with no JVM — and adds S3 remote signing, Cedar policy-as-code, and per-decision policy tracing in the audit log. Polaris sits under the Apache Software Foundation.

Unity Catalog is excellent inside Databricks; Lakekeeper is built for estates that aren't only Databricks. If your Spark runs on Databricks, your ad-hoc queries run on Trino and something else runs on-premises, Unity governs one of those well and the others partially — which leaves you reconciling several partial answers when an auditor asks a single question. Lakekeeper sells no compute, so it has no reason to make governance work better inside one engine.

Glue and Lake Formation govern AWS well and stop at the AWS boundary. Lakekeeper runs the same policy across AWS, Azure, Google Cloud, on-premises S3-compatible storage and air-gapped environments, with one audit trail spanning all of them. If your estate is entirely AWS and will stay that way, Lake Formation is a reasonable answer; if it isn't, you end up with a governance model that only covers part of it.

Every request is checked against policy before any data is read. An engine asks the catalog for a table, Lakekeeper resolves the caller's identity against your identity provider, evaluates the request, and only then issues credentials scoped to that access — so an unauthorised read isn't detected afterwards, it never happens. The decision and its outcome are recorded.

With credential vending, an engine receives a token scoped to a storage prefix and can read anything in that prefix until it expires. With remote signing, the engine never receives a credential at all — for each individual file it calls back to Lakekeeper, which checks policy and returns a pre-signed URL for that one object. Authorisation happens per object rather than per session, so a compromised worker node can't read a single byte without Lakekeeper logging the request.

No. Lakekeeper administers and enforces access without reading data contents — the engine reads directly from your object storage using credentials Lakekeeper issued, and the bytes never pass through it. That's why it can run air-gapped and why the sovereignty question has an architectural answer rather than a contractual one: control without custody.

Yes — an agent is just another caller, subject to the same policy check as Spark or a human analyst. For delegated access, Trusted Engines lets a query engine you've registered prove its own identity to Lakekeeper and then assert the human it's acting for, with referenced-by chains resolving permissions for that person at every hop. Trino is the engine type supported today. The audit log names the person rather than a shared service account.

OIDC — including several providers simultaneously — plus native Kubernetes service account authentication. For role and group resolution there are dedicated providers for Okta (with DPoP sender-constrained tokens), Microsoft Entra ID via Graph including US-government and China sovereign clouds, and LDAP / Active Directory with transitive group resolution and range retrieval for users in more than 1,500 groups. Lakekeeper is never an identity provider itself and stores no passwords.

Who accessed what, under which policy, with the outcome — and in Plus, which specific policy determined each allow or deny decision. That's the difference between showing an auditor that a request happened and showing them the rule that permitted it. Audit logging is enabled by default and emitted at INFO level, so the record exists from first start rather than being something you switch on after an incident.

Lakekeeper's authorization runs on OpenFGA for relationship-based access control, with Cedar policy-as-code available in Plus, and a Rust Authorizer trait you can implement to connect Lakekeeper to your own system. Plus also adds an external admission gate that calls your own decision service after authentication and fails closed if it doesn't answer. Separately, the OPA bridge publishes Lakekeeper's permissions through Open Policy Agent so engines that run their own access control via OPA — Trino today — enforce the same permissions instead of a second, drifting copy.

Lakekeeper provides view security with DEFINER semantics: a user with no access to the underlying tables can be granted access to a view, which executes under its creator's context and returns only the transformed result. That covers most filtering and masking requirements by defining the view rather than by evaluating per-caller rules against the base table.

Yes, and it's designed for it. Lakekeeper is a single Rust binary with no JVM, deployable via Helm with documented CA handling for air-gapped images, certified for Red Hat OpenShift, and available in a FIPS-pinnable base image for compliance-constrained environments. It supports on-premises S3-compatible storage alongside AWS S3, Azure ADLS Gen2, Microsoft OneLake and Google Cloud Storage.

PostgreSQL 15 or later, and an OIDC provider if you want authentication. That's it — no JVM, no Zookeeper, no separate metastore. It's stateless and scales horizontally, with read-replica support, tuned caches exposed as Prometheus metrics, and optional HashiCorp Vault KV2 for secrets.

It produces the evidence those regimes require: a complete record of who accessed what, under which policy, across every engine, in one place. DORA also requires a credible exit plan for every material ICT provider — and because Lakekeeper is Apache 2.0, that plan is straightforward to write. Lakekeeper is infrastructure that produces evidence; it does not make you compliant on its own.

Core is Apache 2.0 and yours to keep: the Iceberg REST catalog, web console, Datasets and AI-native formats. It's production software, not a trial. Plus adds what regulated production asks for — Cedar policy as code with per-decision audit trails, Okta / Entra ID / LDAP role providers, admission gates, customer-managed KMS encryption, automated Iceberg table maintenance and an SLA. Cloud is Plus operated for you, currently in private beta.