SOLUTION · REPLICATE TO DYNAMODB

Real-time data replication to Amazon DynamoDB from your operational databases

Committed changes from your relational and document databases land in DynamoDB tables continuously, through the AWS SDK, instead of through export jobs and stream consumers you maintain.

Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, MySQL, MongoDB, and other heterogeneous sources with a dedicated agent per database, then writes them to Amazon DynamoDB through a target agent that embeds the official AWS SDK for Java and Kotlin, with TLS on every connection. A snapshot seeds each table, CDC follows in real time, and Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API.

Start a Gluesync trial Talk to us

WHO THIS IS FOR

Teams that need DynamoDB items to follow the source as it changes

Backend and serverless engineers whose services read DynamoDB and need items that track the source rows, without a Lambda or Kinesis consumer to write and keep alive for each table
Data platform leads who run DynamoDB beside relational and document systems and want one Core Hub for every source, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects moving read traffic or whole workloads from Oracle, SQL Server, or PostgreSQL to DynamoDB, who need the snapshot, the CDC handoff, and a live copy settled before any cutover
Engineers retiring a Kafka Connect DynamoDB sink or a set of export scripts, who want every source delivered to DynamoDB by one product, with snapshots, checkpoints, and monitoring built in

THE PROBLEM

DynamoDB tables fed by exports and custom consumers drift from the source

DynamoDB tables that mirror operational data are usually loaded by scheduled exports or by consumer code: a job queries the source and writes items on a timer, or a function reads a change feed and calls the AWS SDK itself. Readers see the state of the business at the last run, every export adds load to the production database, and each source ends up with its own code, retry logic, and failure mode. Teams looking for real-time DynamoDB ingestion usually weigh AWS Database Migration Service, DynamoDB Streams with Lambda or Kinesis consumers, a Debezium and Kafka Connect sink, or scripts they keep running themselves.

Gluesync addresses that with per-agent CDC into DynamoDB. A source agent reads each database's native change log or change stream, Core Hub routes the changes, and the DynamoDB target agent writes them through the AWS SDK. Oracle to DynamoDB and MongoDB to DynamoDB run on the same pipeline model, the same snapshot, and the same operations.

HOW IT WORKS

How Gluesync writes to DynamoDB

The write path: the AWS SDK, in optimized batches

The DynamoDB agent embeds the official AWS SDK for Java and Kotlin, so there is no JDBC driver, sink connector, or consumer function to deploy beside it. It is a target agent: it receives changes from any Gluesync source agent and writes them to your DynamoDB tables in the region you configure.

Optimized batches, never row by row: Core Hub groups incoming changes into batches before the agent writes them, which cuts network round-trips to DynamoDB and keeps write load predictable. The batch size is configurable on the target agent.
TLS by default: every connection from the agent to DynamoDB is encrypted, with no extra setting to enable.
One agent for both directions: the same Amazon DynamoDB agent also captures changes when DynamoDB is the source. Amazon DynamoDB agent overview ↗

Snapshot first, then continuous CDC

Seed, then stream: each entity loads the full source table into DynamoDB, then switches to CDC from the source agent's change mechanism, with inserts, updates, and deletes applied as they arrive.
Parallel snapshot writes: snapshot writing concurrency is configurable per entity, and logical partitioning splits large source tables into ranges read in parallel.
Resume: an interrupted snapshot resumes from its last saved state when you start the entity again.
Scheduled refreshes: the Chronos Scheduler runs snapshots, or a snapshot followed by CDC, on a schedule for tables you prefer to reload on a cadence. See schedules and events.

Items, keys, and what reaches each table

Write by key: a write to a key that already exists replaces that item, so a duplicate-key error cannot arise and there is no conflict setting to tune on DynamoDB entities.
Allowed Operations: choose per entity which of INSERT, UPDATE, and DELETE reach DynamoDB, for example to keep an archive table that only accumulates items.
Shaping on the way in: Unlock Schema, Custom Field Functions, and UDFs rename fields, change types, compose attributes, or reshape records before they are written, and row filters keep only the items a service needs. See data transformation.
Operations in one place: Core Hub shows the state of every DynamoDB entity, and the Notifications Hub reports pipeline events beside those of your other targets.

What your AWS admin sets up

The agent authenticates with an IAM access key pair and connects to the region where your tables live. Full steps are in the DynamoDB target setup guide ↗.

Create an IAM user for Gluesync and attach the AmazonDynamoDBFullAccess managed policy.
In the IAM console, create an access key for that user and keep the access key ID and the secret access key.
Note the name of the AWS region where your DynamoDB tables are, for example eu-west-1.
In Core Hub, add the DynamoDB agent and enter the Region, Access Key, and Secret Key. The same values can be set through the Core Hub REST API.

Architecture around Core Hub

Lightweight agents sit close to each source; Core Hub orchestrates them through its web UI and REST APIs and routes changes to the DynamoDB agent. A pipeline groups a source agent, the DynamoDB agent, and the entities they replicate, so one Core Hub can run an Oracle pipeline and a MongoDB pipeline into the same AWS account.

Core Hub and the agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud, so the agents can run inside AWS next to DynamoDB or in the data center next to the source. See CDC streaming.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The DynamoDB target agent: one agent, one write path

DynamoDB has one Gluesync target agent. Every entity writes through the AWS SDK in optimized batches, so the choice you make per pipeline is which source agent captures each table and which operations reach DynamoDB.

Agent	Write technique	Versions	Best for
Amazon DynamoDB agent ↗	Official AWS SDK for Java and Kotlin over TLS, batched writes by key	All versions, in any AWS region where DynamoDB is deployed	Operational data that services read from DynamoDB as it changes: serverless backends, high-traffic read models, and workloads moving off relational systems. Pair any Gluesync source agent with it under the same Core Hub.

SOURCES AND TOPOLOGIES

Feed DynamoDB from the systems of record you already run

Any Gluesync source agent can feed DynamoDB, each with its own native capture technique. Open the integrations finder with DynamoDB pre-selected to see every source you can pair with it. To capture changes out of DynamoDB instead, see DynamoDB CDC.

Freshness follows the capture method of each source agent and the write capacity you provision on each table, and Gluesync keeps pace with your change volume at any scale. MOLO17 Professional Services can plan the topology and the table capacity with your team.

Oracle to DynamoDB from the redo logs through LogMiner or XStream: see Oracle CDC
SQL Server to DynamoDB through Change Data Capture or Change Tracking: see SQL Server CDC
PostgreSQL and MySQL to DynamoDB from the WAL and the binlog: see PostgreSQL CDC and MySQL CDC
MongoDB and Couchbase to DynamoDB from Change Streams and the Couchbase DCP stream: see MongoDB CDC and Couchbase CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among DynamoDB ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
AWS Database Migration Service	Managed migration and ongoing replication inside AWS, with DynamoDB among its targets and replication instances you size and run	Agents you deploy next to each source, on-premises or in any cloud, native capture per engine, and one Core Hub for every DynamoDB pipeline; see migrating to Gluesync
DynamoDB Streams with Lambda or Kinesis consumers	A native change stream on the DynamoDB side; getting changes from other databases into DynamoDB is consumer code you write, deploy, and monitor	Gluesync reads each source's own change log and writes to DynamoDB through the AWS SDK, so there is no consumer to own; see log-based CDC explained
Debezium with a Kafka Connect DynamoDB sink	Open-source capture into Kafka topics, then a sink connector writes items to DynamoDB; you run Kafka, Connect, offsets, and schemas	Changes go to DynamoDB with no Kafka cluster in the path, and Kafka stays available as another target; read the Debezium alternative comparison
Striim, Qlik Replicate, and similar commercial platforms	Commercial replication platforms with broad source and target catalogs; packaging and licensing differ by product	A dedicated capture agent per database, one Core Hub, and MOLO17 enterprise support behind every DynamoDB pipeline
Export scripts that call BatchWriteItem	Full control over mapping and timing; your team owns retries, throttling, ordering, and the load each run puts on production	Continuous CDC from the source log, batched writes, snapshot resume, and Core Hub monitoring with no pipeline code to maintain; read batch ETL vs real-time replication

DynamoDB replication background and deployment detail

What does replicating to DynamoDB with Gluesync involve?

A source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and the DynamoDB target agent writes them to DynamoDB continuously after a snapshot seeds each table.

How does Gluesync write to DynamoDB?

Through the official AWS SDK for Java and Kotlin, embedded in the agent, over TLS. Changes are grouped into optimized batches with a configurable size, never written one row at a time, and applied as they arrive.

Which sources can replicate to DynamoDB?

Any Gluesync source agent, including Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, IBM Db2, SAP HANA, MongoDB, and Couchbase. The integrations finder on our website lists every pairing.

What happens when a change targets a key that already exists in DynamoDB?

The write replaces the existing item, so a duplicate-key error cannot arise. That is why DynamoDB entities have no On duplicate key setting to choose.

Which AWS permissions does the agent need?

An IAM user with the AmazonDynamoDBFullAccess managed policy and an access key ID and secret access key for that user. In Core Hub you enter those keys and the region where your tables are.

Are deletes replicated to DynamoDB?

Yes. After the snapshot, inserts, updates, and deletes from the source are applied continuously as they arrive. Allowed Operations can stop deletes from reaching a table that should only accumulate items.

Which DynamoDB deployments are supported?

DynamoDB in any AWS region where the service is deployed, with all versions supported. The agent connects over TLS using the region name and the access key pair.

REPLICATE TO A TARGET