SOLUTION · REPLICATE TO VERTICA

Real-time data replication to Vertica from your operational databases

Committed changes from your systems of record reach Vertica continuously, instead of waiting for the next batch extract.

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 Vertica agent writes them through the Vertica JDBC driver, over TLS and load-balanced connections, 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

WHO THIS IS FOR

Teams that need Vertica to reflect operations now, not after the nightly extract

Analytics engineers who model Vertica tables for dashboards and need current-state tables keyed like the source, with duplicate keys resolved by a per-entity setting instead of a hand-written merge job
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 place one Vertica target agent that receives changes from any source agent, with agents deployed beside each system they replicate and Docker, Docker Compose, or Kubernetes as the runtime
Engineers replacing Kafka Connect sinks or scheduled ELT scripts that load Vertica, who want every source delivered by one product, with snapshots and monitoring built in

THE PROBLEM

Vertica data that arrives in batches is already behind

Most Vertica estates are fed by scheduled extracts: a job queries the source, writes files, and loads them on a timer. Dashboards then show the business as it was at the last load, every extract adds read load to a production database, and each source ends up with its own loader and failure mode. Teams looking for real-time Vertica ingestion or a Vertica CDC pipeline usually weigh managed ELT services such as Fivetran or Airbyte, a Debezium and Kafka stack with a JDBC sink, or scripts their own team keeps running.

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

HOW IT WORKS

How Gluesync writes to Vertica

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

The Vertica agent connects through the official Vertica JDBC driver, bundled with Gluesync. 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: changes are grouped into highly optimized SQL batches, so Vertica receives a few large statements instead of a stream of single-row DML.

Configurable batches: batch size is configurable, separately for writes and for deletes, so you tune round-trips per entity.
TLS: the connection is encrypted, with the certificate path set in the agent configuration.
Load balancing: load-balanced connections are supported.
Agent reference: the Vertica agent overview ↗ lists the features and the driver.

Snapshot first, then real-time changes

Each entity starts with a snapshot that seeds its table in Vertica. After that, the agent applies the change stream captured from the source: inserts, updates, and deletes, delivered continuously and applied as they arrive, in commit order per entity. Vertica stays current with the source without a reload.

Keys and duplicate rows

On duplicate key: each entity chooses Upsert, Skip, or Fail. Upsert, the default, overwrites the Vertica row with the incoming one. Skip keeps the row already in Vertica and raises a warning that lists the skipped keys. Fail stops the entity and reports the error.
Primary keys: Vertica enforces a primary key on tables where the constraint is enabled, and Gluesync creates its tables with that constraint enabled, so the duplicate-key setting applies to them.

What your Vertica admin sets up

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

Create a database user with read and write access to the target tables and to the target database.
Allow the agent host to reach Vertica on port 5433, the default port.
In Core Hub, enter the host or IP address, the database name, the username, and the password for the Vertica agent.
For a TLS connection, set enableTls and certificatePath through the Core Hub REST API.

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

Explore the general CDC streaming architecture →

WRITE OPTIONS

The Vertica target agent

Vertica has one Gluesync target agent. Every Gluesync source agent can feed it, and each entity follows the same snapshot-then-CDC path.

Agent	Write technique	Versions	Best for
Vertica agent ↗	Vertica JDBC driver writing optimized SQL batches over TLS and load-balanced connections; snapshot seeding, then real-time changes applied per entity	Any Vertica deployment, on premises or on AWS, Google Cloud, or Azure; all Vertica versions	Analytical Vertica estates fed from operational databases, where changes should land continuously under the same Core Hub as every other source. Pick it whenever Vertica is the destination.

SOURCES AND TOPOLOGIES

Feed Vertica from the systems of record you already run

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

One Core Hub runs Oracle to Vertica, SQL Server to Vertica, and PostgreSQL to Vertica 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 plan entities and batch settings with your team.

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

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among Vertica 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 Vertica 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 Vertica tables by key with no Kafka cluster in the path, while Kafka stays available as another target. See the Debezium alternative page
Vertica's own loading commands and scheduled jobs	Native bulk loading from files or streams, driven by a scheduler and scripts; getting changes out of each source database is a component you build and run	Gluesync captures from each source's native log and writes through the Vertica JDBC driver, so no loader job sits between the source and Vertica
AWS DMS, Qlik Replicate, and similar replication services	Mature replication products with broad target lists; Vertica 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 Vertica; 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

Vertica replication research and implementation detail

What does replicating to Vertica with Gluesync involve?

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

How does Gluesync write data into Vertica?

The Vertica agent uses the official Vertica JDBC driver, bundled with Gluesync, over TLS and load-balanced connections. Changes are grouped into highly optimized SQL batches with a configurable size, never written one row at a time.

Which sources can replicate to Vertica?

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

How are duplicate keys handled in Vertica?

Each entity chooses Upsert, which is the default and overwrites the Vertica row with the incoming one, Skip, which keeps the existing row and raises a warning, or Fail, which stops the entity. Tables Gluesync creates have their primary key constraint enabled, so the choice applies to them.

Which Vertica deployments are supported?

Any Vertica deployment, whether on premises or on Amazon Web Services, Google Cloud, or Microsoft Azure. The agent connects over the Vertica JDBC driver.

What does the Vertica admin need to set up?

A database user with read and write access to the target tables and the database, network access to Vertica on port 5433 by default, and the host, database name, username, and password entered in Core Hub. A TLS connection uses the enableTls and certificatePath settings in the REST API.

Can I check the rows that land in Vertica from Core Hub?

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

REPLICATE TO A TARGET

Other targets Gluesync delivers to

Evaluate Gluesync with your Vertica cluster

Start a trial on your infrastructure, or talk to MOLO17 about your sources, the Vertica capacity you need, and the duplicate-key behavior each entity should follow.

Start a Gluesync trial Talk to MOLO17