SOLUTION · REPLICATE TO REDIS

Real-time data replication to Redis from your operational databases

Committed changes from your systems of record reach Redis as they happen, written in optimized batches as Redis hashes, instead of waiting for the next scheduled key refresh.

Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, MySQL, MongoDB, and other heterogeneous sources with a dedicated agent per database. The Redis target agent writes them through the Lettuce Java client, one Redis hash per row, after a snapshot seeds the keys. 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 Redis to follow the source as it changes

Application engineers who read operational data from Redis and need hash keys and fields that mirror the source rows, so lookups use the same identifiers as the system of record
Data platform leads feeding Redis from Oracle, SQL Server, PostgreSQL, MySQL, or MongoDB who want one Core Hub for every source, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects deciding where each source's changes land, and how Redis sits beside the operational database as a low-latency copy of its data
Engineers replacing scheduled key-refresh scripts, or a Kafka Connect and Debezium chain that exists only to write Redis, who want every source delivered by one product with snapshots and monitoring built in

THE PROBLEM

Redis data that refreshes on a schedule is already stale

Most Redis data is fed by scheduled jobs: a script reads the source, rewrites the keys, and runs again an hour or a night later. Between runs, applications read the state of the business as it was at the last refresh, every extract adds read load to the production database, and each source ends up with its own script and failure mode. Teams looking for real-time Redis replication or a Redis CDC pipeline usually weigh Kafka Connect or Debezium with a Redis sink connector, custom consumers they write and maintain, and scheduled extract jobs or managed ELT services.

Gluesync addresses that with per-agent CDC into Redis. A source agent reads each database's native change log, journal, or change stream; Core Hub routes the changes; the Redis target agent applies them in real time. PostgreSQL to Redis, Oracle to Redis, or MongoDB to Redis all share the same snapshot, monitoring, and pipeline model.

HOW IT WORKS

How Gluesync writes to Redis

The write path: the Lettuce client and one hash per row

The Redis target agent connects with the Lettuce Java client, over TLS when your deployment requires it. It is a target agent: it receives changes from any Gluesync source agent and writes each source row as a Redis hash with HSET, so applications read the fields directly with HGETALL or HGET.

Deletes: a delete at the source removes the matching hash key, so Redis holds exactly the rows the source holds.

Optimized batches, never row by row

Gluesync never handles Redis writes one row at a time. Incoming changes are grouped into chunks, and each chunk is sent through Lettuce's asynchronous API, so the agent keeps many commands in flight instead of waiting on a round-trip per key. The chunk size is configurable on the target agent, so you can push throughput while seeding a large keyspace and keep bursts small once applications read from Redis at full load.

Snapshot first, then continuous CDC

Seed: snapshot batches are serialized and written to Redis, so every key exists before live changes start.
Stream: after the snapshot, inserts, updates, and deletes from the source agent's change mechanism are applied in real time.
Resume: an interrupted snapshot resumes from its last saved state when you start the entity again.
Scheduled reseeds: the Chronos Scheduler runs snapshots on a cadence when you want a full rewrite of the keys. See schedules and events.

Keys, values, and overwrites

Key layout: keys follow the table and primary key pattern, as in ARTICLES::1, with one hash field per column.
Values: fields are stored as Redis strings, so numbers and dates come back as text that your application parses into its own types.
Overwrites by key: a write sets the fields of the existing hash, so a replayed change lands as the same hash and there is no duplicate-key policy to manage.
Your other keys stay put: Gluesync never flushes the Redis keyspace, so keys outside the replicated entities are left exactly as they are.

What your Redis administrator sets up

The agent needs a Redis user with read and write permission on the target database. Every connection field is listed in the Redis target setup guide ↗.

Create a Redis user with read and write access to the database index that receives the data.
Note the hostname or IP address of the deployment, the port (6379 by default), and the database index.
In Core Hub, enter the hostname, port, database index, username, and password for the Redis agent.
Turn on TLS for encrypted connections, and provide the certificate path (PEM or JKS) when your deployment requires it.

Architecture around Core Hub

Lightweight agents sit close to each source, and Core Hub orchestrates them through its web UI and REST APIs. A pipeline groups a source agent, the Redis agent, and the entities they replicate, so several sources can feed the same Redis deployment from one control plane. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud. See CDC streaming for the wider design.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The Redis target agent: one agent, one hash per row

Redis has one Gluesync target agent. Every entity from every source lands as Redis hashes, so the choice you make is the pipeline and its sources, not the write path.

Agent	Write technique	Versions	Best for
Redis agent ↗	Lettuce Java client; optimized asynchronous batches of HSET writes, one hash per row, for snapshot and CDC	Any Redis deployment: on-premises, or in AWS, Google Cloud, Azure, or Redis Cloud	Applications that read operational data from Redis at low latency and need it to follow the source as it changes. Pick it when the readers need hash keys shaped like the source rows, fed from any Gluesync source under one Core Hub.

SOURCES AND TOPOLOGIES

Feed Redis from the systems of record you already run

Any Gluesync source agent can feed Redis, each with its own native capture technique. Open the integrations finder with Redis pre-selected to see every source you can pair with it.

One Core Hub runs several sources into the same Redis deployment side by side, each pipeline with its own snapshot and monitoring. Gluesync keeps pace with your change volume at any scale. MOLO17 Professional Services can plan the key layout and the topology with your team.

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

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among Redis ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
Kafka Connect or Debezium with a Redis sink connector	Open-source capture into Kafka topics, then a sink connector writes Redis. You run Kafka, Connect, offsets, and schema changes, and you own the key mapping	Changes go straight from each source agent to Redis hashes, with no Kafka cluster in the path. Read the Debezium alternative comparison
Custom consumers and scripts	Full control. Your team writes the readers, the key layout, retries, backfills, and the monitoring around them	Snapshot seeding, continuous CDC, and Core Hub monitoring without consumer code to maintain; see log-based CDC explained
Scheduled extract jobs	Simple to start. Freshness equals the schedule, and each run reads the source again	Changes are read from the source log as they happen, so Redis tracks the source between refreshes; read batch ETL vs real-time replication
Managed ELT services	Connector catalogs with scheduled syncs, mostly aimed at analytical destinations. Redis coverage differs by product	A dedicated capture agent per database, with Redis as a native write target, all run from one Core Hub
Commercial replication platforms such as Qlik Replicate	Mature log-based replication across many targets. Coverage of each target differs by product and version	Agents that run on-premises or in any cloud with Docker, Docker Compose, or Kubernetes, writing to Redis from one Core Hub; see migrating to Gluesync

Redis replication reading and documentation

What does replicating to Redis with Gluesync involve?

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

How does Gluesync write data into Redis?

The Redis target agent uses the Lettuce Java client to write each row as a Redis hash. Snapshot rows and continuous changes are grouped into optimized batches sent asynchronously.

Which sources can replicate to Redis?

Any Gluesync source agent can feed Redis, including Oracle, SQL Server, PostgreSQL, MySQL, MongoDB, and IBM Db2. The integrations finder shows every pairing for Redis.

How are Redis keys and fields named?

Each row becomes one hash. The key joins the table name and the primary key, for example ARTICLES::1, and each column becomes a hash field, so the hash reads like the source row.

What happens when a key already exists in Redis?

The write sets the fields of the existing hash, so a replayed change lands as the same hash. A delete at the source removes the hash key.

What does the Redis administrator need to set up?

A Redis user with read and write permission on the target database, the hostname, port (6379 by default), and database index, and TLS when your deployment requires it. Core Hub takes these credentials in its web UI or REST API.

Which Redis deployments are supported?

Any Redis deployment, whether on-premises or in AWS, Google Cloud, Azure, or Redis Cloud. The agent connects over the standard Redis protocol with TLS available.

REPLICATE TO A TARGET

Other targets Gluesync delivers to

Evaluate Gluesync with your Redis deployment

Start a trial on your infrastructure, or talk to MOLO17 about your sources, the key layout your applications need, and how Redis fits next to your operational databases.

Start a Gluesync trial Talk to MOLO17