Iceberg is built for analytics — columnar scans and aggregations. Lance is built for the opposite — random-access point lookups and vector search. The emerging best practice for AI data is to use both, co-located in one object store with a SQL engine bridging them. SeaweedFS table buckets do exactly that: an Iceberg bucket and a Lance bucket in the same cluster, each with its built-in catalog, joined by DuckDB. A complete, real transcript: analyze a document catalog in Iceberg, derive embeddings, and serve fast similarity lookups from Lance.
A SeaweedFS table bucket can hold Lance datasets, fronted by a built-in Lance Namespace catalog that LanceDB connects to with connect_namespace(“rest”, …). This is a complete, real transcript: start SeaweedFS, write an embeddings table, build an IVF_PQ index, and run approximate nearest-neighbor search — every vector, index file, and manifest living in your own S3 bucket. Every command and output block below was run end to end on one machine.
ClickHouse’s DataLakeCatalog engine attaches straight to a SeaweedFS table bucket — the built-in Iceberg REST catalog, no Hive Metastore or Glue. Reads work the moment you attach. Writes are the interesting part: ClickHouse’s experimental Iceberg inserts produce metadata other engines reject, so the SeaweedFS catalog repairs each commit as it lands — and PyIceberg reads ClickHouse’s rows right back. A complete, real transcript.
A SeaweedFS table bucket is an S3 bucket that’s also an Apache Iceberg warehouse, fronted by a built-in Iceberg REST catalog — no Hive Metastore, Nessie, or Glue to run. This is a complete, real transcript: start SeaweedFS, create and load a table with PyIceberg, then attach the catalog from DuckDB and run SQL. Every command and output block below was run end to end on one machine.
S3 conditional writes — If-None-Match, If-Match, etag preconditions, object lock — need a read-check-write that’s atomic across every gateway and filer. Instead of demanding compare-and-swap from each of SeaweedFS’s many metadata backends, or taking a distributed lock on every write, SeaweedFS routes each object’s writes to one owner filer that serializes them locally. Consistent on LevelDB through Cassandra, at the cost of at most one extra hop.
A frozen seal rejects every write — perfect for finished data, awkward for a directory that still takes the occasional straggler. Mutable seals keep most of the metadata savings while staying writable. Here’s how they work, what they cost — measured on a live cluster — and why you still shouldn’t seal everything this way.
A complete, real transcript: install the seaweed-vfs kernel module and daemon on a bare Debian box, mount a SeaweedFS filer with mount -t seaweedvfs, run SQLite and a compiler on it, watch the page cache do its thing — and re-export the whole namespace over NFS with the stock Linux kernel server.
Replication and erasure coding protect you from dying disks — not from a bad rm, a corrupting ETL job, or an AI agent rewriting the wrong prefix. SeaweedFS Enterprise gives every second in a retention window a working undo: find and restore deletes, or rewind a whole subtree to any instant, with a previewed plan before anything changes.
Most metadata in a large cluster describes files nobody has touched in months — yet it costs the same as metadata for hot files. Sealed directories pack a cold directory’s entries into compressed, volume-stored chunks, while every file stays readable in place.