MinIO

High-performance S3-compatible object storage — now primarily the commercial AIStor platform after the open-source repo was archived.

Overview

MinIO was the leading open-source S3-compatible object storage. In February 2026, the open-source repository was archived and placed into maintenance mode. Active development continues under MinIO AIStor, a commercial platform designed for AI, analytics, and exascale workloads. Organizations using the archived OSS version should evaluate transition paths.

Key Facts

Attribute	Detail
Repository	github.com/minio/minio (⚠️ ARCHIVED)
Stars	~50k+ ⭐
Latest OSS	Archived (Feb 13, 2026)
Active Product	MinIO AIStor (commercial)
Language	Go
License	⚠️ AGPL 3.0 (archived OSS); Commercial (AIStor)
Company	MinIO, Inc.

⚠️ Critical Notice

The MinIO open-source repository was archived on February 13, 2026. It is now read-only. All active development has moved to MinIO AIStor (commercial). Evaluate alternatives (Ceph RGW, SeaweedFS, Garage) for new open-source deployments.

Evaluation

Pros	Cons
Best-in-class S3 compatibility	⚠️ OSS archived — no more community updates
Excellent performance (AI/ML workloads)	AGPL 3.0 (copyleft, not permissive)
Apache Iceberg V3 native integration	AIStor requires commercial license
Multi-NIC networking	Vendor lock-in risk with AIStor
Simple single-binary deployment	No block or file storage
Erasure coding + bitrot protection

AIStor Features

Feature	Detail
Iceberg V3	Native REST Catalog API, views, multi-table transactions
SSE-S3 / SSE-KMS	Table/warehouse-level encryption
Direct-write GetObject	Eliminates intermediate pipes for lower latency
Coalesced locks	Batched lock-refresh reduces RPC traffic
eBPF loader	Memory-safe Go implementation (replaced C)
Multi-NIC	Aggregate internode bandwidth

Notes

• How It Works
• Architecture
• Operations
• Benchmarks
• Commands & Recipes
• Security
• Sources
• Questions

---

Sources

• MinIO Docs
• mc CLI
• ⚠️ Archived OSS Repo — archived Feb 2026
• AIStor — commercial successor

---

Questions

Answered

• Q: Can I still run existing MinIO? -- Yes, but no new OSS releases. AIStor is commercial path.

• Q: What are erasure sets and how are they formed? -- Erasure sets are groups of up to 16 drives that form the foundational unit of MinIO availability. MinIO automatically groups drives in a pool into erasure sets and stripes them symmetrically across nodes. Objects are partitioned into data and parity shards distributed across an erasure set. MinIO uses a deterministic hash based on the object name to select the erasure set.

• Q: What parity level should I use? -- It depends on the fault tolerance vs storage overhead tradeoff. EC:4 (4 parity drives out of 16, ~33% overhead, tolerates 4 drive failures) is a common default. EC:2 (~14% overhead, tolerates 2 failures) maximizes usable capacity. EC:8 (100% overhead, tolerates 8 failures) maximizes resilience. The read quorum requires at least data_shards intact drives; write quorum requires data_shards + 1.

• Q: How does MinIO bitrot protection work? -- MinIO computes HighwayHash-256 checksums on every shard as it is written. On read, the checksum is verified. If a shard is corrupted (bitrot), MinIO reconstructs it from the remaining data and parity shards. This operates at the erasure set level and is automatic.

• Q: What is the difference between SSE-S3, SSE-KMS, and SSE-C? -- SSE-S3 uses server-managed keys (simplest, MinIO handles key management internally). SSE-KMS uses keys from an external KMS via the MinIO KES proxy (HashiCorp Vault, AWS KMS, etc., providing key rotation and audit). SSE-C uses client-provided keys sent with each request (MinIO never stores the key; losing the key means losing the data).

• Q: How does MinIO site replication work? -- Site replication synchronizes distinct independent MinIO deployments (peers) bidirectionally. Writes to any site replicate to all others. Buckets, objects, and IAM configuration replicate automatically. Bucket notifications, ILM configurations, and site settings do not replicate. Setup via mc admin replicate add. A global load balancer with health probes handles failover.

• Q: What is KES and why is it needed? -- KES (Key Encryption Service) is a lightweight stateless proxy between MinIO and the external KMS. It authenticates MinIO servers via mutual TLS, enforces key access policies, and handles cryptographic operations at scale. KES is required for SSE-KMS and supports HashiCorp Vault, AWS KMS, GCP KMS, and Azure Key Vault as backends.

• Q: Can I expand a MinIO deployment? -- Yes, through pool expansion. Each additional pool is an independent group of nodes with its own erasure sets. MinIO queries each pool to locate the correct erasure set for a given object. Existing data remains in its original pool. Each additional pool adds some internode coordination overhead per request.

• Q: Does MinIO require a load balancer? -- Not strictly required, but strongly recommended for production. Any node can serve any request, so a load balancer (NGINX, HAProxy) distributes traffic evenly and provides a single endpoint that survives topology changes (pool expansion, node failures). The load balancer must pass through unaltered headers because MinIO validates AWS Signature V4 signatures.

• Q: How does MinIO STS work? -- The Security Token Service issues temporary credentials (access key, secret key, session token) with a configurable expiration. Methods include Web Identity (OIDC), Client Grants (OAuth2), AssumeRole, and LDAP STS. Temporary credentials avoid long-lived access keys and support federated identity patterns.

Open

• Q: What are the best open-source alternatives now that MinIO OSS is archived? -- Ceph RGW, SeaweedFS, and Garage are the leading alternatives. Need a structured comparison of S3 compatibility, performance, and operational complexity.

• Q: How does MinIO AIStor's Iceberg V3 integration compare to using S3 + Spark/Iceberg with other object stores? -- AIStor offers native REST Catalog API and direct Iceberg table integration. Need to evaluate whether this provides meaningful performance or operational advantages over standard S3 + Iceberg catalog on Ceph RGW or SeaweedFS.

• Q: What is the practical performance impact of pool expansion on MinIO? -- Each additional pool adds internode traffic per request because MinIO must query all pools. Need benchmarks quantifying the latency impact as pool count grows.