How it works
A lakehouse, with the compute wherever your agent runs.
LakehouseBox keeps analytical data as Apache Iceberg tables in a catalog with its own object storage. Your agent queries and writes those tables with an engine it runs itself, DuckDB most of the time. This page explains the pieces: what a lakehouse is, how that differs from a cloud data warehouse, why the table format matters, what LakehouseBox does and does not do, and what you pay for.
01What a lakehouse is
Files in object storage, a catalog that makes them tables.
A data lake is a collection of files, usually Parquet, in object storage. It is cheap and any tool can read it, but nothing says which files make up a table or what changed last night.
A lakehouse adds a table format and a catalog. The table format, Apache Iceberg here, records which files belong to a table, its schema, its partitioning and every version of it. The catalog is where engines ask which tables exist and where the current version of each one is.
The result is a set of tables with transactions, schema and history, stored as open files. Storage and compute are separate: the tables sit in one place, and any engine that speaks Iceberg can open them.
In LakehouseBox the hierarchy is organisation → catalog → namespace → table. A catalog is one Iceberg REST catalog with its own bucket; a namespace is a schema. The engine sees demo_data.garden.sensor_readings.
02DuckDB where your agent runs, versus a warehouse
The engine goes to the data. The data stays put.
A cloud data warehouse runs the compute in the vendor's cluster. You load data in, send SQL over a driver, and pay for the compute each query used. The rows live in the vendor's format, behind the vendor's account, and every result comes back over the wire.
DuckDB is an analytical engine that runs inside a process: a Python script, a laptop shell, a CI job, a sandbox, a browser tab. With its Iceberg extension it talks to a REST catalog and reads Parquet from object storage directly, over HTTPS. There is no cluster to start, size or leave running; the compute is whatever the agent already has.
That fits how an agent works. The agent has a machine; the question is where the data lives between sessions. With LakehouseBox the agent attaches the catalog, runs the query locally and, when a result is worth keeping, writes it back as a new Iceberg table another session can open.
In the recorded run of 2026-09-20, DuckDB 1.5.5 on a laptop read a 185,884-row table from the live catalog, pivoted it into 61 rows in 363 ms and saved the result as a new table in 1,231 ms; a second process attached and read it back 340 ms later. Nothing ran on our side but the catalog calls and the object reads.
| Cloud data warehouse | LakehouseBox + your engine | |
|---|---|---|
| Where compute runs | The vendor's cluster | Where your agent runs: DuckDB in its process, or Spark on your cluster |
| What is billed | Compute per query, plus storage | Stored bytes only. Query compute is yours, so it is never on our bill |
| Who holds the format | The vendor, in its own format or its managed tables | You: Apache Iceberg tables and Parquet files, readable by any Iceberg engine |
| Credential scope | An account or role over the warehouse | Per catalog, read or write; storage credentials vended per table for about an hour; catalog tokens 900 s |
| When the session ends | The cluster idles or bills; results left in the driver are gone | The tables remain; maintenance keeps running; the next agent attaches the same catalog |
03Other engines
DuckDB first. Not DuckDB only.
The catalog is a standard Iceberg REST catalog and the storage is S3-compatible, so any engine that speaks both can open the tables. We publish for each engine what has actually been run against the service.
Verified, read and write: DuckDB 1.5.5 or newer, exercised in every phase of the integration suite; PyIceberg 0.12 (format version 2; it reads version 3 but cannot write it); Spark 3.5 with Iceberg 1.11, format version 3 included, verified 2026-09-20 with a geometry column.
Recipes from the REST contract, not yet verified: Trino and ClickHouse. There is no recorded run against the service yet, and the docs say so until there is one.
Limited: Snowflake. Its catalog integration connects; the data path does not work yet and needs work on both sides. Untested: Databricks, no run and no recipe.
One command, tablemere connect --engine duckdb|pyiceberg|spark, prints the recipe with the credential filled in. Every recipe, its verification date and its gotchas: Engines.
04Why open table formats matter
Iceberg gives files the properties of a database, without the lock-in.
Atomic commits. A write becomes visible in one step or not at all. A second commit against a stale version is refused and retried; a table is never half updated.
Snapshots and time travel. Every commit is a snapshot, and an engine can read the table as it was before the last load. On LakehouseBox maintenance keeps 20 snapshots and 7 days per table, so time travel reaches back that far.
Schema evolution. Columns can be added, renamed, widened or dropped without rewriting the data files.
Many engines, one table. The same table is read by DuckDB, PyIceberg and Spark today, and by any engine that implements the specification. The engine is a choice, not a commitment.
The data is yours to take. A table is Parquet files plus JSON and Avro metadata in a bucket you can list. Copy it out with standard tools at any time; there is no export format to convert from. The software we run to serve it is open source and named on the sovereignty page.
05What LakehouseBox does, and does not
Catalog, storage, credentials, maintenance. Never the query.
It runs the catalog and the storage as one system, in Nuremberg, Germany. Every catalog is its own bucket with its own storage identity; a credential for one catalog cannot list, read or write another, and the boundary is enforced by the catalog and the object store, not by our application code.
It hands out short-lived credentials. The engine exchanges the catalog's credential for catalog tokens (900 s) and per-table storage credentials (about an hour) by itself. People sign in on the account page; an agent connects with tablemere login, approved once in a browser, and receives its own revocable key.
It maintains the tables: compaction, snapshot expiry and orphan cleanup, hourly, whether or not anyone is connected. Off-host copies run every 5 minutes for accounts and grants, hourly for table metadata and nightly for data files; the restore is rehearsed.
It is never in the query path. There is no query endpoint. Rows travel between your engine and the object store; LakehouseBox sees the catalog call and the object reads, never a result set. The MCP server has no query tool either, by design.
It does not run your compute. You bring the engine.
Not yet: high availability (one host; a failure means downtime until a restore), an SLA, encryption at rest, paid plans, a full dashboard, public datasets. The full list, with what is live: Capabilities.
06What you pay for
One thing is metered: how much you store.
Storage is measured hourly and on demand, and it is the only figure on the bill. Not queries, not commits, not rows, not egress. Query compute runs in your environment, so there is nothing of ours to charge for it. Table maintenance costs us a fraction of a cent per gigabyte processed, so it is included rather than metered.
Today the offer is the free plan: 5 GB stored, no card. Paid plans are not yet announced. The other limits are guards, not prices, and the API tells you each one and its headroom before you reach it.
Next.
5 GB stored, no card. Data in Nuremberg, Germany. Everything the platform has, with its status: Capabilities.