Flint Cache is a durable, disk-first cache that speaks the Redis protocol. Your working set lives on NVMe instead of being held hostage in RAM — it survives restarts and failovers, scales behind one endpoint, and costs storage economics instead of memory economics.
Every write lands in the on-NVMe write-ahead log before it is acknowledged, fsynced on a bounded half-second cadence — a restart never costs you the cache. Hot keys serve from the managed memory tier at RAM speed; the long tail lives on NVMe at a fraction of the cost.
Replication runs under an enforced lag bound, promotion is epoch-fenced so split-brain is structurally impossible, and a failed node's data is still there when it returns.
Slot-sharded behind a stateless proxy. Your client never sees cluster topology, migrations, or failovers — any Redis or Valkey client, no SDK, no cluster mode.
TLS on every client connection and mutual TLS on every internal hop by default. Tokens hashed at rest; credentials and certificates rotate automatically with zero downtime.
The built-in operations agent meters usage, heals failed replicas, retires drained credentials, and plans capacity — every action journaled and auditable.
Every command is conformance-tested against a reference implementation, and every failure claim has a runnable drill — including randomized chaos with a ledger oracle.
$ valkey-cli -h cache.yourco.flint.dev --tls -a $FLINT_TOKEN > SET session:42 "..." OK # in the WAL before the ack > GET session:42 "..." # RAM-speed on the hot tier > LPUSH jobs task-1 (integer) 1 > ZADD leaderboard 100 alice (integer) 1
Strings, hashes, sets, lists, sorted sets, TTLs — the working Redis surface, minus the foot-guns (no cross-slot surprises, no data-losing restarts).
Client-observed GET latency on one AWS i4i.2xlarge (8 vCPU, 61 GB RAM, 1.7 TB NVMe), 1 KB incompressible values, uniform random keys — the worst-case access pattern. Valkey 8.1 holds 20 GB (near its RAM ceiling on this box); Flint serves 112 GB on the same machine — a dataset Valkey cannot run at all.
| configuration | dataset | p50 | p99 | throughput |
|---|---|---|---|---|
| Valkey (all data in RAM) | 20 GB | 31 µs | 55 µs | 161 K/s |
| Flint — hot tier (page-cached) | 112 GB | 79 µs | 223 µs | 84 K/s |
| Flint — steady state, uniform over all 112 GB | 112 GB | 207 µs | 415 µs | 36 K/s |
| Flint — fully cold (caches dropped) | 112 GB | 223 µs | 775 µs | 27 K/s |
Even fully cold, a Flint read is sub-millisecond at p99 — inside the latency budget of most cache callers (a cross-AZ hop alone costs ~500 µs–1 ms). Real traffic is skewed, so production mixes sit near the hot-tier row. Every write in every row went through the full durable write path — write-ahead log before the ack, fsync on the bounded cadence.
The 5 TB wall: ElastiCache Serverless documents a maximum of 5,000 GiB per cache (and 32 GiB per hash slot — a single hot slot hits eviction or out-of-memory errors even sooner). Growing past the cap means sharding across caches in your own client code. A Flint cluster scales past 200 TB behind the same single endpoint — and past that, federation keeps the endpoint while adding clusters.
Measured July 2026 with redis-benchmark 7.0 over
RESP, same box, same client, same day. Reproduce it yourself: the
harness (industry-standard memtier_benchmark scenarios) ships in the
open repo as tools/memtier_bench.sh.
| objective | commitment | how it's held |
|---|---|---|
| Availability | designed for 99.99% monthly | per-tenant error-minute accounting from the proxy's own metrics |
| Failover recovery (RTO) | under 10 seconds | drill-measured 0.6–1.2 s from master kill to writable again |
| Loss window on failover (RPO) | at most 10 s of acknowledged writes | enforced at 1 s by default — past the lag cap the master sheds writes rather than widen the window |
| Restart durability | zero acknowledged-write loss on restart; host loss bounded at half a second | write-ahead log before every ack, fsynced on a 500 ms cadence; a restarted node comes back warm with its data |
For reference: AWS commits ElastiCache Serverless and Multi-AZ to 99.99% monthly, documents failover promotion as “typically just a few seconds”, and notes that with asynchronous replication “a small amount of data might be lost due to replication lag” — without a stated bound (its newest durability mode bounds asynchronous loss at 10 seconds). Flint's commitments match that class; the differences are the enforced one-second cap — so observed loss windows sit near milliseconds, not near the commitment — and an endpoint that never moves by DNS. (As published July 2026.)
These are design objectives backed by measured drills — the formal SLA with service credits ships with general availability, once the numbers have months of fleet history behind them. The proofs are runnable today: failover, lease-fenced split-brain, and randomized chaos drills in the open repo.
Every command below ships with a conformance test validated against a reference Redis-protocol implementation and both Flint engines — if it is listed, it behaves the way your client already expects. Grey chips are supported option forms.
Not yet: keyspace SCAN (cursor semantics across live shard migration deserve a careful design; the per-key HSCAN/SSCAN/ZSCAN above cover most iteration needs).
Excluded by design: cross-slot multi-key commands, MULTI/EXEC/WATCH, pub/sub, streams, blocking commands, KEYS/RANDOMKEY, and EVAL/EVALSHA — these conflict with sharded multi-tenancy or reintroduce the single-threaded bottlenecks Flint exists to avoid. Need one of them? Tell us the workload — patterns with broad demand get first-class commands.
The entire Flint stack — storage engine, server, proxy, control plane, and the tooling that proves it — is source-available under the Elastic License 2.0: free to run yourself, at any scale, for any purpose except reselling it as a service. Crestway operates the managed fleet — the autonomy, metering, and consoles — so you don't have to.