| MinIO AIStor | SeaweedFS | |
|---|---|---|
| Latest Release | RELEASE.2026-03-20T23-11-32Z (Mar 20, 2026) | v4.17 (Mar 11, 2026) |
| License | Proprietary (enterprise) | Apache 2.0 (OSS) / Commercial ($1/TB/mo) |
| Architecture | Single binary, no external dependencies | 3-tier: Master + Volume + Filer servers, requires external metadata database |
| Primary Author | MinIO Inc. (experienced engineering team) | Primarily Chris Lu (~9,018 of ~11,000 commits) |
| GitHub Stars | ~50k (open-source MinIO) | ~31k |
| Capability | MinIO AIStor | SeaweedFS |
|---|---|---|
| Signature V4 | Native implementation | Copied from MinIO (acknowledged in source) |
| Signature V2 | Native | Copied from MinIO |
| Multipart Upload | Full | Full |
| Versioning | Full | Full |
| Object Lock / WORM | Full (compliance + governance) | Supported |
| SSE-S3 / SSE-KMS / SSE-C | Full | Supported |
| S3 Select | CSV, JSON, Parquet | Not supported |
| Lifecycle (transitions) | Full ILM with tiering transitions | TTL-only (no transitions) |
| Bucket Replication | Full with metrics, filtering, reset | Own async replication (not S3-API-based) |
| Event Notifications | AMQP, Kafka, MQTT, Redis, NATS, PostgreSQL, MySQL, ES, Webhooks | Own notification system (not SNS/SQS/Lambda compatible) |
| IAM | Full (users, groups, policies, roles, LDAP, OIDC, STS) | Basic access control, no full IAM policy engine |
| Batch Operations | Replicate, Expire, Catalog, Key Rotation | Not supported |
| POST Policy | Native | Copied from MinIO |
| S3 Express (CreateSession) | Supported | Not supported |
| ListObjectsV2 | Full with metadata extension | Full |
| STS (AssumeRole, etc.) | 6 STS methods (LDAP, WebIdentity, Certificate, etc.) | Not supported |
MinIO AIStor has significantly deeper S3 API coverage. SeaweedFS's own S3 auth layer was copied from MinIO's source code (clearly attributed in their files).
| Feature | MinIO AIStor | SeaweedFS |
|---|---|---|
| Erasure Coding | Always-on, configurable ratios (2-32 drives) | Optional, RS(10,4) default; custom ratios enterprise-only |
| Bitrot Protection | HighwayHash checksums | Enterprise-only (self-healing storage) |
| Site Replication | Active-active, multi-site, replicates IAM/STS/configs | Async only, eventually consistent, no IAM replication |
| QoS / Rate Limiting | Per-bucket, per-API-operation | Not available |
| FTP/SFTP Access | Supported | Not mentioned |
| FUSE Mount | Via minfs / AWS mountpoint-s3 | Built-in |
| WebDAV | Not built-in | Supported |
| HDFS Compatible | Not built-in | Supported |
| Cloud Tiering | S3, Azure, GCS | S3, Azure, GCS, BackBlaze |
| Compression | Supported | MIME-type-based |
| Pool Management | Decommission, rebalance, expand | Add volume servers |
| Node Maintenance | Cordon/Uncordon | Not documented |
| Healing | Continuous, automated, resumable | Enterprise-only |
| Feature | MinIO AIStor | SeaweedFS |
|---|---|---|
| MCP Server | Built-in, 79 AI-callable tools | Not available |
| Apache Iceberg REST Catalog | Built-in (AIStor Tables, 35+ endpoints) | Partial (~12 endpoints, ~40% of spec) |
| Delta Sharing | Full v1.0 protocol | Not available |
| Object Lambda | Webhook-based transforms, PromptObject | Not available |
| RDMA / GPU Direct | In development (libcuobjserver) | Not available |
| S3 ZIP Operations | Access files inside ZIP in-place | Not available |
This is the most significant feature gap. MinIO AIStor implements a production-grade Iceberg REST Catalog; SeaweedFS implements a partial subset.
| Category | MinIO AIStor Tables | SeaweedFS |
|---|---|---|
| Namespace CRUD | Full | Yes |
| Namespace property updates | Yes | No |
| Table CRUD | Full | Yes |
| Table rename | Yes | No |
| Table register | Yes (with overwrite) | No |
| Commit (OCC) | Yes (with crash recovery + rollback) | Yes (single-table, 3 retries) |
| Views (all 7 endpoints) | Full (create, load, commit, drop, list, rename, register) | None |
| Multi-table transactions | Yes (with transaction logs + recovery) | No |
| Vended credentials | Struct defined, not yet issuing | No |
| Scan planning | Not implemented | Not implemented |
| Table metrics | Yes | No |
| Table maintenance | Background snapshot expiration | Compaction, snapshot expiry, orphan removal |
| Multi-warehouse | Yes (with per-warehouse encryption) | No (single default) |
| Delta Sharing | Full v1.0 (OAuth2, predicate pushdown, CDF, time travel) | No |
| MCP AI tools | 17 table-related AI-callable tools | No |
| Auth model | MinIO IAM with s3tables:* policy actions |
SigV4 only (breaks Trino compatibility) |
| Metadata storage | Inline in MinIO buckets (no external DB) | Filer xattr (requires external DB) |
| Tested query engines | Spark, Trino, PyIceberg, DuckDB | PyIceberg, DuckDB, Trino (broken due to SigV4) |
Endpoint count: SeaweedFS ~12 of ~28 spec endpoints. MinIO AIStor 35+ (including extensions like warehouses, maintenance config, encryption, and Delta Sharing).
| Dimension | MinIO AIStor | SeaweedFS |
|---|---|---|
| Max Objects/Bucket | No limit | No documented limit |
| Max Buckets | 500,000 (soft limit) | No documented limit |
| Max Servers | No limit | No documented limit |
| Metadata | Distributed across erasure sets | Centralized filer (external DB required) |
| Single Binary | Yes | No (3 separate server types + external DB) |
This is SeaweedFS's fundamental architectural weakness. The Filer component requires an external metadata database that the user must independently operate.
| Component | Min Count | Purpose |
|---|---|---|
| Master servers | 3 (Raft) | Cluster coordination, volume placement |
| Volume servers | 3+ | Actual data storage |
| Filer servers | 2+ | Metadata gateway |
| External metadata DB | 3+ node cluster | Stores ALL file/object metadata |
| S3 gateway | 1+ | S3 API layer |
| Total | 12+ processes, 5 component types |
MinIO AIStor: single binary, no external dependencies. A 4-node HA cluster is 4 identical processes.
Every single I/O operation hits the metadata DB:
- Every S3 PUT = metadata DB write
- Every S3 GET = metadata DB read (path-to-chunk lookup)
- Every S3 LIST = metadata DB range scan
At 1 billion objects with ~1KB metadata each: ~1TB of metadata database storage that must be provisioned on fast SSDs, replicated, backed up, and managed. The DB scales linearly with object count.
Default LevelDB caps at ~2,000 inserts/sec on a single filer. For real scale, you end up operating a full distributed database (Cassandra, TiDB, CockroachDB) alongside your object store.
- SeaweedFS does not provision, back up, upgrade, or scale the metadata DB
- Schema upgrades across SeaweedFS versions are not documented
- If the metadata DB crashes or gets corrupted: all data becomes orphaned (volume servers have raw chunks but no path mapping)
- If encryption is enabled, encryption keys are stored in the metadata DB -- lose the DB, lose the data permanently
- No built-in point-in-time recovery
- The user must use the DB's own tools (
pg_dump, RedisBGSAVE, Cassandra snapshots, etc.)
The external DB adds a parallel storage tier:
- ~500 bytes to several KB per object (path, attributes, chunk locations, encryption keys, extended attrs)
- 1B objects = ~1TB metadata DB, requiring its own SSDs, memory, compute, and replication
- This is in addition to the 16 bytes per blob that volume servers keep in memory
MinIO AIStor: metadata is inline in xl.meta within the same erasure-coded drives. No separate infrastructure. Metadata capacity scales automatically with data capacity.
| MinIO AIStor | SeaweedFS | |
|---|---|---|
| Type | Active-active, strongly consistent | Async, eventually consistent |
| What replicates | Buckets, objects, IAM (users/groups/policies/service accounts), STS, configs, encryption, CORS, object lock | Object data only via weed filer.sync changelog replay |
| IAM sync | Automatic across all sites | Not replicated -- each cluster has independent identity.json |
| Credential management | Built-in (LDAP, OIDC, STS, service accounts, groups, policies) | Flat JSON file with access key + simple action strings |
| Consistency | Strong | Eventually consistent; documented risk of "not keeping up" |
| Multi-site | Unlimited peer sites | Warns against fully-meshed topologies (rename ordering issues) |
| External dependency | None | Each site needs its own metadata DB cluster |
The SeaweedFS README contains a "Compared to MinIO" section with several misleading or outdated claims:
1. "MinIO metadata are in simple files. Each file write will incur extra writes to corresponding meta file."
Misleading. MinIO AIStor uses inline metadata within erasure-coded parts (xl.meta). There is no "separate meta file for each file" in the way SeaweedFS implies. Metadata is part of the erasure set, not a standalone sidecar file.
Outdated/Wrong. MinIO AIStor has extensive small-file optimizations including inline data storage (small objects stored directly in xl.meta), prefix-based listing optimization, and efficient metadata handling. The xl.meta format is specifically designed for compact metadata representation.
Misleading comparison. MinIO reads from erasure-coded shards (typically 2-4 reads depending on EC ratio), which provides data durability and integrity verification. SeaweedFS's O(1) read comes from simple replication without integrity checks (bitrot detection is enterprise-only). Trading durability for read IOPs is not an optimization -- it is a tradeoff they do not disclose.
Framed as a weakness when it is a strength. Always-on erasure coding means MinIO AIStor provides consistent data durability with lower storage overhead (typically 1.5x vs 3x for replication). SeaweedFS's default 3x replication uses 2x more raw storage for equivalent durability.
Inaccurate. MinIO handles billions of objects in production deployments. The inline data feature, efficient listing, and distributed metadata all specifically address small-file workloads.
SeaweedFS's entire S3 authentication and authorization layer was directly copied from MinIO's source code, with attribution retained in the files:
| SeaweedFS File | Attribution |
|---|---|
weed/s3api/auth_signature_v4.go |
"mostly copied from minio implementation" |
weed/s3api/auth_signature_v2.go |
"mostly copied from minio implementation" |
weed/s3api/chunked_reader_v4.go |
"copied and modified from minio source code" -- full MinIO copyright header |
weed/s3api/s3err/s3-error.go |
MinIO Go Library copyright 2015-2017 |
weed/s3api/s3_constants/header.go |
MinIO Cloud Storage copyright 2019 |
weed/s3api/policy/post-policy.go |
MinIO Go Library copyright 2015-2017 |
weed/s3api/policy/postpolicyform.go |
MinIO Cloud Storage copyright 2015-2017 |
weed/s3api/policy/postpolicyform_test.go |
MinIO Cloud Storage copyright 2016 |
These files were added in 2020 when MinIO was under Apache 2.0. They cover: AWS Signature V4/V2 authentication, chunked upload streaming, S3 error code definitions, HTTP header constants, and POST policy validation -- the foundational S3 compatibility layer.
Additional references throughout the codebase:
s3_validation_utils.go: "Following Minio's approach"iam.go: "following the pattern used by MinIO and Ceph RGW"- Various test files reference MinIO behavior for compatibility
SeaweedFS could not have become S3-compatible without MinIO's code, and their README then positions SeaweedFS as superior to the very project they borrowed their S3 layer from.
MinIO AIStor is a purpose-built, enterprise-grade S3-compatible object store: single binary with inline metadata, always-on erasure coding with bitrot protection, full IAM (LDAP/OIDC/STS), strong active-active site replication, a near-complete Iceberg REST Catalog (35+ endpoints including views, multi-table transactions, and Delta Sharing), and an AI/ML feature set (MCP server, Object Lambda, RDMA/GPU Direct).
SeaweedFS is a general-purpose distributed file system that added S3 compatibility later using MinIO's own auth code. It requires operating an external metadata database that scales linearly with object count, has a minimal IAM system (flat JSON, no groups/roles/STS), offers only eventual consistency for cross-DC replication without IAM sync, and implements roughly 40% of the Iceberg REST Catalog spec with no views, no transactions, and an auth model that breaks Trino compatibility.
For production S3 workloads at scale -- especially those requiring IAM, lifecycle management, site replication, Iceberg tables, and AI/ML integration -- MinIO AIStor is categorically more complete.