Overall Satisfaction with IBM Cloudant
We use Cloudant as our online cloud database solution for our mobile health app. Our solution had to work cross platform with Android and iOS and allow syncing to local databases for offline use. Cloudant allowed for easy integration into our stack with very little setup. By not having to worry about converting between database architectures we were able to focus our development time on building features into our app.
- Easy Setup
- Simple API's
- Great Documentation
- Open Standards / Works with CouchDB and mobile PouchDB
- Built in live listeners to watch for data changes would be a nice addition
It's easier to use than Dynamo, more open than Firebase, and has better documentation that CouchDB... it might not be fair to compare Modulus, Modulus obviously suffers from some scalability issues and might not be in the same class... but its a hosted DB service we had some experience with in the past....
If you are using MEAN stack and require a 3rd party cloud database it really is up there with firebase. Firebase has a couple extra features attached to its non-sql DB, and if you need those particular features then that might be a best choice. But if you don't, cloudant is far more open and most scripts and tools that work with CloudDB will work with cloudant. Firebase is far more proprietary which gives it a steeper learning curve also. Another thing to consider is how many different types of software will interact with your DB. If you are just building a web app and only one application needs the data then arguably the pros and cons against any hosted solution like Amazon Dynamo, Modulus (MongoDB), or Firebase is going to be minimal and subjective. But if you are using lots of different technologies and many different devices there is a major advantage to going with a less proprietary solution. You get all the compatibility of CouchDB but the reliability of having IBM behind your DBaaS.
No SQL Capabilities
The service scales incredibly well. As you would expect from CloudDB and IBM combination. The only reason I wouldn't score it a 10 is the fact that document trees can get nested and nested very quickly if you are attempting to do very complex datasets. Which makes your code that much more complex to deal. Its very possible we could find a solution to this problem with better database planning to begin with, but one of the reasons we chose a service over a self-hosted solution was so we could set it up quick and forget about it. So we weren't going to dedicate a team to architecture optimization.