Full client/server feature compatibility
The following matrix shows the minimal version of each client required for full feature compatibility with the given server version.
|Aerospike server version||7.0||6.4||6.3||6.2||6.1||6.0||5.7|
|Java client version||7.2.0||6.1.0||6.1.0||6.1.0||6.1.0||6.0||5.1.6|
|Python client version||14.0.0||11.0.1||11.0.1||7.0.0||7.0.0||7.0.0||6.0.0|
|Go client version||7.0.0||6.13.0||6.10.0||6.0.0||6.0.0||6.0.0||5.0.0|
|C# client version||6.2.0||6.0.0||6.0.0||5.2.0||5.2.0||5.0.0||4.2.2|
|C client version||6.5.0||6.3.1||6.3.1||6.1.1||6.1.1||6.0.0||5.2.3|
|Node.js client version||5.9.0||5.4.0||5.4.0||5.0.0||5.0.0||5.0.0||4.0.0|
Language-specific compatibility notes
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.
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.
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.
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 inherits all variables from the
Policy class, which contains
ReadModeAP only applies to reads, not writes, so all writes (which use
Specific parameters control write transaction behavior in AP mode.
ReadModeAPcontrols duplicate resolution. The possible values are
ALL, which enables duplicate resolution, and
ONE, which disables duplicate resolution.
ReadModeSCcontrols consistency options in strong consistency-enabled namespaces. The possible values are:
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.
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.
- All changes in the Aerospike Java Client API are listed in Incompatible API Changes.
ReadModeSCpresents options in terms of ‘relaxed reads’ which give you granular control over when a client read may be permitted, and which copy is read.
In a strong-consistency namespace:
- Duplicate resolution always takes place. This is not configurable.
write-commit-level-overridedo not apply.
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.
|Aerospike server version||7.0||6.4||6.3||6.2||6.1||6.0||5.7||5.6||5.3||4.9|
|Java client version||6.0.0||6.0.0||6.0.0 (5.1.6)||6.0.0 (5.0.1)||6.0.0 (5.0.1)||6.0.0 (5.0.1)||4.4.20||4.4.20||3.3.3||3.3.3|
|Python client version||7.0.2 (6.1.0)||7.0.2 (6.1.0)||7.0.0 (6.1.0)||7.0.0 (6.0.0)||7.0.0 (6.0.0)||7.0.0 (6.0.0)||6.0.0||6.0.0||3.1.1||3.1.1|
|Go client version||7.0.0||6.10.0 (5.4.0)||6.0.0 (5.4.0)||6.0.0 (4.0.0)||6.0.0 (4.0.0)||6.0.0 (4.0.0)||4.2.0||4.2.0||1.38.0||1.38.0|
|C# client version||5.1.0 (4.2.2)||5.1.0 (4.2.2)||5.0.0 (4.2.2)||5.0.0 (4.0.0)||5.0.0 (4.0.0)||5.0.0 (4.0.0)||3.9.15||3.9.15||3.13.0||3.13.0|
|C client version||6.0.0 (5.2.3)||6.0.0 (5.2.3)||6.0.0 (5.2.3)||6.0.0 (5.0.0)||6.0.0 (5.0.0)||6.0.0 (5.0.0)||4.6.24||4.6.24||4.5.0||4.5.0|
|Node.js client version||5.0.3 (4.0.0)||5.0.3 (4.0.0)||5.0.0 (4.0.0)||5.0.0 (4.0.0)||5.0.0 (4.0.0)||5.0.0 (4.0.0)||3.16.7||3.16.7||3.9.0||3.9.0|
|Ruby client version||2.25.0||2.25.0||2.25.0||2.25.0||2.25.0||2.25.0||2.23.0||2.23.0||2.14.0||2.14.0|
Aerospike server version 5.2 introduced filter expressions as an upgrade to the predicate expressions query language. The predicate expression system was supported until server version 6.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 version||Breaking change|
|7.0.0||Go client versions before 7.0.0 working with server 7.0 unexpectedly interpret integers larger than 2^32 as |
|18.104.22.168||Removed the deprecated info commands for scan, |
|22.214.171.124||Removed the |
|126.96.36.199||Removed predicate expressions (PredExp).|
|188.8.131.52||Removed scan policies |
|4.9.0||Client applications must support the new style |
|184.108.40.206||Removed support for |
|220.127.116.11||Removed suport for |
The following table shows the feature compatibility of different language clients. See the feature guide for more information.
|Boolean Data Type||✅||✅||✅||✅||✅||✅||✅||✅||✅|
|Context Path Creation||✅||✅||✅||✅||✅||✅||✅||✅||✅|
|HyperLogLog Data Type||✅||✅||✅||✅||✅||✅||✅||✅||✅|
|PI Query (Scan)||✅||✅||✅||✅||✅||✅||✅||✅||✅|
|Background Query Operation||✅||✅||✅||✅||✅||✅||✅||✅|
|Filter Expressions on Operations⁸||✅||✅||✅||✅||✅||✅||✅||✅||✅|
|Filter Expressions on Queries⁸||✅||✅||✅||✅||✅||✅||✅||✅||✅|
|Load Balancer as Seed Node||✅||✅||✅||✅||✅||✅||✅||✅|
|Rack Aware Reads||✅||✅||✅||✅||✅||✅||✅||✅|
2 C client supports libev, libuv, and libevent asynchronous frameworks.
4 Refers to a transaction of read operations (`operate`) run in a batch against multiple keys.
5 Node.js client supports TLS on Linux only.
6 Node.js has RBAC support for connections to EE clusters, but not the management of users and roles.
7 REST has TLS, IPv6 and PKI authentication between the gateway and the EE cluster, but not for calls to the gateway itself.
8 Aerospike Filter Expressions were added in Aerospike Database 5.2; Operation Expressions were added in Aerospike Database 5.6.
9 Minimum JDK version is 17.