MongoDB is configured with primary and secondary nodes, making it difficult (and expensive) to scale MongoDB horizontally. This is especially relevant for IoT, considering the vast scalability requirements of many IoT use cases.
 |
MongoDB is mostly used as a single-node database: its performance is optimized for single-node operations. On the contrary, CrateDB is a database with shared-nothing nodes and automatic replication and cluster rebalancing. CrateDB is built to scale, and thus it shows the best results when operated in a multi-node cluster.
CrateDB provides all the versatility of NoSQL, but without abandoning SQL. Querying is way easier when compared to MongoDB, which demands considerably more code when working, for example, with time-series data.
 |
On top of that, CrateDB schemas are dynamic. MongoDB doesn’t enforce a schema, but it is necessary to define a schema initially in order to get good results. Besides, MongoDB's indexing can cause problems in IoT use-cases.
MongoDB offers excellent development tools, but it is a database quite complex to operate and maintain. To integrate MongoDB with existing applications is often difficult, and the risk of getting locked in is high.
Due to its document-store structure, MongoDB is not efficient at handling high volumes of IoT time-series data. We compared the cost of running an industrial IoT use case with MongoDB and with CrateDB.
For the same monthly budget, MongoDB gave you access to fewer resources; it also required more memory, and ~60% more storage than CrateDB. In the use case studied, MongoDB's default index already exceeded the RAM available, forcing the user to upgrade to a more expensive machine.
