Note: this blog post is a revist of Matthew Revell’s Moving from MongoDB to Couchbase Server
This is a developer-focused guide to moving your application’s data store from MongoDB to Couchbase Server. If you’re interested in migrating from a relational database to Couchbase, start with Laurent’s guide to making the move from PostgreSQL, and I will be working on a SQL Server migration post in the future.
While this guide doesn’t cover every corner-case, it does offer pointers to what you should consider when planning your migration. If you’re interested in learning about why you would do this migration, or learning about a Couchbase customer that has done this migration, check out Viber.
If you currently use MongoDB, and you’re using Mongoose ODM with Node, here is a video from the Connect 2016 conference on Migrating from MongoDB with Ottoman.js.
Versions
This guide is written for Couchbase Server 4.5 and MongoDB 3.4.. Note: if you’re interested in using Couchbase as a plain key-value store, read my blog post on Using Couchbase to Store Non-JSON Data.
Differences between BSON and JSON
It’s likely that your application stores JSON-style documents in MongoDB, so we’ll start there.
MongoDB stores data in the BSON format, which is a binary JSON-like format. The key difference when migrating is that BSON records additional type information.
When you export data from MongoDB using a tool such as mongoexport, the tool will produce JSON that preserves that type information in a format called Extended JSON.
Let’s take a look at an example in Extended JSON:
As you can see, the Extended JSON is still valid JSON. That means you can store, index, query and retrieve it using Couchbase Server. However, you’ll need to maintain that additional type information (in the above example, Extended JSON is storing a long integer as a string, for instance) in the application layer.
Alternatively, you could convert the Extended JSON to standard JSON before (or after) you import it into Couchbase Server. With N1QL queries, this should be relatively straightforward, though potentially tedious. Here’s an example that converts the “myInt” field above to a standard JSON number field:
Which would result in:, you might think this doesn’t concern you, and is an ops issue. However, it does mean that it’s easier to rely on Couchbase Server should usage of your software grow.
Replication and consistency
Couchbase Server maintains a single active copy of each document and then up to three is favoring unsuitable as namespaces. Instead they serve as a way to share configuration and modeling
Couchbase Server offers N1QL. N1QL is a SQL-like language and is quite different from querying in MongoDB.
Let’s look at an example where we return the name of employees from the Mountain View office who have worked there for two years or more, ordered by start date:
N1QL should be very familiar to you.
Concurrency
In Couchbase Server, locking always happens at the document level and there are two types:
- Pessimistic: no other actor can write to that document until it is released or a timeout is hit
- Optimistic: use CAS (check-and-set) values to check if the document has changed since you last touched it and the act accordingly.
Optimistic locking can be more efficient, but pessimistic locking may be necessary sometimes., Kafka, Talend, Elasticsearch, and ODBC/JDBC, Linq2Couchbase for .NET, and there’s a NodeJS ODM called Ottoman. If you currently use Mongoose for MongoDB, watch this video on Migrating from MongoDB with Ottoman.js.
Conclusion
Moving from one document store to another is relatively straightforward, as the broad shape of your data doesn’t need to change all that much (as opposed to a relational migration). the Couchbase forums.
If you have any questions, comments, or if you find anything inaccurate, please leave a comment or reach out to me on Twitter.