Capabilities

What the platform has, and what it does not yet.

Every capability of LakehouseBox on one page, with its status and a link to the page that documents it. live runs on the managed service today. beta runs, with a gap we name. coming soon is designed or built but not switched on. The last section lists what is not there at all.

01Storage and catalog

One system holds the tables and answers for them.

  • Apache Iceberg REST catalog and object storage. The catalog and the S3-compatible store are one process, SeaweedFS 4.47, run on Hetzner servers in Nuremberg, Germany. Each catalog is one Iceberg REST catalog with its own bucket; engines talk to catalog.tablemere.com and s3.tablemere.com directly. Getting started
    live
  • Table buckets that accept only Iceberg. A table bucket takes data files (Parquet, ORC, Avro, Lance) and Iceberg metadata in the Iceberg layout and refuses everything else, for every credential. Files that are not tables go to the blob bucket beside each catalog. Engines
    live
  • Format versions 2 and 3. Each catalog has a default format version for the tables the platform creates; an engine's own CREATE TABLE is honoured as sent. Version 3 carries geometry columns; GET /v1/config/formats lists which engines write which version. CLI reference
    live
  • Managed maintenance. Compaction to 128 MB files, snapshot expiry (20 snapshots, 7 days per table) and orphan cleanup run hourly on every table, whether or not anyone is connected. Included; nothing to configure. Pricing
    live
  • Cold storage tier. A catalog carries a tier policy, hot or cold, settable by an admin with tablemere catalog update --tier. The move of quiet volumes to cold storage is built and measured but not switched on for the managed service; no table is cold today. CLI reference
    coming soon

02Access and identity

Short-lived where it can be, revocable where it cannot.

  • Per-table short-lived credential vending. An engine exchanges the catalog's credential for catalog tokens (900 s) and storage credentials scoped to one table (about an hour) by itself. Rotating the catalog's credential refuses the old keys at once; vended sessions run out within the hour. Engines
    live
  • Catalog-enforced tenant isolation. Every catalog has its own storage identity, and the only grant is a bucket policy naming that identity, enforced by the catalog and the store rather than by our application code. A credential for one catalog cannot list, read or write another. The isolation suite, with positive and negative controls, gates every deployment. Security overview
    live
  • Accounts, organisations, members and roles. A person signs up with an email address and a password on the account page. An organisation has two roles, admin and member; admins hold write on every catalog, manage members and claim the company's email domain. Access to a catalog is a grant, read or write, per member or per agent key. Getting started
    live
  • Agent keys and tablemere login. The CLI prints a link and a code, a person approves the connection in the browser, and the CLI receives a key of its own, saved to disk and never shown. A key holds exactly the grants it was given and is revoked on its own; keys can also be minted by hand for a machine without a browser. Agent setup
    live
  • Audit log. Every action on the account, its catalogs, grants and keys is recorded with who did it; tablemere audit and GET /v1/audit read it back for 400 days. API reference
    live

03Interfaces

Three faces of one API, and a small account page.

  • The CLI. One Python file, standard library only, verified against a published SHA-256. Output is JSON whenever stdout is not a terminal; six exit codes carry the failure class. tablemere duckdb opens a DuckDB shell with the catalog attached. CLI reference
    live
  • The REST API. JSON in, JSON out. Every error is a typed object with a code, a message, usually a remedy and always a request_id. Creates take an Idempotency-Key header and replay the original response. GET /v1/usage lists every limit with its headroom and says which are enforced. API reference
    live
  • The MCP server. The account as tools for Claude Code, Claude Desktop, Cursor or any MCP host: catalogs, connection recipes, table credentials, grants, tokens, members, usage. Over stdio on your machine, or over Streamable HTTP at mcp.tablemere.com/mcp. No query tool by design; the agent runs the recipe in its own engine. Installable from a checkout; not on PyPI yet. MCP
    live
  • The account page with a SQL panel. Catalogs with your level on each, agent tokens, members, usage against the 5 GB, and a SQL explorer running DuckDB compiled to WebAssembly in the browser: the site never sees the data. The panel is read-only, with one sanctioned write, loading the 20-row sample table. Getting started
    live
  • Engines. DuckDB 1.5.5 or newer, PyIceberg 0.12 and Spark 3.5 with Iceberg 1.11 read and write, verified against the service. Trino and ClickHouse recipes come from the REST contract and are not yet verified. Snowflake's catalog integration connects; its data path does not work yet. Databricks is untested. Engines
    live · limited

04Getting data in

Engines, imports, drops and intakes.

  • Writes from your engine. CREATE TABLE … AS SELECT, INSERT and COPY from DuckDB, PyIceberg or Spark commit straight to the catalog. Measured: a million rows, 18 MB of Parquet, in about 2.3 s from a laptop, one commit. Engines
    live
  • Table import. tablemere table import loads many Parquet or CSV files as one commit, keeps GeoParquet metadata as table properties, and creates a format-version 3 table with typed geometry when the catalog asks for it. CLI reference
    live
  • Blob buckets and uploaders. Every catalog has a second bucket for files that are not tables: Parquet, CSV, images, any object. An uploader is a write-only, long-lived, revocable credential that can only put objects under one prefix of that bucket; it cannot read, delete or touch the tables. The catalog's own credential reads what was dropped and turns it into tables. Uploaders
    live
  • Lifecycle rules. On the blob bucket, expire files by age or by date under a prefix and abort stale multipart uploads; the store applies rules in a daily pass, so a deletion can be up to a day late. Table buckets never take lifecycle rules. Lifecycle
    live
  • Ingest sinks. One HTTP intake per table for a device, a webhook or an agent with no query engine: post JSON arrays to one URL with a send-only key, up to 16 MiB per batch, with an idempotency key. Batches are appended to the table on a rolling policy (default every 300 s or 64 MiB), each row stamped with its arrival time; rows that do not fit the schema are kept for the producer to read. Enabled on the service. Sinks
    live

05Operations

What we run for you, and what we measure.

  • Off-host copies and rehearsed restore. Control-plane state is copied off-host every 5 minutes, store metadata hourly, data files nightly, to Hetzner Object Storage in Falkenstein, Germany. A restore onto a fresh server was rehearsed in about 35 minutes. No automatic failover: one host, and a failure means downtime until the restore. Security overview
    beta
  • Encryption. In transit: TLS 1.2 and 1.3 only on every public hostname, HSTS, S3 requests SigV4-signed. At rest: we do not currently claim encryption at rest for customer content or for tenant secrets. Security overview
    in transit only
  • Limits and the usage endpoint. Storage (5 GB on the free plan) and catalogs per project (3) are enforced; tables (50), namespaces (10), objects (50,000) and the commit rate are guidelines. Storage is measured hourly and on demand; over the limit, creating and vending write credentials answer 409 and reading keeps working. Limits
    live
  • Key rotation. tablemere catalog rotate replaces a catalog's credentials; the old keys are refused at once and vended sessions run out within the hour. Our own admin and signing keys have scripted rotations with measured revocation. Security overview
    live

06Deployment

Our service, or your servers.

  • Managed service in Nuremberg. Operated by Tablemere SL on Hetzner infrastructure; no US-controlled company operates any part of the service or holds your data. Who touches what, by name: Sovereignty.
    live
  • Self-hosting. The same containers on your own host: the compose file and the deploy scripts the managed service uses, one node per install, backups to an S3-compatible store of your choice. No packaged installer yet; licence and support terms are being decided. Self-hosting
    beta
  • Public datasets. Free hosting for public data, read by anyone without credentials. Designed and measured, not switched on. Interested in publishing one? Get in touch.
    coming soon

07Not yet

What is not there, and we say so.

  • An SLA. None during the beta; we publish what we measure instead.
    none
  • High availability. One host. A failure means downtime until the restore from the off-host copies.
    planned
  • Paid plans. The free plan, 5 GB stored and no card, is the offer today. Paid plans wait for the company registration; the payment provider will be European.
    later
  • A full web dashboard. The account page is small; the API and the CLI are the primary interface.
    partial
  • Sign in with Google or any social login. Accounts are created with an email address.
    none
  • Bring your own bucket at another provider. Your data lives on our storage, in Germany.
    roadmap

Next.

Start free How it works Read the docs

5 GB stored, no card. Questions about any item: hello@tablemere.eu.