Skippr Docs

Appearance

What to Check Before Ingesting from DynamoDB ​

May 2026

DynamoDB ingestion starts cleanly when you decide up front whether you need a table scan, a CDC setup, or both, then verify the AWS permissions for that choice.

Short Answer ​

Before ingesting from DynamoDB, confirm the exact table_name, the AWS region, the credential source Skippr will use, and whether the first pipeline should be a batch scan or a CDC setup with DynamoDB Streams. Batch ingestion needs dynamodb:DescribeTable and dynamodb:Scan. If you want ongoing mutation capture, the docs call out additional Streams permissions, so it is worth deciding that before the first run instead of treating CDC as a small follow-up toggle.

A practical example is a customers-prod table in us-east-1. If the runner is pointed at us-west-2, the pipeline will look broken even with valid AWS credentials. If you are testing against LocalStack with endpoint_url, the endpoint has to be explicit or Skippr will call AWS instead of the local emulator.

Why Teams Struggle with This ​

DynamoDB is one of the connectors where the first question is operational, not syntactic. Teams often know the table name but have not settled whether they want a one-time scan, continuous change capture, or a staged rollout that starts with batch and adds Streams later.

  • Region mismatch is a common first-run failure because table names can be correct while the AWS client is looking in the wrong place.
  • Batch ingestion and CDC do not share the same permission profile; Scan alone is not enough if the real goal is Streams-based change capture.
  • LocalStack or other custom endpoints need endpoint_url, otherwise the connector will try the default AWS endpoints.
  • Credential-chain assumptions should be checked on the runner itself, especially when relying on IAM roles, AWS SSO, or shared profiles.

How Skippr Handles It ​

Skippr keeps the DynamoDB setup compact: identify the table, region, and optional endpoint, then choose whether the first phase is a direct item read or a CDC-enabled pipeline. That is helpful because the initial evaluation can stay narrow without locking you out of a later CDC setup.

The connector docs also make the permissions boundary clearer than many DynamoDB walkthroughs do. If the team knows which AWS principal will run the pipeline and whether Streams are in scope, the first ingestion plan gets much easier to review.

  • Straightforward DynamoDB source config with table_name, region, and optional endpoint_url.
  • AWS default credential-chain support so the pipeline can use keys, IAM roles, or SSO-backed access.
  • Batch-read prerequisites called out directly through DescribeTable and Scan permissions.
  • CDC expansion path through DynamoDB Streams when the first ingestion needs to become an ongoing pipeline.

What the First Useful Version Looks Like ​

The first useful DynamoDB ingestion is often a single-table read in the right region with the AWS identity verified from the same runtime environment that will execute Skippr.

If the team already knows it needs fresh mutations after the initial load, decide that now and verify Streams access before you treat the first scan as complete.