ByteDance’s production memory system, written up as a VLDB 2026 industry paper. The relevant fact up front: the authors state they “have open-sourced a subset of the core capabilities of VikingMem via OpenViking” — so this is the production specification behind the context database this machine runs. Reread alongside the Context Cartography paper captured here yesterday, the two documents line up almost line for line: Cartography scored OpenViking 5/5 on selection, projection and layering, and 1/5 on simplification and aggregation; those two gaps are precisely what VikingMem implements upstream.

The framing is database-flavoured rather than agent-flavoured. The authors argue that stuffing ever-longer histories into prompts is “architecturally incapable of providing structured, lifecycle-aware state management for consolidation, forgetting, or provenance,” and propose a Memory Base: a service-grade substrate built on three principles — selective extraction from low-density raw streams, inherent statefulness where events drive the continuous refinement of entities, and a generalizable schema that serves companions, agents and education without per-vertical prompt engineering.

The abstraction is the interesting part.

  • Events are selectively extracted, timestamped, schema-constrained records — explicitly not a recency window, and merged across non-contiguous segments when a topic is interrupted and resumed.
  • Entities are persistent, evolving state (user profile, tool-usage library, agent SOP), where each property names the event type and the operator that updates it.
  • So the event store is a log and entities are materialized views over it: SELECT OP(event.content) FROM Events WHERE filters(event) GROUP BY keys(event). The same LLM_MERGE operator produces per-day snapshots or a lifelong profile by changing the grouping key — “a small, reusable algebra over events and entities” instead of one bespoke prompt per use case.

The engineering choices are concrete. Extraction is one-pass (all memory types in a single LLM call: $0.35 → $0.07 and 11.02s → 7.42s versus multi-pass). Entity updates skip the LLM entirely via patch-and-approximate-match (SEARCH/REPLACE patches applied with edit-distance matching). Retrieval ranks two paths — dense/sparse hybrid with time-decay and business weights, plus a keyword graph for indirect queries — separately with quotas rather than merging raw results, then reranks with quantized ColBERT-style late interaction because cross-encoders blow the latency budget.

The numbers: 88.83 and 90.12 LLM-judge overall on LOCOMO (versus 78.66 best baseline), 66.36 and 75.80 on LongMemEval_s (versus 63.21), at p50 0.20-0.25s / p95 0.39-0.89s. On LongMemEval it stores 16.82% of the raw tokens — an 83% reduction — and still scores higher than naive RAG (75.80 vs 63.81). The ablation says segmentation is the single biggest contributor (−5.32 points when removed), and production reports >1B tokens of memory data per tenant per day.

Two things to read carefully.

  • The paper you linked is v1; v3 (12 Jun) is the VLDB camera-ready and it quietly revises the headline claim from “up to 38% in retrieval accuracy” to “up to 30%” — matching what v1’s own abstract already said. Cite 30%.
  • The temporal machinery was switched off for the evaluation: “since both datasets consist primarily of fact-based queries, where time-weighting offers little benefit, we disabled this feature by default.” So TIME_COMPRESS and the recency decay — the second design principle — did not produce the headline numbers, and the reported latencies were measured with them off. The production figures (1B tokens/day, 83.2% storage, 900ms P95 cut) run on the closed VikingDB-backed implementation, so they are the authors’ claims rather than something the public evaluation code can reproduce.