Compatibility

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

The Couchbase PHP SDK generally tracks PHP’s own supported versions, and recommends the most recent "Active Support" version, except as specified in our documentation and especially the release notes.

As of June 2024, these versions are PHP 8.3 (Latest Active Support), 8.2 (Active Support), and 8.1 (Security Support) — see the table below for supported versions and dates.

Platform Compatibility

PHP Version Compatibility

The Couchbase PHP SDK aims to support all supported versions of PHP. The table below indicates the PHP SDK version where support of a version of PHP was added. PHP versions that have reached their End-of-Life date are not supported.

Supported PHP Versions
PHP Version	Security Support EOL	Couchbase SDK Versions Supported
8.2	until 2026-12-31	from 4.1.0
8.3	until 2027-12-31	from 4.1.6
8.4	until 2028-12-31	from 4.2.5
8.5	until 2029-12-31	from 4.5.0

OS Compatibility

In general, the SDK can be expected to run on all of the Operating Systems supported by Couchbase Server.

However, the PHP SDK is tested and supported specifically on the following OSs and platforms:

The PHP SDK will run on, and is supported on, the following OSs and platforms. The SDK has been tested on a representative subset of the platforms listed below.

GNU/Linux

Amazon Linux 2 & AL2023.
Red Hat Enterprise Linux 8, 9, & 10.
Oracle Linux 8, 9, & 10.
Ubuntu (LTS) 22.04 (Jammy) & 24.04 (Noble).
Debian 11 (Bullseye), Debian 12 (Bookworm), & Debian 13 (Trixie).
SUSE Enterprise Linux 12 & 15.
Alpine Linux 3.21 - 3.23.

Microsoft Windows

Microsoft Windows 10 & 11;
Windows Server 2019, 2022, & 2025.

Mac OS X

The current and previous two releases of OS X. At time of writing (March 2026): 26 (Tahoe), 15 (Sequoia), and 14 (Sonoma).

x86-32 Processor Not Supported

Use of the PHP SDK on legacy or embedded 32-bit platforms is not supported.

While the SDK can be compiled for 32-bit version of x86 platform, there are complications in use from working around number handling in the API, including use of unsigned integers, and it is not generally tested and supported.

==== Platforms, Chipsets, and Virtual Environments

Couchbase SDKs can be expected to run on modern ARM chips (such as AWS Graviton) and virtualised platforms (such as Microsoft Hyper-V). Nevertheless, there are so many products available that not all can be tested — as such, we do not call out specific support for any particular product. Please contact our support organisation if you run into any issues.

As always, running the very latest version of the SDKs will pick up any fixes already made to platform support (see the Release Notes).

=== 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 tunables, you should attempt the same workload from a supported, LAN-like environment.

==== Serverless Environments

Recent SDKs offer better resilience in handling errors that may occur when running your application in serverless environments, in particular when processes are frozen or thawed, and a rebalance is required. This means official support for AWS Lambda, Azure Functions, and GCP Functions.

When DNS SRV records are used to connect to the SDK it is possible for the underlying addresses to change (i.e. the cluster could move). The SDK will detect this and react accordingly so that your application can continue to work correctly.

== Couchbase Server Compatibility

Couchbase SDKs are tested against a variety of different environments to ensure both backward and forward compatibility with different versions of Couchbase Server.

=== Couchbase Version/SDK Version Matrix

The matrix below denotes the version of Couchbase Server, the version of the PHP 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.

Recommended SDK per Server Version Matrix
	4.1 - 4.2	4.3	4.4
Server 7.0 - 7.2	✔	✔	✔
Server 7.6 ①	✔	✔	✔
Server 8.0 ①	✔	✔	✔

① Server 7.6 & 8.0 are compatible with all supported (not yet End-of-Life) versions of the PHP SDK, but for full support of the latest features you need to upgrade to a recent version of the SDK. See the Feature Availablity matrix below and the Release Notes page.

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

=== Capella Compatibility

The Couchbase Ruby SDK is fully compatible with Couchbase Capella, our fully-hosted database-as-a-service. To make development easier, the SDK includes the Capella client certificate ready installed.

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.

=== Couchbase New Feature Availability Matrix

Couchbase Server and SDK Supported Version Matrix
	Server 7.0 & 7.1	Server 7.6
Enhanced Durability	All SDK versions
Durable Writes	Since 3.0
Analytics	Since 2.6
Collections	Since 3.0.5
Scope-Level SQL++ (formerly N1QL) Queries & all Collections features	Since SDK 3.2.0
Request Tracing	Since SDK 3.2.0
Distributed ACID Transactions	Since SDK 4.0.0
Cloud Native Gateway	Not Yet Supported
Vector Search	N/A	From SDK 4.2.0

=== API Version

This release of the SDK is written to version 3.9 of the SDK API specification (and matching the features available in Couchbase 8.0.1 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 (and a table that covers the earliest versions of the 3.x SDK API can be found in documentation for earlier versions of the SDK).

Whilst these two numbers match for the .NET SDK, this is not the case for the others, as version numbers for individual SDKs are bumped up in line with Semantic Versioning — check the release notes of each SDK for individual details.

SDK API Versions
	API 3.4	API 3.5	API 3.6	API 3.7	API 3.8	API 3.9
.NET	3.4	3.5	3.6	3.7	3.8	3.9
C (libcouchbase)	3.3.3 ①	N/A ②	N/A ②	N/A ②	N/A ②	N/A ②
C++	-	-	1.0	1.1	1.2	1.3
Go	2.6 & 2.7	2.8	2.9	2.10	2.11	2.12
Java	3.4 & 3.5	3.6	3.7	3.8	3.9 & 3.10	3.11
Kotlin	1.1 & 1.2	1.3	1.4	1.5	3.9 & 3.10 ③	3.11
Node.js	4.2	4.3	4.4	4.5	4.6	4.7
PHP	4.1	4.2	4.2.2	4.3	4.4	4.5
Python	4.1	4.2	4.3	4.4	4.5	4.6
Ruby	3.4	3.5	3.5.2	3.6	3.7	3.8
Rust	-	-	-	-	-	1.0
Scala	1.4 & 1.5	1.6	1.7	1.8	3.9 & 3.10 ③	3.11

1	Excludes DNS SRV refresh support in Serverless Environments.
2	For most purposes better productivity and functionality can be found in our C++ SDK.
3	With the Java 3.9 release, the other JVM SDKs hosted in the Java SDK monorepo adopted common release versions. This includes a number of other artifacts, as can be seen referenced in the release notes.

SDK API 3.9: Provides support for JWT based authentication, as well as mTLS Certs Refresh (without restart). Adds Amazon Graviton 3 support. Deprecates SDK support for MapReduce Views.

SDK API 3.8: Introduced alongside Couchbase Server 8.0, which adds support for 128 vBuckets on Magma. Server 8.0 introduced vector query using Global Secondary Indexes (GSI), the Query Service index — using either a fast Hyperscale index, or a composite index to combine scalar queries with semantic search.

SDK API 3.7: Introduced support for KV reads from preferred server groups. The .NET SDK has been updated to support the latest Transactions specification — and the library is now incorporated within the .NET SDK. A new getMulti() interface batch reads with read committed isolation. Additionally, the Java SDK now includes a Quarkus extension with GraalVM support.

SDK API 3.6: Introduced support for base 64 encoded vector types alongside Server 7.6.2 (and Capella). General Availability of our C++ SDK — now available as a supported, stand-alone SDK, this SDK is also the core of our Node.js, PHP, Python, and Ruby SDKs.

SDK API 3.5: Introduced support for Vector Search alongside Server 7.6 (and Capella). Adds scoped indexes to Search (for Vector Seach and traditional FTS). Read from Replica for Query and Sub-Doc operations. KV Range Scan for querying documents through the Data Service, even if you don’t know the document IDs (for use cases that require relatively low concurrency and tolerate relatively high latency). Transactions now implemented as a native library in all SDKs (except libcouchbase).

SDK API 3.4: Introduced support for ARM v8 on Ubuntu 20.04, Transactions on Spring Data Couchbase, and compatibility with running in serverless environments, such as AWS λ. The couchbase2:// connection string was introduced in Go 2.7, Java 3.5, Kotlin 1.2, and Scala 1.5, for Cloud Native Gateway with Couchbase Autonomous Operator (from CAO 2.6.1).

SDK API 3.3: Introduced alongside Couchbase Server 7.1, adds Management API for Eventing and Index Management for Scopes & Collections; extends Bucket Management API to support Custom Conflict Resolution and Storage Options; adds new platform support for Linux Alpine OS, Apple M1, and AWS Graviton2; provides improved error messages for better error handling; and an upgraded Spark Connector that runs on Spark 3.0 & 3.1 Platform.

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 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.

=== Older SDK Versions

Documentation on older, unsupported versions of the SDK — that have reached end-of-life — can be found in the archive.