Dragonfly brings feature serving to Current London

Dragonfly is sponsoring Current London on May 19. Its event page advertises demonstrations covering online feature serving, prediction caching and vector search. This is a community event, with a set of proposed workloads to examine. It does not announce a new server version or supply measurements that establish how those workloads perform.

I find the choice of workloads relevant to how I assess Dragonfly. My interest starts with a cache that has outgrown one Redis process and the possibility of scaling one machine before taking on a cluster. Feature serving adds questions about the meaning of the stored values. I would want to establish how values become current and how a caller determines that a returned record belongs to the version it expects.

Serving features needs an update contract

For an online feature store design, I would begin with the producer and reader contract. A record should identify the entity it describes, and its update policy should define which producer owns it. If updates can arrive out of order, the design needs a rule for deciding which value wins. A fast lookup cannot answer that application-level question.

I would also specify what freshness means before choosing an expiration interval. A value may still exist while being too old for a decision. Conversely, removing a value may force the reader into a fallback path. The application should make those outcomes observable and define whether it can return a default, wait for a replacement or reject the request.

These are design requirements I would bring to a demonstration. I am not claiming that the event page supplies a complete feature-store architecture. Its announcement names a use case. Evaluating that use case requires tracing a proposed update through storage to the reader and inspecting what happens when the expected value is missing or delayed.

The recent Dragonfly 1.38 release gives expiry a concrete implementation context. It embeds TTL metadata in keys and removes the separate expiration table. The implementation description explains that active expiry now scans the main table. That makes the mixture of expiring and persistent records a useful part of a serving-workload evaluation.

I would construct a representative mixture before drawing conclusions from the reported TTL memory saving. A feature collection with many small expiring records could have a different metadata proportion from a collection of large persistent records. The release's generated-key measurement is evidence for its test population. It is not a substitute for measuring the proposed feature schema and update pattern.

Prediction caching needs a complete identity

For prediction caching, I would make the model version part of the proposed cache identity. A cached result is useful only if the reader can tell which computation it represents. Changes to preprocessing or to the inputs used by the model may also need to change that identity. I would document those dependencies before deciding how long a result should remain available.

The failure cases deserve explicit handling. If a result expires, can the application recompute it within its request budget? If many requests miss together, what limits duplicate computation? I would ask a demonstration to show the miss path as well as the successful lookup, because a design justified entirely by cache hits leaves the underlying computation unexamined.

Memory evaluation should follow the proposed record format. Storing an opaque result and storing a JSON object have different opportunities for sharing internal representation. The JSON key interning change in 1.37 shares repeated field-name strings through reference-counted storage. Its measurements also report a write-throughput cost in the described test. I would inspect both effects if the proposed prediction records use repetitive JSON schemas.

Vector search asks a different acceptance question

Vector search needs an explicit definition of an acceptable result set. I would separate a requirement for a fixed number of neighbours from a requirement that a candidate lie within a chosen distance. The VECTOR_RANGE implementation introduces the second form, with a radius parameter and an optional distance alias. Version 1.38 includes range queries alongside nearest-neighbour search.

A distance threshold is still an application decision. I would choose it using examples labelled for the intended task and verify its behaviour with the selected vector representation. A query that returns results successfully has established command execution. It has not established that the results meet the application's relevance requirements.

The choice of document representation also affects evaluation. The hash-vector storage change lets the index reference existing hash data, while its description says JSON vectors still require copying. I would therefore compare memory using the representation planned for the application. A demonstration using hashes does not establish the same memory requirement for a JSON design.

For me, the event's value is the opportunity to examine these contracts against a concrete implementation. I would ask for the proposed update ordering and freshness policy in feature serving, then inspect how prediction identity changes when the computation changes. For vector retrieval, I would want labelled examples and measurements using the intended document type. Those details would determine whether Dragonfly fits the system I am considering.