Skip to content

Performance

Code snapshot: 27 September 2026, 2b80a1ea. fdyno implements the DynamoDB API operations listed in Compatibility. The current code revision has no qualified sustained DynamoDB API capacity number or cross-engine ranking. Benchmark results from other revisions or short controls do not describe this revision's throughput or tail latency.

Current measurement coverage

Workload Implemented API behavior Current-revision measurement status
Strong GetItem, PutItem insert/overwrite, DeleteItem, and UpdateItem Signed item operations with the conditions and return shapes described in Compatibility. No repeated, offered-rate, end-to-end capacity series with calibrated client headroom and final-state checks.
Ordered base-table Query Ascending, descending, and sort-key predicates with bounded pages. No sustained current-revision capacity or statistical tail result.
Shared-key Get/Update mixes The individual API operations are implemented. No qualified mixed-workload throughput, ordering, or traffic-weighted coverage result.
Indexes, streams, TTL, transactions, and large items The supported API paths add work to a FoundationDB transaction. No general cost multiplier or cross-engine performance result.

An operation being implemented does not make a planned benchmark workload measured. Likewise, a passing code/mock proof is not a signed API result. No measured user-traffic weights establish that a chosen set of operations covers “80%” of workloads.

Performance-relevant behavior

  • Normal item mutations commit the base item, affected active index entries, and any stream record together. Index projections and stream images add work to the foreground transaction.
  • Reads use FoundationDB transactions, including when ConsistentRead is omitted. Each Query or Scan page is a separate read version.
  • Cached, unfiltered, TTL-disabled base-table Query on a table not in CREATING, with an explicit Limit at most 100, can overlap an ordinary metadata-revision read and range read. fdyno validates the revision before returning that result; other shapes use the regular path. This is not a Snapshot Query or a whole-transaction Snapshot callback.
  • fdyno has no DynamoDB request-unit admission or throttle mechanism. Hot-key conflicts, transaction limits, request deadlines, client load, and FoundationDB capacity can all affect latency and completion.
  • FoundationDB's memory storage engine still logs writes to disk. A single-process local cluster does not measure replicated failover or off-host durability.

What a capacity result needs

A useful API comparison pins the exact binary, FoundationDB version and topology, SDK settings, consistency mode, authentication enforcement, key/payload distribution, indexes, streams, and read/write proportions. It retains all offered requests, bounded drops, responses, errors, retries, unknown mutation outcomes, both scheduled-to-complete and dispatch-to-return latency, client headroom, server/DB resource signals, and a safe final-state oracle. Run repeated steady trials and offered-rate sweeps, and keep failed or interrupted trials in the evidence.

An unknown write outcome cannot count as verified goodput or be blindly replayed to make a final sum pass. Raw FoundationDB get/set/clear calls omit SDK, HTTP, SigV4, DynamoDB JSON, metadata, validation, indexes, and response work. They are diagnostic operations, not an API-equivalent performance floor or a networking-overhead measurement.

Use Operations for process-local metrics and load boundaries, and Reliable writes for ambiguous mutation handling. Measure the exact software and deployment topology before setting application admission limits.