Repository navigation
perf(cache): cache version-manager map grows unbounded with tables × scopes #262
Description
Area: cache — scalability · found via TODO sweep
Issue: the in-memory cache version map keys on table (and scope) and is never bounded or evicted. The code's own TODO flags it: "potentially could be bad/dangerous with a low amount of RAM AND a TON of tables/scopes per table." Under high table/scope cardinality this grows unbounded.
Severity: low today (bounded table set, single-tenant); a real memory risk once scopes/multi-tenant land or table cardinality grows.
Scope: bound the version map (size cap / eviction), or move versions to L2 for distributed/high-cardinality deployments. Coordinate with tiered-cache #86 and the scope/multi-tenant story #214/#235.
Found via codebase TODO sweep, 2026-06-04 (internal/cache/version_manager.go:12).
Activity
EricAndrechek commentedon Sep 26, 2026
#621 fixes the two unbounded-growth paths this issue names for the in-process cache: the version map no longer keeps every tenant ever served (a departed tenant's whole index is dropped, not just bumped), and a table bump no longer accumulates old scope versions underneath it.
Narrowing what's left open here: per-table scope cardinality is still uncapped. Today
scopeis always empty (#235), so this doesn't bite yet, but once #235 populates it, a table with many distinct scopes written between whole-table writes will grow that table's scope map without a cap or eviction — #621 only bounds growth across bumps and tenant departures, not cardinality within a live tenant/table.Trigger for follow-up: when #235 lands scope population,
internal/cache.VersionManager's per-table scope map needs a size cap or eviction policy. Leaving this issue open for that; #621's PR body has the detail under "Deliberately left to later PRs".docs(cache): CHANGELOG says #262 is part-fixed, not fixed
feat(cache): shared redis cache, snapshot keys, uncached write pipes (#…