This is a very generic and high level set of queries related NoSQL type of datastores

Imagine I have two different applications using NoSQL datastores each hosting its own document collection.


  1. What are the design considerations I should be aware of in case I wanted to merge these two applications together?

  2. How can I redesign the datastore so that I can support both the applications from a single unified datastore.?

Apologies if this sounds vague, but this is the only clarity I have at the moment.

In the case of merging an RDBMS into NoSQL, I would have followed these steps:

  • Modelling of the RDBMS structure into NoSQL datastore
  • Dump the entire data from RDBMS into NoSQL with Select *
  • Change the application code wherever affected (ex: Insert/Delete/Lookup etc)

1 Answer 1


The important thing to remember here, is that a commonality NoSQL databases tend to share, is that a query-based approach needs to be taken with respect to table design. The main driver for that, is going to be around how the data is queried.

Another consideration is around each data store's adherence to the CAP theorem. NoSQL tends to side with the P of partition tolerance, and then also choose another side. If the NoSQL products support different sides of CAP (AP vs. CP), you'll need to figure out if the overall application is more dependent on consistency or availability.

I would also consider if search is a part of the application, or rather, if the queries require any pattern matching. Some data stores handle this better than others, so it would be good to understand how each functions in those use cases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.