How much faster is the same query with TTL caching?
We ran 100,000 identical listRows calls against a 10,000-row table, then turned on ttl: 300 and ran them again. Scroll to see what changed.
Your traffic. Your savings.
measured. Numbers above are the totals the benchmark reported for the actual 100,000-request run.
Not just the average.
Press play. Watch the gap open.
Twelve minutes back in your pocket.
Nothing fancy.
seed a realistic table
10,000 rows of product data across 15 typed columns: text, enums, floats, integers, booleans, emails, urls, datetimes, ips, and tag arrays. Seeded with a deterministic PRNG keyed on the row index.
pick a realistic query
Filter by category, threshold on rating, order by reviewCount, limit 25. A categorical filter, numeric threshold, sort, and limit — the shape caching is designed to help.
run it twice
Phase one issues 100,000 calls with ttl = 0. Phase two issues the same 100,000 calls with ttl = 300. One connection, sequential, timed with performance.now().
measure everything
Per-request latency, sorted into min, p50, p90, p95, p99, and max. Total wall clock. Requests per second. Then the deltas.
One parameter.
Enabling the cache is adding a single field to your existing listRows call. The SDK, endpoint, and query stay the same.
const rows = await tablesDB.listRows({
databaseId: '<DATABASE_ID>',
tableId: '<TABLE_ID>',
queries: [
Query.equal('category', 'electronics'),
Query.greaterThan('rating', 3.5),
Query.orderDesc('reviewCount'),
Query.limit(25)
],
ttl: 300
});Every metric, in one grid.
results/2026-04-20_23-56-24.md.