Skip to content

Tradeoffs

fdyno implements the DynamoDB protocol on FoundationDB. It does not reproduce the AWS services around DynamoDB.

Each section states the implementation, its limitation, its result, and the required operator action. Verify exact values in Limits and API coverage in Compatibility.

FoundationDB is the only durable data plane

Implementation. fdyno maps tables, items, indexes, stream records, tokens, and backup objects into FoundationDB directories, tuples, transactions, and versionstamps. It does not maintain a second local database or pluggable storage abstraction.

Limitation. Every data request depends on FoundationDB reachability and transaction limits. Operators must deploy, upgrade, secure, monitor, replicate, and back up a FoundationDB cluster. An alternative storage engine would need a new implementation of ordering, conflicts, atomicity, and versionstamps rather than a driver swap.

Result. The service uses FoundationDB's strict-serializable transactions and recovery system instead of building another consensus and replication layer. fdyno processes remain replaceable, and item/index/stream mutations share one native commit boundary.

Operator action. Use fdyno only if the team already operates FoundationDB or explicitly wants FoundationDB as the transactional store. Otherwise, include FoundationDB ownership in the adoption cost; test cluster failure and native restore before relying on that cluster for recovery. See Architecture and Durability & recovery.

Secondary indexes and streams are synchronous with writes

Implementation. Existing secondary-index entries and change-stream records are written inside the item mutation's FoundationDB transaction.

Limitation. Every projected index and stream image adds encoding, keys, values, conflict ranges, and bytes to the foreground transaction. More indexes and NEW_AND_OLD_IMAGES can increase write latency or push an otherwise valid logical request beyond FoundationDB's size/value limits. A new GSI still needs a multi-transaction backfill.

Result. After a successful normal write, applications do not wait for active GSI propagation or an asynchronous capture worker. A process crash cannot land between the base commit and its associated active-index or stream-record commit.

Operator action. Use this design when immediate derived-state consistency matters more than minimizing write work. Project only attributes that access patterns need, choose the smallest stream view, keep transactions small, and wait for a new GSI to become ACTIVE. See Data model, Change streams, and Limits.

Reads use current FoundationDB transactions

Implementation. Normal fdyno reads use FoundationDB transactions even when a DynamoDB request omits ConsistentRead or sets it to false.

Limitation. There is no eventually consistent replica path and no process-local stale-read fallback. If FoundationDB cannot provide a read version, reads fail. Applications that expect visible eventual-consistency states or use read mode as a capacity/cost control will observe different behavior.

Result. Each point read or response page uses one current MVCC snapshot and cannot be ordered before a write that completed before the read began. Active indexes do not introduce asynchronous propagation lag.

Operator action. Use this read path when the application requires consistency over detached availability. Size the FoundationDB read path for all traffic and design explicit application caches if stale reads are acceptable. Do not mistake the stronger per-page behavior for a cross-page snapshot; see Consistency model.

One FoundationDB deployment defines consistency and failure

Implementation. fdyno has no global-table or cross-Region replication layer. All transactions operate in the attached FoundationDB database.

Limitation. There is no fdyno-level active-active Region failover, asynchronous remote replica, conflict reconciliation, or global-table API. WAN placement and the latency/availability consequences of a FoundationDB topology are operator concerns.

Result. Atomicity and strict serializability have one transaction and commit-order domain. fdyno does not claim cross-Region semantics it cannot verify.

Operator action. Use this topology only when one cluster or site is the data domain. If the application requires DynamoDB global tables, test an external replication design or do not migrate. See Compatibility.

Self-hosting replaces AWS-managed operations

Implementation. fdyno supplies a server binary, health endpoints, process-local JSON and Prometheus fixed-bucket metrics, and bounded maintenance workers. It is not a managed database service.

Limitation. Packaging, TLS, load balancing, secret delivery, rollouts, admission control, dashboards, alerts, FoundationDB maintenance, and restore drills belong to the operator. The repository publishes no availability SLO, supported upgrade matrix, RPO, or RTO. Fixed-bucket metrics are process-local, not durable telemetry or a cluster aggregate. Six worker families report surfaced error attempts, but zero is not health proof and backlog/backup-age coverage remains open.

Result. Deployment topology, data location, infrastructure access, and upgrade timing remain under operator control. Several stateless fdyno processes can share one durable backend without per-process data replay.

Operator action. Assign an owner and define acceptance tests. Put multiple fdyno processes behind a private TLS and authentication layer. Monitor FoundationDB separately. Test backpressure, process failure, cluster failure, and restore. Use Deployment & operations to check deployment requirements. It does not provide a managed-service SLA.

Capacity metadata is compatible, not enforced

Implementation. Provisioned/on-demand fields and consumed-capacity response shapes are implemented for client compatibility, but fdyno does not meter request units, throttle, or apply DynamoDB account/table quotas.

Limitation. ProvisionedThroughput, BillingMode, consumed-capacity totals, and DescribeLimits are not admission-control or billing signals. Overload reaches Go process memory and FoundationDB and may appear as rising latency, transaction errors, timeouts, or unavailability rather than ProvisionedThroughputExceeded. Adding fdyno replicas can increase pressure without adding backend capacity.

Result. A self-hosted deployment does not use the AWS request-unit capacity model. Operators can size directly for their hardware, FoundationDB topology, and workload.

Operator action. Provide infrastructure-level capacity management. Add rate/concurrency control at the proxy or client, monitor backend headroom, and test overload behavior. Applications whose correctness or autoscaling loop depends on DynamoDB throttling require adaptation.

Stream shard count is fixed per generation

Implementation. The environment supplies a default count from 1 through 100 when fdyno enables a stream generation. Table metadata stores the selected count and generation identity. Partition-key hashing assigns each key to one static shard.

Limitation. Shards do not split or merge. Changing the count requires disabling and re-enabling the stream, which starts an empty generation and invalidates old iterators. One hot partition key cannot be divided without breaking per-key order.

Result. One partition key stays in one shard, and its records follow commit order. A single-shard generation provides one table-wide stored order.

Operator action. Choose the count before enablement. Read the persisted shard set through DescribeStream, checkpoint per shard, and monitor lag outside fdyno. See Change streams.

Table backup stores a snapshot, not history

Implementation. fdyno reserves one immutable backup generation, reads bounded pages at one pinned FoundationDB version, verifies page chunks, and publishes only after the generation is complete. Large restores use durable progress, readiness gating, leases, and fencing; interrupted work can resume on another instance.

Limitation. The pinned source version can age out. Backup objects share the source cluster's loss domain. Historical PITR is unsupported and rejected; the API does not copy current state while claiming a requested historical time.

Result. The API provides bounded-memory table-copy and same-cluster recovery with a consistent source version and rebuilt indexes. Independent disaster recovery still requires FoundationDB-native backup to another failure domain.

Operator action. Use it for bounded table copies while the cluster is healthy. Use FoundationDB-native backup to independent storage for cluster disaster recovery, and use a real history source when historical rewind is required. Exercise restore, not only backup creation. See Backup & restore.

SigV4 checks static credentials; IAM is not implemented

Implementation. fdyno verifies SigV4 requests against static access-key/secret pairs. Resource-policy documents can be stored, but they are not in the authorization path.

Limitation. There is no IAM, STS, session-token validation, account isolation, ABAC, per-table authorization, KMS integration, or built-in TLS. Every accepted key can access every exposed table, and credential rotation requires process replacement.

Result. AWS SDK signing works with the configured static credentials.

Operator action. Deploy behind a private network and an external TLS and authorization layer. Use separate FoundationDB databases when tenants require a hard data boundary. The current implementation cannot serve workloads that require endpoint-level IAM. See Deployment & operations.

AWS-managed services are not implemented

Implementation. fdyno implements tested DynamoDB JSON actions, validation, expressions, and SDK behavior. A routed request target does not mean that fdyno performs the AWS-managed integration.

Limitation. PartiQL is a tested subset. Kinesis destination and Contributor Insights surfaces are metadata-only; global tables, historical PITR, S3 import/export, IAM, KMS-backed SSE, and dynamic stream lineage are absent. Rare validation ordering can differ outside conformance coverage.

Result. Existing SDKs, CLI commands, item models, conditions, queries, batches, and transactions can be reused for the tested behavior. fdyno does not claim external effects that it does not perform.

Operator action. Inventory every action and option used by the application, then run its integration suite against fdyno. Treat a routed target or successful metadata update as insufficient proof of an integration. The status matrix is in Compatibility.

Workload fit

Included patterns

These patterns fit the implemented API and one FoundationDB-backed consistency and failure domain:

  • uses tested DynamoDB CRUD, conditions, query/scan, indexes, batch, transaction, or PartiQL-subset paths;
  • benefits from strict-serializable transactions and synchronous active indexes;
  • fits one FoundationDB-backed consistency/failure domain; and
  • has a team and platform that can own FoundationDB, security, admission control, monitoring, and recovery.

Test before use

Run representative integration, load, and failure tests before committing when the workload depends on:

  • uncommon expressions or PartiQL forms;
  • many indexes, large projected items, image-bearing streams, or large transactions;
  • exact TTL reclamation, stream retention, or consumer-topology behavior;
  • large table backups/restores or interrupted maintenance recovery;
  • capacity/throttling signals, multi-tenant controls, or deployment-specific availability goals.

Use Limits to turn these into test cases and Guarantees to define the expected outcome.

Not included

fdyno does not provide these external capabilities:

  • IAM/ABAC/account isolation at the database endpoint;
  • DynamoDB global tables or fdyno-managed multi-Region replication;
  • historical PITR, independent in-cluster table backups, or S3 import/export;
  • Kinesis delivery, CloudWatch-managed integrations, or dynamic stream shard lineage.