What is Gluesync?

Gluesync keeps data in sync between systems that were never designed to talk to each other. It captures every change as it happens on a source database, transforms it in flight, and delivers it to one or more targets — relational databases, NoSQL stores, data lakes, event streams, or APIs — without your data ever landing in a vendor-owned store in between.

The problem it solves

Most organizations end up with data in more than one place: an Oracle or Db2 system of record that cannot be replaced, a cloud analytics warehouse, a NoSQL store behind a customer-facing app, a Kafka topic feeding downstream services. Keeping those copies consistent usually means nightly batch jobs, hand-written ETL scripts, or application code that dual-writes and eventually drifts.

Gluesync replaces that with continuous, change-level replication:

  • Changes, not batches. Gluesync reads the source’s own change log (transaction logs, journals, change streams, or CDC APIs) so it sees inserts, updates, and deletes as the database commits them. Latency is measured in milliseconds, not hours.

  • Heterogeneous by default. Source and target do not need to share a data model. A set of normalized relational tables can land as a single nested document; a document collection can land as flattened rows.

  • No central data store. Gluesync moves data between your systems. It does not require you to first load everything into a new proprietary platform.

  • Non-invasive on the source. Log-based capture means no application rewrite, and — where the source supports it — no triggers or schema changes either.

How a deployment is shaped

Gluesync data path Three lanes of data flow left to right. Source systems (Oracle or SQL Server, MongoDB or Couchbase, and IBM i or Db2) feed source agents that capture changes and buffer them in a local durable queue. The agents forward events to Core Hub, which maps, filters, transforms, and routes each record. Core Hub passes the result to target agents, which write to a warehouse, a relational database, and a streaming platform. The Control Plane UI, REST API, and Prometheus metrics sit above Core Hub. Conductor, Chronos, Automator, Query Studio, and AI Studio attach below it. Control plane Web UI REST API Metrics Source systems Source agents Target agents Target systems Core Hub map · filter · transform · route RDBMS Oracle · SQL Server Source agent Transaction-log CDC Target agent Bulk load · upsert Warehouse Snowflake · BigQuery NoSQL MongoDB · Couchbase Source agent Change streams Target agent JDBC · transactions RDBMS PostgreSQL · MySQL IBM i · Db2 Journal receivers Source agent Journal CDC Target agent Publish · partition Streaming Kafka · Solace Modules Conductor Chronos Automator Query Studio AI Studio

A Gluesync installation is made of three kinds of moving part.

Core Hub

The orchestrator. It holds configuration, coordinates every agent, processes and transforms records in flight, serves the Control Plane UI and the REST API, and exposes metrics. You deploy one Core Hub (or a redundant pair) per environment. See Core Hub 101.

Agents

Lightweight connectors, one per technology, deployed close to the system they talk to. A source agent captures changes; a target agent writes them. Agents are where vendor drivers and SDKs live, which is why each supported platform has its own agent. See Agents 101 and Supported integrations.

Pipelines

The configuration that ties them together. A pipeline groups a source agent, a target agent, and the entities (tables or collections) you want replicated, along with the mapping and transformation rules for each. See Adding agents.

Because agents run next to your databases rather than inside Core Hub, credentials and data paths stay within your network boundary, and you can scale a busy source independently of the rest of the platform.

For the component-by-component breakdown — message routing, the source-side caching layer, SDK and module internals — see Architecture.

What happens inside a pipeline

Once a pipeline is running, each entity moves through the same four stages.

Stage What it does

Snapshot

An initial load that brings the target up to the source’s current state. Can be re-run on demand, in bulk, or scoped to a subset of data. See Snapshot tasks.

Capture

Continuous change data capture from the source’s native mechanism. Supported source agents buffer changes in ArenaCache first, so a Core Hub restart or a brief network outage does not force a resynchronization. See Source-side cache.

Transform

Field mapping, renaming, filtering, denormalization, and computed values. Reusable logic can be written as user-defined functions or applied with built-in field functions.

Deliver

Writes to the target using the strategy you choose — insert-only, upsert, merge, soft delete — with bulk loading where the target supports it. See Write strategies.

Pipelines can fan several sources into one target, chain into each other, or run bidirectionally with recursion protection so changes do not loop back.

More than replication

The same platform that moves your data also lets you work with it.

  • Query Studio — run SQL against any connected system from the Control Plane, without a separate client. See Query data.

  • Query Forge — issue a single federated query that spans multiple connected systems. See Federated queries.

  • Scheduling and automation — trigger syncs, snapshots, and queries on a schedule or in response to events, via Chronos.

  • AI surfaces — AI Studio provides agents that call Core Hub MCP tools, Query Studio includes an AI helper, and gluesync.ai makes AI available through Query Forge SQL. These features call your LLM provider — OpenAI, Anthropic, Azure OpenAI, or a local Ollama — configured under Settings → LLM providers.

Where it runs

Gluesync ships as container images and is built in Kotlin on the JVM, so the same artifacts run everywhere.

Aspect Detail

Platforms

Linux, Windows Server (native nanoserver images, no WSL required), and macOS for development.

Deployment

Docker and Podman, Docker Compose, or Kubernetes. The guided installers cover the common cases.

Topology

Fully on-premises, fully in cloud (AWS, Azure, GCP), or hybrid — Core Hub in one place and agents next to whichever systems they serve.

Sizing

See System requirements.

How you drive it

Interface Use it for

Control Plane UI

The web console, served by Core Hub on port 1717 (commonly fronted by a reverse proxy on 443 in production). Pipeline design, agent deployment, monitoring, alerting, and administration. See Features overview.

REST API

Everything the UI does, driven programmatically for CI/CD and automation. See Rest APIs.

SDKs

Open-source Python and Node.js SDKs implementing the Core Hub handshake, for building your own agents and extensions. See SDKs overview.

Modules

Optional add-ons — Conductor for agent deployment, Chronos for scheduling, Automator for backup and restore, Whisperer for load testing. See Modules overview.

Monitoring

Prometheus metrics and Grafana dashboards ship with the platform. See Monitoring.

Security and access

  • Authentication — local accounts, or single sign-on through any OIDC provider (Auth0, Keycloak, Entra ID, and others). API keys cover programmatic access.

  • Authorization — role-based access control (Super admin, Manager, Viewer) scopes what each user can see and change. See User management and RBAC.

  • Encryption — TLS on the Control Plane and agent APIs, plus optional node-to-node data encryption. See Setup HTTPS and WSS.

  • Recoverability — full configuration export and import via backup and restore, so an environment can be rebuilt or cloned predictably.

Glossary

New to the platform? These are the terms used throughout the documentation.

Core Hub

The central orchestrator. Hosts the Control Plane UI and REST API, stores configuration, routes and transforms data between agents.

Control Plane

The web console served by Core Hub. Where you build pipelines, deploy agents, and watch them run.

Agent

A connector for one technology, deployed near the system it serves. A source agent reads changes; a target agent writes them.

Entity

A single replication unit — typically one table or collection, mapped from source to target with its own rules.

Pipeline

A logical grouping of a source agent, a target agent, and the entities flowing between them.

Group / Chain

Ways to run several pipelines together, either in parallel as a group or in sequence as a chain.

Snapshot

A full load of an entity’s current state, used to initialize or re-align a target.

CDC

Change data capture — reading committed changes from the source’s own log or change API rather than polling it.

Conductor

The module that deploys and updates agents directly from the Control Plane.

Chronos

The scheduler module, for time-based and event-based automation.

Bootstrapper

A scripting toolkit for creating pipelines and entities in bulk.

Automator

A standalone executable with a web interface that runs Bootstrapper workflows, and the supported tool for configuration backup, restore, and duplication.

Whisperer

A module for generating database load, used in testing and benchmarking.

Where to go next