Skip to content

Compatibility

fdyno implements the DynamoDB wire protocol and behavior. This page lists what is covered, where it differs from DynamoDB, and what is out of scope.

What's implemented

  • GetItem, PutItem, UpdateItem, DeleteItem
  • Query, Scan (with FilterExpression, ProjectionExpression, paging, parallel scan segments)
  • BatchGetItem, BatchWriteItem
  • TransactGetItems, TransactWriteItems (serializable + idempotent)
  • ExecuteStatement, BatchExecuteStatement, ExecuteTransaction (PartiQL)
  • Expression grammar: condition, update, filter, and projection
  • Legacy parameters (Expected, AttributeUpdates, KeyConditions, QueryFilter, ScanFilter)
  • CreateTable, DescribeTable, UpdateTable, DeleteTable, ListTables
  • Global and local secondary indexes (synchronous, strongly consistent)
  • TimeToLive configuration and lazy expiry
  • TagResource, UntagResource, ListTagsOfResource
  • Resource-policy storage APIs
  • DescribeLimits, DescribeEndpoints
  • DynamoDB Streams: ListStreams, DescribeStream, GetShardIterator, GetRecords, all four stream view types
  • CreateBackup, DeleteBackup, ListBackups, DescribeBackup
  • RestoreTableFromBackup, RestoreTableToPointInTime
  • DescribeContinuousBackups, UpdateContinuousBackups

Conformance suites

fdyno is checked against three independent black-box corpora, run in parallel on every commit (see .github/workflows/ci.yml):

Suite What it covers Tests passing
ScyllaDB Alternator Black-box API tests: items, expressions, indexes, streams, backup and restore, PartiQL 1,445
nubo-db/dynamodb-conformance Tiered API conformance, validation ordering, error messages 526
ExtendDB The portable, wire-protocol tests from AWS's ExtendDB adapter suite 821

Tests that depend on a backend-specific surface (for example a storage engine's internal configuration) are excluded so they do not count toward the totals.

fdyno targets DynamoDB's documented behavior, including error messages and response shapes. Features specific to a particular product rather than the DynamoDB wire protocol, such as a management console, IAM and ABAC APIs, or extended capacity reporting, are out of scope.

Differences from DynamoDB

fdyno is a single-cluster, single-tenant store. It differs from AWS DynamoDB in the following ways:

  • No account/IAM authorization. fdyno verifies SigV4 signatures but does not model AWS accounts, IAM policies, or resource-policy enforcement. Any caller with a valid signature can access any table. A resource ARN is interpreted under a single-tenant convention, so a foreign-account or malformed ARN does not produce a cross-account AccessDeniedException.
  • PITR is snapshot-on-restore, not historical time-travel (FoundationDB's MVCC window is far shorter than 35 days). See Backup & restore.
  • Streams use a single logical shard per table, ordered by versionstamp, rather than DynamoDB's multi-shard topology. See Change streams.
  • No request throttling / provisioned-capacity enforcement. Capacity is reported (ConsumedCapacity) to match DynamoDB's response shapes, but requests are not throttled.
  • No multi-Region global tables, S3 export/import, Kinesis delivery, contributor insights, or auto-scaling. These control-plane integrations are out of scope.

Secondary-index consistency

fdyno is stricter than DynamoDB in one respect: secondary indexes are strongly consistent. A global or local secondary index is written in the same ACID transaction as the base item, so it reflects a write as soon as that write commits. DynamoDB global secondary indexes are eventually consistent.

Several projects implement the DynamoDB API outside the AWS service. They share fdyno's self-hosted, wire-compatible goal but differ in storage model, consistency, and licensing.

Project Storage engine Secondary-index consistency License
fdyno FoundationDB (ordered, transactional KV) Strong (GSI + LSI) MIT
ScyllaDB Alternator ScyllaDB (LSM, shard-per-core) Eventual (GSI) AGPL-3.0
ExtendDB Pluggable (PostgreSQL, Cassandra, …) Backend-dependent Apache-2.0
DynamoDB local SQLite Eventual (GSI) Proprietary (AWS)
  • ScyllaDB Alternator is the DynamoDB-compatible API of ScyllaDB, a Cassandra-compatible, shard-per-core NoSQL database written in C++. Alternator layers the DynamoDB wire protocol over Scylla's log-structured storage and token-ring distribution. Its upstream black-box test suite is one of the corpora fdyno is checked against.
  • ExtendDB is AWS's open-source (Apache 2.0) DynamoDB adapter. It implements the DynamoDB API over a pluggable storage backend: PostgreSQL is the reference backend, with Apache Cassandra and others available through a backend interface. In a self-hosted deployment it does not include global tables, auto-scaling, DAX, or backup and restore. fdyno runs the portable portion of its conformance suite.
  • nubo-db/dynamodb-conformance is an independent, tiered conformance suite that checks DynamoDB-compatible endpoints down to exact error messages. fdyno passes its full set.
  • DynamoDB local is AWS's single-node tool for local development and testing.

fdyno targets a single backend, FoundationDB, rather than a pluggable interface. That backend is what provides its strongly-consistent secondary indexes, versionstamped change streams, and on-demand backup and restore through one transactional model.

Where implementations diverge

No two DynamoDB-compatible implementations agree on every detail. They converge on the common path (item CRUD, queries, conditional writes) but diverge on exact error wording, the order in which a request is validated, and edge cases such as key-schema checks, nesting-depth limits, and how consumed capacity is reported for transactional versus single-item operations. fdyno follows AWS DynamoDB's documented behavior for these details. Checking it against three independent corpora at once is what surfaces such divergences, since any single suite can encode its own implementation's quirks as if they were the specification.