A table bucket keeps tiny, hot metadata right next to large, cold data. SeaweedFS Enterprise volume classes route each to the right tier the moment it is written — metadata to fast replicated SSD, data to capacity HDD — with built-in Iceberg/Delta/Hudi rules, and tiering profiles age the cold data down a ladder to erasure coding and cloud. A companion job even keeps each Parquet file’s footer on SSD after its body erasure-codes away, so query planning stays fast. This is a real transcript: a cluster with two disk types, a table bucket, and before/after captures of where every byte landed.
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.
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.
A best-practices walkthrough for standing up an analytics warehouse on SeaweedFS: a three-master control plane, SSD and HDD storage tiers across racks, stateless S3 gateways, a tiering policy with erasure coding for cold data, per-tenant QoS, Prometheus metrics — and live proof that access and capacity scale by just adding processes. Every command and screenshot is a real capture from one session, with multi-host deployment via seaweed-up at the end.
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.
SeaweedFS Enterprise Data Movement continuously replicates, migrates, or backs up a filer path to another SeaweedFS cluster or a cloud object store — set up and watched from the Admin UI, executed by data_movement plugin workers. This is a real two-cluster walkthrough: stand up a source and a destination, register a target, create a continuous policy, and watch 25 files snapshot-seed and then tail across, caught up with zero lag.
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.
walgit is a single Rust binary that hosts git with no database and no leader — the bucket is the repository, stored as an immutable write-ahead log. Its one commit point is a compare-and-swap on a manifest object, which needs a store with conditional writes. SeaweedFS’s S3 has them, so walgit runs on it cleanly — at local-disk latency, with cloud S3 as the durable home and SeaweedFS as a cache in front of it. A complete, real transcript: build walgit, point it at SeaweedFS, git push and clone, watch the WAL objects appear in the bucket, then back it with cloud S3 so a lost cache node is just re-mounted.
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.
Seaweed KVCache gives LMCache a shared, persistent L2: every KV block survives Filer, Volume, and Master restarts, and stays available to the rest of your fleet after any single host is replaced. It talks direct RDMA (RC or DC) from inside the LMCache process — no sidecar, no gateway — capacity and throughput scale by adding storage nodes, and cache Volumes can age from NVMe/SSD down to cheaper HDD or cold storage as they cool. This post covers the restart guarantees, the verified HTTP/RC/DC and multi-node benchmark numbers, and a complete setup walkthrough from install to production capacity management.