Azure Cosmos DB vs Cloud Firestore: What are the differences?
What is Azure Cosmos DB? A fully-managed, globally distributed NoSQL database service. Azure DocumentDB is a fully managed NoSQL database service built for fast and predictable performance, high availability, elastic scaling, global distribution, and ease of development.
What is Cloud Firestore? A New Document Database for Apps. Cloud Firestore is a NoSQL document database that lets you easily store, sync, and query data for your mobile and web apps - at global scale.
Azure Cosmos DB and Cloud Firestore can be primarily classified as "NoSQL Database as a Service" tools.
Some of the features offered by Azure Cosmos DB are:
- Fully managed with 99.99% Availability SLA
- Elastically and highly scalable (both throughput and storage)
- Predictable low latency: <10ms @ P99 reads and <15ms @ P99 fully-indexed writes
On the other hand, Cloud Firestore provides the following key features:
- Documents and collections with powerful querying
- iOS, Android, and Web SDKs with offline data access
- Real-time data synchronization
"Best-of-breed NoSQL features" is the primary reason why developers consider Azure Cosmos DB over the competitors, whereas "Easy to use" was stated as the key factor in picking Cloud Firestore.
ReWrite, Whale 🐳, and FetchyFox are some of the popular companies that use Cloud Firestore, whereas Azure Cosmos DB is used by Microsoft, Rumble, and Property With Potential. Cloud Firestore has a broader approval, being mentioned in 34 company stacks & 32 developers stacks; compared to Azure Cosmos DB, which is listed in 24 company stacks and 23 developer stacks.
We are building a social media app, where users will post images, like their post, and make friends based on their interest. We are currently using Cloud Firestore and Firebase Realtime Database. We are looking for another database like Amazon DynamoDB; how much this decision can be efficient in terms of pricing and overhead?
I wouldn't make this decision without lots more information. Cloud Firestore has a much richer metamodel (document-oriented) than Dynamo (key-value), and Dynamo seems to be particularly restrictive. That is why it is so fast. There are many needs in most applications to get lightning access to the members of a set, one set at a time. Dynamo DB is a great choice. But, social media applications generally need to be able to make long traverses across a graph. While you can make almost any metamodel act like another one, with your own custom layers on top of it, or just by writing a lot more code, it's a long way around to do that with simple key-value sets. It's hard enough to traverse across networks of collections in a document-oriented database. So, if you are moving, I think a graph-oriented database like Amazon Neptune, or, if you might want built-in reasoning, Allegro or Ontotext, would take the least programming, which is where the most cost and bugs can be avoided. Also, managed systems are also less costly in terms of people's time and system errors. It's easier to measure the costs of managed systems, so they are often seen as more costly.