How do I transfer data from DynamoDB to Snowflake?

Use one of three feeds. Export the table to S3 and load the files with COPY or Snowpipe, read DynamoDB Streams for changes, or route changes through Kinesis Data Streams into Snowflake Openflow. Managed connectors such as Fivetran combine a full scan with Streams. Decide which attributes become typed columns before the first load.

Does Snowflake have a DynamoDB connector?

Not a dedicated one. Snowflake's own route is the Openflow Connector for Amazon Kinesis Data Streams, which is generally available and reads a Kinesis stream that DynamoDB writes its changes to. Snowflake also documents a DynamoDB CDC pattern built on it. Dedicated DynamoDB sources come from Fivetran, Airbyte, Matillion, Estuary and Hevo.

Is there a zero-ETL integration from DynamoDB to Snowflake?

No. AWS offers DynamoDB zero-ETL integrations with Amazon Redshift, Amazon SageMaker Lakehouse and Amazon OpenSearch Service, and Snowflake is not on that list. Getting DynamoDB into Snowflake always involves an export, a stream consumer or a third-party connector, so the choice is about who runs that piece and what it lands.

How do I stream DynamoDB changes to Snowflake?

Turn on DynamoDB Streams or Kinesis Data Streams for DynamoDB, then consume it. DynamoDB Streams keeps each change once and in order per item for 24 hours. Kinesis keeps records longer but AWS warns they can arrive out of order and more than once, so the Snowflake MERGE has to deduplicate on ApproximateCreationDateTime.

Does exporting DynamoDB to S3 affect table performance?

No. AWS states that exports to S3 are asynchronous, do not consume read capacity units and have no impact on table performance or availability. They do require point-in-time recovery to be enabled, and AWS gives no SLA on how long an export takes, so do not schedule a Snowflake load that assumes a fixed finish time.

How long are DynamoDB Streams records kept?

Twenty-four hours. AWS says data older than that is susceptible to trimming at any moment. A pipeline into Snowflake that stops reading for longer than a day loses changes it can never recover from the stream, and the only fix is a fresh full load or an incremental export from point-in-time recovery.

Does Fivetran support DynamoDB to Snowflake?

Yes. Fivetran scans each selected table for the initial sync, then reads DynamoDB Streams, which must be enabled with new and old images on every table. By default it lands each item packed into a single JSON column named data, and tables with more than 1,000 first-level attributes must stay packed.

Should DynamoDB items land in Snowflake as VARIANT or as columns?

Both, for most teams. Keep the raw item in a VARIANT column so nothing is lost when the app adds an attribute, and project the attributes your reports filter, join and sum on into typed columns. DynamoDB has no date type and sends numbers as strings, so an untyped landing leaves every cast to the analyst.

How much does it cost to move DynamoDB to Snowflake?

Three lines add up. AWS bills exports by table size and incremental exports by data processed, with a 10 MB minimum. The connector bills by its own unit: monthly active rows plus a $5 base per connection at Fivetran, credits at Airbyte and Matillion. Snowflake then bills the warehouse time spent loading and merging.

DynamoDB to Snowflake Connector, Streams and CDC

Which DynamoDB to Snowflake connector should you use?

Choose by freshness and by what has to land. If hourly or daily data is enough, export the table to S3 and load it with Snowpipe: it uses no read capacity and costs little. If you need changes within minutes, read DynamoDB Streams or route them through Kinesis into Snowflake's Openflow connector, and plan the MERGE yourself. Managed connectors run all of that for you but land JSON by default. If your reports need typed columns for nested attributes, you either write and maintain the casting views, or use a mapped sync that lands the declared attributes as typed columns from the first load.

For every other source feeding the same warehouse, see Snowflake ETL tools. If the other NoSQL store in your stack is MongoDB, the same "what lands" question is answered on MongoDB to Snowflake migration tools.

Eight defaults, read from AWS, Snowflake and each vendor's own documentation

DynamoDB only enforces the key. Everything else in an item is whatever the application wrote that day, and Snowflake wants types for anything it can prune, sum or join cheaply. Every route has to bridge that gap, and the setup screens rarely say how. The documentation does. The last column is what we would ship.

Route and setting	What its documentation says	Why it matters to a buyer	What we would ship
Export to S3, DynamoDB JSON	Each line is an "Item" object in "DynamoDB's standard marshalled JSON format": every value sits inside a type descriptor, and a number is written as a string, for example {"N":"600"}.	Loaded into a VARIANT, a price lives at Item:Price:N and is text. Every report casts every attribute, or sorts "100" before "99".	Typed view that unwraps each descriptor
Incremental export	AWS: an item inserted and deleted inside the export window produces "No output". A delete arrives as Keys only, or Keys plus the old image.	A plain COPY appends deletes as half-empty rows and never sees short-lived items. Only a MERGE on the key reads it correctly.	MERGE on keys, Keys-only rows as deletes
DynamoDB Streams	AWS: "All data in DynamoDB Streams is subject to a 24-hour lifetime", and older data "is susceptible to trimming (removal) at any moment."	A consumer that is down over a long weekend comes back to a gap it cannot read. The pipeline resumes, green, from whatever is left.	Alert well inside 24 hours, reconcile after
Stream view type	AWS: "It is not possible to edit a StreamViewType once a stream has been setup." You disable it and create a new stream with a new ARN.	A connector that needs new and old images on a table set to keys only means a new stream, and every existing consumer must move to it.	Check the view type before the trial
Kinesis Data Streams for DynamoDB	AWS: records "might appear in a different order than when the item changes occurred" and "might also appear more than once in the stream."	A MERGE that applies changes in arrival order can overwrite a newer value with an older one, and silently.	Order by ApproximateCreationDateTime
Openflow Connector for Kinesis	Snowflake: "One connector supports only ingestion from a single stream", and past the stream's retention "expired records will not be loaded."	It lands the events, not a current-state table. The MERGE into one row per item is still yours to build and schedule.	Events table plus a merged current table
Fivetran, default	Packed mode is the default and stores the item as JSON in a data column. Unpacked "unpacks one layer". Over 1,000 first-level keys must stay packed. Sets land as JSON.	The same payload landing as the S3 export, minus the type descriptors. Anything below the first level is still JSON.	Choose columns per attribute path
Airbyte DynamoDB source	Sync modes are full refresh and incremental append. Replicating deletes is "not supported". Schema discovery samples up to 1,000 items per scan.	A deleted order stays in Snowflake forever, and an attribute the sample missed never becomes a column.	Full attribute inventory, explicit deletes

The row most teams discover too late is the first one. DynamoDB sends every number across the wire as a string "to maximize compatibility across languages and libraries", in AWS's words, and the export keeps it that way. A Snowflake table loaded straight from an export therefore holds prices, quantities and timestamps as text inside a type descriptor. What Fivetran does with the same table, and what it costs, is in our breakdown of Fivetran for DynamoDB to Snowflake, with the alternatives.

DynamoDB types in Snowflake, and the wrong target a default picks

DynamoDB has ten type descriptors and no date type at all. The second column is how each value travels. The last is the mistake we see most often, and none of them raise an error on load.

DynamoDB type	How it travels	Right Snowflake target	Common wrong target
N, whole numbers	{"N":"103"}, a string	NUMBER(38,0), cast from the string	VARCHAR, which sorts "100" before "99"
N, money	{"N":"19.99"}, a string	NUMBER with a fixed scale, such as (38,2)	FLOAT, which rounds cents in sums
N, very large	Up to 38 digits, exponent to E+125	FLOAT or VARCHAR, chosen on purpose	A NUMBER cast that fails past 38 digits
N, epoch time	Seconds or milliseconds, undeclared	TIMESTAMP with the scale stated, TO_TIMESTAMP(n, 3)	The raw number, or the wrong unit
S, ISO 8601 date	{"S":"2026-09-27T14:05:00Z"}	TIMESTAMP_TZ via TRY_TO_TIMESTAMP_TZ	VARCHAR compared as text
B, binary	Base64 text	BINARY via BASE64_DECODE_BINARY	VARCHAR holding the base64 string
SS, NS, BS sets	A JSON array, order not preserved	ARRAY, sorted before any comparison	Comparing arrays position by position
M, map	Nested descriptors, up to 32 levels	Typed columns for used paths, VARIANT for the rest	One column per key across 1,000+ keys
L, list	A JSON array of descriptors	A child table via FLATTEN, with position	A VARIANT nobody can join cheaply
Missing vs NULL	Absent key vs {"NULL":true}	Nullable column, VARIANT kept to tell them apart	Collapsing both into one NULL

The epoch row deserves a second look. AWS recommends storing timestamps as epoch numbers, partly because Time to Live needs them, and nothing in the item says whether a value is seconds or milliseconds. Snowflake's TO_TIMESTAMP guesses the unit from the size of the number when you do not pass a scale, which works until one table mixes both. State the scale in the cast. The general mechanics of stages, COPY and Snowpipe are covered in how to load data into Snowflake.

The six mechanisms behind "DynamoDB to Snowflake"

Three change feeds exist on the AWS side: exports, DynamoDB Streams and Kinesis Data Streams. Every product below is built on one of them, so the first question is which feed, and the second is who writes the typed layer on top.

Mechanism	Owner	How it moves data	Who it is for	What to watch
Export to S3, then COPY	AWS and Snowflake	Full or incremental exports from point-in-time recovery land gzipped JSON in S3. Snowflake loads them with COPY or Snowpipe.	Analytics that are fine at 15 minutes to daily.	Needs PITR. You write the MERGE.
DynamoDB Streams consumer	You, usually on Lambda	A function reads each shard in order and writes changes to Snowflake through a stage or Snowpipe Streaming.	Teams already running Lambda on the table.	24-hour retention, two readers per shard.
Kinesis plus Openflow	AWS and Snowflake	DynamoDB writes changes to a Kinesis data stream, and the Openflow Kinesis connector ingests it into Snowflake.	Snowflake shops wanting a first-party path.	Duplicates and reordering by design.
Managed ELT	Fivetran, Airbyte, Estuary, Hevo, Matillion	A scan for history, then Streams or a cursor for changes, written into Snowflake on a schedule.	Teams that want no pipeline to operate.	Packed JSON or sampled schemas. Metered bills.
AWS Glue job	You, on AWS Glue	A Spark job reads the table or its export and writes to Snowflake through the Snowflake connector.	Data engineers already on Glue.	Code to own. Deletes are your problem.
Mapped sync (Adapters)	Adapters	You declare attribute paths once, we land typed columns and lists as child tables, then sync changes incrementally.	Teams who want typed Snowflake tables on a flat bill.	Not a sub-second streaming platform.

DynamoDB Streams guarantees that each change appears exactly once and in order for each item. Kinesis trades both guarantees for longer retention. How those trade-offs compare with log-based capture on relational databases is laid out on change data capture tools.

DynamoDB to Snowflake connectors and integration tools compared

Billing units rather than price tags, except where the vendor publishes the number itself: Fivetran's $5 base charge per connection and Estuary's $0.50 per GB were read from their own pricing pages in September 2026. Everything else depends on your item counts and change rates, so we name the unit and leave the arithmetic to a quote. The last column says where each tool is the wrong buy, ours included.

Tool	Approach	Best for	Billing unit	What to watch
S3 export plus Snowpipe	Full and incremental exports, loaded from a stage	Batch analytics without touching table capacity	AWS per GB exported, Snowflake credits to load	Type descriptors on every value
Openflow Kinesis connector	Kinesis stream into Snowflake, GA	Snowflake-first teams wanting near real time	Kinesis, plus Openflow and Snowflake compute	One stream per connector; you merge
Lambda on DynamoDB Streams	Your code, per shard, in order	Small tables and teams comfortable with Lambda	Lambda invocations and your time	24-hour retention; retries are yours
AWS Glue	Spark job from the table or its export	Engineers already running Glue	DPU hours	A codebase, not a product
Fivetran	Scan, then Streams; packed or one layer unpacked	Teams who want zero operations	Monthly active rows, plus $5 base per connection	Packed JSON by default; rescans
Airbyte	Full refresh or incremental append on a cursor	Open source teams who can patch it	Free self-hosted, credits on cloud	No deletes; 1,000-item sample
Estuary	Continuous capture into Snowflake	Low latency with a short setup	$0.50 per GB moved plus connector instances	Ask how the backfill reads the table
Hevo	Managed pipeline with flattening	Smaller teams wanting a UI first	Plans by event volume	Ask how deep flattening goes
Matillion	DynamoDB source inside Snowflake ELT jobs	Teams already building in Matillion	Credits per task hour	Ask whether it scans or exports
Adapters	Mapped sync of declared paths to typed columns	Typed reporting tables on a flat bill	Flat monthly plan from $49	Not built for sub-second latency

Two costs rarely appear in a connector quote. The AWS side bills every export by table size and every incremental export by data processed, with a 10 MB minimum per export, so a 15-minute schedule on a quiet table still pays 96 minimums a day. And the Snowflake side bills the warehouse that runs each MERGE. For how the managed vendors price themselves across every source, see the best data integration tools and Fivetran against Airbyte on cost.

Six numbers worth knowing before you sign anything

24 hours

How long DynamoDB Streams keeps a change. Older records can be trimmed at any moment, so a consumer outage longer than a day is a permanent gap.

AWS DynamoDB Streams docs, read 27 Sep 2026

35 days

The longest point-in-time recovery window, and so the furthest back an S3 export can reach. It is configurable from 1 to 35 days.

AWS point-in-time recovery docs, read 27 Sep 2026

15 min to 24 h

The allowed window for one incremental export. Anything shorter or longer is rejected, and each export bills a 10 MB minimum.

AWS export to S3 docs, read 27 Sep 2026

38 digits

The precision of a DynamoDB number, which can still reach an exponent of E+125. Snowflake NUMBER also stops at 38 digits of precision.

AWS DynamoDB data types, read 27 Sep 2026

2 readers

The most processes AWS says should read one stream shard at once. A second connector on the same table can throttle the first.

AWS DynamoDB Streams docs, read 27 Sep 2026

0

DynamoDB zero-ETL integrations that target Snowflake. The three AWS offers go to Redshift, SageMaker Lakehouse and OpenSearch.

AWS DynamoDB integrations, read 27 Sep 2026

Eight ways this pipeline goes wrong while every check stays green

Change feeds are designed to keep moving, and that is usually right. It also means none of the failures below page anyone. We would check all eight before trusting a number from a new DynamoDB feed.

The failure	What you see	What is actually happening
The weekend gap	Pipeline resumes, no error	The consumer was down for more than 24 hours. DynamoDB Streams trimmed the oldest changes, and the tool carried on from what was left. Snowflake is missing those updates for good.
The order that never existed	Counts match exports	An item created and deleted inside one incremental export window produces no output at all. Harmless for current state, wrong for anyone counting orders placed.
Duplicates from Kinesis	Revenue slightly high	Kinesis Data Streams can deliver the same change twice. An append table summed without deduplicating on ApproximateCreationDateTime counts it twice.
Deletes that never arrive	Row counts only grow	Incremental append syncs cannot see a delete. Cancelled or purged items stay in Snowflake, and totals drift away from the application.
TTL expiry read as a user delete	Churn looks high	Items removed by Time to Live appear in the stream as removals made by the DynamoDB service itself. A pipeline that marks every removal as deleted mixes housekeeping with real cancellations.
Numbers kept as text	Dashboards render	DynamoDB sends every number as a string. Left as VARCHAR, sorting and MAX() work on characters, so "9" beats "10" and nobody notices until a total looks odd.
The attribute the sample missed	Sync green	Schema discovery read a sample of items. An attribute that only newer items carry never became a column, although every item was copied.
A rescan against production	App slows, sync recovers	After a stream outage, a connector re-syncs by scanning the whole table. A scan uses read capacity that an S3 export would not have touched.

Four of the eight are about deletes and time: what the feed forgot, what it never saw, and what it recorded twice. The guard is the same for all of them, a reconciliation of keys and removals after every load. If you are moving off DynamoDB entirely rather than syncing it, the one-time version of this problem is covered by data migration tools.

Six steps that decide whether the Snowflake tables are usable

Step 1

Inventory every attribute, not a sample

Export the table to S3 once and count every attribute path, how often it appears and which type descriptors it carries. DynamoDB is schemaless beyond the key, so this is the only reliable list of what your Snowflake tables need to hold.

Step 2

Turn on point-in-time recovery

Exports need it, and it is your recovery path when a stream consumer falls more than 24 hours behind. Set the window deliberately, anywhere from 1 to 35 days, because it is also how far back a reload can reach.

Step 3

Pick the change feed per table

Incremental exports for tables where 15 minutes or an hour is fresh enough. DynamoDB Streams for ordered, exactly-once changes inside 24 hours. Kinesis when you need longer retention and can deduplicate. Write the choice down per table.

Step 4

Declare the landing shape

Typed columns for the attributes finance and product reports use, VARIANT for the rest, and child tables for lists of line items. State each number's scale and each epoch field's unit before the first load, not after the first wrong total.

Step 5

Load history, then merge changes

Backfill from a full export so production capacity is untouched, then apply changes with a MERGE on the partition and sort key. Decide whether Snowflake holds current state, full history, or both, and how TTL expiry is flagged.

Step 6

Reconcile counts and deletes

Compare the export manifest item count with distinct keys in Snowflake, and removals in the change feed with rows flagged deleted. It is the only check that catches a stream gap, a missed delete or a duplicate.

Why US teams pay to connect DynamoDB to Snowflake

Product analytics on app data

The application runs on DynamoDB for its latency, and the analytics team lives in Snowflake. They need orders, sessions and users joined, fresh within the hour, without a single scan against production.

Finance reporting from a key-value store

Payments, refunds and subscriptions are items with nested maps. Finance needs them as NUMBER columns with a fixed scale that tie out to the ledger, not strings cast on every query.

Joining DynamoDB with SaaS data

Customer items need to meet Salesforce, HubSpot and Stripe data already in Snowflake. The join keys have to be clean typed values, not strings pulled out of a type descriptor.

Retiring a Lambda someone wrote in 2021

A function on the stream writes CSVs to S3 and fails quietly whenever a shard splits. The team wants retries, alerts and a view of every record, not a function nobody owns.

Single-table designs

One DynamoDB table holds customers, orders and invoices under different key prefixes. Snowflake needs them split into separate typed tables by entity, which no default connector does.

Audit and retention

Compliance wants every change to certain items kept for seven years, far past the 35-day recovery window. An append-only history in Snowflake, with a current-state view on top, gives them both.

Five jobs where you should not pick us

A comparison page that never says the competition wins is an advert. These are the cases where something else on this page is the better buy.

You only need a nightly copy of a few tables for ad hoc analysis. A scheduled S3 export loaded with COPY costs very little, touches no read capacity and is fully documented by AWS and Snowflake.
Your team is Snowflake-first and happy to own the MERGE. The Openflow Kinesis connector is generally available and first-party, and a deduplicating MERGE is a well-known pattern.
Your warehouse could just as well be Redshift. The DynamoDB zero-ETL integration with Redshift replicates within minutes with no pipeline to run, which no Snowflake route matches.
You need sub-second latency from a DynamoDB write to a Snowflake row. Streaming platforms built for that will beat our incremental sync.
Your items change shape every sprint and nobody knows which attributes matter yet. Land raw VARIANT with any tool here and come back to typed columns once the reports settle.

Four questions to ask any vendor on this list

Question 01

What exactly lands in the Snowflake table?

Ask for the DDL of one real table after a test sync. A single JSON column, first-level columns only, a schema from a sample, or typed nested paths are all possible answers, and each leads to a different amount of SQL for your analysts.

Question 02

How are deletes and TTL expirations represented?

Removed, flagged, or never seen. Ask whether an item expired by Time to Live is treated like a user delete, because the stream records it as a removal either way and only the identity on the record tells them apart.

Question 03

What happens after a stream outage longer than 24 hours?

A silent gap, a full rescan that uses table read capacity, or a reload from an S3 export that does not. Each answer is fine if you know it in advance. The first one is the expensive surprise.

Question 04

What do you need changed on our DynamoDB tables?

Streams turned on with a specific view type, point-in-time recovery, IAM roles, sometimes more read capacity. A view type cannot be edited in place, so find out before you touch a table other consumers already read.

Related Snowflake and NoSQL guides

The Fivetran breakdown for this route, the other NoSQL routes into warehouses, and the Snowflake pages for the rest of your sources.

Questions buyers ask about DynamoDB to Snowflake

How do I transfer data from DynamoDB to Snowflake?: Use one of three feeds. Export the table to S3 and load the files with COPY or Snowpipe, read DynamoDB Streams for changes, or route changes through Kinesis Data Streams into Snowflake Openflow. Managed connectors such as Fivetran combine a full scan with Streams. Decide which attributes become typed columns before the first load.
Does Snowflake have a DynamoDB connector?: Not a dedicated one. Snowflake's own route is the Openflow Connector for Amazon Kinesis Data Streams, which is generally available and reads a Kinesis stream that DynamoDB writes its changes to. Snowflake also documents a DynamoDB CDC pattern built on it. Dedicated DynamoDB sources come from Fivetran, Airbyte, Matillion, Estuary and Hevo.
Is there a zero-ETL integration from DynamoDB to Snowflake?: No. AWS offers DynamoDB zero-ETL integrations with Amazon Redshift, Amazon SageMaker Lakehouse and Amazon OpenSearch Service, and Snowflake is not on that list. Getting DynamoDB into Snowflake always involves an export, a stream consumer or a third-party connector, so the choice is about who runs that piece and what it lands.
How do I stream DynamoDB changes to Snowflake?: Turn on DynamoDB Streams or Kinesis Data Streams for DynamoDB, then consume it. DynamoDB Streams keeps each change once and in order per item for 24 hours. Kinesis keeps records longer but AWS warns they can arrive out of order and more than once, so the Snowflake MERGE has to deduplicate on ApproximateCreationDateTime.
Does exporting DynamoDB to S3 affect table performance?: No. AWS states that exports to S3 are asynchronous, do not consume read capacity units and have no impact on table performance or availability. They do require point-in-time recovery to be enabled, and AWS gives no SLA on how long an export takes, so do not schedule a Snowflake load that assumes a fixed finish time.
How long are DynamoDB Streams records kept?: Twenty-four hours. AWS says data older than that is susceptible to trimming at any moment. A pipeline into Snowflake that stops reading for longer than a day loses changes it can never recover from the stream, and the only fix is a fresh full load or an incremental export from point-in-time recovery.
Does Fivetran support DynamoDB to Snowflake?: Yes. Fivetran scans each selected table for the initial sync, then reads DynamoDB Streams, which must be enabled with new and old images on every table. By default it lands each item packed into a single JSON column named data, and tables with more than 1,000 first-level attributes must stay packed.
Should DynamoDB items land in Snowflake as VARIANT or as columns?: Both, for most teams. Keep the raw item in a VARIANT column so nothing is lost when the app adds an attribute, and project the attributes your reports filter, join and sum on into typed columns. DynamoDB has no date type and sends numbers as strings, so an untyped landing leaves every cast to the analyst.
How much does it cost to move DynamoDB to Snowflake?: Three lines add up. AWS bills exports by table size and incremental exports by data processed, with a 10 MB minimum. The connector bills by its own unit: monthly active rows plus a $5 base per connection at Fivetran, credits at Airbyte and Matillion. Snowflake then bills the warehouse time spent loading and merging.

For a relational source feeding the same warehouse, see the Postgres to Snowflake connector, and for the connector most teams trial first on this route, read what Fivetran lands from DynamoDB and what it bills.

DynamoDB to Snowflake connector, DynamoDB Streams to Snowflake and integration options, and what actually lands in the table