Now you can answer that. GET user:123 AT 2026-03-27T03:00:00 returns the exact value that was cached at that timestamp. Debug production incidents, satisfy compliance auditors, and compare cache state across time.
Every cache overwrites on SET. The previous value is gone forever. That means you cannot debug, cannot audit, and cannot prove what happened. Three problems, one root cause: no version history.
Every write appends a new version with a timestamp. The version chain is queryable. You can look up what a key held at any moment, view the full history, and diff between two points in time.
Every SET appends a new version to the key's version chain. Previous values are never overwritten. The version chain is an append-only log indexed by timestamp. This means the cache is a complete record of every value a key has ever held, within the retention window.
Each version entry stores: the value, the timestamp, the writer ID (which server or service wrote it), and the operation type (SET, DEL, CDC update). This metadata is what makes debugging and auditing possible.
A standard GET returns the current (latest) value with zero additional latency. The version chain is only traversed when you explicitly use a time-travel query (GET key AT timestamp), which adds approximately 0.5 microseconds for a binary search on the version chain.
Write overhead is a single append to the version chain — the same cost as any other linked-list prepend. Version management and garbage collection happen on a background thread, never on the hot path.
Different data has different retention requirements. Hot operational data needs hours. Compliance data needs months. Audit-critical data needs indefinite retention. Configure retention per key prefix, and the garbage collector handles the rest.
| Data Category | Key Prefix Example | Retention | Storage Tier |
|---|---|---|---|
| Hot operational | session:* |
1–24 hours | RAM |
| Application state | user:* |
7 days | RAM + NVMe |
| Compliance data | audit:* |
30–90 days | NVMe + Cold Archive |
| Audit-critical | txn:* |
Indefinite | Cold Archive |
10M keys × 24 versions/day × 1KB average value = 240GB/day of version data. This is where hybrid tiering composes naturally with temporal versioning: current and recent versions stay in RAM for sub-microsecond access, older versions move to NVMe, and compliance-retention versions archive to cold storage automatically. The garbage collector respects retention policies and reclaims expired versions without blocking reads or writes.
GET pricing:enterprise AT 2026-03-27T03:00:00 returns the exact cached value. HISTORY pricing:enterprise shows when the bad value was written and which server wrote it. Root cause in minutes, not days.GET user:456 AT 2026-03-15T12:00:00 and return the exact value with a cryptographic timestamp. The auditor gets verifiable proof. No hand-waving, no log parsing, no "we think it was correct."DIFF popular:items 2026-03-27T13:00:00 2026-03-27T15:00:00 shows exactly how cache values changed across the deploy window. Was the new strategy caching different data? More stale data? Less data? Now you can see instead of guessing.HISTORY sensitive:key shows every write, every writer, every timestamp. If an unauthorized writer injected a value at 2:47 AM, the version history proves it. Combined with self-healing, Cachee can detect the anomaly and automatically revert to the last known-good version.Temporal versioning is not a standalone feature. It multiplies the value of every other Cachee primitive. Each composition creates behavior that no other caching system can replicate.
Learn more about self-healing cache, cache contracts, and hybrid tiering — and how these primitives compose into a system that is debuggable, auditable, and provably correct.
Temporal versioning maintains a timestamped version history for every cache key. Instead of overwriting values on each SET, the cache appends a new version with a timestamp. You can then query any key's value at any historical point in time using GET key AT timestamp, view the full version timeline with HISTORY key, or compare changes between two points with DIFF key t1 t2.
No. A standard GET command returns the current (latest) value with zero additional overhead. Only time-travel queries (GET key AT timestamp) incur extra latency — approximately 0.5 microseconds for a binary search on the version chain. The version history is maintained as a background append-only structure that does not affect the hot read path.
Retention is configurable per key prefix. You can set different retention periods for different categories of data: 1–24 hours for hot operational data, 30–90 days for compliance data, and indefinite retention for audit-critical keys (archived to cold storage). A background garbage collector automatically removes versions that exceed the retention period without blocking reads or writes.
SOC 2, FINRA, and HIPAA auditors frequently ask: "Can you prove what data was served to users at time X?" With temporal versioning, you answer that question definitively. GET key AT timestamp returns the exact value. Combined with Cachee's cryptographic attestation, you get an independently verifiable proof of cache state at any historical point.
Each version entry adds 32 bytes of metadata (pointer, timestamp, writer ID, operation type). The value payload is stored separately. For 10M keys with 24 versions per day and 1KB average value size, that is approximately 240GB per day of version data. Cachee composes temporal versioning with hybrid tiering: current and recent versions stay in RAM, older versions move to NVMe, and compliance-retention versions archive to cold storage automatically.
Temporal versioning. Time-travel queries. Configurable retention. Compliance-grade audit trails. Git for your cache.