cloudparts

TAG (Tigris Acceleration Gateway)

An S3-compatible caching proxy you run next to your compute, keeping hot Tigris objects on local NVMe.

What it is
Object storage
Used for
Caching
Part of
Built on Tigris
Type
Open source
Made by
Tigris Data
License
Apache 2.0
Facts checked
23 October 2026
Website Source code

What it is

TAG is a Go server that sits between S3 clients and Tigris. Clients change only their endpoint (path-style addressing, port 8080 by default). On a GET, TAG looks in its local cache and answers from there, or fetches from Tigris, stores the object and passes it on; an X-Cache header says HIT or MISS. The cache is OCache, Tigris’s RocksDB-based cache library, embedded in the process and kept on local NVMe. Objects of 1 MiB or more are cached in 1 MiB blocks by default, so a range read, such as a Parquet footer, fetches only the blocks it covers. Concurrent requests for the same uncached object share one upstream fetch. PUT, DELETE and copy requests go through to Tigris and invalidate the cached entries; stale entries are revalidated with conditional requests; and under a disk cap entries are evicted LRU or oldest-first. Several TAG nodes form one cache: they find each other by gossip, split keys by consistent hashing and forward requests to the owning node over gRPC.

In the default transparent mode, clients sign requests with their own Tigris keys and TAG forwards them unchanged. After a client’s first request, TAG learns derived signing keys from Tigris (stored encrypted) and checks later signatures itself, and it serves a bucket from cache to a key only after Tigris has allowed that key a GetObject or HeadObject there. TAG’s own credentials only need read access. A signing mode instead checks requests against TAG’s own credential store and re-signs them, which works with any S3-compatible backend. TAG ships as an install script, a Docker image and Kubernetes manifests (a StatefulSet with autoscaling), and exposes Prometheus metrics at /metrics.

Why teams pick it

  • No code changes: any S3 SDK or tool points its endpoint at TAG and keeps its own credentials
  • One node served about 75,000 requests a second for 1 KiB objects and 10.7 GiB/s of 1 MiB objects in Tigris’s benchmark, using about 12% of the CPU
  • Block-aligned caching and request coalescing suit ML training, model loading and Parquet scans that reread the same files
  • Apache 2.0, with gossip-based clustering, Kubernetes manifests and over 30 Prometheus metrics

Watch out for

  • Path-style addressing only; no object versioning, server-side encryption, Object Lock or browser POST uploads
  • The first read of each object still makes a round trip to Tigris, and objects above the size threshold or marked no-store or private aren’t cached
  • It is another stateful service to run, with NVMe disks, compaction to watch and its own failure modes
  • Transparent mode with local key checks is built for Tigris; other S3 services need signing mode and a credential store in TAG

More of the Tigris family

What all object storage have in common →Compare side by side →
OCacheOpen sourceToolsA disk-backed cache for objects of any size, from Tigris, that runs as a server, a cluster or a Go library; TAG’s cache layer.TigrisFSOpen sourceToolsA FUSE file system that mounts a Tigris or other S3-compatible bucket as a local directory.

How it fits with other technologies

Run TAG on a GPU box and point the AWS CLI at it · bash

curl -fsSL https://tag-releases.t3.storage.dev/latest/install.sh | bash

# TAG's own key: read-only access to the cached buckets
AWS_ACCESS_KEY_ID=tid_tag AWS_SECRET_ACCESS_KEY="$TAG_SECRET" \
  tag --config /etc/tag/config.yaml &       # listens on :8080

# clients keep their own Tigris keys; only the endpoint changes
aws configure set default.s3.addressing_style path
aws s3 cp s3://acme-datasets/shards/0001.tar . --endpoint-url http://localhost:8080   # MISS
aws s3 cp s3://acme-datasets/shards/0001.tar . --endpoint-url http://localhost:8080   # HIT, from NVMe

One node, cache warm#

Tigris’s benchmark: warp with 64 threads against a single i3en.24xlarge with NVMe disks over a 100 Gbps link.

Object sizeGETs per secondThroughputTime to first byte (p50)
1 KiBabout 75,70074 MiB/sunder 1 ms
100 KiBabout 33,3003.2 GiB/sabout 1 ms
1 MiBabout 11,00010.7 GiB/sabout 1 ms
4 MiBabout 2,80010.8 GiB/sabout 1 ms
  • For objects of 1 MiB and larger one node reached about 85 Gbps, close to the network card’s limit. Tigris says TAG is usually limited by NVMe for large objects and by CPU for small ones.

See it in a real stack

No architecture uses TAG (Tigris Acceleration Gateway) yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Article· October 2026Prism: A geo-replicated data lake serving billions of <10 ms point lookupsHåkon Åmdal and Jeff Ling, GoldskyHow Goldsky stores each blockchain’s history once in object storage and serves it in every region: recent blocks in memory, Vortex files that stay compressed in RAM, a SlateDB index beside the data on Tigris, and Tigris’s TAG cache for in-region reads. It gives real latency splits by tier (under 1 ms hot, about 9 ms through the cache, 10 to 800 ms cold) and per chain. It was reviewed by Tigris’s CEO, so read it partly as a showcase for Tigris.
All resources →
Where it came from2025–2026

Tigris already moves objects into the region that reads them, but every read still crosses the network from wherever the compute runs. Training jobs reread the same dataset every epoch, and inference servers reload the same weights on every cold start. TAG puts a cache on machines next to that compute, so repeated reads come from local NVMe.

Its cache layer, OCache, has its own repository, started in July 2025: a cache service with RocksDB for small objects and plain files for large ones. TAG, built on it, appeared on GitHub in January 2026 and reached 1.0.0 on 20 January. By October 2026 it was at 1.22.3, with block-aligned caching on by default, an optional tiered mode that keeps small writes locally, and warming of Parquet footers. Goldsky’s Prism data lake uses it to serve historical blockchain reads in-region, with an average of about 9 ms per GetObject; Tigris’s CEO Ovais Tariq, reviewing that write-up, said a cache in front of object storage should be “boring shared infrastructure”.

Why it’s built this way

A proxy that speaks S3
Training loaders, inference servers and query engines already talk S3, so a cache at the same protocol level works with all of them by changing one endpoint.
Forward the client’s own signature
TAG never needs the clients’ secret keys, and Tigris stays the authority on who may read what; local checks with learned signing keys keep cache hits from waiting on Tigris.
Cache large objects in fixed blocks
Columnar files and model shards are often read in ranges. Caching 1 MiB blocks means a footer read doesn’t pull the whole multi-gigabyte file.

Timeline

  1. 2025

    Repository for OCache, the cache TAG builds on, started in July

  2. 2026

    TAG 1.0.0 in January; 1.22 by October, with block-aligned caching on by default

Sources6 · facts checked 23 October 2026

Improve this page on GitHub