Canonical: https://molo17.com/solutions/replicate-to-redis/ Markdown mirror: https://molo17.com/solutions/replicate-to-redis/index.md Title: Replicate to Redis in real time with Gluesync | MOLO17 Description: Real-time replication to Redis from Oracle, SQL Server, PostgreSQL, MySQL, and MongoDB, with snapshot seeding and batched hash-per-row writes. Start a trial. [Solutions](/solutions/) Replicate to Redis 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](/integrations/?target=Redis#integration-finder) 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](/get-gluesync/) [Talk to us](/contacts/) 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](/support/#customer-ratings) - 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](/integrations/?target=Redis#integration-finder) 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](/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 ↗](https://docs.molo17.com/gluesync/latest/agents/redis-target.html). 1. Create a Redis user with read and write access to the database index that receives the data. 2. Note the hostname or IP address of the deployment, the port (6379 by default), and the database index. 3. In Core Hub, enter the hostname, port, database index, username, and password for the Redis agent. 4. 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](/solutions/cdc-streaming/) for the wider design. [Explore the general CDC streaming architecture →](/solutions/cdc-streaming/) 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 ↗](https://docs.molo17.com/gluesync/latest/agents/redis-intro.html) | 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](/integrations/?target=Redis#integration-finder) 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](/solutions/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](/solutions/oracle-cdc/) - SQL Server to Redis through Change Data Capture or Change Tracking: see [SQL Server CDC](/solutions/sql-server-cdc/) - PostgreSQL and MySQL to Redis from the WAL and the binlog: see [PostgreSQL CDC](/solutions/postgresql-cdc/) and [MySQL CDC](/solutions/mysql-cdc/) - MongoDB to Redis from Change Streams: see [MongoDB CDC](/solutions/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](/solutions/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](/blog/real-time-replication-log-based-cdc/) | | 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](/blog/batch-etl-vs-real-time-data-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](/migrate-to-gluesync/) | RELATED CONTENT ## Redis replication reading and documentation - [Redis agent launch: real-time integration for Redis deployments](/blog/redis-agent-for-gluesync-seamless-integration-for-target-redis-deployments/) - [Batch ETL vs real-time data replication: how to choose](/blog/batch-etl-vs-real-time-data-replication/) - [Log-based CDC explained](/blog/real-time-replication-log-based-cdc/) - [Database offload: read-optimized targets](/solutions/database-offload/) - [Debezium alternative: managed CDC versus Kafka + Debezium](/solutions/debezium-alternative/) - [Redis agent overview ↗](https://docs.molo17.com/gluesync/latest/agents/redis-intro.html) - [Redis target setup guide ↗](https://docs.molo17.com/gluesync/latest/agents/redis-target.html) - [Write strategies: optimized batches ↗](https://docs.molo17.com/gluesync/latest/core-hub/write-strategies.html) FAQ ## Redis replication questions 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 - [Replicate to Aerospike](/solutions/replicate-to-aerospike/) - [Replicate to DynamoDB](/solutions/replicate-to-dynamodb/) - [Replicate to Redshift](/solutions/replicate-to-redshift/) - [Replicate to Amazon S3 & S3-compatible](/solutions/replicate-to-amazon-s3/) - [Replicate to Cassandra](/solutions/replicate-to-cassandra/) - [Replicate to Kafka](/solutions/replicate-to-kafka/) - [Replicate to Cosmos DB](/solutions/replicate-to-cosmos-db/) - [Replicate to Azure Data Lake](/solutions/replicate-to-azure-data-lake/) - [Replicate to ClickHouse](/solutions/replicate-to-clickhouse/) - [Replicate to CockroachDB](/solutions/replicate-to-cockroachdb/) - [Replicate to Couchbase](/solutions/replicate-to-couchbase/) - [Replicate to file stores](/solutions/replicate-to-file-stores/) - [Replicate to BigQuery](/solutions/replicate-to-bigquery/) - [Replicate to Google Cloud Storage](/solutions/replicate-to-google-cloud-storage/) - [Replicate to Google Pub/Sub](/solutions/replicate-to-google-pubsub/) - [Replicate to GridGain](/solutions/replicate-to-gridgain/) - [Replicate to Db2](/solutions/replicate-to-db2/) - [Replicate to Informix](/solutions/replicate-to-informix/) - [Replicate to MariaDB](/solutions/replicate-to-mariadb/) - [Replicate to SQL Server](/solutions/replicate-to-sql-server/) - [Replicate to MongoDB](/solutions/replicate-to-mongodb/) - [Replicate to MySQL](/solutions/replicate-to-mysql/) - [Replicate to Oracle](/solutions/replicate-to-oracle/) - [Replicate to PostgreSQL](/solutions/replicate-to-postgresql/) - [Replicate to RavenDB](/solutions/replicate-to-ravendb/) - [Replicate to SAP ASE](/solutions/replicate-to-sap-ase/) - [Replicate to SAP HANA](/solutions/replicate-to-sap-hana/) - [Replicate to ScyllaDB](/solutions/replicate-to-scylladb/) - [Replicate to SingleStore](/solutions/replicate-to-singlestore/) - [Replicate to Snowflake](/solutions/replicate-to-snowflake/) - [Replicate to Solace PubSub+](/solutions/replicate-to-solace/) - [Replicate to Vertica](/solutions/replicate-to-vertica/) - [Replicate to YugabyteDB](/solutions/replicate-to-yugabytedb/) ## 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](/get-gluesync/) [Talk to MOLO17](/contacts/)