The short answer is no. It is not a joke, we treat it seriously. So far use of embedded JavaScript databases is kind of risk. There are no mature solutions on the market and one day you might start invest your time into debugging of database engine and not developing of application itself.

At least this was our story. Our two years old choice of AlfredDB was wrong. It looks promising, but as we start to work with real data-sets (>10k of records) it became nightmare. We spent months trying to fix it, but, no luck. The main problem is that buggy database engine prevent us from active development of our main application while it was a priority.

One day we decided that we can’t get such risks anymore. We decided to switch to MongoDB with goal to complete our application without worrying about bugs in database. Surprisingly migration was not easy. The fact that database uses MongoDB alike query syntax and has find and findOne methods do not means that it is easy to replace it with MongoDB. For those who saw The Pulp Fiction there are too much of little differences – “It’s the little differences. I mean, they got the same shit over there that we got here, but it’s just…it’s just, there it’s a little different”.

While one part of team work with application itself and didn’t worry about database issues another part of team was building embedded database that will be capable to transparently replace Mongodb. It was not easy but if you focus on this from beginning you can do it. First our decision was that we must have good test coverage and all tests must pass both with MongoDB and TingoDB. Looking back, this was very important decision, we was not need to invent something, we just need to reproduce existing functionality.

Once some core functionality was ready we come to idea that we can reuse tests from MongoDB Node.js driver project. It was not easy as well. We discover that original API is designed to be way too flexible. Many functions can work with or without callback. Some functions accept many different parameter combinations. We have surprised to found that find method support 7 different parameter combinations and on every its call there are dozens of code lines that just guess what you actually want to do. To be honest we was upset with that, but now we at least know how to call it to make this code run faster. Also tests verify use of many options or behaviours that we never used in real life and was not aware. No matter what we precisely duplicate all behaviours including exception error messages and even bugs (as we think about them).

Finally with the all efforts spent on embedded database and migration of application code to MongoDB we came to magic moment of marriage of both. On our luck this part was easy, it just worked. Up to now we keep primary app development with MongoDB. The reason for this is that we found this easier: we can use all the lovely MongoDB tools and do not need to worry about possible bugs in database engine. However in parallel we run manual and automatic QA tests using the final configuration with embedded JavaScript database. That’s our way!