· Javier de la Torre

Why the world needs LakehouseBox

Agents already have compute and tools. What they lack is a shared place to keep analytical data between sessions. Why we built that as a managed Apache Iceberg service, and why we ended up running the storage ourselves, in Germany.

An agent that analyses data today is well equipped. It runs wherever you run it, it has DuckDB or Python within reach, and it can read a Parquet file, join two tables and draw a chart without asking anyone. What it does not have is somewhere to put the result that will still be there tomorrow, for the next session or for a different agent. The context window closes, and with it goes the table it just built.

The workarounds are familiar. Files in a bucket, with no schema, no history and a name that only the agent that wrote it understands. Or a data warehouse designed for people and dashboards, where every exploratory query has a price and the credentials in the agent's environment open the whole account. Neither is built for the way agents actually work: many short sessions, a lot of trying things, and a need to pick up exactly where the last one stopped.

What an agent needs from a data layer

We wrote the list down before we wrote code, and it has not changed much:

  • Tables, not files. A table has a schema that can evolve, a history you can go back to, and a name another agent can find. Apache Iceberg gives all of that in an open format that DuckDB, PyIceberg, Spark and a growing list of engines can read and write.
  • One HTTP API, and errors it can act on. Every error a typed object with a code, a message and a remedy. Every limit readable before it is hit. Every mutation safe to retry.
  • Credentials scoped to the work. The key an agent holds should open one table for one hour, not the account for ever. If it leaks into a log or a transcript, the damage has a boundary.
  • No meter on curiosity. The agent already has compute. If it runs its own DuckDB, nobody should bill it per query for looking at its own data.
  • Somebody else does the maintenance. Compaction, snapshot expiry, orphan cleanup, backups. An agent should never have to think about small files.

That is the thesis of LakehouseBox in one sentence: your agent already has compute; give it shared data. The agent brings the engine. LakehouseBox stores the tables, vends the credentials and keeps the tables healthy.

Why we ended up running the storage ourselves

The first design was the obvious one: a catalog in front of object storage that a European provider operates, with short-lived credentials handed out per table. It fell apart on measurement. Credential vending needs the storage provider to answer STS requests, and no European object storage we tested does: OVHcloud returns 400 and Scaleway 412 to every STS action, and Hetzner's object storage has no API for it at all. Of the providers we measured in September 2026, only an American one vended properly. So "European-operated and real per-table credentials" was impossible on someone else's bucket, unless we sat in the data path of every request, which the engine that matters most, DuckDB, cannot work around.

We chose the other option. LakehouseBox runs the object store and the Iceberg catalog as one system, on servers in Nuremberg, Germany, operated by a Spanish company. That makes us responsible for durability, which we take seriously: state is copied off the host every few minutes, store metadata every hour, data files nightly, and we rehearse the restore. It also makes the promise narrow and true. No US-controlled company operates any part of the service or holds your data, and we publish who touches what and what we still depend on outside the EU. The details, stated as facts rather than promises, are on the sovereignty page.

Full sovereignty is out of reach for most of a company's stack. Analytics is the exception: every layer of an analytical data platform exists as open source or as a European commodity, so it is one of the few places where the promise can be kept rather than aspired to.

What LakehouseBox is today, and what it is not

It is a managed Iceberg service for agents. You paste one prompt into your agent, approve its connection once in the browser, and from then on it talks to one API and runs DuckDB where it already runs. Tables persist across sessions and across agents. Credentials are vended per table and expire. The free plan is 5 GB with no card. DuckDB, PyIceberg and Spark are verified against it; the engines page says exactly what we have tested and what we have not.

It is not a query engine, and it is not a BI tool. We do not sell compute, and we do not intend to. It is also early: one region, no high availability yet, no paid plans yet, and a list of things marked "not yet" on the homepage that we would rather show than hide.

If you have an agent and some data it keeps losing, the setup instructions are written for the agent to follow. The agents page has the whole lifecycle with the commands.

All posts · Atom feed · Questions: hello@lakehousebox.com