DynamoDB to Snowflake: How to Move Your Data
Move data from DynamoDB to Snowflake with Airbyte. How schema inference samples your items, strict cursor rules, and the FLOAT versus NUMBER decimal decision.
Moving data from DynamoDB to Snowflake turns a schemaless key-value store into typed warehouse tables that analysts can query with SQL and join against the rest of your data. Airbyte does this with no code. Two decisions govern whether the result is trustworthy, and both are made before your first sync: how the connector infers a schema from data that has none, and which Snowflake type your numbers land in.
Get either wrong and the sync will still report success. The data will simply be incomplete or imprecise, which is a harder problem to notice than a failure.
How does Airbyte build a schema from a schemaless table?
The DynamoDB source runs discovery in three steps. It scans the table with a scan limit of 1,000, repeating the scan if the returned data set exceeds 1 MB, until it holds at least 1,000 items. It combines every distinct top-level attribute found across those items. Then it determines each attribute's type from the value it saw and maps it to an Airbyte type.
The documentation states the assumption plainly: the implementation assumes the same attribute present in different items has the same type and the same nested structure. Where every item shares a shape, that holds and the inferred schema is right.
Where it breaks is single-table design. If you store several entity types in one table, discriminated by a sort key prefix, attributes genuinely differ in type and presence between items. Attributes belonging to entity types absent from the sampled 1,000 records never enter the schema, so those fields never reach Snowflake. And where one attribute name carries different types across entity types, the inferred type is whichever the connector happened to encounter.
Check the discovered schema against a list of attributes you know exist before you trust the first load. If you run a single-table design, plan to separate entity types in a downstream model rather than treating the landed table as one clean entity.
What are the cursor rules for incremental sync?
The connector supports full refresh and incremental append, and does not replicate deletes. An item removed from DynamoDB stays in Snowflake until a full refresh replaces the table.
The cursor rules are strict. It cannot be nested and must be a top-level attribute on the item. It must never be blank. And it must be a string or an integer, because the connector derives the cursor type from the generated schema, reading a string cursor as ISO 8601 and an integer cursor as epoch time.
The documentation warns that outside those conditions, incremental results may be unpredictable and will depend entirely on DynamoDB's own comparison algorithm. Read that as a requirement rather than a caution: the cursor attribute must be present and populated on every item, without exception. If your items do not carry one, adding it at write time in the application is a smaller job than working around its absence later.
Set the decimal type before your first sync
The Snowflake destination has a Decimal Data Type setting controlling which Snowflake type is used for columns Airbyte types as a number. The options are FLOAT and NUMBER(38,9), and FLOAT is the default.
FLOAT is approximate binary floating point with roughly fifteen digits of precision, which suits scores and measurements. NUMBER(38,9) is exact fixed-point supporting up to 38 total digits, and Airbyte's documentation recommends it. It is what you want for money.
This matters more with DynamoDB than with most sources. DynamoDB's Number type is a single decimal type used for everything from counters to currency amounts, so the connector cannot distinguish a price from a page-view count. Every numeric attribute takes the same setting, which means one decision covers your whole table.
Change it before the first sync, because changing it afterwards is hazardous. Snowflake converts the column in place, switching to NUMBER(38,9) nulls stored FLOAT values carrying more than 29 integer digits without recording the change in the row's metadata, and precision lost during the original FLOAT load cannot be recovered. Only a full refresh restores the original values.
Configuring both ends
The source takes an AWS endpoint and a region. Credentials are optional in a useful way: supplying an access key ID and secret gives user-based access, while omitting both makes the connector use the default credentials provider and the role executing the container workload in AWS. On self-managed Airbyte running inside AWS, that avoids storing long-lived keys.
Two further settings prevent avoidable debugging. Reserved attribute names takes a comma-separated list of attributes colliding with DynamoDB reserved words or containing special characters, which catches common names such as status and size. And an option to ignore tables with missing read permissions lets a sync proceed over what it can read rather than failing outright. Note also that extraction is scan-based and therefore consumes read capacity, which matters on a provisioned-capacity table serving production traffic.
On Snowflake, create dedicated entities rather than reusing existing ones: a role, user, warehouse, database, and schema, with the role holding OWNERSHIP on the database. Airbyte publishes a setup script for this. Size the warehouse at X-Small with a sixty-second auto-suspend and dedicate it to syncs, since Snowflake bills per second and resumes the warehouse on every load. Because the DynamoDB source does not support namespaces, every table lands in the single schema you configure, so agree a naming convention first if you are syncing many tables.
Frequently asked questions
Why are some attributes missing in Snowflake?
Schema discovery samples roughly 1,000 items, so attributes appearing only outside that sample are not in the inferred schema. This is most common in single-table designs sharing one table across entity types.
Why are my numeric values slightly off?
The Decimal Data Type setting defaults to FLOAT, which is approximate. Switch to NUMBER(38,9) and run a full refresh, since in-place conversion cannot restore precision that was never stored.
Can I use a nested attribute as the cursor?
No. It must be a top-level attribute, never blank, and either a string in ISO 8601 format or an integer epoch value.
Do deleted items disappear from Snowflake?
No. The connector does not replicate incremental deletes, so a periodic full refresh is the only way to bring the destination back in line.
Get your DynamoDB data into Snowflake
Verify the inferred schema, set the decimal type before the first load, and make sure your cursor is top-level and always populated. For a relational source into the same warehouse, see our guide to PostgreSQL to Snowflake. For another document store, see MongoDB to BigQuery.
Integrate with 600+ apps using Airbyte
Move data from 600+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.