Skip to content

limitations.md

Latest commit

 

History

History
108 lines (82 loc) · 4.59 KB

limitations.md

File metadata and controls

108 lines (82 loc) · 4.59 KB
Raw

Limitations

ExtendDO is optimized for ExtendDB parity on Cloudflare Workers and Durable Objects. It is not a horizontally sharded Amazon DynamoDB service clone and it is not a full AWS service compatibility layer.

Topology Limits

  • CatalogDO is a single control-plane Durable Object. Account metadata, auth resources, settings, table registry, resource tags, and lifecycle jobs share this object.
  • Each logical table maps to one SQLite-backed TableDO. Items, indexes, streams, TTL metadata, backups, staged imports, export sessions, metrics, and single-table transaction state share that object.
  • TransactionCoordinatorDO coordinates cross-table transactions per account. It records idempotency fingerprints, participant state, durable commit/abort decisions, and recovery state.

This topology favors correctness and implementation simplicity over horizontal scale. There is no PartitionDO, IndexDO, or per-partition routing layer.

Request And Read Limits

  • DynamoDB JSON request bodies are capped at 16 MiB by the Worker entrypoint.
  • Management request bodies are capped at 128 KiB.
  • Scan and Query are executed inside one TableDO. They use SQL paging and bounded raw storage windows so large unbounded reads can return LastEvaluatedKey instead of materializing the entire table in one call.
  • Even with bounded windows, hot or large table scans still serialize through one Durable Object and can delay unrelated work for that table.

Background Work

Control-plane and maintenance work uses Durable Object state and alarms:

  • Table create, delete, restore, import, and export have durable lifecycle state.
  • Cross-table transaction materialization resumes from coordinator alarms and table read/write finalization.
  • TTL cleanup, stream retention, export upload, backup work, import staging, and metrics refresh share the same per-table object as foreground traffic.

Durable Object alarms provide recovery, but they are not a high-throughput job queue. Very large background jobs can take multiple alarm passes.

Import And Export

ExtendDO does not use ExtendDB's filesystem import/export runtime. It uses R2:

  • Imports read from an R2 object key in FileSource.Path.
  • Source R2 object identity is pinned before async processing.
  • Rows are staged and committed before the table is activated.
  • Exports write to generated R2 keys derived from the requested destination and export id.
  • Export sessions use snapshot-backed state and multipart R2 uploads.

The wire shapes are kept close to ExtendDB's DynamoDB-compatible behavior, but filesystem paths are intentionally not emulated.

Backups And Restore

  • Backups and export snapshots are table-local Durable Object state.
  • RestoreTableFromBackup is supported through the ExtendDB-backed storage path and hidden lifecycle states.
  • RestoreTableToPointInTime is intentionally unsupported because ExtendDB currently marks real PITR restore unsupported.

Secondary Indexes And TTL

  • Secondary indexes are maintained as rows inside TableDO.
  • Index reads use table/index cursor data for pagination, but all index state is still local to the table object.
  • Index rebuild and TTL metadata rebuild work can be expensive for large existing tables because the table object must inspect table rows.

Transactions

  • Single-table transactions run inside one table object's synchronous SQLite transaction path.
  • Cross-table write transactions use a durable two-phase protocol with prepared participant rows, item locks, durable coordinator decisions, and alarm-driven recovery.
  • If a coordinator decision cannot be reached or observed, locked-item operations fail fast instead of exposing partial writes.
  • TransactGetItems uses read barriers for cross-table reads.

This is designed to preserve all-or-nothing visibility as far as the current Durable Object topology allows. It does not provide AWS service-scale multi-region transaction behavior.

IAM-Shaped Auth And AWS Scope

ExtendDO keeps ExtendDB-scope IAM-shaped behavior: admins, accounts, users, groups, roles, inline policies, permissions boundaries, principal/resource tags, role sessions, access keys, SigV4 data-plane auth, and ExtendDB policy conditions.

AWS-only management features are removed from the public parity target:

  • Managed policies and policy versions.
  • MFA devices and MFA-backed role conditions.
  • OIDC/SAML providers.
  • Federated assume-role flows.
  • AWS Organizations context.
  • Request-tag condition keys.
  • Trusted network and FAS context headers.

Those routes should return 404 unless ExtendDB adds them upstream and ExtendDO chooses to import that scope.