DynamoDB vs Google Firestore - The Ultimate Comparison

Amazon DynamoDB and Google Firestore: An Overview

Building mission-critical, demanding applications require a solid, high-performing database. However, the solution may differ depending on where you deploy the application. For instance, you can utilize DynamoDB, a fully managed, serverless NoSQL Database offered by AWS. Then there's Google Firestore, a serverless document-based database provided by Google.

Both database services share similarities, such as their nature of being serverless. However, specific differences between the two services make one service better than the other for certain applications.

Therefore, this article will provide an in-depth comparison between DynamoDB and Google Firestore and present helpful facts about the two services to help you decide the best database for your mission-critical, demanding application.

Shared Attributes for DynamoDB and Google Firestore

At a high level, DynamoDB and Google Firestore are both serverless, fully managed services offered by AWS and Google Cloud. This implies that developers do not need to provision a database server but can immediately create a table and consume the service.

Both database services are NoSQL databases that can support documents, though their data models differ. DynamoDB uses a key-value and document data model, while Firestore uses a document model with collections and subcollections.

Finally, both databases are high-speed; DynamoDB can serve up to 100 million requests per day with single-digit millisecond latency, while Google Firestore can serve up to 50,000 document reads per day (on a free plan) with near real-time responses.

Performance

Amazon DynamoDB

DynamoDB utilizes an array of high-performing SSDs to persist data across multiple partitions in a single table. Furthermore, it implements a request router with a hash function that allows DynamoDB to route requests to a specific shard when querying, thus allowing it to limit the dataset to a single shard when it queries data.

The time complexity of this hash function is O(1), meaning that no matter how big the dataset is, DynamoDB can perform consistently. This ensures that it can serve requests at a single-digit millisecond latency regardless of the dataset's size.

Furthermore, developers can achieve single-digit microsecond response latency with the use of DynamoDB Accelerator (DAX), an in-memory caching service.

Finally, DynamoDB can scale up with the increase in demand without developer intervention to ensure that it can perform consistently across varying workloads.

Google Firestore

Google Firestore does not support sub-10 millisecond latency (unlike DynamoDB) as it prioritizes availability and durability over latency. Therefore, Google Firestore does not respond as quickly as DynamoDB.

Although Firestore can still handle demanding operations at scale, it is limited by a maximum of 10,000 writes per second. Because of this, Firestore cannot run applications with demanding write operations, unlike DynamoDB, which can scale up to 40,000 writes per second (varying per region).

Firestore's performance is optimized for real-time synchronization and offline capabilities, making it suitable for applications that require real-time updates and offline access.

Availability and Durability

Amazon DynamoDB

Fundamentally, each item stored in DynamoDB contains a partition key. This allows the request router to route requests to specific shards when data is being queried. Therefore, if the partition keys are used correctly, DynamoDB can effectively spread the incoming load across its partitions, ensuring that specific partitions don't throttle (Hot Partitions) or crash, thus making the service highly durable.

Secondly, DynamoDB automatically replicates its data across multiple availability zones (AZs) which ensures the high availability of user data.

Google Firestore

Google Firestore is a highly available service as it offers data replication across two primary levels:

1. Regional Replication: Firestore will replicate the database data within the same region (in several AZs).
2. Multi-region replication: Firestore will replicate the database data in at least two different regions. This approach is immune to regional outages, making your application highly available.

Figure - Firestore Multi-Replication Replication (Source: Google)

It's essential to select the replication approach carefully. If you choose multi-region replication, there will be a higher read and write latency as data must be synchronously replicated across multiple regions. Therefore, ensure to select the right approach without trading off on performance.

Security

Amazon DynamoDB

DynamoDB is a highly secure database as it offers security at two levels:

1. Encryption at rest: DynamoDB encrypts data using KMS Encryption Keys at rest.
2. Encryption in transit: DynamoDB provides an end-to-end encrypted data transfer from the database to the client.

When DynamoDB encrypts data at rest, it utilizes KMS keys to encrypt the data. It provides an additional layer of security for securing the data in an encrypted table. It's important to understand that all the primary table data, secondary indexes, streams, backups, and global tables are secured in this encrypted table. It makes DynamoDB a highly secured database.

Google Firestore

Google Firestore provides encryption at rest, as all data is encrypted before it is written to the disk. In addition, Firestore allows developers to configure security rules to offer a more granular approach to data access. For example, developers can implement security rules on a document basis where developers can specify which user can access which document.

Firestore also integrates with Google Cloud Identity and Access Management (IAM) to provide fine-grained access control, ensuring that only authorized users can access specific data.

Backups

Amazon DynamoDB

DynamoDB allows users to back up their data in two different ways:

1. AWS Backups - Allows users to utilize the service - AWS Backups to capture full table backups at no performance overhead.
2. Point in time recovery - This feature is present within DynamoDB and must be enabled to use. It captures a history of the table state over the past 35 days and allows users to revert to the table state to a defined state within the last 35 days.

Google Firestore

Developers can manually set up import/export workflows using Google DataStore to export data on Google Firestore on a periodic basis. However, it's quite complex to set up, unlike DynamoDB.

Firestore also supports automated daily backups through Google Cloud's managed export service, which can be scheduled to run at regular intervals.

Scalability

Amazon DynamoDB

DynamoDB was built to withstand the demanding workloads of the Amazon shopping site. Therefore, DynamoDB can scale up to serve more than 20 million requests per second.

The O(1) hash function at the request router is a significant reason for this scalability. It allows DynamoDB to serve users of any data size at the same response rate by effectively locating the partition in which the data is present and routing the request to that shard. This reduces the amount of data being scanned by DynamoDB, which allows it to provide single-digit millisecond latency to datasets of over 100TB.

Users can utilize the PAY_PER_REQUEST billing on DynamoDB to allow DynamoDB to scale up and down based on the incoming traffic to serve responses with no performance loss.

Google Firestore

Google Firestore utilizes autoscaling behind the scene to scale its resources up and down when needed to help serve thousands of requests per second with over a million concurrent connections.

Firestore's automatic scaling is particularly beneficial for applications with fluctuating workloads, as it can dynamically adjust resources to meet demand without manual intervention.

Pricing

Amazon DynamoDB

DynamoDB bills its clients on a pay-as-you-use basis. So, for example, you get billed for reading, writing, and storing data in your table. However, it's important to note that DynamoDB still charges its users separately for services such as DAX and Streams.

DynamoDB has a pricing model, as discussed below.

1. On-Demand Pricing - AWS calculates the bill based on the consumed throughput for the month. In addition, you may also get billed for the used backup storage and other DynamoDB services you may consume. Use this billing model if your application is varying and has unpredictable workloads.
2. Provisioned Pricing - You are required to pay for the provisioned throughput whether you are using them or not. Use this billing model if your application has a predictable workload.

Google Firestore

Since Google Firestore is a serverless solution, it bills its clients based on their usage. However, the pricing model is significantly different when compared to DynamoDB. Google Firestore bills its clients according to the following criteria:

1. The number of document reads, writes, and deletes made.
2. The number of entries matched by aggregation queries.
3. The storage consumed by Firestore to store your data.
4. The network bandwidth used to perform operations on the data.

These are the four main factors that affect pricing on Google Firestore. However, the actual pricing plans differ according to region. Hence, it is recommended that you visit the Google Pricing Calculator to determine the costs based on your preferred region.

Use Cases

Amazon DynamoDB

DynamoDB is a high-speed NoSQL serverless database offered by AWS capable of generating responses with a single-digit millisecond to microsecond latency.

Its capability to serve extremely demanding mission-critical workloads makes it more suitable for the following:

1. Building applications that receive over 100 million requests per day.
2. Building content management platforms with the help of the flexible schema-less data structure and a suitable partition approach.
3. E-commerce platforms that require high availability and low latency for user transactions.
4. Gaming applications that need to handle large volumes of concurrent users and real-time data updates.
5. IoT applications that generate massive amounts of data and require scalable storage and quick retrieval.

Google Firestore

Google Firestore, too, is a serverless NoSQL database. However, it's not able to keep up with DynamoDB with performance. Therefore, it's recommended to use Google Firestore when:

1. Offline First Applications: Firestore has a native implementation of a cache. Thus, Firestore can be configured to return data from an offline store if a device is offline. Additionally, it provides an in-built request queue where local changes will be synced back with the cloud once the network is back online.
2. Real-time Applications: Firestore, when integrated with Google Firebase, can utilize web socket connections to exchange data. Therefore, Firestore has the power to create a real-time application by setting up subscribers to document changes.
3. Mobile and web applications that require real-time synchronization and offline capabilities.
4. Collaborative applications like chat apps or document editing tools where real-time updates are crucial.
5. Applications that benefit from Firestore's integration with other Google Cloud services and Firebase features.

Conclusion

This article presented an in-depth comparison between DynamoDB and Google Firestore. Unfortunately, there is no superior database service between the two. The best database for you depends on your use case.

However, if you are designing and implementing highly demanding workloads of over 300 to 400 million requests per day, DynamoDB is the exemplary service for you due to its immense scalability!

I hope the facts presented and discussed in this article will help you select the correct database service for your project.

Thank you for reading!