Skip to content
Inviting nominations for the Champions of Scale - Nominate a leader building internet-scale data infastructure today! Nominate someone
Developers/Client compatibility matrix

Client Matrix

Aerospike Database features are implemented through an interaction between Aerospike clients and the Aerospike server. The enhanced developer API of a new client is typically required to allow application developers to access new server features. Applications using older client versions will continue to work against an upgraded Aerospike Database cluster, as long as they aren’t using a feature that had been removed after a deprecation period. See Aerospike Database versioning and releases.

This page details compatibility between Aerospike client and server versions, and defines the support period for different clients.

Full client/server feature compatibility

The following matrix shows the minimal version of each client required for full feature compatibility with the given Aerospike Database version.

Aerospike Database version8.1.08.0.07.2.07.1.07.0.06.4.06.3.06.2.06.1.06.0.05.7.0Support Level
Java client version9.1.09.0.38.1.08.1.07.2.06.1.06.1.06.1.06.1.06.0.05.1.6Official
Python client version17.1.016.0.115.1.015.0.014.0.011.0.111.0.17.0.07.0.27.0.26.1.0Official
Go client version8.3.08.0.17.2.07.2.07.0.06.13.06.10.06.4.06.4.06.4.05.10.0Official
C# client version8.1.08.0.27.1.07.1.06.2.06.0.06.0.05.2.35.2.35.0.04.2.7Official
C client version7.1.07.0.26.6.06.6.06.5.26.3.16.3.16.1.16.1.16.0.05.2.8Official
Node.js client version6.3.06.0.25.12.05.12.05.9.05.4.05.4.05.0.35.0.35.0.34.0.0Official
PHP client version--1.11.11.01.01.01.01.01.0-Community
Ruby client version-2.11.02.11.02.11.02.11.02.11.02.11.02.11.02.11.02.11.02.11.0Community
Rust client version-2.0.01.3.01.2.01.2.01.2.01.2.01.2.01.2.01.2.01.2.0Community

Language-specific compatibility notes

C

Rack Awareness

The C client and the clients that rely on it (Python and Node.js) support a maximum replication factor (RF) of 3. If you set a higher RF, it accepts the value, but still uses only three replicas. If your client attempts a third replication, the chosen node uses the master instead of using the fourth replica.

Python

Rack Awareness

The Python client relies on the C client, and likewise supports a maximum replication factor (RF) of 3. If you set a higher RF, it accepts the value, but still uses only three replicas. If your client attempts a third replication, the chosen node uses the master instead of using the fourth replica.

NodeJS

Rack Awareness

The Node.js client relies on the C client, and likewise supports a maximum replication factor (RF) of 3. If you set a higher RF, it accepts the value, but still uses only three replicas. If your client attempts a third replication, the chosen node uses the master instead of using the fourth replica.

Java

Specify read consistency options in write operations

The Aerospike Java client has had various properties to specify read consistency options.

In client versions prior to 4.4.0, use the consistencyLevel property with the server running in Available and Partition-tolerant (AP) mode. In client version 4.4.0 and later, consistencyLevel was replaced with ReadModeAP for availability mode namespaces, and added a ReadModeSC property for strong consistency mode namespaces.

WritePolicy includes ReadModeAP because WritePolicy inherits all variables from the Policy class, which contains ReadModeAP. However, ReadModeAP only applies to reads, not writes, so all writes (which use WritePolicy) ignore ReadModeAP.

Specific parameters control write transaction behavior in AP mode.

  • ReadModeAP controls duplicate resolution. The possible values are ALL, which enables duplicate resolution, and ONE, which disables duplicate resolution.
  • ReadModeSC controls consistency options in strong consistency-enabled namespaces. The possible values are: ALLOW_REPLICA, ALLOW_UNAVAILABLE, LINEARIZE and SESSION.

For write transactions, the server parameter disable-write-dup-res controls duplicate resolution. The default is false, meaning write duplicate resolution is enabled.

At first glance, the client-side parameter commitLevel appears similar in nature to disable-write-dup-res. However, this is not the case. Unlike disable-write-dup-res, which controls behavior during migration, commitLevel and the server side write-commit-level-override determine when the server acknowledges a successful write. By default, the server waits until replica writes are complete. However, you can switch to “fire and forget” mode where the server returns success as soon as the master write is complete. See write-commit-level-override for more details.

Minimum usable client versions

The following matrix shows the minimal client version that ensures non-breaking operation against the given server version. Applications using older client versions may still work, if they do not use developer API functionality affected by the breaking changes specified below.

Database version8.1.08.0.07.2.07.1.07.0.06.4.06.3.06.1.06.0.05.7.04.9.0Support Level
Java client version6.0.06.0.06.0.06.0.06.0.06.0.06.0.0 (5.1.6)6.0.0 (5.0.1)6.0.0 (5.0.1)4.4.23.3.3Official
Python client version7.0.27.0.27.0.27.0.27.0.27.0.27.0.2 (6.1.0)7.0.2 (6.1.0)7.0.2 (6.1.0)6.0.03.1.1Official
Go client version7.0.07.0.07.0.07.0.07.0.06.10.06.0.0 (5.10.0)6.0.0 (4.0.0)6.0.0 (4.0.0)4.2.01.38Official
C# client version5.1.05.1.05.1.05.1.05.1.05.1.05.0.0 (4.2.7)5.0.0 (4.0.0)5.0.0 (4.0.0)3.9.153.13Official
C client version7.0.27.0.26.1.16.1.16.1.16.1.16.0.0 (5.2.3)6.0.0 (5.0.0)6.0.0 (5.0.0)4.6.244.5.0Official
Node.js client version5.0.35.0.35.0.35.0.35.0.35.0.35.0.3 (4.0.0)5.0.3 (4.0.0)5.0.3 (4.0.0)3.16.73.9.0Official
PHP client version1.0.01.0.01.0.01.0.01.0.01.0.01.0.01.0.01.0.01.0.0-Community
Ruby client version-2.11.02.11.02.11.02.11.02.11.02.11.02.11.02.11.02.11.02.11.0Community

Aerospike Database 5.2.0 introduced filter expressions as an upgrade to the predicate expressions query language. The predicate expression system was supported until Database 6.0.0, when it was removed.

In the “Minimum usable client versions” chart, the client version number in parentheses is usable with the corresponding server version as long as the application has migrated to using filter expressions (using a client version that supports both filter and predicate expressions). Otherwise, the higher-numbered client version ensures predicate expressions cannot be used with server versions that don’t support them.

Major server changes

Server versionBreaking change
7.0.0Go client versions before 7.0.0 working with Database 7.0.0 unexpectedly interpret integers larger than 2^32 as uint64 instead of int32. Use Go client version 7.0.0 or later with Database 7.0.0 and later.
6.4.0Removed the deprecated info commands for scan, scan-show, scan-abort, and scan-abort-all. Use the equivalent query commands, query-show, query-abort, and query-abort-all.
6.3.0Removed the jobs: info command.
6.0.0Removed predicate expressions (PredExp).
5.6.0Removed scan policies percent, failOnClusterChange, and priority.
4.9.0Client applications must support the new style truncate command, and the batch-index protocol for batch operations.
4.4.0Removed support for batch-direct.

Client versioning and support

Aerospike clients use semantic versioning for their releases. The version format is major.minor.patch (for example, Java client 9.1.0):

The following tables show the release dates and end-of-life (EOL) dates for each major version of Aerospike’s officially supported clients. All minor and patch releases within a major version share the same EOL date as their parent major version.

See Product Stages for an explanation of General Availability (GA) and EOL.

Java Client

Major VersionInitial Release DateEnd of Life Date
9.x.x2024-11-192027-11-19
8.x.x2024-01-052027-01-05
7.x.x2023-08-022026-08-02
6.x.x2022-03-312025-03-31
5.x.x2020-10-212023-10-21
4.x.x2017-05-222020-05-22
3.x.x2014-03-142017-03-14

Python Client

Major VersionInitial Release DateEnd of Life Date
18.x.x2025-10-012028-10-01
17.x.x2025-05-052028-05-05
16.x.x2024-12-162027-12-16
15.x.x2024-04-092027-04-09
14.x.x2023-11-142026-11-14
13.x.x2023-08-212026-08-21
12.x.x2023-07-282026-07-28
11.x.x2023-03-272026-03-27
10.x.x2023-01-272026-01-27
9.x.x2023-01-042026-01-04
8.x.x2022-11-182025-11-18
7.x.x2022-04-072025-04-07
6.x.x2021-05-102024-05-10
5.x.x2021-02-172024-02-17
4.x.x2020-09-242023-09-24
3.x.x2018-01-102021-01-10
2.x.x2016-02-162019-02-16
1.x.x2014-07-152017-07-15

Go Client

Major VersionInitial Release DateEnd of Life Date
8.x.x2025-01-222028-01-22
7.x.x2023-12-142026-12-14
6.x.x2022-04-072025-04-07
5.x.x2021-05-112024-05-11
4.x.x2020-11-272023-11-27
3.x.x2020-06-082023-06-08
2.x.x2019-03-202022-03-20
1.x.x2014-08-282019-08-28

C# Client

Major VersionInitial Release DateEnd of Life Date
8.x.x2024-12-062027-12-06
7.x.x2023-12-082026-12-08
6.x.x2023-02-032026-02-03
5.x.x2022-03-312025-03-31
4.x.x2020-10-212023-10-21
3.x.x2013-11-202016-11-20

C Client

Major VersionInitial Release DateEnd of Life Date
7.x.x2024-12-062027-12-06
6.x.x2022-03-312025-03-31
5.x.x2020-10-212023-10-21
4.x.x2016-01-142019-01-14

Node.js Client

Major VersionInitial Release DateEnd of Life Date
6.x.x2024-12-232027-12-23
5.x.x2022-05-012025-05-01
4.x.x2022-03-142025-03-14
3.x.x2017-10-032020-10-03
2.x.x2016-04-192019-04-19
1.x.x2014-02-112017-02-11
Feedback

Was this page helpful?

What type of feedback are you giving?

What would you like us to know?

+Capture screenshot

Can we reach out to you?