# AIStore: a storage cluster that treats cloud buckets as data, not cache

> AIStore is a distributed storage stack for AI workloads that scales out linearly, speaks both its own HTTP API and the S3 API, assembles whole training batches with Get-Batch, and runs transformations next to the data with ETL. Its README already documents a feature enabled in the next version, which tells you how fast this moves.

**NVIDIA/aistore** — AIStore: scalable storage for AI applications

- Repository: https://github.com/NVIDIA/aistore
- Website: https://docs.nvidia.com/aistore
- Stars: 1,958 · Forks: 294
- Language: Go
- License: MIT
- Published: 2026-10-12 · Updated: 2026-10-12 · Language: en
- Canonical page: https://hysenlabs.com/projects/nvidia-aistore

## What AIStore is, and the cache remark

AIStore, abbreviated AIS, is a lightweight distributed storage stack tailored for AI applications: an elastic cluster that grows and shrinks at runtime, deployable ad hoc, with or without Kubernetes, from a single Linux machine to a bare-metal cluster of any size. The README claims linear scale-out, consistent performance and a deployment model it calls flexible.

One sentence in the overview carries more design information than any feature bullet, and it is a negative one: the system operates on in-cluster and remote data without treating either as a cache.

That is a positioning statement with teeth. Most systems in this space are transparent caches in front of an object store, which means the cluster can be rebuilt from the origin and eviction is a normal event. AIS instead presents both tiers as data you own, which is why the feature list includes protection features such as mirroring and erasure coding and also a per-bucket LRU cache that you configure yourself.

The cluster shape follows from that. A control plane and a data plane are both redundant, the system self-heals, and any number of lightweight proxies serve as access points. Proxies are the entry tier that clients talk to, and their count is a scaling knob rather than a fixed role.

Deployment is documented at three sizes, from a minimal container-based compose setup through Google Colab to Kubernetes, with a linked page stating there are no built-in limitations on deployment size or functionality.

## Two APIs: native HTTP and S3 compatibility

AIStore exposes a feature-rich native HTTP API with SDKs for Go and Python, and separately implements the Amazon S3 API so unmodified S3 clients can run against it.

That pairing is the practical adoption story. Existing applications, tools and scripts already written against S3 keep working, which removes the usual objection to introducing a new store. The native API is where the AI-specific capabilities live, and clients that want those need the native path.

The internal dependency list confirms the S3 side is real rather than approximate: the AWS SDK for Go v2 with its S3 service client, feature manager and credentials provider, the Azure SDK with azcore and azblob, Google Cloud storage, and the Oracle OCI Go SDK. All four major providers have first-party clients compiled in, which is what makes the multi-cloud claim structural rather than aspirational.

The API is also where consistency is defined. The README states guaranteed consistency across all gateways, with read-after-write semantics, and write-through behaviour in the presence of remote backends. Write-through is the important half: a write to a local node is pushed to the backend rather than deferred, which costs latency and buys the guarantee that a local read will not disagree with the cloud.

Authentication is JWT based, validated per request, with access control at cluster and bucket level using either static keys or a dynamic OIDC issuer lookup through JWKS. That means an existing identity provider can issue the tokens rather than the cluster holding every credential.

## Chunked objects and Get-Batch, the training pipeline features

Two features stand out for machine learning workloads, and they are the reason to consider this over a general object store.

The first is the chunked object representation. Objects are split into chunks that are independently retrievable, with metadata v2 and checksum-protected manifests. The manifest is what makes that safe: chunks can be verified individually and reassembled without trusting the listing. Rechunking, parallel reads and integration with Get-Batch, the blob downloader and multipart uploads to cloud backends are all listed on top of that representation.

Parallel reads matter for training because a sample fetched serially is a sample that wastes the input pipeline. Chunks that can be requested independently are what let a data loader saturate bandwidth.

The second is Get-Batch, which retrieves multiple objects or stored files with a single call, designed for ML and AI pipelines, fetching an entire training batch in one operation and assembling a TAR or another supported serialization format containing all requested items in the exact user-specified order. A paper is linked for the design.

Order is the detail that matters. A training batch is not a bag of samples; every index in it has a position, and a fetcher that returns them in completion order has broken the batch. Making the requested order part of the API contract, rather than something the client sorts, removes a class of subtle bug that only shows up as a model that trains badly.

Together these two features attack the same problem: moving training data efficiently and verifiably, which is where a GPU cluster usually waits.

## ETL next to the data, and archives as a first-class format

The ETL subsystem executes I/O heavy transformations close to the data, in two modes. Inline transformations run on the fly as part of each read request, so nothing intermediate is stored. Offline transformations are batch jobs whose output populates a destination bucket, which suits a conversion you pay for once.

The distinction is a real operational choice. Inline is right for something cheap and request-dependent, such as a filter or a decode; offline is right for something expensive and reusable, such as decoding a dataset once into a better layout.

Native, first-class support for TAR, TGZ, TAR.LZ4 and ZIP is unusual for a storage system and follows from the workload. AI datasets arrive as tarballs of small files, and a store that keeps them as separate objects would turn every training step into millions of metadata operations. Storing tarballs as the unit of storage and exposing their contents through the API keeps the small-file problem inside the system.

Compression support is in the dependency list as pierrec/lz4, and the batch job set includes a dsort operation, so large tarballs can be sorted or repacked by the cluster rather than by a machine you have to schedule.

Related to this is the blob downloader, listed alongside native bucket inventory, which are the two features the README adds after the main job list as the set continues to grow.

## Multi-cloud, unified namespace, and bucket identity

Multi-cloud access means more than accepting several provider endpoints. AIStore describes AWS S3, GCS, Azure and OCI as backends with fast-tier performance and configurable redundancy, and it calls out one property that is easy to miss: namespace-aware bucket identity, so same-name buckets can coexist across accounts, endpoints and providers.

That last point is the one that bites in practice. A team migrating from one provider to another, or running two accounts of the same provider, hits bucket name collisions immediately, and every application that hardcodes a bucket name breaks. Making identity namespace-aware means the cluster can hold an s3://prod-images and s3://staging-images without renaming either.

The unified namespace solves a different collision. Clusters can be attached together so datasets are addressable across independent clusters, with shared buckets referenced by cluster-specific identifiers. For an organisation running several AI clusters that share a dataset, that avoids copying petabytes between them.

Data protection follows the same pattern of making a normally-implicit decision explicit. The cluster offers n-way mirroring and erasure coding, and the batch job list includes mirror, rebalance and resilver, which are the operations you run after adding or losing nodes. The erasure coding dependency is klauspost/reedsolomon.

The reverse operation is also present: evict-remote-bucket appears in the job list alongside cleanup and evict-objects, so a bucket can be copied in and later freed.

## Batch operations, throttling and observability

Operations are driven by a CLI whose job list is visible in the README, and reading that list is the fastest way to understand what the cluster expects to do.

The job names themselves come out of the help output:

```console
$ ais show job --help
```

which prints the operations the cluster recognises.

More than thirty cluster-wide batch operations are listed, and their names are worth reading as a description of what the cluster expects to do: copy-bucket, copy-objects, delete-objects, dsort, ec-bucket, ec-get, ec-put, elect-primary, etl-bucket, etl-inline, etl-objects, evict-objects, evict-remote-bucket, get-batch, list, lru-eviction, mirror, prefetch-objects, promote-files, put-copies, rebalance, rechunk, rename-bucket, resilver, summary and warm-up-metadata.

Several of those names describe maintenance rather than data movement. Elect-primary is a control plane operation, rebalance redistributes after a node change, resilver repairs after a failure, warm-up-metadata pre-populates state, and dsort handles large tarballs. A storage system that names its own maintenance operations in its feature list is telling you it expects to be operated.

Protective behaviour is also explicit. Load-aware throttling uses a multi-dimensional load vector, listed as CPU, memory, disk, file descriptors and goroutines, to slow requests under stress. Using goroutine counts in that vector is a Go-specific detail that reflects how the node is built.

Observability is described as comprehensive: Prometheus metrics, Grafana dashboards, detailed logs with configurable verbosity, and CLI-based performance tracking. The Go dependencies agree, with client_golang, OpenTelemetry, and the OTLP trace gRPC exporter, so traces leave the cluster rather than staying in local logs.

For Kubernetes, production deployment lives in a separate ais-k8s repository containing an operator, Ansible playbooks, Helm charts and guidance.

## What the README gets confusing, and where the project stands

Two things in the documentation are worth sorting out before you evaluate the project, and neither is a defect so much as a consequence of moving quickly.

The first is version numbering. The README badge reads version v5.0. The published tags are v1.5.0 with the name 5.0, v1.4.9 named 4.9, and v1.4.8 named 4.8. So the tag prefix and the product version are different series, and a script or a document that references either can be wrong.

The second is that the feature list documents per-node Ed25519 request signing as enabled in v5.1, following a mandatory v5.0 compatibility bridge. A feature described as enabled in a version later than the current one means the documentation runs ahead of what you can install, so you cannot tell from the README alone which behaviour your binary has.

Both are consequences of a large project moving quickly, and both are answerable by reading the version notes rather than the README.

On the code side, the module requires Go 1.26.0 and the Makefile reflects that, with commented cross-compilation using a golang:1.26 image. The dependency list is long but purposeful: cloud SDKs for the four backends, gRPC and WebSocket for transport, fasthttp for the data path, msgp for serialisation, buntdb and cuckoofilter for metadata and caches, and the Kubernetes client libraries for the operator side.

The code carries an MIT licence, and nothing was committed to the repository after 2026-09-28.

## Conclusion

Adopt AIStore when your pipeline is bottlenecked on assembling training data rather than on GPUs, since Get-Batch assembling an entire batch in one ordered call, ETL running next to the data, and chunked objects with independently retrievable chunks are the specific mechanisms that address it, and the S3-compatible API means existing clients work unmodified. Do not adopt it as a general-purpose object store replacement for a small team, because this is an elastic cluster with proxies, mirroring, resharding and thirty-plus batch operations, and operating that is a project in itself. Verify four things first. Resolve the version numbering, since the README badge reads v5.0 while the published tags read v1.5.0 (5.0) and v1.4.9 (4.9), and one feature is documented as enabled in v5.1. Decide where it runs, because the README points at three shapes: a minimal container compose deployment, Google Colab, and petascale Kubernetes through a separate ais-k8s repository with an operator, Helm charts and Ansible playbooks. Confirm your data protection posture, since the cluster does n-way mirroring and erasure coding and offers a per-bucket LRU cache, which is a different model from treating cloud buckets as an eviction layer. And check consistency, since write-through semantics apply in the presence of remote backends. Start with the local compose deployment and one bucket before touching a multi-node cluster.

## FAQ

### What is AIStore and what is it for?

AIStore, abbreviated AIS, is a lightweight distributed storage stack for AI applications: an elastic cluster that scales out linearly and can run from a single Linux machine to a bare-metal cluster, with or without Kubernetes.

### Can existing S3 clients talk to AIStore?

Yes. Alongside its native HTTP API and Go and Python SDKs, AIStore implements the Amazon S3 API so unmodified S3 clients can run against the cluster, with AWS, Azure, Google Cloud and OCI backends supported.

### What does Get-Batch do in AIStore?

It fetches an entire training batch in a single operation, assembling a TAR or another supported serialization format containing all requested items in the exact order the user specified. A design paper is linked from the README.

### How does AIStore handle data protection and availability?

It offers a redundant control and data plane, self-healing, end-to-end protection, n-way mirroring and erasure coding, plus any number of lightweight proxies as access points. Batch operations include mirror, rebalance and resilver for maintenance.

### How is AIStore deployed?

The README points at a minimal container-based compose deployment, Google Colab for experimentation, and Kubernetes for production, where a separate ais-k8s repository provides an operator, Helm charts, Ansible playbooks and deployment guidance.

## Sources

- [License: MIT](https://github.com/NVIDIA/aistore/blob/main/LICENSE)
- [NVIDIA/aistore on GitHub](https://github.com/NVIDIA/aistore)
- [Project website](https://docs.nvidia.com/aistore)
- [README](https://github.com/NVIDIA/aistore/blob/main/README.md)
- [Releases](https://github.com/NVIDIA/aistore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nvidia-aistore