DynamoDB to PostgreSQL: How to Move Your Data
Move DynamoDB into PostgreSQL with Airbyte. How schema inference samples your table, strict cursor rules, and whether Postgres suits the volume.
Moving DynamoDB into PostgreSQL means turning a schemaless key-value store into typed relational columns, and the interesting part happens before any data moves. DynamoDB tables do not have schemas. PostgreSQL tables do. Something has to invent one, and that something is Airbyte's discovery phase.
This guide covers the managed path with Airbyte. Understanding how the schema gets inferred is the difference between a pipeline you trust and one that silently drops fields, and the relational destination makes that inference matter more than it would in a lakehouse.
DynamoDB to PostgreSQL at a glance:
Why move data from DynamoDB to PostgreSQL?
Two situations account for most of these pipelines.
The first is querying by something other than the key. DynamoDB is superb at fetching an item by its key and awkward at almost everything else: joins, aggregations, ad hoc filters. Replicating into Postgres gives internal tools and reporting a database that answers those questions without you adding secondary indexes to a production table.
The second is joining DynamoDB data to relational data that already lives in Postgres. If instead you are doing large-scale analytics across a very large table, a warehouse or lakehouse is the better destination, for reasons the volume section below covers.
What do you need before you start?
Two credentials decisions and two that determine whether the resulting tables are trustworthy:
AWS credentials, or better, an IAM role. Supply an access key ID and secret access key for user-based access, or omit both and the connector falls back to the default credentials provider, picking up the role attached to the workload running it. On self-managed Airbyte in EKS or ECS the second option is better: no long-lived keys in the configuration.
A cursor attribute that satisfies the rules. Incremental sync needs a top-level attribute, not one nested inside a map, of string or integer type, in ISO 8601 or epoch format, and never blank on any item. Single-table designs that bury timestamps inside nested attributes cannot use them without restructuring.
Knowledge of your sparse attributes. Discovery samples your table, so an attribute appearing only on items outside that sample will not reach Postgres. Ask your application developers what optional attributes exist rather than trusting the discovered schema.
A Postgres user with write permission. On the target schema. If you already run a Postgres destination on an older connector version, read the migration guide before upgrading, because downstream models referencing raw tables will need updating.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Postgres side before you begin.
How do you build a DynamoDB to PostgreSQL pipeline in Airbyte?
Step 1: Establish what the items actually contain
Sit down with whoever owns the table and list the attributes, including the optional ones and any that changed type over the years. This takes twenty minutes and it is the only way to check the discovered schema against reality, because a schemaless store cannot tell you what it should contain.
Step 2: Configure the DynamoDB source
Click Sources in the left navigation, then New Source, and select DynamoDB, following adding a source. Supply the region and either your access keys or nothing at all if you are using a role. Then review the discovered schema against your list from step 1 rather than accepting it, and refresh it after any deploy that adds attributes.
Step 3: Configure the PostgreSQL destination
Click Destinations, then New Destination, and select Postgres, following adding a destination. From version 3.0.0 the Postgres destination uses Direct Load architecture, writing records straight to final tables with no intermediate raw tables, and adds its own metadata columns including a JSONB column recording per-row typing changes.
Step 4: Create the connection and plan for deletes
Click Connections, then New connection, select your tables and a sync mode. The source is cursor-based rather than reading DynamoDB Streams, so deletions never reach Postgres and updates are only seen when they advance the cursor attribute. Decide now whether that matters, because a soft-delete flag in DynamoDB is far easier to add before an application depends on the copy.
Where deletions genuinely occur and you cannot add a flag, a periodic full refresh on the affected table is the remedy. On DynamoDB that is a full scan, which consumes read capacity, so schedule it deliberately rather than nightly out of habit.
How does the schema get invented?
The connector scans your table with a limit of 1,000 items. If the returned data exceeds 1MB it scans again with the same limit, repeating until it has at least 1,000 items. It then combines every top-level attribute it saw across those items and infers each attribute's type from its value.
Two consequences follow. An attribute appearing only on items outside that sample will not be in the catalogue and therefore not in Postgres: on a table where two percent of items carry an optional attribute, a sample drawn from the front of the table may miss it entirely. And the connector assumes an attribute has the same type everywhere, which DynamoDB does not enforce, so a field that is a number on older items and a string on newer ones behaves unpredictably.
Neither is a bug. They are the necessary cost of inferring structure from a store that has none, and they matter more against Postgres than against a lakehouse, because a relational destination gives you typed columns and no comfortable place to inspect what did not fit. Keep the metadata column Airbyte provides, which records per-row typing changes, and check it when something looks wrong.
Is PostgreSQL big enough for your table?
Airbyte is direct about this: Postgres is an excellent relational database but it is not a data warehouse, and Postgres destinations are recommended for small volumes of roughly 10GB or less, or for testing. Beyond that, expect slowdowns on large writes and watch memory, CPU and IOPS during syncs.
DynamoDB tables routinely exceed that, because the whole reason people choose DynamoDB is that it scales past what a single relational instance handles comfortably. Replicating a large production table wholesale into Postgres is therefore likely to be the wrong shape of project.
What works well is a subset: one table rather than a whole estate, or a recent window rather than all history. If somebody needs the entire table for analysis, that is a warehouse or lakehouse job, and the same DynamoDB source points at one without rebuilding anything.
Frequently asked questions
Does Airbyte use DynamoDB Streams for change data capture?
No. The source is cursor-based. Deletions are not captured and updates are only seen if they advance the cursor attribute.
Why is an attribute missing from my Postgres table?
Discovery did not see it in the sampled items. Refresh the source schema, and check whether the attribute is sparse enough that a 1,000 item sample would plausibly miss it.
Can I use a nested field as the cursor?
No. Cursor fields must be top level, string or integer, in ISO 8601 or epoch format, and never blank. Single-table designs that nest timestamps need a restructure or a full refresh.
How do I avoid storing AWS keys in Airbyte?
Omit both key fields and attach an IAM role to the workload running the connector. It then falls back to the default credentials chain.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. The work that is not clicking is checking the discovered schema against what your application actually writes.
Get your DynamoDB data into PostgreSQL
Check the discovered schema against what your developers say the items contain, pick a cursor that satisfies the rules rather than the one you wish worked, decide what a deletion should mean before an application depends on the copy, and be realistic about table size against the Postgres volume guidance.
Airbyte's connector catalog includes 700+ pre-built connectors, so the same DynamoDB source can feed a lakehouse when the volume outgrows a database. For that pairing, see DynamoDB to Databricks, and for another schemaless source landing in a relational destination, MongoDB to PostgreSQL.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.