Cloudant is an open source non-relational, distributed database service that requires zero-configuration. It's based on the Apache-backed CouchDB project and the creator of the open source BigCouch project.
Cloudant's service provides integrated data management, search, and analytics engine designed for web applications. Cloudant scales your database on the CouchDB framework and provides hosting, administrative tools, analytics and commercial support for CouchDB and BigCouch.
Cloudant is often…
$1
per month per GB of storage above the included 20 GB
IBM watsonx.data
Score 8.7 out of 10
N/A
Watsonx.data is presented as an open, hybrid and governed data store that makes it possible for enterprises to scale analytics and AI with a fit-for-purpose data store, built on an open lakehouse architecture, supported by querying, governance and open data formats to access and share data.
N/A
Pricing
IBM Cloudant
IBM watsonx.data
Editions & Modules
Standard
$1
per month per GB of storage above the included 20 GB
Standard
$75
per month 100 reads/second ; 50 writes/second ; 5 global queries/second
Lite
Free
20 reads/second ; 10 writes/second ; 5 global queries / second ; 1 GB of storage capacity
Our organization found Cloudant most suitable if One, a fixed pricing structure would make the most sense, for example in a situation where the project Cloudant is being used in makes its revenue in procurement or fixed retainer — thus the predictability of costs is paramount; Two, where you need to frequently edit the data and/or share access to the query engine to non-engineers — this is where the GUI shines.
Real-time transaction processing (both reads and writes) is where DataStax Enterprise shines. It's very fast with linear scalability should more resources be needed. Additional nodes are added very easily. DataStax Enterprise on its own (without Solr or Spark enabled) isn't well suited for long complicated reports. The data model doesn't support joining multiple tables together which is common in BI reporting.
Datastax Cassandra provides high availability and good performance for a database. It is built on top of open source Apache Cassandra so you can always somewhat understand the internal functioning and why.
Datastax Cassandra is fairly simple to start using, you can install/setup your cluster and be productive in 1 day.
Datastax Cassandra provides a lot of good detailed documentation, and when starting, the detailed free videos on the Datastax site and documentation are very helpful.
Datastax Enterprise Edition of Cassandra provides more tools, good support, and quick response SLA for enterprise business support.
Integration complexity with Security Tools while watsonx.Data is well-suited for native tools, but integration with third-party security tools requires custom connectors or manual ETL pipelines. which leads to an increase in setup time.
the flexibility of NoSQL allow us to modify and upgrade our apps very fast and in a convenient way. Having the solution hosted by IBM is also giving us the chance to focus on features and the improvement of our apps. It's one thing less to be worried about
As an open source technology Cassandra can be readily used with or without any commercial support. DataStax provides value-added services and features, and in the end it is up to individual situations to strike a balance between the desirability of such support/service versus the associated cost.
It's mostly just a straight forward API to a data store. I knock one off for the full text search thing, but I don't need it much anyways. Also, the dashboard UI they give is pretty nice to use. It provides syntax-highlighting for writing views and queries are easy to test. I wish other DBs had a UI like this.
DataStax has a good community built around it and has amazing scalability options. Though the initial setup is a bit costly, in the long run, it makes up for it. It also has powerful monitoring tools and a clean UI.
it is a highly available solution in the IBM cloud portfolio and hence we have never had any issues with the data base being available - we also do continuous replication to be on the safer side just in case some thing goes awry. We also perform twice a year disaster recovery tests.
very easy to get started and is very developer friendly given that it uses couchDB analytics. It is a cloud based solution and hence there is no hardware investment in a server and staging the server to get started and the associated delays/bureaucracy involved to get started. Good documentation is also available.
We have had a few situations where we caused an outage or something has gone wrong and we are able to get a support person to offer live help within minutes. The escalation process is excellent - the best I've seen - and the support team is incredibly strong. Outside of emergencies, the team is very helpful with general questions and working through data model exercises and the subscription I believe still comes with some hours to help get the data model reviewed.
online resources are good enough to understand but there is nothing like testing. In our case, we discovered some not documented behavior that we take in count now. Also, the experience in NodeJs is critical. Also, take in count that most of the "good practices" with cloudant are not in online courses but in blogs and pages from independent developers
The feature-set, including security, is very comparable. Overall, IBM's services added to the product are mature and stable, although product support and engineers could be a little better. Global availability is improving, and Disaster Recover Capabilities are great. Overall, it's very comparable to MongoDB as a DBaaS offer, available globally and with great documentation.
Pinecone and IBM watsonx.data (Milvus in our case) both work great as a full-managed cloud-based vector database. We selected IBM watsonx.data because it integrates well with watson.ai and is a little more beginner friendly than Pinecone, but I think both are great anyway.
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.
