DynamoDB-compatible layer over FoundationDB
DynamoDB API.
FoundationDB core.¶
Use standard AWS SDKs with fdyno. State-changing item writes commit with affected secondary indexes and, on stream-enabled tables, change records in FoundationDB transactions.
REQUEST PATH / DURABLE BOUNDARY
WRITE BOUNDARYitem + indexes + stream
READ MODELcurrent FDB snapshot
DEPENDENCYFoundationDB required
Current behavior
Implemented behavior¶
The endpoint accepts DynamoDB JSON requests from standard AWS SDKs. Support depends on the implemented behavior, not only on the action name.
| Area | fdyno behavior | Limit or difference |
|---|---|---|
| SDK and protocol | boto3, AWS SDKs, and the AWS CLI use SigV4 and DynamoDB attribute values against fdyno's endpoint. | Static credentials only; no IAM, STS, accounts, or resource-policy enforcement. |
| Items and expressions | CRUD, conditions, projections, nested paths, updates, Query, and Scan are implemented. |
Test uncommon expression forms against the conformance suites. |
| Secondary indexes | GSI and LSI entries commit synchronously with the base item. | New GSI backfill is multi-transaction and incomplete while CREATING. |
| Transactions | TransactGetItems, TransactWriteItems, conditions, cancellation reasons, and durable request tokens are implemented. |
The encoded operation must fit one FoundationDB transaction. |
| Change streams | Stream records commit with item mutations and are commit-ordered per static shard. | No dynamic shard splitting, iterator expiry, or exactly-once consumer effects. |
| PartiQL | The tested SELECT, INSERT, UPDATE, and DELETE subset is available. |
It is a purpose-built subset, not the complete PartiQL language. |
| Backup and recovery | On-demand table snapshots and durable restore jobs are available. | Snapshots share the FDB failure domain; historical PITR is rejected as unsupported. |
| Capacity | Capacity fields and response shapes are compatible. | Request units are not metered or throttled; operators own admission control. |
Open the compatibility table · Read exact limits · Read the conformance test evidence
Architecture facts
Architecture effects¶
| Implementation | Result | Limitation |
|---|---|---|
| FoundationDB is the only durable data plane. | fdyno processes can be replaced without replaying table state or running a second recovery system. | Every data request depends on the configured FoundationDB cluster. |
| Base-item, active-index, and enabled-stream writes share a transaction. | A successful state-changing write keeps the item and active indexes together and, when streams are enabled, commits its change record. | No-op mutations, disabled streams, and receipt replays need not create a new stream event; projections and images add foreground work. |
Reads use FoundationDB transactions even when ConsistentRead is omitted. |
Each point read or page uses one current MVCC snapshot. | There is no cheaper stale-replica path or offline-read mode. |
| Stream positions use FoundationDB versionstamps. | Records are ordered by commit within a shard. | Shard count is static deployment configuration and must be chosen before use. |
Read the architecture · Review guarantees · Read tradeoffs
Deployment boundaries
Included and excluded¶
This documentation site is public. Source and CI links point to a private repository and require access. fdyno provides the API layer; the following components are not included in the server:
| Included in fdyno | Not included; provide separately if needed |
|---|---|
| SigV4 verification against configured static credentials | IAM, account isolation, per-table authorization, credential rotation, and TLS termination |
| Stateless HTTP listeners and readiness probes | Load balancing, deployment packaging, rollout orchestration, and request-unit admission |
| FoundationDB-backed items, indexes, streams, and tokens | A FoundationDB cluster with the desired replication, encryption, backups, and failure-domain placement |
| Process-local JSON/Prometheus metrics and optional access logs | Centralized telemetry, alerting, and workload-specific admission limits |
| Same-cluster on-demand table snapshots | Historical PITR and independent off-host disaster recovery |
Configure the endpoint · Check feature scope · Review current benchmark coverage