Skip to content

[RESEARCH]: Pin the second-tier KV/cache landscape (Aerospike, Tarantool, Kvrocks, Hazelcast/Ignite/Coherence, Skytable, Redka) #162

@ELares

Description

@ELares

Filed from the IronCache pre-implementation coverage audit (2026-06-13): no existing issue adequately owned this.

Why this is needed

Add a second prior-art dimension and claims block pinning, at version, the architectural bets of cache/KV systems IronCache never surveyed: Aerospike (hybrid-memory primary index + all-flash, XDR active-active), Tarantool (single-thread + Lua + WAL fiber, vinyl LSM), Kvrocks (RocksDB-backed Redis-protocol server), Hazelcast/Ignite/Coherence (partitioned in-memory grids with near-cache and read-through/write-behind), and the small Rust/Go Redis-likes (Skytable, Redka), capturing borrow/adapt/reject per system the way #6 does. Grep of claims.yaml/PRIOR_ART.md/all issues returns ZERO mentions; #6's pinned set is exactly Redis/Valkey/Dragonfly/KeyDB/Garnet/Memcached and nothing else. Most pointedly, #65 rejects RocksDB-as-core-engine without citing Kvrocks (the live production system built on that exact choice) and #66 designs RAM->SSD tiering citing Memcached extstore and FASTER/F2 but never Aerospike's canonical hybrid-memory/all-flash index. Feeds #64/#65/#66/#68/#79.

Context

Relates to / partially overlaps #6. Part of the vision EPIC #1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions