SOLUTION · REPLICATE TO SINGLESTORE

Real-time data replication to SingleStore from your operational databases

Committed changes from your systems of record reach SingleStore continuously, so real-time analytics run on current data instead of the last batch.

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 SingleStore agent writes them through the SingleStore JDBC driver, on-premises or on DBaaS, and bulk loads go through staging tables for high-throughput ingestion. 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 SingleStore to reflect operations now, not after the nightly load

Analytics engineers who serve dashboards and real-time analytics from SingleStore and need current-state tables keyed like the source, with duplicate keys resolved by a per-entity setting
Data platform leads who want one Core Hub for Oracle, SQL Server, PostgreSQL, MySQL, IBM i, and MongoDB instead of one connector product per source, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects who offload analytical reads from a transactional system of record into SingleStore, with agents deployed beside each source and Docker, Docker Compose, or Kubernetes as the runtime
Engineers replacing Kafka sinks or scheduled ELT scripts that load SingleStore, who want every source delivered by one product, with snapshots and monitoring built in

THE PROBLEM

SingleStore data that arrives in batches is already behind

Most SingleStore pipelines start with a copy job: a script or scheduled extract reads the source, lands files or rows, and loads them on a timer. Analytics then run on the state at the last load, every extract adds read load to a production database, and each source needs its own loader. Teams looking for real-time SingleStore ingestion or a SingleStore CDC pipeline usually weigh a Debezium and Kafka stack with a JDBC sink, managed ELT services such as Fivetran or Airbyte, the native ingestion features of the database, or scripts their own team keeps running.

Gluesync addresses that with per-agent CDC into SingleStore. A source agent reads each database's native change log, journal, or change stream; Core Hub routes the changes; the SingleStore agent applies them as they arrive, in commit order per entity. Whether the data comes from Oracle, IBM i, or MongoDB, the pipeline model and the operations stay the same.

HOW IT WORKS

How Gluesync writes to SingleStore

Optimized batches, never row by row, over the SingleStore JDBC driver

The SingleStore agent connects through the SingleStore JDBC driver, bundled with Gluesync, to on-premises or DBaaS deployments. It is a target agent: it applies the change stream from any Gluesync source agent to your tables in real time. Gluesync never writes one row at a time: inserts, updates, and deletes are grouped into highly optimized SQL batches.

Configurable batches: batch size is configurable, separately for writes and for deletes.
Native bulk load: switch it on per entity for the initial snapshot, for ongoing CDC, or both, as described below.
TLS: the connection is encrypted, with certificates uploaded in the agent configuration. A certificate password is passed to the keystore.

Native bulk load for snapshots and CDC

Bulk load runs through a staging table and is switched on per entity with two independent settings: Bulk for Snapshot for the initial load and Bulk for CDC for the ongoing change stream. Both can be changed 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 batch is loaded into a staging table in the Gluesync schema on SingleStore, columns the source log omitted can be backfilled from the live table, and deletes and inserts are then applied to the final table in one pass before the staging table is cleared. SingleStore receives a few set-based statements per cycle instead of one statement per change.

Snapshot first, then real-time changes

Each entity starts with a snapshot whose batches are inserted into SingleStore tables. After that, the agent applies the change stream captured from the source: inserts, updates, and deletes, applied as they arrive and in commit order per entity. The pipeline keeps running after the snapshot, without a reload.

Keys and duplicate rows

On duplicate key: each entity chooses Upsert, Skip, or Fail. Upsert, the default, overwrites the SingleStore row with the incoming one. Skip keeps the row already in SingleStore and raises a warning that lists the skipped keys. Fail stops the entity and reports the error.
Changing the choice: the setting can be changed on an existing entity. Save the configuration and the next write uses the new behavior, with no recreation of the entity.

What your SingleStore admin sets up

The agent needs a SingleStore user with read and write access to the target tables and database. Full statements are in the SingleStore target setup guide ↗.

Create a SingleStore user with read and write access to the target tables and to the target database.
Allow the agent host to reach SingleStore on port 3306, the default port.
In Core Hub, enter the host or IP address, the port, the database name, the username, and the password.
For TLS, upload the certificate in the agent configuration, and set the certificate password when your keystore requires one. Through the Core Hub REST API, the same connection uses enableTls and certificatePath.

Query and operate from 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 SingleStore agent. A pipeline groups a source agent, the SingleStore agent, and the entities they replicate. Query Studio, the SQL workbench inside Core Hub, opens the same SingleStore connection with autocomplete and read-only access, so checking landed rows does not need another client. See Query Studio.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The SingleStore target agent

SingleStore has one Gluesync target agent. Every Gluesync source agent can feed it, and each entity writes in optimized batches or with native bulk load through a staging table.

Agent	Write technique	Versions	Best for
SingleStore agent ↗	SingleStore JDBC driver writing optimized SQL batches; native bulk load through a staging table for snapshots and CDC; snapshot seeding, then real-time changes	On-premises and DBaaS deployments, including those on AWS, Google Cloud, or Azure	Real-time analytics on SingleStore fed continuously from operational databases, with native bulk load for snapshots and CDC switched on per entity. Pick it when SingleStore is the analytical or read-optimized copy and every source should reach it under one Core Hub.

SOURCES AND TOPOLOGIES

Feed SingleStore from the transactional databases you already run

Any Gluesync source agent can feed SingleStore. Open the integrations finder with SingleStore pre-selected to see every source you can pair with it.

One Core Hub runs Oracle to SingleStore, MySQL to SingleStore, and PostgreSQL to SingleStore side by side, with the same snapshot, monitoring, and duplicate-key settings for each. Gluesync keeps pace with your change volume at any scale, and MOLO17 Professional Services can help choose batch and bulk settings per table.

Oracle to SingleStore from the redo logs, through LogMiner or XStream: see Oracle CDC
MySQL to SingleStore from the binlog: see MySQL CDC
PostgreSQL to SingleStore from the write-ahead log: see PostgreSQL CDC
SQL Server to SingleStore through Change Data Capture or Change Tracking: see SQL Server CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among SingleStore ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
Fivetran and Fivetran HVR	Managed ELT with a broad connector catalog and scheduled syncs; HVR adds log-based database replication. Packaging differs by product	Agents you deploy next to each source, native capture per engine, and JDBC writes into SingleStore under one Core Hub; see warehouse sync
Airbyte	Open-source and cloud ELT connectors; incremental and CDC modes vary by source connector, and you run the platform or use the managed service	A commercial product with a dedicated capture agent per database and MOLO17 support behind every pipeline
Debezium, Kafka Connect, and a JDBC sink connector	Open-source capture into Kafka topics, loaded by a sink connector; you run Kafka, Connect, offsets, and schemas, and usually add a step that merges change events into current-state tables	Changes applied to SingleStore tables by key with no Kafka cluster in the path, while Kafka stays available as another target. See the Debezium alternative page
The database's own ingestion features for files and streams	Native loading from files and streams inside the database; getting changes out of each source database is a component you choose and run	Gluesync captures from each source's native log and writes with the SingleStore JDBC driver, staged bulk loads included, so each source does not need its own loader
AWS DMS, Qlik Replicate, and similar replication services	Mature replication products with broad target lists; SingleStore support and load method vary by product	Agents that run on premises or in any cloud with Docker, Docker Compose, or Kubernetes and write straight to SingleStore; see migrating to Gluesync
DIY scheduled ELT and scripts	Full control; your team owns extract queries, file staging, merge logic, retries, and the load each run puts on production	Log-based capture, snapshot seeding, and Core Hub monitoring without pipeline code to maintain; read batch ETL vs real-time data replication

SingleStore replication research and implementation detail

What does replicating to SingleStore with Gluesync involve?

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

Does Gluesync bulk load into SingleStore?

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 staging table in the Gluesync schema, and applied to the final table in one pass. Without bulk load, the agent writes through the SingleStore JDBC driver in optimized batches.

Which sources can replicate to SingleStore?

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

Are deletes and updates applied to SingleStore?

Yes. After the snapshot, the SingleStore agent applies inserts, updates, and deletes from the source as they arrive, in commit order per entity.

Which SingleStore deployments are supported?

On-premises and DBaaS deployments, including those running on Amazon Web Services, Google Cloud, or Microsoft Azure. The agent uses the bundled SingleStore JDBC driver.

What does the SingleStore admin need to set up?

A user with read and write access to the target tables and database, network access to SingleStore on port 3306 by default, and the host, database name, username, and password entered in Core Hub. TLS connections use an uploaded certificate, with a certificate password when the keystore requires one.

Can I query SingleStore from Core Hub?

Yes. Query Studio opens the SingleStore connection with autocomplete and read-only access, so you can check landed rows without a separate SQL client.

REPLICATE TO A TARGET

Other targets Gluesync delivers to

Evaluate Gluesync with your SingleStore deployment

Start a trial on your infrastructure, or talk to MOLO17 about your sources, the SingleStore capacity you need, and the bulk-load settings each table should use.

Start a Gluesync trial Talk to MOLO17