Introducing the Aerospike Java and Python SDKs: A generational upgrade to building on Aerospike

Most database clients were designed before AI coding assistants existed, and before teams expected to go from prototype to production without a database expert. The syntax and documentation reflect that gap. AI coding assistants struggle to generate correct code when APIs rely on non-obvious patterns and hidden configuration flags. And clients that are easy enough to get started with often hit a wall when production traffic arrives.

The Aerospike Java and Python SDKs are designed from scratch to address these problems. They introduce idiomatic APIs with clear, predictable patterns, readable by both developers and AI coding assistants. That means correct code from the first attempt, not after several rounds of correction. And they cleanly separate what application developers care about, writing business logic, from what SREs and DBAs care about, cluster configuration, timeouts, and retry policies. That separation means developers can move quickly without accidentally misconfiguring something that only breaks under production load.

They are available in Preview today.

A platform designed for predictability

Aerospike earned its reputation in environments where most databases stop working well: real-time bidding systems processing millions of auctions per second; fraud detection at the moment of a transaction; and personalization engines that have to know everything about a user before the page loads. These are workloads where latency is not a metric but a product requirement, and where the cost of getting it wrong is immediate and visible.

The database architecture that makes Aerospike work in those environments is not incidental. Aerospike is built on design choices that compound over years of production operation. Latency stays predictable regardless of dataset size. Performance does not degrade as clusters age or storage fills. High availability does not require the cost of triple replication. Operators and architects who run Aerospike at scale trust it precisely because its behavior stays consistent under conditions that would destabilize other systems.

That trust has been earned. The new SDKs are about making that enterprise performance and predictability available to all.

A gap worth closing

For a developer new to Aerospike, the path from "I want to store and retrieve data" to "this is working correctly in production" has historically required significant learning of Aerospike-specific concepts. 

The existing clients were built when the priority was exposing the full control surface of the database. That produced an API where common operations required understanding policy objects, operational flags, and configuration patterns that had little to do with the application logic a developer was actually trying to write.

Like a lot of powerful infrastructure tools, Aerospike rewarded expertise. Developers who invested the time got a database that could do things no other database could achieve. But developers evaluating Aerospike for a new use case, or expanding into a new application, often needed deep familiarity or external help to be productive. We heard this consistently, and it is what the new SDKs are designed to fix.

SDKs designed and built for developer flow

The Java and Python SDKs are not the existing clients with improvements layered on. They are built from the ground up with an updated set of priorities. The core principle is that common operations should be obvious, and the API should get out of the developer's way. This means idiomatic code that reads naturally in each language, specific methods with clear names rather than generic calls controlled by policy flags, and defaults that reflect how most applications actually behave. It means one way to do each thing, not five. And it means a clean separation between what application engineers care about, the business logic of reading and writing data, and what SREs and DBAs care about: timeouts, retry policies, and cluster configuration. In the new SDK, those concerns live in different places, so each role can focus on what they are responsible for without stepping on the other.

The difference in practice is significant. Here is the same operation in the legacy client followed by the new Java SDK:

Old code:

// -- Connect --
ClientPolicy clientPolicy = new ClientPolicy();
clientPolicy.user = "admin";
clientPolicy.password = "admin123";
clientPolicy.readPolicyDefault.sendKey = true;
clientPolicy.writePolicyDefault.sendKey = true;
clientPolicy.queryPolicyDefault.sendKey = true;
clientPolicy.batchPolicyDefault.sendKey = true;

AerospikeClient client = new AerospikeClient(clientPolicy, "localhost", 3100);

WritePolicy wp = client.copyDefaultWritePolicy();
wp.recordExistsAction = RecordExistsAction.CREATE_ONLY;
client.put(wp,
    new Bin("name", "Tim"),
    new Bin("age", 312));

New code:

Cluster cluster = new ClusterDefinition("localhost", 3100)
       .withNativeCredentials("admin", "admin123")
       .connect();

Behavior sendKeysBehavior = Behavior.DEFAULT.deriveWithChanges(
        "sendKeys",
        arg -> arg.on(
            Selectors.all(), ops -> ops.sendKey(true)
        )
    );
Session session = cluster.createSession(sendKeysBehavior);

session.insert(key)
   .bin("name").setTo("Tim")
   .bin("age").setTo(312)
   .execute();

The new version is shorter, but more importantly, it is readable without knowing what clientPolicy, writePolicy, or RecordExistsAction mean, nor remembering to copy the appropriate policy on each call. A developer can write it correctly the first time.

The Aerospike Expression Language

One of the areas where the learning curve was steepest was writing filters and conditional expressions. The existing API required assembling Exp objects with nested method calls that bore little resemblance to the condition being expressed. The new SDKs introduce the Aerospike Expression Language (AEL), which lets developers write those conditions directly. For example, let’s say we want to update the status of an account to “Completed,” but only if it currently has a balance over $500 and a status of “Active”:

Old code:

WritePolicy writePolicy = client.copyWritePolicyDefault();
writePolicy.recordExistsAction = RecordExistsAction.UPDATE_ONLY;
writePolicy.filterExp = Exp.build(
   Exp.and(
       Exp.gt(
           Exp.intBin("balance"),
           Exp.val(500)
       ),
       Exp.eq(
           Exp.stringBin("status"),
           Exp.val("ACTIVE")
       )
   )
);
client.put(writePolicy, key, new Bin("status", "COMPLETE"));

New code:

session.update(key)
   .bin("status").setTo("COMPLETE")
   .where("$.balance > 500 and $.status == 'ACTIVE'")
   .execute();

AEL follows a pattern well established in the industry. Java has Java EL, Spring has SpEL, and Google has CEL. The concept of a non-Turing-complete expression language for filtering and querying data in a specific domain is familiar to most developers. Aerospike now has one too.

Built for how developers work today

A growing share of application code is written with AI coding assistants. The new SDKs are designed with this in mind. The documentation is structured for LLM readability, meaning tools like GitHub Copilot or Cursor can generate accurate, near-production-quality Aerospike code rather than plausible-looking code that fails at runtime. Error messages are structured and human-readable, with specific error codes and suggested remediation steps, useful for developers reading them directly and for AI agents that need to interpret and respond to them.

This connects to a broader direction for Aerospike's developer tooling. Alongside the new SDKs, we are releasing Voyager, a data browser and UI with an MCP server that makes Aerospike accessible from within the tools modern developers already use. The SDKs and Voyager are different surfaces of the same goal: making the power of Aerospike reachable without requiring a specialist.

What is available now

The Java and Python SDKs are available in Preview today. The APIs are stable enough to build on and gather real feedback, but may still evolve before general availability. We want to hear what works, what is confusing, and what is missing.

The existing Java and Python clients remain fully supported. There is no pressure to migrate. Both can run against the same cluster simultaneously, giving you time to move at your own pace.

To get started, visit our developer docs.