DynamoDB vs Google Datastore: Firestore in Datastore mode

Choose DynamoDB for AWS workloads built around key-based access and managed throughput scaling. Choose Firestore in Datastore mode when an existing application depends on Datastore APIs, entity keys, or App Engine integrations. Google Datastore is no longer offered as a standalone database product: Firestore is its successor, and Google recommends the newer Firestore APIs for applications without a Datastore dependency.

Amazon DynamoDB and Google Datastore: an overview

DynamoDB is AWS's managed key-value and document database. Tables have partition keys and optional sort keys, while other item attributes can vary. AWS manages the underlying infrastructure, partition distribution, and replication.

Google's Datastore overview now describes Datastore as a compatibility API on Firestore. This page uses Datastore mode for the current service and legacy Cloud Datastore only when discussing older behavior. That distinction matters because many old comparisons incorrectly carry legacy consistency and entity-group limits into current deployments.

Both services provide managed storage, replication, and atomic transactions. Your team still owns application schemas, indexes, access controls, recovery settings, and the behavior of retries.

DynamoDB vs Datastore mode at a glance

Limits are documented in DynamoDB constraints and Datastore mode limits. They should be checked separately from adjustable project quotas.

Data models and query capabilities

DynamoDB organizes efficient requests around table and index keys. For example, a customer partition key and order-time sort key make fetching one customer's recent orders straightforward. A new cross-customer query may need a secondary index or a derived view. Filtering a scan does not eliminate the read work already performed.

Datastore mode's entities and keys use kinds, properties, identifiers, namespaces, and optional ancestor paths. Entities of the same kind do not need identical properties. Application code is responsible for validating the shape and meaning of those values.

Datastore indexes support queries over properties. Built-in indexes cover simple cases, while composite indexes support additional query shapes. Missing or excluded properties affect which entities can appear in a query. Indexing large arrays or many property combinations can also increase storage and write work.

GQL provides SQL-like query syntax; it is not a relational SQL engine. Neither GQL nor DynamoDB's PartiQL supplies arbitrary relational joins. For either service, write out your access patterns before choosing the schema. The DynamoDB modeling guide shows how access patterns drive keys and indexes.

Consistency and transactions: current versus legacy behavior

DynamoDB can perform strongly consistent reads on tables and local secondary indexes. Global secondary indexes remain eventually consistent. Transactions can atomically read or write multiple items within the documented scope. MREC global tables replicate a transaction's changes independently; MRSC global tables do not support transaction APIs.

Current Datastore mode provides strong queries and serializable transactions. Its transaction documentation distinguishes pessimistic, optimistic, and OPTIMISTIC_WITH_ENTITY_GROUPS concurrency modes.

The legacy-compatible entity-group mode retains restrictions such as 25 entity groups per transaction, one write per second per entity group, and ancestor-only queries within transactions. Those are not universal limits of every Datastore-mode database. Check an upgraded application's concurrency setting before applying older advice.

Datastore transactions also have a notable read behavior: queries and lookups observe the transaction's starting snapshot, including after writes made within that transaction. They do not read those pending writes back. Design application logic and tests accordingly. Retries should be idempotent because a commit error does not always prove that no commit occurred.

Performance

Amazon DynamoDB

DynamoDB is designed for low-latency operations on well-distributed keys. That does not establish a constant latency guarantee for every operation or prove that it is faster than every other NoSQL database. Network distance, item size, index access, contention, and retries all affect the measured result.

DAX can improve suitable read-heavy workloads through caching. It is an additional service with client integration, consistency considerations, and cost. Cache-hit latency is not the latency of all database requests.

Firestore in Datastore mode

Datastore mode automatically distributes work, but a sudden traffic jump into a small key range can create a hotspot. Google's best practices recommend starting a new kind at no more than 500 operations per second, then increasing traffic by 50% every five minutes with evenly distributed keys.

The same guidance illustrates reaching about 740,000 operations per second after 90 minutes of that ramp. This is arithmetic illustrating the ramp schedule, not a documented service ceiling or a guarantee that a particular application achieves that rate.

Benchmark key lookups, indexed queries, writes, and transactions separately. Keep location, data sizes, traffic distribution, and consistency comparable rather than ranking databases by unrelated headline numbers.

Availability and durability

DynamoDB replicates across Availability Zones within a Region. Cross-Region replication requires global tables; it is not enabled automatically for an ordinary regional table. AWS's Standard SLA is 99.99%, while the qualifying Global Tables SLA is 99.999% under its stated conditions.

Datastore mode offers regional and multi-region locations. Google describes it as sharing Firestore's underlying availability characteristics. Use the current Firestore SLA for the covered service and chosen location instead of copying legacy Datastore percentages into a new design. Its regional terms include a Stockholm-specific exception.

The database's availability is only part of application availability. Keep compute, authentication, external APIs, failover routing, and backup recovery in the same review. Replication will not undo an authorized deletion caused by a programming mistake.

Security

DynamoDB supports encryption at rest, TLS in transit, IAM policies, resource-based policies, and AWS KMS key choices. Client-side encryption is a separate capability; it should not be confused with TLS. Scope permissions to the tables, indexes, streams, and operations an application needs.

Datastore mode provides server-side encryption and IAM authorization. Choose service identities and roles appropriate to each backend component. Entity namespaces organize data, but application-level tenant authorization still needs to be enforced.

Do not import Firebase Security Rules assumptions from Native mode. Datastore APIs are a backend access model. For a mobile or web application, authenticate users at the application boundary and validate which entities they may access.

Backups and recovery

DynamoDB provides on-demand backups and configurable PITR retention from 1 to 35 days. AWS Backup can add centrally managed schedules and cross-Region backup policies. PITR restores create a new table, so a recovery procedure must include operational settings and application reconnection.

Datastore mode now supports managed backup schedules and restore, along with PITR for up to seven days when enabled. It is no longer accurate to describe a Cloud Storage export workflow as the only protection available.

Managed exports and imports remain useful for data movement and recovery workflows. An ordinary export is not automatically a consistent snapshot at one instant; the documented PITR export path is the relevant option when a particular retained timestamp matters. Check destination permissions and test importing into a separate database.

Scalability and operations

DynamoDB offers on-demand throughput and provisioned throughput with auto scaling. Warm throughput describes immediately supportable capacity, while per-key concentration and service quotas can constrain an abrupt spike. You still monitor throttles, latency, consumed capacity, and index activity.

Datastore mode handles infrastructure scaling. Your responsibilities include key distribution, composite indexes, transaction contention, traffic ramps, and recovery settings. Adding servers manually is not the normal scaling interface, but changing the data model may still be necessary when a workload concentrates on one key.

For both services, test deployments and backfills as well as normal traffic. A migration that redirects all users into a new key range at once can behave differently from a workload that grew gradually.

When and where to pick each database

DynamoDB use cases

DynamoDB fits sessions, application state, shopping carts, content metadata, event ingestion, and IoT state when access patterns are explicit. It can support bidding or gaming backends with careful key distribution and measured latency requirements.

It can collect data for analytics, but arbitrary analytical queries generally belong in a suitable downstream system. Logging also needs retention and cost design; a dedicated log service may fit better than storing every event as a database item. DAX is useful for repeated reads, not a substitute for those decisions.

Datastore mode use cases

Datastore mode is particularly relevant for existing App Engine and backend applications built around Datastore APIs, entity models, and indexes. Content management and device-state applications can continue using those models without rewriting every access path.

For a new Google Cloud application, Google's API selection guidance recommends the newer Firestore APIs unless Datastore compatibility is required. Native mode provides the client and real-time capabilities discussed in the DynamoDB vs Firestore comparison. Datastore mode does not inherit those merely because both use Firestore storage.

Pricing

DynamoDB pricing depends on request or provisioned capacity and storage. Ordinary writes are sized in 1 KB units, and strongly consistent reads in 4 KB units; eventual and transactional reads use different capacity. Index writes, replicas, backups, and DAX can change the bill. Estimate the workload with the pricing calculator.

DynamoDB's Standard-class provisioned capacity and storage allowances are not simply a 12-month trial. The read/write capacity allowance does not cover on-demand requests, and account-level Free Tier plan rules are separate from service allowances.

Datastore mode pricing bills entity operations, storage, network usage, and additional protection features. Use the Datastore pricing page rather than Firestore Enterprise's byte-based pricing. Location, query work, retained backups, and data transfer affect the total.

Build estimates from the same request mix and recovery topology. An unused provisioned allocation, an over-indexed entity, or repeated queries can make a nominally cheap operation expensive at application scale.

Using both or migrating between them

Use both only with a defined ownership boundary, such as a legacy Google Cloud application retaining its Datastore records while an AWS service owns independent DynamoDB state. Cross-cloud copies require a deliberate synchronization and reconciliation process.

A migration is not a mechanical table rename. Map entity keys, namespaces, ancestors, query indexes, data types, and transaction assumptions into the destination model. Verify completeness and conflict behavior during cutover. Avoid uncontrolled dual writes: a successful write to one database does not atomically commit the other.