Fivetran DynamoDB to Snowflake: what the connector lands, what it costs, and the alternatives worth pricing

Does Fivetran support DynamoDB to Snowflake?

Yes. Fivetran lists Amazon DynamoDB as a database source and Snowflake as a destination, and the mechanics of the pairing are documented plainly. For the initial sync, in Fivetran's words, "we scan through each of your selected tables one at a time to fetch your data." After that, "we use Amazon DynamoDB Streams to pull new and changed data at regular intervals." Deletes are recorded by setting a _fivetran_deleted column to TRUE rather than removing the row. Every other route into Snowflake, with what each one lands, is compared on our DynamoDB to Snowflake connector page.

What does Fivetran land in Snowflake from DynamoDB?

One JSON column per item, unless you change it. Fivetran offers two modes. Packed, the default, stores the whole item in a column called data. Unpacked "unpacks one layer of nested fields and infer types", so first-level attributes become columns while anything nested below them stays JSON. There is also a hard ceiling: a table with more than 1,000 first-level attributes has to stay packed. Single-table designs, where one DynamoDB table holds customers, orders and invoices under different key prefixes, can reach that ceiling faster than you would expect.

Fivetran's documented type mapping, and what it means once the data is in Snowflake:

The practical consequence is that the reporting layer is still a project. Payment amounts inside a payment map, line items inside a list, a customer email two levels down: all of them sit in VARIANT, and every dashboard either casts them on read or depends on a view someone maintains. That is a fine outcome if you planned for it. It surprises teams who bought a connector expecting tables.

What do I need to set up in DynamoDB for Fivetran?

Streams on every table, with both images. Fivetran's setup guide asks you to select "New and old images" and to repeat the steps "for every table that you want to sync", because comparing both images is how it captures deletes. It also needs an IAM role with DescribeStream, DescribeTable, GetRecords, GetShardIterator, ListTables and Scan on those tables.

Two AWS rules make this harder than it reads. A stream's view type cannot be edited after it is created: if a table already streams keys only to a Lambda, you disable that stream and create a new one, and every existing consumer has to move to the new ARN. And AWS says no more than two processes should read the same shard at once, so a table that already has two consumers will throttle when Fivetran becomes the third. Granting an outside vendor read access to production tables is also the kind of change auditors ask about, so it is worth logging the role and its scope wherever you track vendor access against your SOC 2 controls.

How much does Fivetran cost for DynamoDB to Snowflake?

It depends on how many distinct items change each month, and Fivetran does not publish a per-row rate. The bill is built from monthly active rows, counted per connection, plus a $5 base charge per connection that applied from 1 January 2026 (immediately on pay-as-you-go, at renewal on annual contracts). From the same date, deleted rows count toward active rows. For DynamoDB that last change matters more than usual, because tables that expire items with Time to Live generate a steady stream of removals, and each expired item is now a billable row. Snowflake then bills separately for the warehouse that applies each batch of changes. We keep a fuller breakdown of the model in Fivetran pricing: MAR, plans and the $5 base charge.

What happens if the Fivetran sync falls more than 24 hours behind?

It starts over. DynamoDB Streams keeps changes for 24 hours, and AWS warns that older records can be trimmed "at any moment". Fivetran's documentation says that when syncs fail beyond 24 hours it will "automatically trigger automatic re-syncs to make sure we capture the data changes." That protects the data, and it has a cost you should plan for: a re-sync is a table scan, and a scan consumes read capacity on the production table. Fivetran itself recommends "a high provisioned throughput read capacity" to avoid throttling. An S3 export, by contrast, uses no read capacity at all, which is why several alternatives below backfill from exports instead.

What are the alternatives to Fivetran for DynamoDB to Snowflake?

Five are worth pricing, and each wins a different job. There is no AWS zero-ETL integration into Snowflake (the DynamoDB zero-ETL targets are Redshift, SageMaker Lakehouse and OpenSearch), so every option here involves some pipeline.

If you are weighing the two best-known managed options more broadly, our comparison of Fivetran and Airbyte pricing at high volume covers how each one counts, and the general Fivetran alternative page covers the other sources.

When is Fivetran the right choice for DynamoDB?

When nobody on the team wants to operate a pipeline and a JSON landing is acceptable. Fivetran handles shard lineage, retries and the re-sync after an outage, and it records deletes, which Airbyte's DynamoDB source does not. If your analysts are comfortable writing views over VARIANT and your change volume is modest, it is a reasonable buy. It gets expensive, or awkward, in three cases: tables with heavy TTL churn now that deletes count as active rows, single-table designs that need splitting by entity, and reports that need typed columns for attributes nested more than one level down.

Can I get typed Snowflake columns from DynamoDB without writing views?

Yes, by typing in the pipeline instead of the warehouse. Adapters has you declare the attribute paths that matter once, casts each number with the scale you state, converts epoch fields with the unit you state, sends lists to child tables and keeps the raw item beside them. The demo at the top of this page maps a real DynamoDB order onto Snowflake columns. Plans are flat, from $49 a month, and not metered by rows. For every other source feeding the same warehouse, see Snowflake ETL tools, and if MongoDB also lives in your stack, the equivalent guide is MongoDB to Snowflake migration tools.