DynamoDB and Google Cloud Bigtable are both distributed NoSQL databases that partition data by key, but they target different shapes of workload. DynamoDB is a serverless AWS key-value and document store built for operational (OLTP-style) access. Bigtable is a GCP wide-column store designed to scale into the petabyte range for analytical, time-series, and high-throughput ingest workloads.
Should you use DynamoDB or Bigtable?
Choose DynamoDB if you are on AWS and want a serverless, pay-per-request key-value/document database for operational access patterns with no cluster to run. Choose Google Cloud Bigtable if you are on GCP with very high-throughput or petabyte-scale time-series, IoT, or analytical data, want HBase/Cassandra API compatibility, and can provision cluster nodes. Cloud and workload shape usually decide it.
DynamoDB vs Bigtable at a glance
| Characteristic | DynamoDB | Google Cloud Bigtable |
|---|---|---|
| Data model | NoSQL key-value and document; typed items up to 400 KB in tables | Wide-column store; a sparse, sorted map keyed by row key, with column families and cells (can be very wide) |
| Query language / API | Native API (GetItem, Query, Scan) plus PartiQL, a SQL-compatible language |
Bigtable API (row-key reads and scans); HBase and Cassandra API compatibility; SQL support for queries |
| Keys / access | Partition key with optional sort key; access designed around known patterns | Single row key that determines sort order; range scans over the sorted key space |
| Secondary indexes | Global secondary indexes (GSI) and local secondary indexes (LSI) | No synchronous secondary indexes; you design the row key, and continuous materialized views can act as asynchronous secondary indexes |
| Consistency | Eventually consistent by default; strongly consistent reads available per request | Strong consistency on a single-cluster instance; multi-cluster instances default to eventual (configurable) |
| Scaling model | Automatic partitioning; serverless on-demand or provisioned capacity | Provisioned cluster nodes (with autoscaling); scales to petabytes across many machines |
| Transactions | ACID transactions across multiple items within a Region | Single-row atomic read-modify-write; no general multi-row ACID transactions |
| Pricing / ops model | Pay-per-request (on-demand) or provisioned capacity plus storage; serverless, AWS-only | Billed by provisioned node-hours plus SSD/HDD storage (and network); node-based, GCP-only |
| Best-fit workloads | Operational apps with predictable key access needing consistent low latency | Petabyte-scale time-series, IoT, analytics, and high-throughput ingest with range scans |
When DynamoDB is the better choice
- You are on AWS and want zero operations. DynamoDB is serverless — no cluster nodes to size or scale. On-demand capacity bills per request and scales to traffic automatically.
- Your access is operational and key-based. Get-by-id, query-a-partition, and filter-within-a-partition map naturally to DynamoDB, and secondary indexes let you query on alternate keys without maintaining separate tables.
- You want per-request strong consistency. DynamoDB offers strongly consistent reads on demand without configuring cluster topology.
- You need native AWS integration. IAM, Lambda, and Streams reduce glue code.
When Bigtable is the better choice
- You are on GCP with petabyte-scale data. Bigtable is built to scale across hundreds or thousands of machines into the petabyte range, adding nodes for more throughput.
- Your workload is time-series, IoT, or analytical. A single sorted row key plus wide rows suits time-ordered data and large range scans, and it feeds the Hadoop/Spark/Beam ecosystem.
- You want HBase or Cassandra API compatibility. Bigtable supports the open HBase API standard and a Cassandra API, easing migration from those systems.
- You need very high sustained write throughput with predictable, provisioned node capacity.
What a Bigtable row-range scan becomes in DynamoDB
Bigtable has one index per table: the row key, and "row keys sort rows
lexicographically from the lowest to the highest byte string". Every read is a shape
cut out of that one sorted space. Two reads against a sensor table keyed
device#<id>#<timestamp>:
# one device, one day
cbt -instance metrics read sensor-data prefix=device#4711#2026-07-27 count=20
# every device in a block, one contiguous scan
cbt -instance metrics read sensor-data start=device#0001# end=device#0500#
The first ports cleanly. Split the row key at the first # and you have a DynamoDB
partition key plus a sort key, and the prefix becomes begins_with:
{
"TableName": "sensor_data",
"KeyConditionExpression": "device_id = :d AND begins_with(reading_ts, :day)",
"ExpressionAttributeValues": {
":d": {"S": "4711"},
":day": {"S": "2026-07-27"}
},
"Limit": 20
}
The second has no DynamoDB equivalent. Query requires the partition key name and a
single value for it as an equality condition, so there is no request that walks from
one partition key to the next. That range across 500 devices becomes either a Scan,
which reads the whole table and bills for items evaluated rather than items returned,
or 500 separate Query calls you fan out and merge yourself. The global sort order
that was the entire read interface in Bigtable stops existing above the partition
key.
What you get back is the escape hatch. Bigtable's answer to a second access pattern is
a second row key, which means a second table you write yourself, or an asynchronous
secondary index built on a continuous materialized view whose defining SQL cannot be
modified after creation. DynamoDB's answer is a GSI: AWS keeps it in sync
asynchronously, propagating "within a fraction of a second, under normal conditions",
and charges the index write to the index. You never write it.
That hatch has its own edges worth knowing before you lean on it. A GSI query cannot
fetch attributes that are not projected into the index, so the projection is a
decision you make at creation time, and every read from a GSI is eventually consistent
with no strongly consistent option.
Wide rows do not survive the trip either. A Bigtable row can hold up to 256 MB across
its cells, and the docs recommend staying under 100 MB. A DynamoDB item caps at
400 KB. So a row that accumulates a year of readings as thousands of cells arrives as
thousands of items sharing a partition key, with the sort key recovering the ordering
the cell qualifiers used to give you.
Once the data is split that way, rolling it back up is application work. DynamoDB has
no aggregate functions and no GROUP BY, and PartiQL adds neither. The cross-device
rollup that opened this section is one statement in DynoTable's SQL Workbench:
SELECT device_id, COUNT(*) AS readings, SUM(kwh) AS total
FROM sensor_data
WHERE reading_ts >= '2026-07-01'
GROUP BY device_id
It compiles to DynamoDB's native Query and Scan, planned against your real keys and
indexes, and performs the grouping and the sums on the client. This one spans every
device, so it compiles to a Scan and costs what a Scan costs. That is the honest
answer rather than a hidden one, and it is the same price the hand-written fan-out
would pay. What the Workbench removes is the fan-out-and-tally code, not the read.
Working with DynamoDB
If DynamoDB fits your operational workload, DynoTable is a native desktop client for it on macOS, Windows, and Linux. It reads your standard AWS credential chain, so your data stays in DynamoDB with nothing to migrate. It browses and inline-edits items, builds key conditions and filters visually, and adds a SQL Workbench that expresses relational-shaped queries within DynamoDB's access-pattern rules, plus an AI agent on your own AWS Bedrock credentials.
The free DynamoDB Expression Builder generates key-condition, filter, and update expressions in SDK, CLI, and PartiQL form without an install. DynoTable is a closed-source commercial app; this page describes what it does, not how it is built.
FAQ
Is DynamoDB based on Bigtable?
No. They are independent products from AWS and Google. Bigtable's 2006 design influenced the wider NoSQL field (including Cassandra), and DynamoDB traces to Amazon's 2007 Dynamo work, but they share design lineage in the space, not a codebase.
Does Bigtable have secondary indexes like DynamoDB?
Not in the same way. Bigtable's primary access path is its single row key, which you design for your read pattern; continuous materialized views can serve as asynchronous secondary indexes maintained in the background. DynamoDB provides global and local secondary indexes as built-in structures that let you query on an alternate key directly.
DynamoDB or Bigtable for time-series data?
Bigtable is purpose-built for large-scale time-series: a sorted row key over time ranges plus wide rows suits range scans and petabyte volumes. DynamoDB can handle time-series too — commonly with a composite sort key and time-bucketed partitions — and is the simpler choice on AWS at moderate scale, but Bigtable is designed for the very high-volume analytical end.
Related
- Learn how DynamoDB partition keys work and sort key strategies for time-ordered data.
- Understand read modes in the DynamoDB consistency guide and when to use DynamoDB.
- Build queries fast with the free DynamoDB Expression Builder.
- Download DynoTable to browse, query, and edit your DynamoDB tables.
References
- What is Amazon DynamoDB? — AWS DynamoDB Developer Guide
- Improving data access with secondary indexes in DynamoDB
- DynamoDB read consistency
- DynamoDB on-demand capacity mode
- Bigtable overview — Google Cloud
- GoogleSQL for Bigtable
- Bigtable continuous materialized views (asynchronous secondary indexes)
- Bigtable product page (HBase and Cassandra compatibility)
Last verified 2026-07-13 against the official AWS DynamoDB Developer Guide and Google Cloud Bigtable documentation. Google Cloud Bigtable is a trademark of Google LLC; referenced here for identification only.
Top comments (0)