# Valkey 9.1 adds database-specific access controls and TLS diagnostics > Valkey 9.1 introduces access rules for numbered databases, certificate monitoring and script controls, giving operators more precise deployment checks. Canonical URL: https://www.devobs.io/news/news-valkey-91-database-access-controls/ By: Claire Dubois Published: 2026-09-06T11:58:54.645Z Updated: 2026-09-06T11:58:54.645Z Event date: 2026-05-19 Section: Data Valkey announced version 9.1 on May 19, extending access controls to numbered databases and adding tools for monitoring TLS certificates and thread activity. The [release announcement](https://valkey.io/blog/valkey-9-1-delivers-improvements-in-security-performance-and-more/) also describes separating Lua support into an optional module. ## Access rules become more specific Previously, a user's command and key permissions applied across databases. The new database-level rules let operators constrain which numbered databases that user can access. This is a meaningful additional control for deployments using that organization model. For an application team, the practical question is whether connection setup selects the database the access policy expects. An upgrade test should include denied selections and reconnections, alongside ordinary permitted reads and writes. A successful command in the intended database does not establish that another database is inaccessible. The Lua change also gives operators a configuration choice when scripting is unused. Before disabling it, inventory application calls and operational utilities that depend on scripts. That review should include infrequent repair and maintenance paths. ## Make certificate rotation observable Valkey 9.1 exposes certificate expiration information through INFO and supports certificate reload in the background. New cumulative thread metrics help distinguish actual work from busy-wait activity that can inflate apparent CPU utilization. Our assessment is that these additions are most useful when they become operational checks. Certificate monitoring should identify the instance, expiry and expected replacement, while a rotation rehearsal should exercise both existing and newly established connections. Similarly, compare thread metrics with request latency and traffic before changing capacity. A high CPU graph alone can send an investigation in the wrong direction. Record the new measurements under a familiar workload first, so subsequent incidents have a baseline grounded in the service's own behavior. ## Source references -