v0.14.2 · engine stable
Sub-microsecond state,
in every process.
Attos compiles your read-heavy state into a memory-mapped artifact and decodes it with an off-heap Apache Fury engine. Zero-allocation deserialization, O(1) lookups, and no network hop between your service and its data.
- P99 lookup
- 181 ns
- Allocations / op
- 0 B
- Heap at 15M keys
- 0 MB
- Uptime SLA
- 99.99%
state distribution pathlive
01Control planerevision r1482
02Attos Binary Compiler174 MB artifact
03Zonal replicaus-east1-b
04Page cachemmap, evictable
05Your processzero-copy read
last read181 ns
Compliance posture
AES-256-GCM
At rest + in transit
GDPR Compliant
EU data residency
99.99% Uptime SLA
Financially backed
90-day Key Rotation
HSM-backed KMS
VPC Peering
Single-tenant isolation
Benchmark Suite · 15M Keys
Built for Ultra-Low Latency & Zero OOM Risk at 15M+ Scale
515ns
P99 Tail Latency (Rust)
Sub-microsecond lookups
0MB
Hot-Path Heap Allocation
Zero GC pause risk
174MB
Total Pod RAM @ 15M Keys
Up to 15x smaller footprint
< 40ms
Cold-Start File Load Time
Instantaneous initialization
Total Pod RAM required for 15M keys
lower is betterAttos (Rust/Go)174 MB
ChronicleMap1,606 MB
BigCache / FreeCache1,946 – 2,610 MB
ConcurrentHashMap / DashMap1,745 – 2,867 MB
Architecture
Zero-copy state distribution, end to end.
Six stages from a committed write to a nanosecond read. Select a stage to see what runs and what it costs.
Stage 01 / 06
Source of truth commits
Postgres, Kafka or your control plane emits a changeset. Attos treats every write as an immutable revision — there is no in-place mutation anywhere in the pipeline.
revision r1482
Capacity planning
Model the resident memory before you provision.
Attos pages stay in the OS page cache, which the kernel can evict under pressure — so they never count toward the cgroup limit that produces Exit Code 137.
Dataset size
10,000,000 keys
1M100M
Lookup latency (ns)
AttosO(1)
181ns
FastCacheO(1)
552ns
LMDBO(log N)
930ns
BBoltO(log N)
1,991ns
RedisO(1) + RTT
85,000ns
