SOLUTION · REPLICATE TO MARIADB

Real-time data replication to MariaDB from your operational databases

Committed changes from your systems of record land in MariaDB continuously, through JDBC batches and staged bulk cycles, instead of waiting for the next batch job.

Gluesync by MOLO17 captures changes from Oracle, MySQL, SQL Server, PostgreSQL, MongoDB, and other heterogeneous sources with a dedicated agent per database. The MariaDB agent writes them through the built-in MariaDB JDBC driver, with TLS, after a snapshot seeds each table. Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API.

Start a Gluesync trial Talk to us

VENDOR COMPATIBILITY

Battle-tested on every MariaDB you deliver to

The same Gluesync MariaDB agent is tested against each vendor offering below, self-managed or fully managed, so delivery behaves the same wherever MariaDB runs.

MariaDB Source Target Tested
Amazon RDS for MariaDB Source Target Tested

WHO THIS IS FOR

Teams that need MariaDB to reflect the system of record now, not after the next batch job

Analytics and application engineers who need MariaDB tables that match the source, with primary keys carried over, a reviewed CREATE TABLE generated from the source definition, and inserts, updates, and deletes applied in commit order
Data platform leads feeding MariaDB from Oracle, MySQL, SQL Server, PostgreSQL, or MongoDB who want one Core Hub for every source instead of one connector per source, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects who decide which tables use native bulk load and which use optimized batches, which sources feed which MariaDB databases, and where each agent runs
Engineers replacing Kafka Connect JDBC sinks, scheduled export and import scripts, or hand-written upsert jobs with one product for every source, with snapshots and monitoring built in

THE PROBLEM

MariaDB data that arrives in batches is already behind

Most MariaDB targets are fed by scheduled jobs: a script or ETL tool extracts rows from the source, loads them, and rebuilds tables on a timer. Dashboards and applications then read the state at the last run, every extract adds load to a production database, and each source ends up with its own schedule and failure mode. Teams weighing a fix usually compare managed ELT services such as Fivetran or Airbyte, a Debezium and Kafka stack with a JDBC sink connector, AWS Database Migration Service, or scripts they maintain themselves.

Gluesync addresses that with per-agent CDC into MariaDB. A source agent reads each database's native change log, Core Hub routes the changes, and the MariaDB target agent applies them with JDBC batches or staged bulk cycles. Whether the data comes from Oracle, MySQL, or MongoDB, the pipeline model, the snapshot, and the operations stay the same.

HOW IT WORKS

How Gluesync writes to MariaDB

The write path: optimized batches and staged bulk load

The MariaDB agent connects through the built-in MariaDB JDBC driver, with TLS. It is a target agent: it applies the change stream from any Gluesync source agent to your tables in real time, after a snapshot seeds each table. Gluesync never writes one row at a time; each entity uses one of two paths.

Optimized batches, never row by row: by default, changes are grouped into highly optimized SQL batches applied in commit order, which cuts round-trips and keeps load on the server predictable. The chunk size is configurable on the target agent.
Native bulk load: switch it on per entity for the initial snapshot, for ongoing CDC, or both, as described below. See the MariaDB agent overview ↗.

Native bulk load for snapshots and CDC

Bulk load is switched on per entity with two independent settings, one for the initial load and one for the ongoing change stream. Turn on one, the other, or both, on an existing entity without recreating it.

In each mirroring cycle Core Hub collects the change events and collapses those on the same primary key: an insert followed by a delete is skipped, and consecutive updates become one update. The agent fills a temporary staging table with multi-row INSERT statements, then applies deletes and inserts to the target table in one pass and clears the staging table for the next cycle. Each changed key lands as one current row.

When the source log omits unchanged columns, an optional update join fills them from the live MariaDB table before the apply, so rows stay complete.

Snapshot first, then continuous CDC

Seed, then stream: each entity loads its full table into MariaDB, then follows the source agent's change stream, applied in commit order per entity.
INSERT or UPSERT: INSERT with TRUNCATE before snapshot is the fast path for empty or reset tables. UPSERT merges the snapshot with rows that already exist in MariaDB.
On duplicate key: Upsert, Skip, or Fail, set per entity. Upsert overwrites the row, Skip keeps the row already in MariaDB and raises a notification, and Fail stops the entity.
Pre and post SQL: commands can run before or after the snapshot and before or after CDC, for example to set session parameters or to clean up staging objects.

Schema, types, and keys in MariaDB

Table creation: when a target table does not exist, Core Hub generates a CREATE TABLE from the source columns, data types, and primary key, converted to MariaDB syntax. You review and edit the statement before it runs.
Type mapping: each source value is normalized into a Gluesync data family and written in the closest representation the MariaDB connector supports. The Fields Editor shows the inferred target type for each column before you deploy.
RSA password exchange: Allow public key retrieval lets the MariaDB driver fetch the server's public key for RSA password exchange instead of reading it from a local file. It is off by default.

What your MariaDB administrator sets up

The agent needs a database user that can read and write the target tables. Full connection fields are in the MariaDB target setup guide ↗.

Create a user with read and write access to the target database and tables. Table creation and bulk staging also need DDL rights on the schemas they use.
For native bulk load, set local_infile=1 in the [mysqld] section of the server configuration, usually /etc/mysql/mariadb.conf.d/50-server.cnf, then restart MariaDB.
On AWS RDS and other managed MariaDB services, enable TLS for the connection. In Core Hub, enter the host, the port (3306 by default), the database name, and the user's credentials, with TLS and the certificate path set.

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 MariaDB agent. A pipeline groups the source agents, the MariaDB agent, and the entities they replicate. Core Hub and the agents deploy with Docker and Podman, Docker Compose, or Kubernetes. See CDC streaming.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The MariaDB target agent: batches by default, bulk cycles per entity

MariaDB has one Gluesync target agent. Writes use optimized SQL batches by default, and native bulk load can be switched on per entity for the snapshot, for CDC, or both.

Agent	Write technique	Versions	Best for
MariaDB agent ↗	Built-in MariaDB JDBC driver with TLS; optimized SQL batches by default; native bulk load through a staging table for snapshots and CDC	Any MariaDB version, on self-managed hosts and in managed services that accept TLS connections	Continuous replication into MariaDB from any Gluesync source. Optimized batches by default, and native bulk load for snapshots and CDC, switched on per entity.

SOURCES AND TOPOLOGIES

Feed MariaDB from the systems of record you already run

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

One Core Hub runs MySQL to MariaDB, Oracle to MariaDB, and MongoDB to MariaDB side by side, with the same snapshot, monitoring, and write settings for each. Gluesync keeps pace with your change volume at any scale, and MOLO17 Professional Services can help design the pipeline with your team.

MySQL to MariaDB from the binary log, for migrations inside the MySQL family: see MySQL CDC
Oracle to MariaDB from the redo logs through LogMiner or XStream, or through triggers: see Oracle CDC
PostgreSQL to MariaDB from the write-ahead log, for cross-engine moves: see PostgreSQL CDC
MongoDB to MariaDB, for document data that feeds relational reporting: see MongoDB CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among MariaDB ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
Debezium, Kafka, and a JDBC sink connector	Open-source capture into Kafka topics, then a sink connector that writes to MariaDB; you run Kafka, Connect, and the schemas, and usually add a step that turns change events into current-state tables	Changes applied to current-state MariaDB tables with no Kafka cluster in the path, and Kafka still available as another target. Compare the Debezium alternative
Managed ELT services such as Fivetran and Airbyte	Managed connector catalogs with scheduled syncs; incremental and CDC modes vary by connector, and the sync schedule sets how fresh the data is	Log-based capture per engine, with changes applied as they arrive instead of on a sync schedule, and MOLO17 enterprise support behind every pipeline
AWS Database Migration Service	Managed migration and replication that runs on a replication instance in AWS, typically used for database moves into AWS	Agents sit next to each source and write straight to MariaDB, with the same product for every source under one Core Hub. See migrating to Gluesync
Qlik Replicate, Striim, and similar replication platforms	Commercial log-based replication with broad source and target catalogs; licensing and deployment differ by product	Native capture per engine, optimized batches with native bulk load, and enterprise support from MOLO17, deployed with Docker, Docker Compose, or Kubernetes
Native replication between MySQL-family servers	Built-in replication that keeps a MySQL-family replica in step with its primary; it works inside one engine family, so a move from Oracle, SQL Server, or MongoDB needs another tool	Continuous replication across engines, so MariaDB can be loaded from heterogeneous sources while the source keeps serving its applications
DIY scheduled jobs and scripts	Full control; your team owns the extract queries, the upsert logic, retries, and the load each run puts on production	Log-based capture, staged bulk apply, snapshots started from Core Hub, and monitoring without pipeline code to maintain; read batch ETL vs real-time data replication

MariaDB replication background and implementation detail

What does replicating to MariaDB with Gluesync involve?

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

Does Gluesync bulk load into MariaDB?

Yes, for the initial snapshot and for ongoing CDC, with a separate switch for each on every entity. Changes are collapsed per primary key, loaded into a temporary staging table with multi-row INSERT statements, and applied in one pass. Without bulk load, the agent writes through the built-in MariaDB JDBC driver in optimized SQL batches.

Which sources can replicate to MariaDB?

Any Gluesync source agent, including Oracle, MySQL, SQL Server, PostgreSQL, IBM Db2 for i, and MongoDB. The integrations finder on our website shows every source that pairs with MariaDB.

How are duplicate keys handled when replicating to MariaDB?

The On duplicate key setting is applied per entity. Upsert overwrites the existing row and is the default, Skip keeps the row already in MariaDB and raises a notification, and Fail stops the entity.

What does the MariaDB administrator need to set up?

A user with read and write access to the target tables, with DDL rights where Gluesync creates tables or staging objects. For native bulk load, local_infile is set to 1 in the server configuration, and TLS is enabled for managed services such as AWS RDS.

Can Gluesync create the tables in MariaDB?

Yes. When a target table is missing, Core Hub generates a CREATE TABLE from the source definition, converted to MariaDB syntax, and you review it before it runs.

Which MariaDB deployments can Gluesync write to?

Any MariaDB version, on self-managed hosts and in managed services such as AWS RDS, which accept connections only over SSL. The agent connects with TLS enabled.

How do I build a MariaDB CDC pipeline with Gluesync?

Create a pipeline in Core Hub, add a source agent such as MySQL, Oracle, or SQL Server, add the MariaDB agent as the target, and choose snapshot, CDC, or both for each entity.

REPLICATE TO A TARGET

Other targets Gluesync delivers to

Evaluate Gluesync with your MariaDB databases

Start a trial on your own infrastructure, or talk to MOLO17 about your sources, the write path for each table, and how MariaDB fits your replication plan.

Start a Gluesync trial Talk to MOLO17