Dragonfly introduces experimental user namespaces

Key prefixes let applications share a naming convention, but separate namespaces let the same key name refer to different values. Dragonfly's initial multi-tenant implementation adds that distinction by associating a user with one namespace. Users assigned to the same namespace share its contents, while users assigned elsewhere see a different keyspace.

Dragonfly 1.21.0, released on August 7, describes this as very basic multi-tenancy support. The implementation is experimental and omits non-default namespaces from replication and RDB saving. Those limits are central to understanding the feature. Successful isolation between live connections does not mean the same data participates in the existing recovery and replica paths.

I am interested in the operational simplicity of putting more cache work into one Dragonfly process. Namespaces fit that direction because they can separate application key names without requiring separate processes. The omitted recovery paths also mean this initial version cannot be treated as a complete replacement for every deployment that currently separates tenants by instance.

The user selects the keyspace

The new ACL option attaches the namespace to an account. The source gives NAMESPACE: as the option prefix, followed by the namespace name. This example follows the documented form, with a placeholder credential and a deliberately broad command rule to keep attention on namespace selection.

ACL SETUSER application NAMESPACE:app-space ON >replace-this-password +@all ~*

After authenticating as that account, a connection operates in app-space. The command and key-pattern rules still describe the account's permissions. The namespace adds another dimension by determining the collection of keys those operations address. Using the wildcard in this particular example does not make the account's namespace the default namespace.

The version-pinned namespace test makes that behaviour concrete. An administrative connection writes a value under foo. A user in a newly created namespace writes a different value under the same name. Each connection subsequently reads its own value. The separation therefore applies even when neither application changes its key spelling.

Another user assigned to that same namespace reads and updates the first user's value. A user assigned to a second namespace sees no value for foo. These cases show that the namespace is shared state associated with a group of accounts, not a private database created separately for every username. The grouping decision belongs to account configuration.

That model changes the application-facing coordination required for shared caching. Two applications can use the same library-generated key names without adding mutually agreed prefixes, provided their accounts belong to different namespaces. Conversely, accounts intended to share data must name the same namespace. An account assignment error can therefore change which data the application sees even when authentication succeeds.

Data isolation does not supply recovery coverage

The initial implementation's description explicitly states that replication and RDB saving ignore non-default namespaces. It also says defragmentation and statistics either use the default namespace or combine namespaces without separating them. These are different omissions, with different operational consequences.

The replication omission means an application cannot infer that values in its namespace appear on a replica through the existing replication mechanism. The RDB omission means the snapshot path does not represent those values as part of a normal saved dataset. This is a coverage limit, not a claim about occasional failure under load.

Statistics introduce a separate attribution problem. A combined measurement can describe the whole process without explaining each namespace's contribution. An application sharing a process still needs to distinguish name isolation from resource accounting. The source does not promise per-namespace memory budgets or a separate scheduling guarantee, so neither follows from the multi-tenancy label.

I see the feature as a useful experiment in keyspace separation. Its present suitability depends on what the cache is allowed to lose and how it can reconstruct data. That judgement follows from the implementation's stated exclusions, rather than from a general objection to sharing cache infrastructure.

Namespace context must reach internal execution paths

The release includes a transaction-context fix that copies the namespace when constructing a connection context from its owner. Its regression test queues several TYPE commands inside MULTI and expects none replies after execution. This addresses a crash path involving namespace context during queued execution.

That correction explains why namespace support reaches beyond account parsing. A command may execute through an internally derived context, and that context still needs the namespace belonging to the original connection. Copying permissions without copying the selected keyspace would leave an incomplete representation of the connection's state.

A separate shutdown-order correction removes a race between a periodic fiber and namespaces during shutdown. Creating namespaces introduces objects whose lifetime must remain compatible with periodic background activity. Correct command routing while the server runs is only one part of integrating those objects into the engine.

Conditional field writes preserve an existing expiry

Version 1.21 also adds an NX option to HSETEX. The regression tests show the command's option placement and compare ordinary replacement with conditional insertion. Without NX, the command can replace an existing field value. With NX, an existing field keeps its value.

HSETEX settings 100 feature enabled
HSETEX settings NX 1 feature changed

The second command follows the tested syntax. For an existing field, the option also preserves the earlier expiration instead of replacing it with the shorter lifetime. The tests advance time beyond the short duration and still retrieve the field. This makes the condition relevant to the field's lifetime as well as its contents.

The test also distinguishes the return value from whether an update occurred. An ordinary overwrite returns zero for an already existing field while still changing its value. A conditional operation on that field also returns zero but leaves the value unchanged. The caller therefore has to interpret the result according to the command options it supplied. Alongside namespaces, this addition extends a specific application behaviour while leaving its meaning visible in the command's tested cases.