SOLUTION · REPLICATE TO RAVENDB

Real-time data replication to RavenDB from your operational databases

Committed changes from your relational and NoSQL systems land in RavenDB documents continuously, through the official Java SDK, instead of waiting for the next sync job.

Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, MySQL, IBM i, MongoDB, and other heterogeneous sources with a dedicated agent per database. The RavenDB agent writes them to Community Edition or Enterprise Edition clusters, on-premises or on RavenDB Cloud, through the official Java SDK, with automatic node discovery and load balancing across the cluster. A snapshot seeds each collection, 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 RavenDB documents to reflect operations now, not after the next sync

Backend engineers building read models in RavenDB who need documents kept current from the transactional database, without a sync service for every table
Data platform leads who want one Core Hub for every source feeding RavenDB, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects planning an offload or read layer on RavenDB who need to see which sources feed which collections, where agents run, and how the cluster is reached over TLS
Engineers replacing Kafka consumers or nightly sync jobs that write into RavenDB, who want every source delivered by one product with snapshots and monitoring built in

THE PROBLEM

RavenDB documents built from nightly loads drift from the database

Most RavenDB models are fed by application code or scheduled jobs: a service reads the relational tables, reshapes the rows into documents, and writes them back. Each job adds read load to the source, the documents describe the database as of the last run, and every table or service needs its own code and retry logic. Teams weighing an alternative usually compare Debezium with Kafka Connect and a custom consumer, ETL suites, or the SDK scripts they maintain themselves.

Gluesync addresses that with per-agent CDC into RavenDB. A source agent reads each database's native change log, journal, or change stream; Core Hub routes the changes; the RavenDB agent applies them to collections through the Java SDK. Whether the source is Oracle or MongoDB, the snapshot, the collections, and the operations stay the same.

HOW IT WORKS

How Gluesync writes to RavenDB

The write path: the official Java SDK, in optimized batches

The RavenDB agent is a target agent built on the official RavenDB Java SDK, which Gluesync bundles. It receives changes from any Gluesync source agent and writes them to RavenDB through the SDK, with no staging step and no local buffer: documents go straight to the cluster.

Optimized batches, never row by row: Core Hub groups incoming changes into chunks, and groups at or above a configurable minimum batch size go out as SDK batches, so the cluster handles a few large requests instead of many small ones. Smaller groups use the default operation APIs, which keeps quiet periods responsive.
Cluster access: automatic node discovery and load balancing across cluster nodes, with high availability provided by the RavenDB cluster itself. RavenDB agent overview ↗

Snapshot first, then changes, into collections

Seed: each source table or collection is serialized and stored as documents during the initial snapshot, written in SDK batches.
Stream: after the snapshot, the entity switches to CDC from the source agent's change mechanism, and inserts, updates, and deletes are applied as they arrive.
Collections: by default, each source table or collection maps one to one to a RavenDB collection with the same name, so every document traces back to the table it came from.
Parallel and resumable snapshots: snapshot writing concurrency is configurable per entity, logical partitioning reads large source tables in parallel ranges, and an interrupted snapshot resumes from its last saved state.
Shaping on the way in: Unlock Schema, Custom Field Functions, and UDFs compose and reshape fields into the document your application reads, and Allowed Operations decides per entity which operations reach the collection. See data transformation.

Connectivity and TLS to the cluster

Port: 8080 by default, or 443 when TLS is enabled.
TLS: enable TLS on the connection and point the agent at a PEM file that holds both the private key and the certificate. We recommend TLS for every production cluster.
Editions and hosting: Community Edition and Enterprise Edition clusters, self-managed on-premises or in any cloud, or on RavenDB Cloud.

What your RavenDB admin sets up

Grant the agent's user read and write access to the target database, then enter the cluster details in Core Hub. Field-by-field settings and REST examples are in the target setup guide ↗.

Create a user with read and write permission on the target database.
Enter the hostname or IP address of a cluster node and the target database name.
Set the port to 8080, or to 443 when TLS is enabled, and upload the PEM certificate file if the cluster uses TLS.
Over the REST API, the same credentials, enableTls, and certificatePath are set on the agent's credentials endpoint.

Architecture around Core Hub

Lightweight agents sit close to each source, and Core Hub orchestrates them through its web UI and REST APIs and routes changes to the RavenDB agent. A pipeline groups a source agent, the RavenDB agent, and the entities they replicate, so an Oracle pipeline and an IBM i pipeline can feed collections in the same database side by side.

Core Hub and its agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud, so the RavenDB agent can run next to a self-managed cluster or close to RavenDB Cloud. See CDC streaming.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The RavenDB target agent: one agent, one SDK

One target agent writes to RavenDB through the official Java SDK. Batch sizing is set per pipeline, and every source feeds the same agent.

Agent	Write technique	Versions	Best for
RavenDB agent ↗	Official RavenDB Java SDK; optimized document batches at or above the configurable minimum batch size, with the default operation APIs for smaller groups	RavenDB 5.0 and later; Community Edition and Enterprise Edition, on-premises or RavenDB Cloud	Any RavenDB database fed from operational systems: read models, offload stores, and document views of relational data. Pair any Gluesync source agent with it under the same Core Hub.

SOURCES AND TOPOLOGIES

Feed RavenDB from the systems of record you already run

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

One Core Hub can run Oracle to RavenDB, SQL Server to RavenDB, and MongoDB to RavenDB side by side, with the same snapshot, monitoring, and batch settings for each. Gluesync keeps pace with your change volume at any scale, and the minimum batch size is configurable per agent; MOLO17 Professional Services can tune it with your team.

Oracle to RavenDB from the redo logs through LogMiner or XStream: see Oracle CDC
SQL Server to RavenDB through Change Data Capture or Change Tracking: see SQL Server CDC
IBM i (AS/400) to RavenDB through the native journal APIs: see IBM i CDC
PostgreSQL, MySQL, and MongoDB to RavenDB from the WAL, the binlog, and Change Streams: see PostgreSQL CDC, MySQL CDC, and MongoDB CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among RavenDB data movement approaches

Approach	What buyers usually get	Where Gluesync fits
Scripted SDK jobs and application sync services	Full control over document shaping, with your team owning the queries, retries, and the load each run puts on the source	Log-based capture for each source, snapshots and changes through one Core Hub, and no sync code to maintain; read batch ETL vs real-time data replication
Debezium or Kafka Connect with a custom consumer	Open-source capture into Kafka topics, then a consumer you write and run to turn events into documents; you operate Kafka, Connect, and the offsets	Changes applied to RavenDB collections straight from the source agent, with no Kafka cluster in the path; see the Debezium alternative comparison
ETL suites with a RavenDB connector	Broad connector catalogs and scheduled syncs; connector coverage and sync modes differ by product	A dedicated capture agent per source database, continuous delivery into RavenDB collections, and MOLO17 enterprise support behind every pipeline
Migration and one-off export tools	Well suited to a single cutover, where a one-time copy is the goal and ongoing changes are planned as a separate project	Snapshot and continuous changes in one pipeline, so RavenDB stays current while the cutover is planned and executed
Cloud-managed capture services	Managed capture for specific cloud databases, usually matched to the services of one cloud provider	Agents run on-premises or in any cloud, and RavenDB Cloud or self-managed clusters are both targets; see migrating to Gluesync

RavenDB replication research and implementation detail

What does replicating to RavenDB with Gluesync involve?

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

How does Gluesync write documents to RavenDB?

Through the official RavenDB Java SDK, which Gluesync bundles, never one row at a time. Groups of documents at or above a configurable minimum batch size go out as SDK batches, and smaller groups use the default operation APIs.

Which RavenDB versions and editions are supported?

RavenDB 5.0 and later, on Community Edition and Enterprise Edition, on-premises or on RavenDB Cloud.

Which sources can replicate to RavenDB?

Any Gluesync source agent, including Oracle, SQL Server, PostgreSQL, MySQL, IBM i, MongoDB, and Couchbase. The integrations finder on our website shows every pairing.

How are source tables mapped to RavenDB collections?

By default, each source table or collection maps one to one to a RavenDB collection with the same name, so the model stays easy to trace back to the source.

How is the connection to the cluster secured?

Enable TLS on the connection and point the agent at a PEM file that holds both the private key and the certificate. The port is 8080 by default and 443 when TLS is enabled.

What does the RavenDB side need before the pipeline starts?

A user with read and write permission on the target database, plus the hostname or IP address of a cluster node and the database name, entered in Core Hub.

REPLICATE TO A TARGET