Perplexity Left DynamoDB for CobbleDB: When Should You?

Leave DynamoDB only when your own CloudWatch numbers show that large items and fan-out batch reads drive both the bill and the tail latency, and a cheaper fix (capacity mode, keys, caching, item shape) cannot touch them. Perplexity cleared that bar with CobbleDB. Almost nobody else should copy it, but almost everybody should run the same audit.

According to The New Stack's report, Perplexity replaced DynamoDB on its search read path with CobbleDB, a roughly 40,000-line Rust key-value store, because it was paying too much and could not control how reads behaved. The lesson is not "build your own database". It is that an exit is only defensible when you can name the cost driver and the missing control in one sentence each.

What Perplexity actually reported

The numbers are worth stating precisely, because the caveats matter as much as the headline. A single Search API call fetches 100 to 120 page keys in batches of 10 to 20, and each item averages about 50 KB. Perplexity measured median batch-read latency at 5.6 ms on CobbleDB versus 31.4 ms on DynamoDB, and p99 fell from 123 ms to 24.2 ms. Its cost model puts CobbleDB at least 20% below DynamoDB across the commitment options it evaluated.

Now the fine print, which the article itself flags. The two latency figures were not measured side by side on identical traffic: DynamoDB's were recorded before the cutover, CobbleDB's after. The 20% estimate excludes the engineering cost of running the thing. It took two engineers, hundreds of coding agents and about eight weeks to build. The agents did not run production; the engineers did.

The read path was the real complaint

The article says DynamoDB gave Perplexity little say over how reads were handled, so one slow replica could hold up an entire batch. CobbleDB's router can try another replica when one is slow, keeps reads inside the same availability zone when possible, and lets replicas fall behind and catch up independently.

That is a tail-latency argument. When one request fans out into 100-plus keys, your latency is the slowest of many lookups, so p99 of the store becomes p50 of your API. If your workload is single-key lookups by primary key, this complaint does not apply to you, and the exit case loses half its weight immediately.

Check the bill against the item size first

Large items are where DynamoDB's cost model bites hardest. Per the AWS developer guide, a strongly consistent read of an item up to 4 KB costs one read unit, an eventually consistent read costs half, and sizes round up to the next 4 KB. A 50 KB item rounds to 52 KB, so it costs 13 units strongly consistent or 6.5 eventually consistent, before you multiply by 100-plus keys per call. BatchGetItem gives no discount: it rounds each item separately.

Before anything else, measure what your table actually consumes. This pulls seven days of consumed read and write units from CloudWatch and turns them into a monthly figure. Set the two price variables yourself from the AWS DynamoDB pricing page for your region and mode; we deliberately do not hard-code numbers that change. For orientation, the on-demand example on that page works out to $0.125 per million read request units and $0.625 per million write request units for the Standard table class in US East (N. Virginia), as of October 2026.

#!/usr/bin/env bash
# ddb-cost-estimate.sh <table-name> ; needs aws CLI v2 and awk
set -euo pipefail
TABLE="$1"
# USD per million units, copied from the AWS pricing page for your region/mode
RRU_PER_M="${RRU_PER_M:?set price per million read units}"
WRU_PER_M="${WRU_PER_M:?set price per million write units}"
END=$(date -u +%Y-%m-%dT%H:%M:%SZ)
START=$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-7d +%Y-%m-%dT%H:%M:%SZ)

sum_metric() {
  aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB \
    --metric-name "$1" --dimensions Name=TableName,Value="$TABLE" \
    --start-time "$START" --end-time "$END" --period 86400 \
    --statistics Sum --query 'Datapoints[].Sum' --output text |
    tr '\t' '\n' | awk '{s+=$1} END {printf "%.0f", s}'
}

R=$(sum_metric ConsumedReadCapacityUnits)
W=$(sum_metric ConsumedWriteCapacityUnits)
awk -v r="$R" -v w="$W" -v rp="$RRU_PER_M" -v wp="$WRU_PER_M" 'BEGIN {
  printf "7d reads: %d units, writes: %d units\n", r, w
  printf "Estimated monthly: $%.2f (scaled x30/7)\n", (r/1e6*rp + w/1e6*wp) * 30/7
}'

This estimate fits on-demand tables, where consumed units map directly to billed units. On a provisioned table, you pay for what you provisioned, so compare against ProvisionedReadCapacityUnits instead; the gap between the two is your waste.

Rule out the cheaper fixes before you write Rust

Leaving DynamoDB is the last item on the list, not the first. Work down in this order:

On-demand versus provisioned. A steady, predictable workload on on-demand pays a premium for flexibility it never uses. Switching to provisioned with autoscaling, or reserved capacity, is a config change, not a migration.

Hot partitions. Throttling with low average consumed capacity usually means a skewed key, not a bad database. Fixing the key design costs a week; replacing the store costs a year. Our notes on database sharding choices we wish we made earlier cover the same skew problem from the other side.

Caching. If reads are repetitive, DAX or a plain in-process or Redis cache in front of the table can cut consumed units sharply; pick the pattern deliberately using cache-aside versus read-through and write-through. Perplexity's batch pattern across a huge corpus probably caches poorly, which is part of why its case is real. Yours may not be.

Item shape. If items are large because you store blobs, move the blobs to S3 and keep pointers in the table. Perplexity did a version of this at scale by separating durable document storage from the serving store.

Migration risk is the cost nobody puts in the spreadsheet

Perplexity's 20% figure omits maintenance, on-call, and the day a replica corrupts. Add that number yourself. For most teams, 20% of a modest DynamoDB bill is less than one engineer's salary, and the arithmetic ends there.

If a different managed store fits the access pattern better, that is a far cheaper exit than self-hosting. Read-heavy, globally distributed workloads might suit something like the ones in Turso vs Cloudflare D1, and a tracked bill is easier to defend with the right tooling from our best FinOps tools roundup. The broader question of which database fits which workload shape is worth working through on its own; see choosing the right database for your workload.

The decision, concretely

• Is the bill high mainly because of large items or steady bulk reads? Measure with the script above, then shrink items or move blobs to S3 before considering anything else.
• Do you see tail latency from fan-out batch reads you cannot steer? That is the one complaint that a managed key-value store may genuinely not fix; test a replica-aware alternative.
• Is the workload steady and single-key? Stay. Provisioned capacity, reservations, and a cache will beat any migration.
• Do you lack a team that can own a datastore on call? Stay, whatever the savings estimate says.

Questions people ask

Why did Perplexity leave DynamoDB?

Perplexity's search read path fetches 100 to 120 keys per API call, each item averaging about 50 KB. That item size makes DynamoDB reads expensive, because reads are billed per 4 KB, and DynamoDB gave Perplexity little control over slow replicas, so one laggard held up a whole batch. CobbleDB lets the router retry another replica and keep reads in the same availability zone.

Is CobbleDB really faster than DynamoDB?

Perplexity reported median batch-read latency of 5.6 ms on CobbleDB against 31.4 ms on DynamoDB, and p99 falling from 123 ms to 24.2 ms. The New Stack notes these were not a controlled side-by-side benchmark: DynamoDB was measured before the cutover and CobbleDB after. Treat the gap as directional, not as a number you can expect on your own workload.

How do I cut my DynamoDB bill without migrating?

Check capacity mode first: a steady workload on on-demand usually costs less on provisioned capacity with autoscaling or reserved capacity. Then fix hot partition keys, add a cache such as DAX or Redis for repetitive reads, and move large blobs to S3 with pointers in the table. Each is a configuration or schema change, not a new datastore to run on call.

The call we'd make

Stay on DynamoDB unless you can show, with your own CloudWatch numbers, that item size and fan-out reads drive the bill and the tail. Fix keys, capacity mode, and caching first, then look at a different managed store. Build your own only if you have Perplexity's scale, its read-path grievance, and engineers you are willing to page.

Sources

• Perplexity's AI agents helped build a database (The New Stack)
• DynamoDB read and write operations: capacity unit consumption (AWS docs)
• Amazon DynamoDB pricing (AWS)