Compatibility

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 Python SDK and whether the SDK is:

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

The Couchbase Python SDK aims to support Python versions in security or bug-fix (a.k.a. maintenance) status. The table below indicates the Python SDK version where support of a version of Python was added. Python versions that have reached their End-of-Life date are not supported.

Because the Python SDK is written primarily in C using the CPython API, the official SDK will not work on PyPy.

Other Python versions and implementations might work but are not tested and are not supported. Please make sure you run on one of the latest patch releases, since they provide stability improvements and security fixes in general.

The Python SDK is built on top of the C++ SDK (not currently available separately), which is tested and supported on the following platforms:

Wheels are available for macOS, Linux and Windows — see the releases page for details.

Although installable or compilable on many other platforms, we cannot provide support for untested combinations.

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.

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:

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:

This release of the SDK is written to version 3.4 of the SDK API specification (and matching the features available in Couchbase 7.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.

Whilst these two numbers match for the .NET, Java, and Ruby SDKs, 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 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 λ.

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.

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