Getting Started

      UWP project

      Create or open an existing Virtual Studio project and install Couchbase Lite using the following method.


      1. Install either of the following packages from Nuget.

        Couchbase Lite Community Edition

        Install the Couchbase.Lite package.

        Couchbase Lite Enterprise Edition

        If you have a license or you are evaluating the Enterprise edition, install the Couchbase.Lite.Enterprise package.

      2. Your app must call the relevant Activate() function inside of the class that is included in the support assembly (there is only one public class in each support assembly, and the support assembly itself is a nuget dependency).

        For example, UWP looks like Couchbase.Lite.Support.UWP.Activate(). Currently the support assemblies provide dependency injected mechanisms for default directory logic, and platform specific logging (i.e., Android will log to logcat with correct log levels and tags. No more "mono-stdout" at always info level.)

      Starter code

      Open Main.cs in Visual Studio and copy the following code in the main method. This snippet demonstrates how to run basic CRUD operations, a simple Query and running bi-directional replications with Sync Gateway.

      // Get the database (and create it if it doesn't exist)
      var database = new Database("mydb");
      // Create a new document (i.e. a record) in the database
      string id = null;
      using (var mutableDoc = new MutableDocument()) {
          mutableDoc.SetFloat("version", 2.0f)
              .SetString("type", "SDK");
          // Save it to the database
          id = mutableDoc.Id;
      // Update a document
      using (var doc = database.GetDocument(id))
      using (var mutableDoc = doc.ToMutable()) {
          mutableDoc.SetString("language", "C#");
          using (var docAgain = database.GetDocument(id)) {
              Console.WriteLine($"Document ID :: {docAgain.Id}");
              Console.WriteLine($"Learning {docAgain.GetString("language")}");
      // Create a query to fetch documents of type SDK
      // i.e. SELECT * FROM database WHERE type = "SDK"
      using (var query = QueryBuilder.Select(SelectResult.All())
          .Where(Expression.Property("type").EqualTo(Expression.String("SDK")))) {
          // Run the query
          var result = query.Execute();
          Console.WriteLine($"Number of rows :: {result.Count()}");
      // Create replicator to push and pull changes to and from the cloud
      var targetEndpoint = new URLEndpoint(new Uri("ws://localhost:4984/example_sg_db"));
      var replConfig = new ReplicatorConfiguration(database, targetEndpoint);
      // Add authentication
      replConfig.Authenticator = new BasicAuthenticator("john", "pass");
      // Create replicator
      var replicator = new Replicator(replConfig);
      replicator.AddChangeListener((sender, args) =>
          if (args.Status.Error != null) {
              Console.WriteLine($"Error :: {args.Status.Error}");
      // Later, stop and dispose the replicator *before* closing/disposing the database

      Build and run. You should see the document ID and property printed to the console. The document was successfully persisted to the database.

      Supported Versions

      Couchbase Lite .NET is a .NET Standard 2.0 library. The following tables list out the supported platforms.

      Officially Supported

      Runtimes which have received more testing and are officially supported are:

      .NET Runtime Minimum Runtime Version Minimum OS version

      .NET Core Win


      10 (any supported)

      .NET Framework


      10 (any supported)




      Not Officially Supported

      The following runtimes are also compatible but have not received as much testing and are not officially supported yet, but they will be once they go through the QE process.

      .NET Runtime Minimum Runtime Version Minimum OS version

      .NET Core Mac



      .NET Core Linux



      Xamarin iOS



      Xamarin Android


      4.4 (API 19)

      * There are many different variants of Linux, and we don’t have the resources to test all of them. They are tested on Ubuntu 16.04, but have been shown to work on CentOS, and in theory work on any distro supported by .NET Core.

      Comparing this to the supported versions in 1.x you can see we’ve traded some lower obsolete versions for new platform support.

      API References


      Visual Studio

      The public facing API has completely changed in Couchbase Lite 2.0 and will require a re-write to upgrade an application that is using Couchbase Lite 1.x. To update an Xcode project built with Couchbase Lite 1.x:

      • Remove the existing Couchbase Lite nuget package from the Visual Studio project.

      • Remove all the Couchbase Lite 1.x dependencies (see the 1.x installation guide).

      • Install the Couchbase Lite 2.0 framework in your project (see the Getting Started section). At this point, there will be many compiler warnings. Refer to the examples on this page to learn about the new API.

      • Build & run your application.

      Database Upgrade

      Databases that were created with Couchbase Lite 1.2 or later can be used with Couchbase Lite 2.0. Upon detecting it is a 1.x database file, Couchbase Lite will automatically upgrade it to 2.0. This feature is only available for the default storage type (i.e., not a ForestDB database). Additionally, the automatic migration feature does not support encrypted databases, so if the 1.x database is encrypted you will first need to disable encryption using the Couchbase Lite 1.x API (see the 1.x Database Guide).

      Handling of Existing Conflicts

      For conflicts in the 1.x database, the automatic upgrade process copies the default winning revision to the new 2.0 database and does NOT copy any conflicting revisions. This functionality is related to the way conflicts are being handled in Couchbase Lite 2.0 (see Handling Conflicts). Optionally, existing conflicts in the 1.x database can be resolved with the 1.x API prior to the database being upgraded to 2.0.

      Handling of Existing Attachments

      Attachments that were persisted in the 1.x database will be copied to the 2.0 database. In Couchbase Lite 2.0, the Attachment API has been renamed to Blob API. The functionally is identical but the internal schema for attachments has changed. In 1.x they were stored under the _attachments field and in Couchbase Lite 2.0 they are stored anywhere in the document like other value types. The automatic upgrade functionality will not update the internal schema for attachments, so they will still be accessible under the _attachments field. The following example shows how to retrieve an attachment that was created in a 1.x database with the 2.0 API.

      var attachments = document.GetDictionary("_attachments");
      var avatar = attachments.GetBlob("avatar");
      var content = avatar?.Content;

      Replication Compatibility

      The replication protocol used in Couchbase Lite 2.0 has been re-designed from the ground up and it is not backwards compatible with the 1.x replication protocol. Therefore, to use replication with Couchbase Lite 2.0, the target Sync Gateway instance must also be upgraded to 2.0.

      Sync Gateway 2.0 will continue to accept clients that connect through the 1.x protocol. It will automatically use the 1.x replication protocol when a Couchbase Lite 1.x client connects through http://localhost:4984/db and the 2.0 replication protocol when a Couchbase Lite 2.0 client connects through ws://localhost:4984/db. This allows for a smoother transition to get all your user base onto a version of your application built with Couchbase Lite 2.0.


      New Database

      As the top-level entity in the API, new databases can be created using the Database class by passing in a name, configuration, or both. The following example creates a database using the Database(string name) method.

      var db = new Database("my-database");

      Just as before, the database will be created in a default location. Alternatively, the Database(string name, DatabaseConfiguration config) initializer can be used to provide specific options in the DatabaseConfiguration object such as the database directory.

      Finding a Database File

      Where a database goes by default depends on the platform it is running on. Here are the defaults for each platform:

      • .NET Core: Path.Combine(AppContext.BaseDirectory, "CouchbaseLite") (unless the app context is altered [e.g., by XUnit], this will be the same directory as the output binary)

      • UWP: Windows.Storage.ApplicationData.Current.LocalFolder.Path (Inside the installed app sandbox. Note that this sandbox gets deleted sometimes when debugging from inside Visual Studio when the app is shutdown)

      • Xamarin iOS: In a folder named CouchbaseLite inside of ApplicationSupportDirectory (this can be retrieved more easily from the simulator using the SimPholders utility)

      • Xamarin Android: Using the Context passed in the Activate() method, Context.FilesDir.AbsolutePath (database can be retrieved using adb)


      Couchbase Lite’s logging strategy provides for the redaction of sensitive information in CBL logs. This redaction requires no configuration. It will operate whenever logging is enabled — that is when LogLevel is not None.

      The log messages are split into different domains (LogDomains). Each log domain’s logging level can be set independently of any other domain’s logging level.

      For more on logging configuration, see:

      The example code snippet below sets the logging level to verbose for both the replicator, and query domains.

      Database.SetLogLevel(LogDomain.Replicator, LogLevel.Verbose);
      Database.SetLogLevel(LogDomain.Query, LogLevel.Verbose);

      Loading a pre-built database

      If your app needs to sync a lot of data initially, but that data is fairly static and won’t change much, it can be a lot more efficient to bundle a database in your application and install it on the first launch. Even if some of the content changes on the server after you create the app, the app’s first pull replication will bring the database up to date.

      To use a prebuilt database, you need to set up the database, build the database into your app bundle as a resource, and install the database during the initial launch. After your app launches, it needs to check whether the database exists. If the database does not exist, the app should copy it from the app bundle using the Database.Copy(string, DatabaseConfiguration) method as shown below.

      // Note: Getting the path to a database is platform-specific.  For .NET Core / .NET Framework this
      // can be a simple filesystem path.  For UWP, you will need to get the path from your assets.  For
      // iOS you need to get the path from the main bundle.  For Android you need to extract it from your
      // assets to a temporary directory and then pass that path.
      var path = Path.Combine(Environment.CurrentDirectory, "travel-sample.cblite2" + Path.DirectorySeparatorChar);
      if (!Database.Exists("travel-sample", null)) {
          _NeedsExtraDocs = true;
          Database.Copy(path, "travel-sample", null);


      In Couchbase Lite, a document’s body takes the form of a JSON object — a collection of key/value pairs where the values can be different types of data such as numbers, strings, arrays or even nested objects. Every document is identified by a document ID, which can be automatically generated (as a UUID) or determined by the application; the only constraints are that it must be unique within the database, and it can’t be changed.


      The following methods/initializers can be used:

      • The MutableDocument() constructor can be used to create a new document where the document ID is randomly generated by the database.

      • The MutableDocument(string documentID) constructor can be used to create a new document with a specific ID.

      • The database.GetDocument(string documentID) method can be used to get a document. If it doesn’t exist in the database, it will return null. This method can be used to check if a document with a given ID already exists in the database.

      The following code example creates a document and persists it to the database.

      using (var newTask = new MutableDocument("xyz")) {
          newTask.SetString("type", "task")
              .SetString("owner", "todo")
              .SetDate("createdAt", DateTimeOffset.UtcNow);


      By default, when a document is read from the database it is immutable. The document.toMutable() method should be used to create an instance of the document which can be updated.

      using(var document = db.GetDocument("xyz"))
      using (var mutableDocument = document.ToMutable()) {
          mutableDocument.SetString("name", "apples");

      Changes to the document are persisted to the database when the saveDocument method is called.

      Typed Accessors

      The Document class now offers a set of property accessors for various scalar types, including boolean, integers, floating-point and strings. These accessors take care of converting to/from JSON encoding, and make sure you get the type you’re expecting.

      In addition, as a convenience we offer DateTimeOffset accessors. Dates are a common data type, but JSON doesn’t natively support them, so the convention is to store them as strings in ISO-8601 format. The following example sets the date on the createdAt property and reads it back using the document.GetDate(string key) accessor method.

      newTask.SetValue("createdAt", DateTimeOffset.UtcNow);
      var date = newTask.GetDate("createdAt");

      If the property doesn’t exist in the document it will return the default value for that getter method (0 for getInt, 0.0 for getFloat etc.). To check whether a given property exists in the document, you should use the Document.Contains(string key) method.

      Batch operations

      If you’re making multiple changes to a database at once, it’s faster to group them together. The following example persists a few documents in batch.

      db.InBatch(() =>
          for (var i = 0; i < 10; i++) {
              using (var doc = new MutableDocument()) {
                  doc.SetString("type", "user");
                  doc.SetString("name", $"user {i}");
                  doc.SetBoolean("admin", false);
                  Console.WriteLine($"Saved user document {doc.GetString("name")}");

      At the local level this operation is still transactional: no other Database instances, including ones managed by the replicator can make changes during the execution of the block, and other instances will not see partial changes. But Couchbase Mobile is a distributed system, and due to the way replication works, there’s no guarantee that Sync Gateway or other devices will receive your changes all at once.

      Document Constraints

      Couchbase Lite APIs do not explicitly disallow the use of attributes with the underscore prefix at the top level of document. This is to facilitate the creation of documents for use either in local only mode where documents are not synced, or when used exclusively in peer-to-peer sync.

      "_id", :"_rev" and "_sequence" are reserved keywords and must not be used as top-level attributes — see Example 1.

      Users are cautioned that any attempt to sync such documents to Sync Gateway will result in an error. To be future proof, you are advised to avoid creating such documents. Use of these attributes for user-level data may result in undefined system behavior.

      For more guidance — see: Sync Gateway - data modeling guidelines

      Example 1. Reserved Keys List
      • _attachments

      • _id

      • _deleted

      • _removed

      • _rev


      We’ve renamed "attachments" to "blobs", for clarity. The new behavior should be clearer too: a Blob is now a normal object that can appear in a document as a property value. In other words, you just instantiate a Blob and set it as the value of a property, and then later you can get the property value, which will be a Blob object. The following code example adds a blob to the document under the avatar property.

      // Note: Reading the data is implementation dependent, as with prebuilt databases
      var image = File.ReadAllBytes("avatar.jpg");
      var blob = new Blob("image/jpeg", image);
      newTask.SetBlob("avatar", blob);

      The Blob API lets you access the contents as in-memory data (a Data object) or as a InputStream. It also supports an optional type property that by convention stores the MIME type of the contents.

      In the example above, "image/jpeg" is the MIME type and "avatar" is the key which references that Blob. That key can be used to retrieve the Blob object at a later time.

      When a document is synchronized, the Couchbase Lite replicator will add an _attachments dictionary to the document’s properties if it contains a blob. A random access name will be generated for each Blob which is different to the "avatar" key that was used in the example above. On the image below, the document now contains the _attachments dictionary when viewed in the Couchbase Server Admin Console.

      attach replicated

      A blob also has properties such as "digest" (a SHA-1 digest of the data), "length" (the length in bytes), and optionally "content_type" (the MIME type). The data is not stored in the document, but in a separate content-addressable store, indexed by the digest.

      This Blob can be retrieved on the Sync Gateway REST API at http://localhost:4984/justdoit/user.david/blob_1. Notice that the blob identifier in the URL path is "blob_1" (not "avatar").


      Database queries have changed significantly. Instead of the map/reduce views used in 1.x, they’re now based on expressions, of the form "return ____ from documents where ____, ordered by ____", with semantics based on Couchbase’s N1QL query language.

      There are several parts to specifying a query:

      • SELECT: specifies the projection, which is the part of the document that is to be returned.

      • FROM: specifies the database to query the documents from.

      • JOIN: specifies the matching criteria in which to join multiple documents.

      • WHERE: specifies the query criteria that the result must satisfy.

      • GROUP BY: specifies the query criteria to group rows by.

      • ORDER BY: specifies the query criteria to sort the rows in the result.


      Before we begin querying documents, let’s briefly mention the importance of having a query index. A query can only be fast if there’s a pre-existing database index it can search to narrow down the set of documents to examine.

      The following example creates a new index for the type and name properties.

          "_id": "hotel123",
          "type": "hotel",
          "name": "Apple Droid"
      // For value types, this is optional but provides performance enhancements
      var index = IndexBuilder.ValueIndex(
      db.CreateIndex("TypeNameIndex", index);

      If there are multiple expressions, the first one will be the primary key, the second the secondary key, etc.

      Every index has to be updated whenever a document is updated, so too many indexes can hurt performance. Thus, good performance depends on designing and creating the right indexes to go along with your queries.

      SELECT statement

      With the SELECT statement, you can query and manipulate JSON data. With projections, you retrieve just the fields that you need and not the entire document.

      A SelectResult represents a single return value of the query statement. You can specify a comma separated list of SelectResult expressions in the select statement of your query. For instance the following select statement queries for the document _id as well as the type and name properties of all documents in the database. In the query result, we print the _id and name properties of each row using the property name getter method.

          "_id": "hotel123",
          "type": "hotel",
          "name": "Apple Droid"
      using (var query = QueryBuilder.Select(
          .From(DataSource.Database(db))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Document ID :: {result.GetString("id")}");
              Console.WriteLine($"Document Name :: {result.GetString("name")}");

      The SelectResult.all() method can be used to query all the properties of a document. In this case, the document in the result is embedded in a dictionary where the key is the database name. The following snippet shows the same query using SelectResult.all() and the result in JSON.

      using (var query = QueryBuilder.Select(SelectResult.All())
          .From(DataSource.Database(db))) {
          // All user properties will be available here
              "travel-sample": {
                  "callsign": "MILE-AIR",
                  "country": "United States",
                  "iata": "Q5",
                  "icao": "MLA",
                  "id": 10,
                  "name": "40-Mile Air",
                  "type": "airline"
              "travel-sample": {
                  "callsign": "TXW",
                  "country": "United States",
                  "iata": "TQ",
                  "icao": "TXW",
                  "id": 10123,
                  "name": "Texas Wings",
                  "type": "airline"

      WHERE statement

      Similar to SQL, you can use the where clause to filter the documents to be returned as part of the query. The select statement takes in an Expression. You can chain any number of Expressions in order to implement sophisticated filtering capabilities.


      The comparison operators can be used in the WHERE statement to specify on which property to match documents. In the example below, we use the equalTo operator to query documents where the type property equals "hotel".

          "_id": "hotel123",
          "type": "hotel",
          "name": "Apple Droid"
      using (var query = QueryBuilder.Select(SelectResult.All())
          .Limit(Expression.Int(10))) {
          foreach (var result in query.Execute()) {
              var dict = result.GetDictionary(db.Name);
              Console.WriteLine($"Document Name :: {dict?.GetString("name")}");

      Collection Operators

      Collection operators are useful to check if a given value is present in an array.

      CONTAINS Operator

      The following example uses the Function.arrayContains to find documents whose public_likes array property contain a value equal to "Armani Langworth".

          "_id": "hotel123",
          "name": "Apple Droid",
          "public_likes": ["Armani Langworth", "Elfrieda Gutkowski", "Maureen Ruecker"]
      using (var query = QueryBuilder.Select(
                  Expression.String("Armani Langworth"))))) {
          foreach (var result in query.Execute()) {
              var publicLikes = result.GetArray("public_likes");
              var jsonString = JsonConvert.SerializeObject(publicLikes);
              Console.WriteLine($"Public Likes :: {jsonString}");
      IN Operator

      The IN operator is useful when you need to explicitly list out the values to test against. The following example looks for documents whose first, last or username property value equals "Armani".

      var values = new IExpression[]
          { Expression.Property("first"), Expression.Property("last"), Expression.Property("username") };
      using (var query = QueryBuilder.Select(
          .Where(Expression.String("Armani").In(values))) {
          foreach (var result in query.Execute()) {
              var body = result.GetDictionary(0);
              var jsonString = JsonConvert.SerializeObject(body);
              Console.WriteLine($"In results :: {jsonString}");

      Like Operator

      The like operator can be used for string matching. It is recommended to use the like operator for case insensitive matches and the regex operator (see below) for case sensitive matches.

      In the example below, we are looking for documents of type landmark where the name property exactly matches the string "Royal engineers museum". Note that since like does a case insensitive match, the following query will return "landmark" type documents with name matching "Royal Engineers Museum", "royal engineers museum", "ROYAL ENGINEERS MUSEUM" and so on.

      using (var query = QueryBuilder.Select(
              .And(Expression.Property("name").Like(Expression.String("Royal Engineers Museum"))))
          .Limit(Expression.Int(10))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Name Property :: {result.GetString("name")}");

      Wildcard Match

      We can use % sign within a like expression to do a wildcard match against zero or more characters. Using wildcards allows you to have some fuzziness in your search string.

      In the example below, we are looking for documents of type "landmark" where the name property matches any string that begins with "eng" followed by zero or more characters, the letter "e", followed by zero or more characters. The following query will return "landmark" type documents with name matching "Engineers", "engine", "english egg" , "England Eagle" and so on. Notice that the matches may span word boundaries.

      using (var query = QueryBuilder.Select(
          .Limit(Expression.Int(10))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Name Property :: {result.GetString("name")}");

      Wildcard Character Match

      We can use an _ sign within a like expression to do a wildcard match against a single character.

      In the example below, we are looking for documents of type "landmark" where the name property matches any string that begins with "eng" followed by exactly 4 wildcard characters and ending in the letter "r". The following query will return "landmark" type documents with the name matching "Engineer", "engineer" and so on.

      using (var query = QueryBuilder.Select(
              .And(Expression.Property("name").Like(Expression.String("Royal Eng____rs Museum"))))
          .Limit(Expression.Int(10))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Name Property :: {result.GetString("name")}");

      Regex Operator

      The regex operator can be used for case sensitive matches. Similar to wildcard like expressions, regex expressions based pattern matching allow you to have some fuzziness in your search string.

      In the example below, we are looking for documents of type "landmark" where the name property matches any string (on word boundaries) that begins with "eng" followed by exactly 4 wildcard characters and ending in the letter "r". The following query will return "landmark" type documents with name matching "Engine", "engine" and so on. Note that the \b specifies that the match must occur on word boundaries.

      using (var query = QueryBuilder.Select(
          .Limit(Expression.Int(10))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Name Property :: {result.GetString("name")}");

      JOIN statement

      The JOIN clause enables you to create new input objects by combining two or more source objects.

      The following example uses a JOIN clause to find the airline details which have routes that start from RIX. This example JOINS the document of type "route" with documents of type "airline" using the document ID (_id) on the "airline" document and airlineid on the "route" document.

      using (var query = QueryBuilder.Select(
              .And(Expression.Property("sourceairport").From("route").EqualTo(Expression.String("RIX"))))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Name Property :: {result.GetString("name")}");

      GROUP BY statement

      You can perform further processing on the data in your result set before the final projection is generated. The following example looks for the number of airports at an altitude of 300 ft or higher and groups the results by country and timezone.

          "_id": "airport123",
          "type": "airport",
          "country": "United States",
          "geo": { "alt": 456 },
          "tz": "America/Anchorage"
      using (var query = QueryBuilder.Select(
          .GroupBy(Expression.Property("country"), Expression.Property("tz"))) {
          foreach (var result in query.Execute()) {
                  $"There are {result.GetInt("$1")} airports in the {result.GetString("tz")} timezone located in {result.GetString("country")} and above 300 ft");
      There are 138 airports on the Europe/Paris timezone located in France and above 300 ft
      There are 29 airports on the Europe/London timezone located in United Kingdom and above 300 ft
      There are 50 airports on the America/Anchorage timezone located in United States and above 300 ft
      There are 279 airports on the America/Chicago timezone located in United States and above 300 ft
      There are 123 airports on the America/Denver timezone located in United States and above 300 ft

      ORDER BY statement

      It is possible to sort the results of a query based on a given expression result. The example below returns documents of type equal to "hotel" sorted in ascending order by the value of the title property.

      using (var query = QueryBuilder.Select(
          .Limit(Expression.Int(10))) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Title :: {result.GetString("title")}");

      To run a full-text search (FTS) query, you must have created a full-text index on the expression being matched. Unlike regular queries, the index is not optional. The following example inserts documents and creates an FTS index on the name property.

      var index = IndexBuilder.FullTextIndex(FullTextIndexItem.Property("name")).IgnoreAccents(false);
      db.CreateIndex("nameFTSIndex", index);

      Multiple properties to index can be specified in the IndexBuilder.FullTextIndex(params FullTextIndexItem[] items) method.

      With the index created, an FTS query on the property that is being indexed can be constructed and ran. The full-text search criteria is defined as a FullTextExpression. The left-hand side is the full-text index to use and the right-hand side is the pattern to match.

      var whereClause = FullTextExpression.Index("nameFTSIndex").Match("'buy'");
      using (var query = QueryBuilder.Select(SelectResult.Expression(Meta.ID))
          .Where(whereClause)) {
          foreach (var result in query.Execute()) {
              Console.WriteLine($"Document id {result.GetString(0)}");

      In the example above, the pattern to match is a word, the full-text search query matches all documents that contain the word "buy" in the value of the doc.name property.

      Full-text search is supported in the following languages: danish, dutch, english, finnish, french, german, hungarian, italian, norwegian, portuguese, romanian, russian, spanish, swedish and turkish.

      The pattern to match can also be in the following forms:

      • prefix queries: the query expression used to search for a term prefix is the prefix itself with a "*" character appended to it. For example:

        -- Query for all documents containing a term with the prefix "lin". This will match
        -- all documents that contain "linux", but also those that contain terms "linear",
        --"linker", "linguistic" and so on.
      • overriding the property name that is being indexed: Normally, a token or token prefix query is matched against the document property specified as the left-hand side of the match operator. This may be overridden by specifying a property name followed by a ":" character before a basic term query. There may be space between the ":" and the term to query for, but not between the property name and the ":" character. For example:

        'title:linux problems'
        -- Query the database for documents for which the term "linux" appears in
        -- the document title, and the term "problems" appears in either the title
        -- or body of the document.
      • phrase queries: a phrase query is a query that retrieves all documents that contain a nominated set of terms or term prefixes in a specified order with no intervening tokens. Phrase queries are specified by enclosing a space separated sequence of terms or term prefixes in double quotes ("). For example:

        "'"linux applications"'"
        -- Query for all documents that contain the phrase "linux applications".
      • NEAR queries: A NEAR query is a query that returns documents that contain a two or more nominated terms or phrases within a specified proximity of each other (by default with 10 or less intervening terms). A NEAR query is specified by putting the keyword "NEAR" between two phrase, token or token prefix queries. To specify a proximity other than the default, an operator of the form "NEAR/" may be used, where is the maximum number of intervening terms allowed. For example:

        "'database NEAR/2 "replication"'"
        -- Search for a document that contains the phrase "replication" and the term
        -- "database" with not more than 2 terms separating the two.
      • AND, OR & NOT query operators: The enhanced query syntax supports the AND, OR and NOT binary set operators. Each of the two operands to an operator may be a basic FTS query, or the result of another AND, OR or NOT set operation. Operators must be entered using capital letters. Otherwise, they are interpreted as basic term queries instead of set operators. For example:

        'couchbase AND database'
        -- Return the set of documents that contain the term "couchbase", and the
        -- term "database". This query will return the document with docid 3 only.

        When using the enhanced query syntax, parenthesis may be used to specify the precedence of the various operators. For example:

        '("couchbase database" OR "sqlite library") AND linux'
        -- Query for the set of documents that contains the term "linux", and at least
        -- one of the phrases "couchbase database" and "sqlite library".

      Ordering results

      It’s very common to sort full-text results in descending order of relevance. This can be a very difficult heuristic to define, but Couchbase Lite comes with a fairly simple ranking function you can use. In the OrderBy array, use a string of the form Rank(X), where X is the property or expression being searched, to represent the ranking of the result.


      Couchbase Mobile 2.0 uses a new replication protocol based on WebSockets. This protocol has been designed to be fast, efficient, easier to implement, and symmetrical between the client and server.


      The new protocol is incompatible with CouchDB-based databases. And since Couchbase Lite 2 only supports the new protocol, you will need to run a version of Sync Gateway that supports it.

      To use this protocol with Couchbase Lite 2.0, the replication URL should specify WebSockets as the URL scheme (see the "Starting a Replication" section below). Mobile clients using Couchbase Lite 1.x can continue to use http as the URL scheme. Sync Gateway 2.0 will automatically use the 1.x replication protocol when a Couchbase Lite 1.x client connects through http://localhost:4984/db and the 2.0 replication protocol when a Couchbase Lite 2.0 client connects through ws://localhost:4984/db.

      Starting Sync Gateway

      Download Sync Gateway and start it from the command line with the configuration file created above.

      powershell & 'C:\Program Files (x86)\Couchbase\sync_gateway.exe' sync-gateway-config.json
      bash ~/Downloads/couchbase-sync-gateway/bin/sync_gateway

      For platform specific installation instructions, refer to the Sync Gateway installation guide.

      Starting a Replication

      Replication objects are now bidirectional, this means you can start a push/pull replication with a single instance. The replication’s parameters can be specified through the ReplicatorConfiguration object; for example, if you wish to start a push only or pull only replication.

      The following example creates a pull replication with Sync Gateway.

      public class MyClass
          public Database Database { get; set; }
          public Replicator Replicator { get; set; } (1)
          public void StartReplication()
              var url = new Uri("ws://localhost:4984/db"); (2)
              var target = new URLEndpoint(url);
              var config = new ReplicatorConfiguration(Database, target)
                  ReplicatorType = ReplicatorType.Pull
              Replicator = new Replicator(config);
      1 A replication is an asynchronous operation. To keep a reference to the replicator object, you can set it as an instance property.
      2 The URL scheme for remote database URLs has changed in Couchbase Lite 2.0. You should now use ws:, or wss: for SSL/TLS connections.

      To verify that documents have been replicated, you can:

      • Monitor the Sync Gateway sequence number returned by the database endpoint (GET /{db}/). The sequence number increments for every change that happens on the Sync Gateway database.

      • Query a document by ID on the Sync Gateway REST API (GET /{db}/{id}).

      • Query a document from the Query Workbench on the Couchbase Server Console.

      Couchbase Lite 2.0 uses WebSockets as the communication protocol to transmit data. Some load balancers are not configured for WebSocket connections by default (NGINX for example); so it might be necessary to explicitly enable them in the load balancer’s configuration (see Load Balancers).

      By default, the WebSocket protocol uses compression to optimize over speed and bandwidth. The level of compression is set on Sync Gateway and can be tuned in the configuration file (replicator_compression).

      Replication Ordering

      To optimize for speed, the replication protocol doesn’t guarantee that documents will be received in a particular order. So we don’t recommend to rely on that when using the replication or database change listeners for example.


      As always, when there is a problem with replication, logging is your friend. The following example increases the log output for activity related to replication with Sync Gateway.

      Database.SetLogLevel(LogDomain.Replicator, LogLevel.Verbose);
      Database.SetLogLevel(LogDomain.Network, LogLevel.Verbose);

      Replication Status

      The replication.Status.Activity property can be used to check the status of a replication. For example, when the replication is actively transferring data and when it has stopped.

      replicator.AddChangeListener((sender, args) =>
          if (args.Status.Activity == ReplicatorActivityLevel.Stopped) {
              Console.WriteLine("Replication stopped");

      The following table lists the different activity levels in the API and the meaning of each one.

      State Meaning


      The replication is finished or hit a fatal error.


      The replicator is offline as the remote host is unreachable.


      The replicator is connecting to the remote host.


      The replication caught up with all the changes available from the server. The IDLE state is only used in continuous replications.


      The replication is actively transferring data.

      Handling Network Errors

      If an error occurs, the replication status will be updated with an Error which follows the standard HTTP error codes. The following example monitors the replication for errors and logs the error code to the console.

      replicator.AddChangeListener((sender, args) =>
          if (args.Status.Error != null) {
              Console.WriteLine($"Error :: {args.Status.Error}");

      When a permanent error occurs (i.e., 404: not found, 401: unauthorized), the replicator (continuous or one-shot) will stop permanently. If the error is temporary (i.e., waiting for the network to recover), a continuous replication will retry to connect indefinitely and if the replication is one-shot it will retry for a limited number of times. The following error codes are considered temporary by the Couchbase Lite replicator and thus will trigger a connection retry.

      • 408: Request Timeout

      • 429: Too Many Requests

      • 500: Internal Server Error

      • 502: Bad Gateway

      • 503: Service Unavailable

      • 504: Gateway Timeout

      • 1001: DNS resolution error

      Custom Headers

      Custom headers can be set on the configuration object. And the replicator will send those header(s) in every request. As an example, this feature can be useful to pass additional credentials when there is an authentication or authorization step being done by a proxy server (between Couchbase Lite and Sync Gateway).

      var config = new ReplicatorConfiguration(database, target)
      		Headers = new Dictionary<string, string>
      				["CustomHeaderName"] = "Value"

      Handling Conflicts

      In Couchbase Lite 2.0, document conflicts are automatically resolved. This functionality aims to simplify the default behavior of conflict handling and save disk space (conflicting revisions will no longer be stored in the database). There are 2 different save method signatures to specify how to handle a possible conflict:

      • save(document: MutableDocument): when concurrent writes to an individual record occur, the conflict is automatically resolved and only one non-conflicting document update is stored in the database. The Last-Write-Win (LWW) algorithm is used to pick the winning revision.

      • save(document: MutableDocument, concurrencyControl: ConcurrencyControl): attempts to save the document with a concurrency control. The concurrency control parameter has two possible values:

        • lastWriteWins: The last operation wins if there is a conflict.

        • failOnConflict: The operation will fail if there is a conflict.

      Similarly to the save operation, the delete operation also has two method signatures to specify how to handle a possible conflict:

      • delete(document: Document): The last write will win if there is a conflict.

      • delete(document: Document, concurrencyControl: ConcurrencyControl): attemps to delete the document with a concurrency control. The concurrency control parameter has two possible values:

        • lastWriteWins: The last operation wins if there is a conflict.

        • failOnConflict: The operation will fail if there is a conflict.

      Database Replicas

      Database replicas is available in the Enterprise Edition only (https://www.couchbase.com/downloads). Starting in Couchbase Lite 2.0, replication between two local databases is now supported. It allows a Couchbase Lite replicator to store data on secondary storage. It would be especially useful in scenarios where a user’s device is damaged and the data needs to be moved to a different device.

      Certificate Pinning

      Couchbase Lite supports certificate pinning. Certificate pinning is a technique that can be used by applications to "pin" a host to it’s certificate. The certificate is typically delivered to the client by an out-of-band channel and bundled with the client. In this case, Couchbase Lite uses this embedded certificate to verify the trustworthiness of the server and no longer needs to rely on a trusted third party for that (commonly referred to as the Certificate Authority).

      The openssl command can be used to create a new self-signed certificate and convert the .pem file to a .cert file (see creating your own self-signed certificate). You should then have 3 files: cert.pem, cert.cer and key.pem.

      The cert.pem and key.pem can be used in the Sync Gateway configuration (see installing the certificate).

      On the Couchbase Lite side, the replication must be configured with the cert.cer file.

      var certificate = new X509Certificate2("cert.cer");
      var config = new ReplicatorConfiguration(db, target)
          PinnedServerCertificate = certificate

      This example loads the certificate from the application sandbox, then converts it to the appropriate type to configure the replication object.

      Thread Safety

      The Couchbase Lite API is thread safe except for calls to mutable objects: MutableDocument, MutableDictionary and MutableArray.

      Release Notes



      New Feature — Log redaction

      This release adds out-of-the-box support for the redaction of sensitive information in Couchbase Lite logs. The redaction requires no configuration. It will operate whenever logging is enabled.

      For more on adjusting the logging-levels see Logging


      • #647 Equivalent to full text search

      • #964 AddLoggerProvider

      • #884 Replication with DNS endpoint failing on (at least) Mac

      • #894 Crash on iOS Simulator 9.x on Query.Run() execution

      • #957 SG doesn’t have any docs in its cache after replication

      • #966 Incorrect callback type(?) leads to AOT compilation failure for Xamarin

      • #994 2.0db023 SetBinaryLogDirectory(string) path ignored, still written to AppContext.BaseDirectory

      Known Issues
      • #1002 System proxy is not being used for replication

      • #1012 Reusing the same collation in a query will cause all of them to be affected by the last modification