Watch keynotes and sessions from MongoDB.live, our virtual developer conference.

Couch DB queries to MongoDB queries - Adapter / Parser

Hi all, thanks for your time.
I wanted to know if there is some adapter that exists that parses Couch DB queries into MongoDB queries. Any suggestions are welcome. Thanks.

Welcome to the community @Sreeramji_K_S!

I’m not aware of a solution for transforming CouchDB queries into MongoDB Query Language, but if you are migrating an application it would be best to take advantage of MongoDB’s native query language so you do not have the overhead of transformation or risk of subtle bugs due to differences in query syntax.

The JSON Mango Query language added in the CouchDB 2.0 release was inspired by the MongoDB query language, so there are a lot of similarities and it should be straightforward to migrate.

There are additional MongoDB Query and Projection Operators you may want to take advantage of as well as the Aggregation Framework for more complex queries and transformations.

Regards,
Stennie

1 Like

Thanks a lot @Stennie. That was helpful. I am actually trying to move from Couch to Cosmos for my application. But the constraint is that I can’t change the code.

Hi @Sreeramji_K_S,

Migrating to Cosmos will introduce some further challenges, since Cosmos is an emulation of MongoDB with a distinct server implementation and features.

If your goal is to move your application between environments without changing any code, I would look for a compatible hosted solution for your existing database backend.

What challenges are you trying to solve for your CouchDB implementation?

Regards,
Stennie

1 Like

Thanks @Stennie . I agree with your point. But I currently have these constraints:

  1. I have to use Cosmos DB.
  2. Code has a lot of dependency with Couch, so modification of code is not possible. That was the sole reason for me to consider writing a parser to convert the Couch DB queries arising from the code into MongoDB queries.
    Looking at the available APIs in Cosmos, Mongo seemed the one most relatable. (Open for suggestions).

If possible, can you please elaborate on the “further challenges” that can come up?

Regards
Sreeramji

Hi Sreeramji,

You will effectively be using three APIs (CouchDB, MongoDB, and Cosmos DB) with varying behaviours and limits. You can perhaps translate to lowest common denominator, but your legacy application is only expecting CouchDB and you may have to invest significant effort into creating a translation layer.

For example, querying and indexing will not be identical across all three and some error codes, request handling, and limits will be specific to one of the APIs involved. Cosmos DB provisions and limits resources based on Request Units (RUs), which is a request handling concept you do not have to consider in either CouchDB or MongoDB. Cosmos DB currently has a 2MB document size limit (versus 16MB in MongoDB and 8MB by default in CouchDB 3.0).

You’ll have to decide what makes sense for your use case and constraints, but this approach sounds like a lot of effort compared to using a hosted version of CouchDB on Azure or doing a proper rewrite to support a different database backend.

Regards,
Stennie