{"id":8478,"date":"2020-04-25T12:51:59","date_gmt":"2020-04-25T19:51:59","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=8478"},"modified":"2025-06-13T23:42:43","modified_gmt":"2025-06-14T06:42:43","slug":"introduction-to-couchbase-for-mongodb-developers-and-experts","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/introduction-to-couchbase-for-mongodb-developers-and-experts\/","title":{"rendered":"Couchbase Intro for MongoDB Developers and NoSQL Experts"},"content":{"rendered":"
\n

Six thousand years ago, the Sumerians invented writing for transaction processing — Gray & Reuter<\/a><\/h4>\n<\/blockquote>\n

By any measure, MongoDB is a popular document-oriented JSON database. In the last dozen years, it has grown from its humble beginnings of a single lock per database to a modern multi-document transaction with snapshot isolation.\u00a0 MongoDB University has trained a large number of developers to develop on the MongoDB database.<\/span><\/p>\n

There are many JSON databases now. While it\u2019s easy to start with MongoDB to learn NoSQL and flexible JSON schema, many customers choose Couchbase for performance, scale, and SQL. <\/span>As you progress in your database evaluation and evolution, you should learn about other JSON databases. We\u2019re working on an online training course for MongoDB experts to learn Couchbase easily.\u00a0 Until we publish that, you\u2019ll have to read this article. :-)\u00a0 <\/span><\/p>\n

If you know RDBMS like Microsoft SQL Server and Oracle, we have easy to follow courses to learn do the mapping of your database knowledge to Couchbase with these two courses:<\/span><\/p>\n

    \n
  1. CB116m – Intro to Couchbase for MSSQL Experts<\/span><\/a><\/li>\n
  2. CB116o – Introduction to Couchbase for Oracle Experts<\/span><\/a><\/li>\n<\/ol>\n

    SUMMARY<\/strong><\/p>\n

    MongoDB and Couchbase have many things in common. Both are NoSQL distributed databases<\/a>; Both use JSON model; Both have high-level query languages with support for select-join-project operations; Both have secondary indexes; both have an optimizer that chooses the query plan automatically. Both support intra- and inter-cluster replication.<\/p>\n

    As you’d expect, there are differences.\u00a0 Some are more significant than others.\u00a0 Couchbase is designed to be distributed from the get-go.\u00a0 For example, the data container Bucket is always distributed — with nothing to shard.\u00a0 Simply add new nodes and the system will automatically distribute. Intra cluster replication requires no new servers — simply set the number of replicas and you’re all set. From the developer interaction perspective, the big difference is the query language itself — MongoDB has a proprietary query language<\/a> and Couchbase has N1QL – SQL for JSON<\/a>. MongoDB uses its B-Tree based index for search as well and recently released $searchbeta<\/a> for the Atlas service using Apache Lucene; Couchbase has a built-in Full-Text Search<\/a>.<\/p>\n

    Hopefully, the differences in Couchbase are the ones that make your life easier.\u00a0 Let’s deep dive.<\/p>\n

    HIGH-LEVEL TOPICS<\/b><\/span><\/p>\n

      \n
    1. Resources<\/li>\n
    2. Architecture<\/span><\/li>\n
    3. Database Objects<\/span><\/li>\n
    4. Data Types<\/span><\/li>\n
    5. Data Model<\/span><\/li>\n
    6. SDK<\/span><\/li>\n
    7. Query Language<\/span><\/li>\n
    8. Indexes<\/span><\/li>\n
    9. Optimizer<\/span><\/li>\n
    10. Transactions<\/span><\/li>\n
    11. Analytics<\/li>\n<\/ol>\n

      RESOURCES<\/strong><\/span><\/h4>\n
      \n\n\n\n\n\n\n\n\n
      <\/td>\n\n

      MongoDB<\/strong><\/h4>\n<\/td>\n

      		\n

      Couchbase<\/strong><\/h4>\n<\/td>\n<\/tr>\n

      \n

      Docs<\/p>\n<\/td>\n

      		\n

      https:\/\/docs.mongodb.com\/<\/a><\/p>\n<\/td>\n

      		\n

      https:\/\/docs.couchbase.com\/home\/index.html<\/a><\/p>\n<\/td>\n<\/tr>\n

      \n

      Forums<\/p>\n<\/td>\n

      		\n

      https:\/\/developer.mongodb.com\/community\/forums\/<\/a><\/p>\n<\/td>\n

      		\n

      https:\/\/www.couchbase.com\/forums\/<\/a><\/p>\n<\/td>\n<\/tr>\n

      \n

      Latest Version (April 2020)<\/span><\/p>\n<\/td>\n

      		\n

      4.2.6<\/p>\n<\/td>\n

      		\n

      6.5.1<\/p>\n<\/td>\n<\/tr>\n

      \n

      License<\/p>\n<\/td>\n

      		\n

      https:\/\/www.mongodb.com\/licensing\/server-side-public-license\/faq<\/a><\/p>\n<\/td>\n

      		\n

      https:\/\/www.couchbase.com\/licensing-and-support-faq<\/a><\/p>\n<\/td>\n<\/tr>\n

      \n

      Query Language<\/p>\n<\/td>\n

      		\n

      MongoDB query language<\/a><\/p>\n<\/td>\n

      		\n

      N1QL – SQL for JSON<\/a><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

      ARCHITECTURE<\/strong><\/span><\/h4>\n

      Laptop Version:\u00a0<\/strong><\/p>\n

      \"\"<\/a><\/p>\n

      MongoDB:<\/strong> \u00a0Simply install and use the Mongodb on your laptop with the right parameters; you\u2019re up and running.\u00a0 Single process to deal with the whole database.\u00a0 This has changed a little bit in 4.2 where you\u2019d need mongos to run your transactions. All of the MongoDB features (data, indexing, query) are available here — except full text search available only on the Atlas service.<\/p>\n

       <\/p>\n

       <\/p>\n

       <\/p>\n

       <\/p>\n

      \"\"<\/a>Couchbase: <\/b>Couchbase is different.\u00a0 It has abstracted each of the services (data, index, query, search, analytics, eventing) and you have the option to choose which of the features you\u2019d want to run on your instance to optimize the resources. A typical installation has data, index, and query.\u00a0 Search, eventing, and analytics will run on your laptop — install and use them per your use case.<\/span><\/p>\n

       <\/p>\n

       <\/p>\n

       <\/p>\n

      Cluster deployment: <\/b>As with most NoSQL databases, both MongoDB and Couchbase can scale out. In MongoDB, you can scale by <\/span>sharding<\/span><\/a> the collection into multiple nodes. You can shard by hash or range.\u00a0 Without an explicit shard, each collection remains in a single shard.\u00a0 The config servers store the metadata and configuration for the cluster. MongoDB is uniformly distributed and Couchbase is multi-dimensionally distributed.\u00a0 Mongodb process (service) manages data, index and query on every shard (node) whereas Mongos does the distributed query processing and merging from intermediate results and does not manage any data or index.\u00a0 Mongos acts as the coordinator and mongodb is the worker bee.\u00a0<\/span><\/p>\n

      \"\"<\/a><\/p>\n

      Couchbase can be deployed in a uniform distribution with each node managing the data and all services – data, index, query, analytics, and eventing.\u00a0 Each service is a layer in the traditional database. These services are loosely coupled — they run in different process spaces and communicate via a network.\u00a0 Hence they can be deployed uniformly in a single node or distributed multi-dimensionally on a cluster. The choice depends on your workload and SLAs. The data itself is stored in buckets. All the buckets are hash partitioned among given nodes — this is automatic and doesn\u2019t require any specification. When the application has the document keys, it can directly operate on the data without any intervening nodes.\u00a0 This is one of the key architectural differences contributing to the high performance and scale-out of Couchbase. \u00a0 In addition, there are no config servers. The metadata and its management is built into the core database. \u00a0 The data service manages data, cluster and replication within a Couchbase cluster. Replication between multiple Couchbase clusters is managed by XDCR.\u00a0 Read this article to understand the replication mechanisms in MongoDB and Couchbase:\u00a0 Replication in NoSQL document databases (Mongo DB vs Couchbase)<\/a><\/span><\/p>\n

      \"\"<\/a><\/p>\n

      Inside the cluster deployment.<\/b><\/p>\n

      MongoDB\u2019s cluster components and deployment are explained <\/span>here<\/span><\/a> and I assume that as prior knowledge.\u00a0 I\u2019ll avoid repeating.<\/span>
      \n<\/a><\/p>\n

      Couchbase deployment starts with the key-value data service.\u00a0 This is the (consistent) hash distributed key-value data store. This also has intracluster replication built-in eliminating any need for separate replica servers or config servers.\u00a0 The query service orchestrates the execution of <\/span>N1QL<\/span><\/a> queries. Uses <\/span>GSI<\/span><\/a> (Global Secondary Indexing), <\/span>FTS<\/span><\/a> (Full-Text Search) indexes as needed.\u00a0 FTS manages the full-text index and can be queried <\/span>directly<\/span><\/a> or via the N1QL <\/span>query service<\/span><\/a>.\u00a0 <\/span>The Eventing function<\/span><\/a> enables you to automatically trigger action (by executing a Javascript function) upon data mutation.\u00a0 The Couchbase <\/span>Analytics engine<\/span><\/a> is an MPP data and query engine.\u00a0 Makes a copy of the data and redistributes it into its nodes, executes the query in parallel for the best performance possible. All of these can be seamlessly used by the rich set of APIs available in our <\/span>SDKs<\/span><\/a> available in all the popular languages.\u00a0<\/span><\/p>\n

      \"\"<\/a><\/p>\n

      DATABASE OBJECTS<\/strong><\/span>
      \n<\/a><\/h4>\n

      MongoDB has a collection and database as the logical objects users have to work with. Couchbase traditionally had just the <\/span>Buckets<\/span><\/a>. Bucket worked both for resource management\u00a0 (e.g. amount of memory used), security as well as the data container. In 6.5, we introduced the notion of <\/span>collection and scope<\/span><\/a> as a developer preview.\u00a0 This bucket:scope:collection hierarchy is analogous to RDBMS\u2019s database:schema:table.\u00a0 This makes the database more secure and a better multi-tenant.\u00a0 In 6.5, without the developer preview, each bucket uses a default scope and collection, making the transition seamless.<\/span><\/p>\n

      \"\"<\/a><\/p>\n

      \n\n\n\n\n\n\n\n\n
      \n

      RDBMS<\/strong><\/p>\n<\/td>\n

      		\n

      MongoDB<\/strong><\/p>\n<\/td>\n

      		\n

      Couchbase<\/strong><\/p>\n<\/td>\n<\/tr>\n

      \n

      Database<\/p>\n<\/td>\n

      		\n

      Database<\/p>\n<\/td>\n

      		\n

      Bucket<\/p>\n<\/td>\n<\/tr>\n

      \n

      Table<\/p>\n<\/td>\n

      		\n

      Collection<\/p>\n<\/td>\n

      		\n

      Bucket<\/p>\n

      Future: Collection<\/p>\n<\/td>\n<\/tr>\n

      \n

      Row<\/p>\n<\/td>\n

      		\n

      Document (BSON)<\/p>\n<\/td>\n

      		\n

      Document (standard JSON)<\/p>\n<\/td>\n<\/tr>\n

      \n

      Column<\/p>\n<\/td>\n

      		\n

      Field\/Attribute<\/p>\n<\/td>\n

      		\n

      Field\/Attribute<\/p>\n<\/td>\n<\/tr>\n

      \n

      Partition (Table\/collection\/bucket)<\/p>\n<\/td>\n

      		\n

      Not partitioned by default.<\/p>\n

      Hash & range partitioning (sharding) is supported manually.<\/p>\n<\/td>\n

      		\n

      Partition (hash automatic)<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

      Notes to Developers<\/strong><\/h4>\n

      In MongoDB, you start with your instance (deployment) and create databases, collections and indexes.<\/p>\n

      In Couchbase, you start with your instance and create your buckets and indexes. Each bucket can have multiple types of documents, so each document should have an application designated field for recognizing its type. {“type”: “parts”}. Since each bucket can have any number of types of documents, you should avoid creating too many buckets. This also means, when you create an index you’ll be interested in creating an index for each type: customer, parts, orders, etc.\u00a0 So, the index creation will include a WHERE clause for the document type.<\/p>\n

      CREATE INDEX ix_customer_zip\u00a0 ON customer(zip) WHERE type = “customer”;<\/p>\n

      SELECT * FROM customer WHERE zip = 94040 AND type = “customer”<\/p>\n

      Each MongoDB document contains an explicitly provided or implicitly generated document id field _id.<\/p>\n

      In Couchbase, the users should generate and insert an immutable document key for each document.\u00a0 When inserting via N1QL, you can use the UUID() function to generate one for you.\u00a0 But, it’s a good practice to have a regular structure for the document key<\/a>.<\/p>\n

      DATA TYPES<\/strong><\/span><\/h4>\n

      MongoDB\u2019s data model is <\/span>BSON<\/span><\/a> and Couchbase data model is <\/span>JSON<\/span><\/a>. The proprietary BSON type has some types, not in JSON. \u00a0 JSON has a string, numeric, boolean (true\/false), array, object types.\u00a0 BSON has a string, numeric, boolean, array, object, binary, UTC DateTime, timestamp, and many other custom proprietary extensions,\u00a0 The most common difference is the DateTime and timestamp.\u00a0 In Couchbase, all time-related data is stored as string in ISO 8601 format.\u00a0 Couchbase N1QL has a plethora of functions to extract, convert, and calculate on the time.\u00a0 Full function details are<\/span> available in this article<\/span><\/a>.\u00a0<\/span><\/p>\n

      \n\n\n\n\n\n\n\n\n\n\n\n\n
      \n

      Data Type<\/strong><\/p>\n<\/td>\n

      		\n

      MongoDB<\/strong><\/p>\n<\/td>\n

      		\n

      Couchbase<\/strong><\/p>\n<\/td>\n

      		\n

      JSON<\/strong><\/p>\n<\/td>\n<\/tr>\n

      \n

      Numbers<\/p>\n<\/td>\n

      		\n

      BSON Number<\/p>\n<\/td>\n

      		\n

      JSON Number<\/p>\n<\/td>\n

      		\n

      { “id”: 5, “balance”:2942.59 }<\/p>\n<\/td>\n<\/tr>\n

      \n

      String<\/p>\n<\/td>\n

      		\n

      BSON String<\/p>\n<\/td>\n

      		\n

      JSON String<\/p>\n<\/td>\n

      		\n

      { “name”: “Joe”,”city”: “Morrisville” }<\/p>\n<\/td>\n<\/tr>\n

      \n

      boolean<\/p>\n<\/td>\n

      		\n

      BSON Boolean<\/p>\n<\/td>\n

      		\n

      JSON Boolean<\/p>\n<\/td>\n

      		\n

      { “premium”: true, \u201dpending”: false}<\/p>\n<\/td>\n<\/tr>\n

      \n

      datetime<\/p>\n<\/td>\n

      		\n

      Custom Data format<\/p>\n<\/td>\n

      		\n

      JSON ISO 8901 String with extract, convert and arithmetic functions<\/p>\n<\/td>\n

      		\n

      { \u201csoldate\u201d: “2017-10-12T13:47:41.068-07:00” }<\/p>\n

      MongoDB:<\/p>\n

      { \u201csoldate\u201d: ISODate(“2012-12-19T06:01:17.171Z”)}<\/p>\n<\/td>\n<\/tr>\n

      \n

      spatial data<\/p>\n<\/td>\n

      		\n

      GeoJSON<\/p>\n<\/td>\n

      		\n

      Supports nearest neighbor and spatial distance.<\/p>\n<\/td>\n

      		\n

      “geometry”: {“type”: “Point”, “coordinates”: [-104.99404, 39.75621]}<\/p>\n<\/td>\n<\/tr>\n

      \n

      MISSING<\/p>\n<\/td>\n

      		\n

      Unsupported<\/p>\n<\/td>\n

      		\n

      MISSING<\/p>\n<\/td>\n

      		<\/td>\n<\/tr>\n
      \n

      NULL<\/p>\n<\/td>\n

      		\n

      JSON Null<\/p>\n<\/td>\n

      		\n

      JSON null<\/p>\n<\/td>\n

      		\n

      { “last_address”: null }<\/p>\n<\/td>\n<\/tr>\n

      \n

      Objects<\/p>\n<\/td>\n

      		\n

      Flexible JSON Objects<\/p>\n<\/td>\n

      		\n

      Flexible JSON Objects<\/p>\n<\/td>\n

      		\n

      { “address”:\u00a0 {“street”: “1, Main street”, “city”: Morrisville, “zip”:”94824″}}<\/p>\n<\/td>\n<\/tr>\n

      \n

      Arrays<\/p>\n<\/td>\n

      		\n

      Flexible JSON Arrays<\/p>\n<\/td>\n

      		\n

      Flexible JSON Arrays<\/p>\n<\/td>\n

      		\n

      { “hobbies”: [“tennis”, “skiing”, “lego”]}<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

      ALL ABOUT MISSING<\/b><\/p>\n

      MISSING is the value of a field absent in the JSON document or literal.<\/span><\/p>\n

      {\u201cname\u201d:\u201djoe\u201d}\u00a0 Everything but the field \u201cname\u201d is missing from the document.\u00a0 You can also set the value of a field to MISSING to make the field disappear. Traditional relational databases use <\/span>three valued logic<\/span><\/a> with true, false, and NULL.\u00a0 With the addition of MISSING, N1QL<\/span> uses 4-value logic<\/span><\/a>.\u00a0<\/span><\/p>\n

      You have the following expressions with MISSING.\u00a0\u00a0<\/span><\/p>\n

      \n\n\n\n\n\n\n
      \n

      IS MISSING<\/p>\n<\/td>\n

      		\n

      Returns true if the document does not have a status field<\/p>\n

      FROM CUSTOMER WHERE status is MISSING;<\/p>\n<\/td>\n<\/tr>\n

      \n

      IS NOT MISSING<\/p>\n<\/td>\n

      		\n

      Returns true if the document has a status field<\/p>\n

      FROM CUSTOMER WHERE status is NOT MISSING;<\/p>\n<\/td>\n<\/tr>\n

      \n

      MISSING AND NULL<\/p>\n<\/td>\n

      		\n

      MISSING is a known missing quantity<\/p>\n

      null is a known UNKNOWN. You can check for null value similar to MISSING with IS NULL or IS NOT NULL expression.<\/p>\n

      Valid JSON: \u00a0{\u201cstatus\u201d: null}<\/p>\n<\/td>\n<\/tr>\n

      \n

      MISSING value<\/p>\n<\/td>\n

      		\n

      Simply make the field of any type to disappear by setting it to MISSING<\/p>\n

      UPDATE CUSTOMER SET status = MISSING WHERE cxid = \u201cxyz232\u201d<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

      DATA MODELING<\/b><\/span><\/h4>\n\n\n\n\n\n\n
      Relationship<\/b><\/td>\nMongoDB<\/b><\/td>\nCouchbase\u00a0<\/b><\/td>\n<\/tr>\n
      1:1<\/span><\/td>\n\n
        \n
      • Embedded Object (implicit)<\/span><\/li>\n
      • Document Key Reference<\/span><\/li>\n<\/ul>\n<\/td>\n
      		\n
        \n
      • Embedded Object (implicit)<\/span><\/li>\n
      • Document Key Reference<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
      1:N<\/span><\/td>\n\n
        \n
      • Embedded Array of Objects<\/span><\/li>\n
      • Document key Reference<\/span><\/li>\n
      • Query with $lookup operator<\/span><\/li>\n<\/ul>\n<\/td>\n
      		\n
        \n
      • Embedded Array of Objects<\/span><\/li>\n
      • Document key Reference<\/span><\/li>\n
      • Query with INNER, LEFT OUTER, RIGHT OUTER, NEST, UNNEST\u00a0 joins<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
      N:M<\/span><\/td>\n\n
        \n
      • Embedded Array of Objects<\/span><\/li>\n
      • Arrays of objects with references<\/span><\/li>\n
      • Difficult to query with $lookup operator<\/span><\/li>\n<\/ul>\n<\/td>\n
      		\n