A newer version of this documentation is available.

Compatibility of Couchbase Features, Couchbase Server Versions, and the Couchbase Java SDK

Features available in different SDK versions, and compatibility between Server and SDK. Plus notes on Cloud, networks, and AWS Lambda.

The 3.2 SDK requires Java 8 or later to be installed, earlier versions will not work. Java 17 is recommended, which has various enhancements like sealed classes, pattern matching for switch expressions (in preview), and further updates and improvements on core libraries. Most of the flavors available will do, although we may only provide support for OpenJDK and Oracle JDK going forward.

Couchbase Version/SDK Version Matrix

Couchbase SDKs are tested against a variety of different environments to ensure both backward and forward compatibility with different versions of Couchbase Server. The matrix below denotes the version of Couchbase Server, the version of the Java SDK and whether the SDK is:

✖ Unsupported: This combination is not tested, and is not within the scope of technical support if you have purchased a support agreement.
◎ Compatible: This combination has been tested previously, and should be compatible. This combination is not recommended by our technical support organization. It is best to upgrade either the SDK or the Couchbase version you are using.
✔ Supported: This combination is subject to ongoing quality assurance, and is fully supported by our technical support organization.

Table 1. Recommended SDK per Server Version Matrix
	SDK 2.7	SDK 3.0, 3.1	3.2
Server 5.0	✔	◎	◎
Server 5.5	✔	✔	✔
Server 6.0	✔	✔	✔
Server 6.5-6.6	✔	✔	✔
Server 7.0	◎	◎	✔

Note the End of Life dates for Couchbase Server and SDK versions. See the notes there for Support details.

Capella Compatibility

At time of release, the Couchbase 3.2 Java SDK is fully compatible with Couchbase Capella, our fully-hosted database-as-a-service.

Note, Capella is offered as a fully provisioned service, so the underlying version of Couchbase Server changes over time. For this reason, compatibility information between Capella and the SDK is available on the Capella compatibility page.

JDK Version Compatibility

The Java SDK is tested with Oracle JDK and OpenJDK. Other JDK implementations might work but are not tested and are unsupported. We recommend running the latest LTS version (i.e. at the time of writing JDK 17) with the highest patch version available.

We only support LTS versions of Oracle JDK and OpenJDK. Other versions may work — but they are not tested and they are not supported.

The following JDK releases are supported:

OpenJDK 17 with HotSpot JVM (recommended)
Oracle JDK 17 (recommended)
OpenJDK 1.8 with HotSpot JVM
Oracle JDK 1.8

Please make sure you run on one of the latest patch releases, since they provide stability improvements and security fixes in general.

OS Compatibility

In general, the JVM eliminates concerns about underlying OS compatibility, and Couchbase JVM SDKs can be expected to run on all of the Operating Systems supported by Couchbase Server. The JVM SDKs should also be expected to run on other commonly-available GNU/Linux distributions which support an appropriate JDK, but not all combinations can be tested — notable exceptions are listed below.

Alpine Linux Compatibility

The Netty I/O library used by our JVM SDKs supports native optimizations to achieve higher throughput and lower latency — which the SDK enables by default. Those modules are compiled against glibc and Alpine Linux uses musl instead — so the Java SDK is unable to complete bootstrapping on this platform.

Because Alpine Linux does not have the glibc support needed, we highly recommend that you seek an alternative distribution where possible (note, in any case, that OpenJDK does not support Alpine Linux). If that is not a option, then a possible workaround that can be applied is as follows:

Disable the native IO:

ClusterEnvironment env = ClusterEnvironment.builder().ioEnvironment(IoEnvironment.enableNativeIo(false)).build();
Disable it in Netty itself via the following system property: -Dcom.couchbase.client.core.deps.io.netty.transport.noNative=true

The downside of these workarounds is potentially reduced performance, which can be determined through benchmarking and profiling.

Couchbase Feature Availability Matrix

Table 2. Couchbase Server and SDK Supported Version Matrix
	Server 5.0, 5.1, & 5.5	Server 6.0	Server 6.5 & 6.6	Server 7.0
Enhanced Durability	All SDK versions
Durable Writes	Not Supported		Since 3.0
Analytics	DP in 5.5 with 2.6	Since 2.7
Distributed ACID Transactions	Not Supported		Since 3.0^[1]
N1QL Queries inside the Transaction Lambda	Not Supported			Since 3.0.7^[2]
Collections	Not Supported		Developer Preview in 6.5-6.6, SDK 3.0	Since 3.0.6
Scope-Level N1QL Queries & all Collections features	Not Supported			Since SDK 3.2.0
Field Level Encryption v2	Not Supported		Since SDK 3.0.5^[3]
Request Tracing	Not Supported		Since SDK 3.1.0

Network Requirements

Couchbase SDKs are developed to be run in an environment with local area network (LAN) like throughput and latencies. While there is no technical issue that prevents the use across a wide area network (WAN), SDKs have certain thresholds around timeouts and behaviors to recover that will not be the same once the higher latency and possible bandwidth constraints and congestion of a WAN is introduced. Couchbase tests for correctness under LAN like conditions. For this reason, only LAN-like network environments are officially supported.

Couchbase does document, for purposes of convenience when developing and performing basic operational work, what may need to be tuned when network throughputs and latencies are higher. If you encounter issues, even with these tune-ables, you should attempt the same workload from a supported, LAN-like environment.

Running on AWS Lambda

AWS Lambda’s execution environment can freeze/thaw processes. Current Couchbase SDKs run background processing to check and adapt to topology changes in the Couchbase Cluster being used. Since the freeze does not allow this background processing and upon thaw the event-driven Couchbase SDKs may issue requests to an old topology, unexpected behavior including failures may occur. AWS λ does not provide a way to detect the freeze/thaw cycle. For this reason AWS λ is not currently a tested and supported platform for running current Couchbase SDKs.

Spring Data Couchbase Compatibility

Spring Data Couchbase uses the Java SDK underneath and as a result is also provides different compatibilities with Couchbase Server. The following table provides an overview.

Table 3. Recommended Spring Data Couchbase per Server Version Matrix
	SDC 3.x	SDC 4.0 - 4.2
Status →	SDK 2.x only	New Features, Active Development
Server 5.x	SDK 2.x	Not Compatible
Server 6.0	SDK 2.x	Recommended
Server 6.5 & 6.6	SDK 2.x	Recommended
Server 7.0	Not Supported	Recommended

Check the Spring Data Couchbase’s compile dependencies — older versions may link an out-of-date version of the Java SDK in their dependencies list, although a supported version should be in the updates. Please make sure that you are using a supported version of the Couchbase Java SDK, prefereably the latest version, which will contain any available bug fixes. Using the latest Spring Data Couchbase should ensure that this is so.

Reactor Core Version

SpringBoot may set the io.projectreactor version at an earlier version than the one needed by the current version of Couchbase JVM Core IO. In case of errors, override with Core IO’s preferred version, e.g.:

<dependency>
    <groupId>io.projectreactor</groupId>
    <artifactId>reactor-core</artifactId>
    <version>3.4.6.RELEASE</version>
</dependency>

Interface Stability

Couchbase SDKs indicate the stability of an API through documentation. Since there are different meanings when developers mention stability, we mean interface stability: how likely the interface is to change or be removed entirely. A stable interface is one that is guaranteed not to change between versions, meaning that you may use an API of a given SDK version and be assured that the given API will retain the same parameters and behavior in subsequent versions. An unstable interface is one which may appear to work or behave in a specific way within a given SDK version, but may change in its behavior or arguments in future SDK versions, causing odd application behavior or compiler/API usage errors. Implementation stability is implied to be more reliable at higher levels, but all are tested to the level that is appropriate for their stability.

Couchbase uses three interface stability classifiers. You may find these classifiers appended as annotations or comments within documentation for each API:

Committed: This stability level is used to indicate the most stable interfaces that are guaranteed to be supported and remain stable between SDK versions. This is the default — unless otherwise stated in the documentation, each API has Committed status.
Uncommitted: This level is used to indicate APIs that are unlikely to change, but may still change as final consensus on their behavior has not yet been reached. Uncommitted APIs usually end up becoming stable APIs.
Volatile: This level is used to indicate experimental APIs that are still in flux and may likely be changed. It may also be used to indicate inherently private APIs that may be exposed, but "YMMV" (your mileage may vary) principles apply. Volatile APIs typically end up being promoted to Uncommitted after undergoing some modifications.

APIs that are marked as Committed have a stable implementation. Uncommitted and Volatile APIs should be stable within the bounds of any known and often documented issues, but Couchbase has not made a commitment to these APIs and may not respond to reported defects with the same priority.

Additionally, take note of the following interface labels:

Deprecated: Any API marked deprecated may be removed in the next major version released. Couchbase recommends migrating from the deprecated API to the replacement as soon as possible. In rare instances, deprecated API may be rendered non-functional in a dot-minor release when the API cannot continue to be supported.
Internal: This level is used to indicate you should not rely on this API as it is not intended for use outside the module, even to other Couchbase components.

SDK API Specification and Version

API Specification (referred to as API going forward) and its version represents a logical grouping of a set of features being bundled. SDK Versions follow Semantic Versioning and implement an API specification version.

This release of the SDK is written to version 3.2 of the SDK API specification (and matching the features available in Couchbase 7.0 and earlier). For most developers, just using the latest version will be all that matters, and few will need to look at another of our SDKs. Just for those few that do, the table below shows each Couchbase SDK release version that matches the API version.

Whilst these two numbers may match — for the C, .NET, Java, PHP, Python, and Ruby SDKs — this is not the case for the others. Check the release notes of each SDK for individual details.

Table 4. API vs SDK Versions
	API 2.7	API 3.0	API 3.1	API 3.2
C (libcouchbase)	2.10	3.0	3.1	3.2
.NET	2.7	3.0	3.1	3.2
Go	1.5 & 1.6	2.0 & 2.1	2.2	2.3 & 2.4
Java	2.7	3.0	3.1	3.2
Node.js	2.6	3.0	3.1	3.2 & 4.0
PHP	2.6	3.0	3.1	3.2
Python	2.5	3.0	3.1	3.2
Ruby	-	3.0	3.1	3.2
Scala	-	1.0	1.1	1.2

SDK API 3.2: Introduced alongside Couchbase Server 7.0, provides features in support of Scopes and Collections, extends capabilities around Open Telemetry API to instrument telemetry data, enhanced client side field level encryption to add an additional layer of security to protect sensitive data, adds new platform support such as Ubuntu 20.04 LTS.

SDK API 3.1: Introduced alongside Couchbase Server 6.6, focuses on Bucket Management API, adds capabilities around Full Text Search features such-as Geo-Polygon support, Flex Index, and Scoring.

SDK API 3.0: Introduced alongside Couchbase Server 6.5, is a major overhaul from its predecessor, has simplified surface area, removed long-standing bugs and deprecated/removed old API, introduces new programming languages Scala and Ruby, written in anticipation to support Scopes and Collections.

SDK API 2.7: Introduced alongside Couchbase Server 6.0, with support for its new features such as the Analytics Service, improvements to Full Text Search, and support for more complex network configurations.

Unresolved include directive in modules/project-docs/pages/compatibility.adoc - include::7.1@sdk:shared:partial$archive.adoc[]

1. 3.0.7 or more recent recommended; preferably, follow the transitive dependency for the transactions library in Maven.

2. With Java Transactions Library 1.1.3 — but Java Transactions Library 1.2.1 or newer recommended.

3. Field Level Encryption distributed as separate library.