Tables vs DynamoDB
You can use DynamoDB-compatible APIs so existing SDKs and tooling keep working. Under the hood, Skippr Cloud tables run on FoundationDB — not on Amazon DynamoDB. This page explains what that means for API shape, consistency, capacity, and change data.
Status: Preview — same op coverage as Tables. DynamoDB wire protocol is for convenience; it does not imply full AWS DynamoDB product parity.
What maps
| You send | Skippr Cloud Tables |
|---|---|
DynamoDB JSON (X-Amz-Target: DynamoDB_20120810.*) | Accepted on tables.eu-central-1.cloud.skippr.io (via gateway) |
SigV4 service name dynamodb, region eu-central-1 | Required for SigV4; Cloud JWT via gateway also works |
| Table / item / partition (+ optional sort) key model | Same concepts |
Attribute types S / N / B / BOOL / NULL / M / L / SS / NS / BS | Supported |
| Item size ≤ 400 KiB | Enforced |
GetItem / PutItem / UpdateItem / DeleteItem | Supported, including conditionals |
Query / Scan with pagination | Supported — prefer Query |
BatchGetItem / BatchWriteItem | Supported |
TransactWriteItems / TransactGetItems | Supported — each call is one ACID transaction |
| Global secondary indexes (GSI) | Supported; maintained in the same transaction as the base write |
TTL (UpdateTimeToLive / DescribeTimeToLive) | Supported |
Point your AWS SDK or boto3 at Skippr Cloud hostnames and credentials. Do not point them at amazonaws.com and expect Skippr Tables.
What differs (intentional)
Storage engine
Tables store data in FoundationDB. The DynamoDB protocol is a compat surface so familiar clients work — Tables are not a hosted DynamoDB cluster and are not an AWS DynamoDB bridge.
Consistency
| DynamoDB | Skippr Cloud Tables |
|---|---|
ConsistentRead=false can return eventually consistent data | All reads are strongly consistent (including when you send ConsistentRead=false) |
| GSI reads can lag the base table | GSI updates commit with the base write — index and base stay consistent after commit |
Responses may report approximated fields via the x-cloud-ignored header (reason strong_read_only). Safer than DynamoDB eventual reads; do not rely on stale-read behavior.
Capacity and billing metaphors
FoundationDB has no RCU/WCU model.
| DynamoDB field | Tables behavior |
|---|---|
ProvisionedThroughput / capacity numbers | Accepted as a no-op; reported in x-cloud-ignored (noop_capacity) |
| On-demand vs provisioned billing mode | Accepted; capacity numbers are not enforced |
ConsumedCapacity | Not a billing signal — treat as approximate or unused |
Do not size or throttle your app as if Tables were provisioned DynamoDB capacity units.
Change data (not DynamoDB Streams)
| DynamoDB | Skippr Cloud Tables |
|---|---|
DynamoDB Streams shard APIs (GetShardIterator, GetRecords, …) | Not offered — never |
Table streams enabled via StreamSpecification | Coming soon — change records go to Cloud’s table CDC log (not the AWS Streams API, not Cloud streams, not Cloud queue) |
If you need DynamoDB Streams shard consumers as-is, Tables will not satisfy that path.
Region and extras
| Topic | Tables (Preview) |
|---|---|
| Region | eu-central-1 only |
| Global tables / multi-region replication | Not offered |
| DAX | Not offered |
| Local secondary indexes (LSI) | Not in Preview |
PartiQL (ExecuteStatement, …) | Not in Preview |
| On-demand backup / PITR APIs | Not in Preview |
| Encryption with customer AWS KMS ARNs | Not applied in Preview (noop_sse_kms when sent) |
Auth and tenancy
Calls are bound to your Skippr Cloud account through gateway auth (SigV4 or JWT) and Cloud ABAC. Cross-account IAM resource policies and AWS account IDs are not the tenancy model.
Practical migration notes
- Keep the SDK — change endpoint, credentials, and region to Skippr Cloud. Service name stays
dynamodbfor SigV4. - Expect stronger reads — remove logic that depends on eventual consistency or GSI lag.
- Drop capacity planning — ignore throughput settings; watch
x-cloud-ignoredinstead of assuming silent success. - Rework stream consumers — DynamoDB Streams shard clients will not work; wait for Tables CDC (coming soon) or use another Cloud product for fan-out.
- Stay on one region — design for
eu-central-1only in Preview.