Redis 6.0 RC1 separates client identity from network processing

A shared password cannot express that one Redis client should read application keys while another administers the server. Adding network workers does not solve that problem either. Redis 6.0 RC1 changes both areas, with ACL users defining permitted operations and optional I/O threads changing how the server handles client traffic. The two changes belong to different stages of serving a request.

The first release-candidate notes date RC1 to 19 December 2019. They also introduce TLS support and the RESP3 reply protocol. This is a release candidate for evaluation, and the notes say further candidates will follow before the code is considered production ready. Its interfaces are concrete enough to inspect, but the release does not establish a completed stable Redis 6.0.

I have used Redis since its release and like the consistency of its existing semantics. RC1 interests me because it expands how applications connect and authenticate without requiring every existing client to adopt all the new options together. The useful engineering question is which change affects which part of that relationship.

ACL users express authority after authentication

The RC1 configuration describes users with enabled or disabled status, passwords, permitted commands and key patterns. This lets an installation assign different authority to different identities. Authentication can establish who a client is, after which authorization can limit the operations available to that user.

The configuration's examples also establish that rule order matters. Adding a command category and then removing a command produces a different result from removing the command first and subsequently adding the category. ACL rules are processed left to right. A configuration review therefore needs the sequence of rules, not merely a bag of permission tokens.

That is a practical difference from a server-wide command rename. Renaming changes the command name visible to clients, while an ACL can associate permitted commands with an identity. The RC1 configuration deprecates command renaming and recommends assigning administrative commands to an administrative user through ACLs.

Key patterns add another dimension. An application may need the same command as another application while operating on different keys. Restricting the command alone cannot express that separation. A user definition can carry a key-pattern restriction alongside its command permissions, so those two aspects of the policy are represented together.

The default user preserves a compatibility route

The configuration explains that requirepass becomes a compatibility layer over the ACL system. Setting it assigns a password to the default user. The existing single-password AUTH form continues to work, and clients can also authenticate explicitly as the default user with a username and password.

This avoids making adoption of named application identities a prerequisite for every existing connection. It does not mean that preserving an old password setting automatically creates a useful least-privilege policy. An installation still has to define the permissions it wants users to have. Compatibility preserves an authentication route, while policy design determines the authority behind it.

User definitions can live in redis.conf or in a separate ACL file. The configuration says those two methods cannot be mixed, and the server refuses to start when both are configured. The external file uses the same user-definition format. This gives deployments a separate place to manage identities without creating a second rule language.

Replication also receives an identity setting. The configuration documents masteruser for a replica authenticating to its upstream server with a username and password. If the default user cannot perform replication commands, a replica needs an identity that can. Application and replication access therefore need not rely on the same configured user.

TLS protects a different boundary

TLS is disabled by default in the supplied configuration. RC1 exposes a TLS listening port separately from the ordinary port, and the configuration shows disabling the ordinary port when using TLS on the usual port number. Certificate, private-key and CA settings supply the material used to authenticate the server and its peers.

The CA configuration is explicit. The comments say Redis will not implicitly use the system-wide CA configuration. That matters when translating an existing deployment's certificate assumptions into Redis settings. A certificate file alone does not describe every trust decision the service needs.

The configuration also has separate switches for TLS replication and the Redis Cluster bus. Enabling a TLS listener for application clients does not, by itself, describe those other channels. The cluster-bus comments state that mutual authentication is enforced when TLS is enabled there.

ACLs and TLS therefore answer different questions. ACL rules determine the permitted actions of a user. TLS supplies transport protection and certificate-based peer checks according to the configured channel. A deployment can need both because knowing which operation is allowed does not protect its bytes in transit.

I welcome the ability to express these boundaries inside the service configuration. It makes the application's identity and the connection's transport properties separately reviewable. Neither setting should have to be inferred from the presence of the other.

I/O threads do not imply parallel command execution

The RC1 configuration parser defines io-threads with a default value of one. It separately defines io-threads-do-reads, disabled by default. The presence of threaded I/O in the release notes therefore does not mean the default server starts processing client traffic with multiple workers.

The network implementation divides pending clients among worker lists. A worker performs reads or writes according to the current I/O operation and then clears its pending count. The coordinating path waits until the workers finish before continuing the next stage.

For threaded reads, that next stage processes pending commands after the read workers complete. This is a meaningful boundary. Reading and parsing network input can occur in the I/O phase without turning command execution into arbitrary concurrent access to the dataset. The source explicitly separates those steps.

The implementation also avoids starting threaded work when too few clients have pending output. It uses the pending-client count to decide whether to retain the direct path. Distributing a small amount of work across threads has coordination costs, so enabling more workers does not imply that every event-loop pass uses them.

This explains why a general performance multiplier would be incomplete. A workload dominated by network handling has a different opportunity from one dominated by command computation. The release notes advertise improved throughput in their stated context, but the implementation's division of work is the more useful basis for understanding where that benefit can arise.

RESP3 changes how replies describe values

RC1 introduces RESP3 so clients can interpret reply types with more semantic information. The HELLO implementation in the same network source accepts protocol version two or three and rejects unsupported versions. It also supports authentication and connection naming as options during negotiation.

The command requires an authenticated client before completing protocol selection, unless authentication succeeds through its AUTH option. That connects protocol negotiation to the new user model without making the two concepts identical. A client can choose a reply protocol and supply credentials as part of establishing its connection state.

For an already authenticated client, the minimal negotiation request is:

HELLO 3

This changes the protocol for that connection. It does not require the application to replace its keys or change the underlying meaning of every command. Client libraries still need to understand the selected reply representation before exposing its values to application code.

That is a separate compatibility concern from authenticating as a named user. A library may support the new AUTH form without supporting RESP3's reply types, or support protocol negotiation while using the default user. RC1 provides distinct mechanisms for those connection choices.

Some additions remain explicitly experimental

The release notes label server support for client-side caching as experimental and expect changes during later candidates. That status belongs in an account of RC1 even though the same release includes more established-looking configuration options. A feature list does not give every listed capability an identical maturity level.

The notes also describe module API additions and replica-side diskless loading. These expand different integration paths around the server. They do not alter the specific division shown by the network code, where I/O workers finish their phase before the main path processes pending commands.

RC1 therefore gives evaluators several independent contracts to inspect. User definitions determine authority, TLS configuration describes protected channels and HELLO selects a connection's reply protocol. Optional I/O workers handle network phases under separate defaults, with command processing continuing after those workers finish their assigned work.