Skip to content

2026

A tested foundation

fdyno's correctness argument is short, and most of it is not about fdyno. The server is a thin, stateless translator: it maps the DynamoDB wire protocol onto FoundationDB transactions and holds no durable state of its own. Isolation, durability, atomic commit, and crash recovery are not properties fdyno implements; they are properties it inherits. So the interesting question is why FoundationDB's guarantees can be trusted, and the answer is an unusually rigorous methodology: deterministic simulation.

Strict serializability on FoundationDB

A DynamoDB-compatible API can be implemented over almost any storage engine, and the isolation a client actually gets is decided entirely by that engine. fdyno runs on FoundationDB, which provides strict serializability, the strongest model in the standard hierarchy. This post traces how that guarantee reaches the wire, what it rules out, and what it costs.

  • in Indexes
  • 3 min read

Secondary indexes that never lag

DynamoDB's global secondary indexes are eventually consistent: a write to a base table propagates to its GSIs asynchronously, so a query against a GSI can briefly miss an item that a GetItem on the base table already returns. fdyno maintains every index inside the same transaction as the base write, so this window does not exist. That choice buys a simpler mental model and costs throughput; both halves are worth spelling out.