A newer version of this documentation is available.

View Latest

Compatibility of Couchbase Features, Couchbase Versions and the Couchbase C (libcouchbase) SDK

API Styles and versions

Since the first release of libcouchbase 2.x in November 2012, we have added, in a compatible way, newer APIs to allow a faster and more efficient programming model. There are two broad categories of APIs in the library, one is known as api2 and the other is known as api3.

API2 is the original C 2.0 API, and is available in all versions of libcouchbase, but is considered deprecated since version 2.6.0. It looks something like this:

API2 - Scheduling
lcb_get_cmd_t gcmd = { 0 };
lcb_get_cmd_t* gcmd_p = &gcmd;
gcmd.version = 0;
gcmd.v.v0.key = "key";
gcmd.v.v0.nkey = nkey;
lcb_get(instance, cookie, 1, &gcmd);
API2 - Callback

void get_callback(lcb_t instance, const void *cookie, lcb_error_t err, const lcb_resp_get_t *resp)
    if (err) {
        // ...
    } else {
        printf("Value is: %.*s\n", (int)resp->v.v0.nbytes, resp->v.v0.bytes);

API3 is available since version 2.5.6 (but see note below) and offers a more concise way of performing operations:

API3 - Scheduling
lcb_CMDGET gcmd = { 0 };
LCB_CMD_SET_KEY(&gcmd, "key", 3);
lcb_get3(instance, cookie, &gcmd);
API3 - Callback
lcb_install_callback(instance, LCB_CALLBACK_GET, (lcb_RESPCALLBACK)get_callback);

void get_callback(lcb_t instance, int cbtype, const lcb_RESPGET *resp)
    if (resp->rc) {
    } else {
        printf("Value is: %.*s\n", (int)resp->nvalue, resp->value);

While API3 is available from version 2.4.0, the above example will only work from version 2.5.6, although it will compile on any version. Versions prior to 2.5.6 require explicit scheduling to be used in the application. Explicit scheduling requires invoking lcb_sched_enter() and lcb_sched_leave() around any code scheduling operations. Therefore the above snippet will work in version 2.4.0 and higher by using the following:

lcb_get3(instance, cookie, &gcmd);

It is recommended to upgrade to api3. Internally the older api2 implementation is simply a wrapper around api3, and api3 provides more concise code. Newer APIs and couchbase features will be added to api3 but not api2. Here are some things to keep in mind when porting:

  • You can mix and match callback and scheduling styles. This means that you can use lcb_get3 together with lcb_set_get_callback, or lcb_get with lcb_install_callback3.

  • API3 allows you to have a single callback function that handles multiple operation types (refer to CRUD Document Operations using the C (libcouchbase) SDK with Couchbase Server), so you can consolidate multiple lcb_set_operation_callback into a single API3 callback.

  • If you are using a version of libcouchbase prior to 2.5.6, be sure to invoke lcb_sched_leave before lcb_wait (or before returning to the event loop, for non-blocking applications). Calling lcb_sched_leave is no longer required as of version 2.5.6

  • There is no explicit batching API in api3. If you wish to schedule multiple operations, simply invoke the relevant scheduling API (e.g. lcb_operation3()) multiple times, once for each set of input.

  • The memory ownership model and callback semantics are the same for both API versions. This means that key and value buffers provided to the library are copied into the library’s buffers. Likewise this means that buffers received via callbacks are owned by the library’s internal buffers.

Feature Compatibility

To take advantage of all features offered by Couchbase Server, you need to know what version of the client provides compatibility for the features you want to use. The following matrix shows which versions of the C SDK client support the major features of each version of Couchbase Server.

Table 1. Couchbase Server and SDK Supported Version Matrix
Feature Server 1.8 Server 2.0 Server 2.5 Server 3.0 Server 4.0 Server 4.5

Basic Features

CRUD Operations

SDK 2.4.0

View Querying APIs

Partial support since SDK 2.4.0. Full row-based support since SDK 2.4.7

Advanced Features

Durability Requirements


Fast (CCCP) Bootstrapping

Not Supported


SSL Connectivity

Not Supported


Partial Cross-SDK Data types

Not Supported

Since 2.0

N1QL Querying

Not Supported

Since 2.5.0

Administrative Features

Administrative API

Not Supported

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.

  • Uncommitted: This level is used to indicate APIs that are unlikely to change, but may still change as final consenus 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.

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

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.