Giving database operators visibility and direct control with dynamic client configurations

If you're a database operator or SRE, you know the frustration: a production incident hits, and the fix requires changing a client configuration, maybe throttling error rates, adjusting connection limits, or tweaking timeout policies. But that change lives in application code. So you file a ticket, wait for a developer to pick it up, wait for code review, wait for the build pipeline, wait for staged rollouts. A two-minute configuration tweak turns into a two-week ordeal.

Aerospike is changing that dynamic with these new Preview features. Dynamic client configuration and enhanced client metrics with user-agent tracking put control where it belongs - in the hands of the operators who manage production stability.

The problem: Operators depend on developers for runtime tuning

Distributed database operators are responsible for cluster health, SLA compliance, and incident response. However, when issues stem from the client side, such as aggressive retry loops, misconfigured timeouts, or connection storms, operators have historically been powerless to act directly.

You see the problem, but you can't fix it. Client configurations live in application code. Adjusting connection pool sizes, error rate thresholds, or read/write policies means asking a development team to make the change. That team has its own priorities, its own sprint cycles, and its own deployment schedules.

You can't see what's connected. When something hits the cluster, you often can't answer basic questions: Which applications are connected? Is one misbehaving service causing the problem? What client versions are they running? Are any blocking my server upgrade? Without this visibility, you're left correlating logs across systems and chasing down application owners.

The result: operators carry pagers for systems they can't fully control, and developers get pulled into operational issues that distract from feature work.

The solution: Operator-controlled client configuration and visibility

To solve this, Aerospike introduces two complementary capabilities focused on control and visibility.

Dynamic client configuration

With dynamic client configuration, operators can now adjust client settings directly through a YAML file - no code changes to the application, no developer tickets, no application restarts.

The setup is straightforward. Point the client to a configuration file:

export AEROSPIKE_CLIENT_CONFIG_URL=file:///path/to/aerospikeconfig.yaml

Then define your settings:

version: 1.0.0

dynamic:
  read:
    total_timeout: 1500
    max_retries: 3
  write:
    total_timeout: 2000
  metrics:
    enable: true
    labels:
      app_id: "payment-service"

When you update this file, changes take effect within seconds. The application logs confirm:

INFO Set Policy.maxRetries = 3
INFO Set Policy.totalTimeout = 1500

During an incident, you can adjust configurations like timeout and retry policies immediately. No waiting on developers. No deployment pipelines. You experiment, observe the impact, and iterate until the cluster stabilizes.

User-agent tracking: See what's connected to your cluster

The second capability addresses visibility. With user-agent tracking, you can see every client connected to your cluster directly from asadm:

Admin> show user-agents

          Node|        Client Version|            App ID|Count
10.1.1.1:3000 | java-8.1.1           | payment-service  |   103
10.1.1.1:3000 | python-16.0.1        | analytics-engine |     1
10.1.1.2:3000 | java-8.1.1           | fraud-detection  |    20
10.1.1.2:3000 | unknown              | unknown          |  4321

The app_id column shows which service each connection belongs to. The unknown entries indicate older clients that haven't been upgraded. This is critical information when planning server upgrades.

This visibility, combined with enhanced client metrics tagged by app_id, lets you identify which application is causing problems without chasing down logs or asking developers to investigate.

Why this matters for operators and SREs

Resolve incidents without developer involvement. When a client threatens cluster stability, you can adjust timeouts, modify retry behavior, throttle error rates, or tune other client policies immediately. Developers stay focused on feature work; you stay focused on production stability.

Plan upgrades with confidence. Before rolling out a server upgrade, run show user-agents to see every connected client version. Check against the compatibility matrix. Identify which teams need to upgrade their clients before you proceed.

End the cross-team coordination tax. Client configuration changes no longer require tickets, meetings, or waiting on other teams' schedules. Operators get direct control over the settings that affect cluster behavior.

Getting started

These features require Aerospike Server 8.1.0 or later and updated client libraries:

• Java 9.2.0+

• Python 17.1.0+

• C 7.1.0+

• C# 8.1.0+

• Node.js 6.3.0+

• Go 8.4.2+

To enable dynamic client configuration, set the environment variable and restart the application once. From that point forward, you can make configuration changes dynamically through the YAML file.

To view connected clients, run show user-agents in asadm.

Available now in preview

Both features are available today in Preview for testing in non-production environments. 

For complete documentation:

• Dynamic client configuration overview

• Quickstart guide

• Client metrics reference

• User-agent tracking in asadm

We're gathering feedback from operators and SREs to refine the experience before general availability, and we’d love to hear from you!