This major release transforms MinIO AIStor into a complete data lakehouse foundation with production-ready S3 Tables/Iceberg Catalog and full Delta Sharing protocol implementation. Combined with infrastructure improvements for dynamic pool management and enhanced monitoring, this release enables enterprise analytics workloads at scale.
Answer
RELEASE.2026-02-02 is a landmark release focused on data lakehouse enablement. The S3 Tables/Iceberg Catalog reaches production maturity with Views API, hierarchical namespaces, and significant performance optimizations. The complete Delta Sharing protocol implementation enables secure cross-organization data collaboration. Infrastructure improvements include dynamic pool hot-reload, S.M.A.R.T. disk monitoring, and extended erasure coding support.
| Environment | Recommendation |
|---|---|
| Data lakehouse/analytics deployments | Upgrade immediately |
| Production deployments | Upgrade at next maintenance window |
| All other environments | Plan upgrade within 30 days |
S3 Tables/Iceberg Catalog — Production Ready
Iceberg Views API
What
Full implementation of Iceberg Views API enabling logical views over table data:
- Create, load, replace, and drop view operations
- Schema evolution support for views
- View metadata persistence with versioning
- Cross-table views spanning multiple Iceberg tables
Availability
Available in this release.
Why
Views are essential for analytics workflows—they enable logical abstractions over physical tables, simplify complex queries, and provide access control boundaries. The Iceberg specification defines Views as first-class citizens alongside Tables, and production analytics platforms expect this capability.
What This Means for Customers
- Simplified analytics — Create reusable query abstractions without data duplication
- Access control — Grant access to views without exposing underlying tables
- Spark/Trino compatibility — Views work seamlessly with popular query engines
- No additional cost — Views are metadata-only, consuming minimal storage
Hierarchical Namespaces
What
Support for multi-level namespace hierarchies enabling complex organizational structures:
catalog.database.schema.tablecatalog.team.project.dataset- Nested namespaces with arbitrary depth
- Namespace-level permissions for fine-grained access control
- Path-based organization matching enterprise data governance patterns
Availability
Available in this release.
Why
Enterprise data platforms organize data hierarchically—by business unit, project, environment, and dataset. Flat namespace models force awkward naming conventions and complicate access control. Hierarchical namespaces align with how organizations actually structure their data.
What This Means for Customers
- Enterprise data organization — Model your data catalog structure naturally
- Simplified governance — Apply policies at namespace boundaries
- Multi-tenant support — Isolate tenants with namespace hierarchies
- Migration path — Match existing Hive/Glue catalog structures
Performance Optimizations
What
Major performance improvements for Iceberg catalog operations:
| Optimization | Improvement |
|---|---|
| Msgpack storage format | Faster serialization than JSON |
| Namespace sharding | 16 separate files eliminate write contention |
| Shard-based pagination | Reduced memory usage for large catalogs |
| Metadata caching | Minimized redundant lookups |
| Per-warehouse locks | Replaced global lock, reduced contention |
Availability
Available in this release. Msgpack migration is automatic and backward-compatible.
Why
Production Iceberg catalogs can contain millions of tables across thousands of namespaces. The previous single-file storage model created contention during concurrent operations. Sharding distributes load and eliminates bottlenecks.
What This Means for Customers
- Higher concurrency — More simultaneous catalog operations
- Lower latency — Faster table creation and metadata lookups
- Larger scale — Support for enterprise-scale catalogs
- No action required — Optimizations apply automatically
Transaction Framework Improvements
What
Enhanced transaction handling for catalog operations:
- Unified recovery framework consolidates recovery code paths
- Atomic RenameTable with persistent transaction logs
- Automatic recovery on server restart
Availability
Available in this release.
Why
Catalog operations must be atomic—partial failures corrupt metadata state. The unified recovery framework ensures consistent state recovery regardless of failure timing.
What This Means for Customers
- Data integrity — No partial or corrupted catalog state
- Crash recovery — Automatic recovery after unexpected restarts
- Operational confidence — Reliable catalog operations under load
Table Authorization System
What
New TableAuthSys provides per-table and per-view authorization:
- Fine-grained permissions at table/view level
- Authorization caching reduces IAM policy evaluation overhead
- Integration with existing IAM policies and roles
Availability
Available in this release.
Why
Catalog-level authorization is insufficient for production analytics—teams need table-level access control. Repeated IAM policy evaluations created performance overhead that caching eliminates.
What This Means for Customers
- Granular access control — Permissions at table level, not just bucket level
- Faster authorization — Cached evaluations reduce latency
- Compliance ready — Audit-friendly access control model
Delta Sharing Protocol — Complete Implementation
What
Full implementation of Delta Sharing v1.0 protocol for secure cross-organization data sharing:
| Capability | Description |
|---|---|
| Complete REST API | Full specification compliance |
| Bearer token auth | Standard authentication mechanism |
| Delta Lake integration | Native log parsing and format support |
| Predicate pushdown | Query optimization for efficient data transfer |
| Databricks compatibility | Works with Databricks sharing clients |
| OAuth 2.0 support | Client credentials flow for automation |
Scale: 19,740+ lines of code across 62 files—a complete, production-ready implementation.
Availability
Available in this release.
Why
Organizations need to share data securely with partners, customers, and across business units without copying data or exposing infrastructure. Delta Sharing provides an open protocol for this use case, and MinIO’s implementation enables sharing directly from AIStor without additional infrastructure.
What This Means for Customers
- Secure data sharing — Share data without exposing storage infrastructure
- No data copying — Recipients query data in place
- Cross-platform — Works with any Delta Sharing-compatible client
- Partner collaboration — Enable secure data exchange with external organizations
- Cost reduction — Eliminate data duplication for sharing use cases
Infrastructure Improvements
Pool Hot-Reload
What
Dynamically add or remove storage pools without server restart:
- SIGHUP signal triggers pool configuration reload
- Zero-downtime capacity expansion
- Live pool removal for decommissioning
Availability
Available in this release.
Why
Production deployments shouldn’t require restarts for capacity changes. Hot-reload enables truly continuous operations during infrastructure modifications.
What This Means for Customers
- Zero downtime — Add capacity without service interruption
- Operational flexibility — Respond to capacity needs immediately
- Simplified maintenance — No restart coordination required
S.M.A.R.T. Disk Monitoring
What
Pure Go implementation of disk health monitoring:
- NVMe drives — Health status, temperature, wear leveling
- SATA drives — S.M.A.R.T. attribute monitoring
- Predictive alerts — Early warning of drive degradation
- No external dependencies — Built into MinIO binary
Availability
Available in this release.
Why
Proactive disk monitoring prevents data loss by identifying failing drives before they fail completely. Native integration eliminates dependency on external monitoring tools.
What This Means for Customers
- Proactive maintenance — Replace drives before failure
- Reduced risk — Early warning of degradation
- Simplified operations — No external monitoring tools required
- Observability — Integrated with MinIO metrics
Thread Pressure Monitoring
What
Automatic backpressure when server reaches critical thread exhaustion:
- HTTP 429 response at ≥85% thread utilization
- Prevents cascading failures from resource exhaustion
- Client-side retry signals enable graceful degradation
Availability
Available in this release.
Why
Under extreme load, accepting more requests than can be processed causes cascading failures. Returning 429 early allows clients to back off and retry, maintaining overall system stability.
What This Means for Customers
- System stability — Prevents runaway resource exhaustion
- Graceful degradation — Clients receive retry signals
- Better SLAs — Predictable behavior under overload
Extended Erasure Coding
What
Support for up to 32 drives per erasure set (default remains 16):
- Environment variable:
MINIO_ERASURE_SET_DRIVE_COUNT(17-32) - Higher fault tolerance with more parity drives
- Larger erasure sets for high-density configurations
Availability
Available in this release. Opt-in via environment variable.
Why
High-density storage servers with 36+ drives benefit from larger erasure sets. Extended support enables optimal configurations for modern hardware.
What This Means for Customers
- Hardware flexibility — Optimize for high-density servers
- Higher durability — More parity drives if needed
- Cost efficiency — Better storage utilization with large drive counts
Async Identity Provider Startup
What
Server starts successfully when LDAP/OIDC providers are temporarily unavailable:
- Deferred authentication until provider becomes available
- Graceful degradation for identity provider outages
- Automatic reconnection when provider recovers
Availability
Available in this release.
Why
Identity provider dependencies shouldn’t prevent MinIO startup. Transient LDAP/OIDC outages during maintenance windows shouldn’t cascade to storage unavailability.
What This Means for Customers
- Improved availability — Start despite IdP outages
- Operational resilience — Survive IdP maintenance windows
- Reduced dependencies — Looser coupling to identity infrastructure
Performance Optimizations
ListObjects Improvements
What
Heap-based k-way merge algorithm for ListObjects operations:
- Reduced memory allocation during large listings
- Faster merge operations across erasure sets
- Improved pagination performance
Availability
Available in this release.
Why
ListObjects with millions of keys requires efficient merge algorithms. Heap-based k-way merge is optimal for this workload.
What This Means for Customers
- Faster listings — Reduced latency for large buckets
- Lower memory — More efficient resource utilization
PutObject Temp Directory Sharding
What
16-way sharding of temporary directories for uploads:
- Reduced filesystem contention during concurrent uploads
- Better parallelism for high-throughput workloads
Availability
Available in this release.
Why
Single temp directory creates filesystem contention during high-concurrency uploads. Sharding distributes load across multiple directories.
What This Means for Customers
- Higher throughput — More concurrent uploads without contention
- Better performance — Especially for small object workloads
Regex Precompilation
What
Precompiled regular expressions eliminate ~1200ns/op overhead per request.
Availability
Available in this release.
Why
Request-path regex compilation adds unnecessary latency. Precompilation moves this cost to startup.
What This Means for Customers
- Lower latency — Reduced per-request overhead
- Consistent performance — No compilation jitter
Experimental Features
Server-Side Logging (Tech Preview)
What
Persistent API, Error, and Audit event logging with multiple targets:
- Internal disk recording for local persistence
- External webhook targets for log aggregation
- Kafka integration for streaming pipelines
- Configurable batching with persistent queue recovery
Configuration options:
log_api_internal,log_error_internal,log_audit_internal- Webhook and Kafka target variants
Availability
Tech preview. Opt-in, disabled by default.
Why
Centralized logging infrastructure isn’t always available or appropriate. Server-side logging provides persistence guarantees for audit requirements.
What This Means for Customers
- Audit compliance — Persistent logs for regulatory requirements
- Operational visibility — Capture events even without external logging
- Flexibility — Multiple target options for different architectures
Security Updates
What
- CVE fixes from Go 1.25.6 security updates
- Environment variable redaction for sensitive data in logs
- TLS certificate error message improvements
Availability
Available in this release.
Why
Security updates must be applied promptly. Sensitive data redaction prevents credential exposure in logs.
What This Means for Customers
- Security compliance — Latest CVE patches
- Credential protection — No sensitive data in logs
- Easier debugging — Improved TLS error messages
Bug Fixes
| Issue | Fix |
|---|---|
| Race conditions in WaitGroup, metrics, lock files | Eliminated data races |
| Replication status corrections | Accurate replication state reporting |
| Disabled replication target filtering | Proper target state handling |
| Decommission metadata handling | Object readability verification |
| JWKS pull fallback | Improved OIDC key retrieval reliability |
| OpenID access key management | Correct key lifecycle handling |
Breaking Changes
| Change | Impact | Migration |
|---|---|---|
DROP TABLE defaults purgeRequested to true | Spark compatibility workaround | Explicit purgeRequested=false if needed |
| Tables metadata uses msgpack format | Storage format change | Automatic migration, backward-compatible |
| v3 metrics returns up to 1000 buckets | Previously limited to 10 | May affect metric consumers expecting fewer buckets |
New Configuration Options
| Option | Default | Description |
|---|---|---|
MINIO_ERASURE_SET_DRIVE_COUNT | 16 | Extended range: 17-32 drives per set |
MINIO_REPLICATION_EVENT_THRESHOLD | 15m | Replication event processing threshold |
PurgeOnDelete: spark | — | Per-bucket versioning config for Spark compatibility |
Summary
RELEASE.2026-02-02 establishes MinIO AIStor as a complete data lakehouse foundation:
- S3 Tables/Iceberg Catalog reaches production maturity with Views, hierarchical namespaces, and major performance improvements
- Delta Sharing enables secure cross-organization data collaboration
- Infrastructure improvements deliver zero-downtime pool management and proactive disk monitoring
- Performance optimizations improve throughput and reduce latency across operations
For upgrade assistance, contact MinIO support through SUBNET.