seaweedfs is a free, open source data warehousing & processing project written in Go and released under Apache-2.0. It has 34,819 GitHub stars, 3,002 forks and 772 open issues, and was last pushed 2 hours ago. On this registry it ranks #2 of 9 tracked projects in Data Warehousing & Processing, with 5 head-to-head comparisons available.

What is seaweedfs?

SeaweedFS is an Apache-2.0 distributed storage system written in Go that serves an S3-compatible object store, a POSIX file system, and Iceberg lakehouse tables from one weed binary, built for storing and serving billions of files with O(1) disk access.

What it is

SeaweedFS is a simple and highly scalable distributed file system with two stated objectives: to store billions of files and to serve those files fast. A single weed binary serves an S3 object store, a POSIX file system, and a lakehouse with S3 Tables, all over the same data. Both read and write operations have O(1) complexity and can run at the full speed supported by the underlying hardware. It is written in Go and released under the Apache-2.0 licence, and it is developed in the object storage, distributed file system, and blob storage space, with topics that also cover erasure coding, FUSE, HDFS, Kubernetes, and POSIX access.

The concrete problem it solves is the cost and latency of address resolution at very large file counts. In SeaweedFS, each blob is one disk read away, so lookup does not grow with the number of stored files, and capacity grows by starting another volume server rather than by reshuffling a fixed cluster. It replaces general-purpose distributed file systems and object stores for teams that need file-level and object-level access to the same bytes; the README positions it directly against HDFS, GlusterFS, Ceph, MooseFS, MinIO, and RustFS. It also acts as a fast cache or tiering layer in front of cloud storage, so hot data sits on local disks while cold data stays in the cloud.

Key capabilities

  • One weed binary exposes an S3 object store, a POSIX file system, and a lakehouse with S3 Tables over the same underlying data.
  • O(1) read and write complexity, because each blob is one disk read away.
  • Horizontal scale-out by starting another volume server, without a redesign of the existing cluster.
  • S3 API coverage that the project describes as the most complete S3 API among its peers.
  • S3 Tables support for building a data warehouse over the same storage.
  • Transparent caching and tiering of cloud storage, so remote buckets can be fronted by local capacity.
  • Erasure coding and a FUSE mount, plus HDFS, Kubernetes, and POSIX integration as named topics.

Who uses it and how

  • Teams running Kubernetes deploy it through the Helm chart to give pods S3-compatible object storage and file access under the same cluster.
  • Environments with billions of files use the volume-server scale-out model, adding servers to grow capacity instead of migrating data.
  • Hadoop and HDFS users run it as a replacement file system, a use case reflected in the hadoop-hdfs and hdfs topics.
  • Applications that expect a real file system mount it through FUSE, exposing the same data as a POSIX file system.
  • Lakehouse and analytics teams use the S3 Tables path to query Iceberg tables while keeping object access for the underlying files.
  • Operators with existing cloud buckets put SeaweedFS in front as a cache, keeping frequently read objects on local disks with tiering back to the cloud.

Getting started

Download the latest binary from the releases page and unzip the single weed (or weed.exe) file, or let the install script place it in /usr/local/bin. Docker users can pull chrislusf/seaweedfs or use the Docker Compose setup, and Kubernetes deployments use the Helm chart; building from source is also supported.

How it compares

The README compares SeaweedFS against HDFS, GlusterFS, Ceph, MooseFS, MinIO, and RustFS, so it belongs to the same family of self-hosted distributed storage rather than to the managed cloud services. Its distinguishing claims within that group are O(1) access for both reads and writes, a single binary covering object, file, and table interfaces, and scale-out by adding volume servers.

When to use it — and when not to

A self-hoster must run the full set of server processes, including the volume servers that hold the data and the components exposing S3, POSIX, and S3 Tables, and must plan for erasure coding, capacity growth, and cloud tiering if those features are used. It is a poor fit for teams that want a fully managed storage service with no cluster to operate, or for small deployments where a single local disk or a hosted bucket is enough. The repository carries 772 open issues, and the README excerpt available here is truncated, so anyone evaluating it should read the full wiki, the architecture paper, and the benchmark section before committing.

project readme (upstream, from github) — read inline

SeaweedFS

Slack Twitter Build Status GoDoc Wiki Docker Pulls SeaweedFS on Maven Central Artifact Hub

SeaweedFS Logo

SeaweedFS is a simple and highly scalable distributed file system. There are two objectives:

  1. to store billions of files!
  2. to serve the files fast!

One weed binary serves an S3 object store, a POSIX file system, and a lakehouse with S3 Tables, all over the same data. Each blob is one disk read away, capacity grows by starting another volume server, and cloud storage can be cached or tiered transparently. Both read and write operations have O(1) complexity and can run at the full speed supported by the underlying hardware.

Table of Contents

Quick Start

One command

Download the latest binary from the releases page and unzip the single weed (or weed.exe) file, or let the install script put it in /usr/local/bin:

curl -fsSL https://raw.githubusercontent.com/seaweedfs/seaweedfs/master/install.sh | bash

Then start a ready-to-use S3 object store:

AWS_ACCESS_KEY_ID=admin \
AWS_SECRET_ACCESS_KEY=secret \
S3_BUCKET=my-bucket \
./weed mini -dir=./data

That's it. The S3 endpoint is at http://localhost:8333, my-bucket exists, and admin/secret are valid credentials:

AWS_ACCESS_KEY_ID=admin AWS_SECRET_ACCESS_KEY=secret \
  aws --endpoint-url http://localhost:8333 s3 cp README.md s3://my-bucket/

The same process also runs the master, a volume server, the filer, WebDAV, the Iceberg REST catalog, and the Admin UI. Add S3_TABLE_BUCKET=warehouse to also create an Iceberg table bucket, or warehouse:LANCE for a Lance one. Drop the AWS keys to run without authentication for development.

macOS: if the binary is quarantined, run xattr -d com.apple.quarantine ./weed first.

weed mini is auto-tuned for one node and is fine for single-node production, such as an S3 gateway that issues presigned URLs. See [Quick Start with weed mini][WeedMini].

Docker

docker run -p 8333:8333 -v weed-data:/data \
  -e AWS_ACCESS_KEY_ID=admin \
  -e AWS_SECRET_ACCESS_KEY=secret \
  -e S3_BUCKET=my-bucket \
  chrislusf/seaweedfs

Same behavior as the weed mini command above.

Docker Compose

To run master, volume server, filer, S3, and WebDAV as separate services:

wget https://raw.githubusercontent.com/seaweedfs/seaweedfs/master/docker/seaweedfs-compose.yml
wget -P prometheus https://raw.githubusercontent.com/seaweedfs/seaweedfs/master/docker/prometheus/prometheus.yml
docker compose -f seaweedfs-compose.yml -p seaweedfs up

[Docker Compose for S3][DockerComposeS3] adds credentials, and the docker/compose folder has variants for replication, mounts, message queues, and more.

Kubernetes with Helm

helm repo add seaweedfs https://seaweedfs.github.io/seaweedfs/helm
helm install seaweedfs seaweedfs/seaweedfs -n seaweedfs --create-namespace -f values.yaml

A production-shaped values.yaml for a three-node cluster: two copies of every write, three masters, and an S3 endpoint with credentials and a bucket.

global:
  seaweedfs:
    enableReplication: true
    replicationPlacement: "001"   # one extra copy on another server; "002" for two

master:
  replicas: 3
  data:
    type: persistentVolumeClaim   # the cluster's default storage class; add storageClass to pick one
    size: 1Gi

volume:
  replicas: 3                     # at least 1 + the sum of the replication digits
  dataDirs:
    - name: data
      type: persistentVolumeClaim
      size: 500Gi
      maxVolumes: 0               # size the volume count from the disk

filer:
  replicas: 2
  data:
    type: persistentVolumeClaim
    size: 20Gi

s3:
  enabled: true
  replicas: 2
  enableAuth: true
  credentials:
    admin:
      accessKey: admin
      secretKey: change-me
  createBuckets:
    - name: app-storage

The S3 endpoint is the seaweedfs-s3 service on port 8333. [Helm Chart Recipes][HelmRecipes] has values for a development cluster, a lakehouse with the Iceberg catalog exposed, filer metadata on PostgreSQL, and node-local disks. The [SeaweedFS Operator][Operator] and the [CSI driver][SeaweedFsCsiDriver] are the other Kubernetes paths.

Build from source

git clone https://github.com/seaweedfs/seaweedfs.git
cd seaweedfs/weed && make install

weed lands in $GOPATH/bin. [Getting Started][GettingStarted] covers running master, volume, filer, and S3 as separate processes.

Scale out

Capacity is a volume server. Start one on any machine with disk and point it at the master:

weed volume -dir=/data -master=<master_host>:9333

Nothing rebalances until you ask it to. Throughput is a filer or S3 gateway; they are stateless, so run as many as you need behind a load balancer. [Production Setup][ProductionSetup] walks through a multi-node cluster.

Back to TOC

Why SeaweedFS

Fast

  • One disk read per blob. A small file is one blob; a large file is split into chunks of a few MB, each its own blob. A volume server keeps a 16-byte index entry per blob in memory and reads it in a single seek, also for erasure-coded data.
  • The master is not in the read path. Clients cache the volume-to-server mapping and talk to volume servers directly.
  • 40 bytes of metadata per file on disk. Small files are packed into append-only volume files, so there is no per-file inode, no per-file metadata file, no fragmentation, and writes are SSD friendly.
  • Hot data is replicated; [erasure coding][ErasureCoding] is applied to warm data in the background, so writes never pay the encoding cost.
  • The [Rust volume server][RustVolume] is a

readme truncated — read the full docs on github

Frequently asked questions

Is seaweedfs free to use?

seaweedfs is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does seaweedfs do?

SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables, designed to handle billions of files with O(1) disk access

What is seaweedfs written in?

seaweedfs is primarily written in Go. Its source is publicly available at https://github.com/seaweedfs/seaweedfs, and it has 34,819 GitHub stars.