Real-time data replication to Snowflake from your operational databases

• Analytics engineers who build dbt models, dynamic tables, or tasks on replicated data and need current-state tables keyed like the source, with column names that follow Snowflake's UPPERCASE identifiers and a reviewed CREATE TABLE generated from the source definition
• Data platform leads feeding Snowflake from Oracle, SQL Server, PostgreSQL, IBM i, or MongoDB who want one Core Hub for every source instead of one connector product per source, backed by best-in-class enterprise support, rated 4.9/5 by customers
• Architects who must keep ingestion compute predictable: a dedicated warehouse for Gluesync writes, bulk cycles that turn many changes into a few set-based statements, and a choice of write path per table
• Engineers running Debezium, Kafka Connect, and a Snowflake sink, or a stack of scheduled ELT jobs, who want every source delivered to Snowflake by one product with snapshots, checkpoints, and monitoring built in

The write path: JDBC with Apache Arrow, Snowpipe, and COPY INTO

The Snowflake agent connects through the official Snowflake JDBC driver, bundled with the agent, and uses Apache Arrow for high-throughput CDC writes. It is a target agent: it receives changes from any Gluesync source agent and writes them to your tables. Gluesync never writes one row at a time; each entity uses one of these paths.

• Snapshots: initial loads are uploaded in batches through the Snowpipe APIs. TRUNCATE before snapshot runs as a Snowflake SQL command when you want a clean reload, and can be disabled for every entity at the agent level.
• Optimized batches, never row by row: by default, changes are grouped into highly optimized SQL batches and applied together. Batch size is configurable on the agent, so each write cuts network round-trips and keeps warehouse load predictable.
• Native bulk load: switch it on per entity for the initial snapshot, for ongoing CDC, or both, and Gluesync loads through PUT and COPY INTO, as described below. Snowflake agent overview ↗

Native bulk load for snapshots and CDC

Bulk load is Snowflake-native loading, switched on per entity with two independent settings: Bulk for Snapshot for the initial load and Bulk for CDC for the ongoing change stream. Turn on one, the other, or both, on any 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 written as CSV, uploaded with PUT, and loaded into a persistent staging table with COPY INTO ... FILE_FORMAT=(NULL_IF=('NULL')). When a source log omits unchanged columns, an optional update join or MERGE fills them from the live Snowflake table. Deletes and inserts are then applied in one pass and the staging table is truncated for the next cycle. Each changed key lands as one current row, and the warehouse runs a handful of set-based statements per cycle instead of one statement per change.

Snapshot first, then continuous CDC

• Seed, then stream: each entity loads the full table into Snowflake, then switches to CDC from the source agent's change mechanism.
• INSERT or UPSERT: INSERT with TRUNCATE before snapshot is the fast path for empty or reset tables; UPSERT merges the snapshot with rows already in Snowflake.
• Parallel loads: snapshot writes run in parallel with configurable writer concurrency, and logical partitioning splits large source tables into ranges read in parallel.
• Resume: an interrupted snapshot resumes from its last saved state when you start the entity again.
• Scheduled refreshes: the Chronos Scheduler runs snapshots, or a snapshot followed by CDC, on a schedule for tables you prefer to reload on a cadence. See schedules and events.

Schema, types, and keys in Snowflake

• 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 Snowflake syntax. You review and edit the statement before it runs.
• Identifier case: Snowflake folds unquoted identifiers to upper case, so Core Hub normalizes target column names and filter clauses to UPPERCASE when an entity is saved, and generated tables follow the same case. Analysts reference columns without quoting them.
• Type mapping: each source value is normalized into a Gluesync data family and written as the closest native Snowflake type. Fixed-point values such as Oracle NUMBER or SQL Server DECIMAL travel as big decimals so precision is kept, and the Fields Editor flags any column that needs a mapping decision.
• Shaping on the way in: Unlock Schema, Custom Field Functions, and UDFs change types, compose columns, or reshape records, and Allowed Operations per entity keeps history tables growing by not forwarding DELETE or TRUNCATE. See data transformation.
• On duplicate key: Upsert, Skip, or Fail, set per entity. Snowflake enforces primary keys on hybrid tables, and Gluesync checks the catalog when an entity starts and reports which behavior applies to each table.

What your Snowflake admin sets up

The agent needs a user that can read and write the target tables, a warehouse to run on, and key-pair authentication. Full statements are in the Snowflake target setup guide ↗.

1. Create a warehouse and a role for ingestion, and grant the role USAGE and OPERATE on the warehouse. Our setup script names all of them INGEST.
2. Grant the role read and write access to the target database and tables. The setup script gives it OWNERSHIP of the ingestion database and schema, which also covers the DDL that table creation and bulk staging use.
3. Create the user with that default role, warehouse, and namespace. Generate an RSA key pair with openssl, set RSA_PUBLIC_KEY on the user, and give the agent the rsa_key.p8 private key.
4. If the user has MFA enabled, generate a Programmatic Access Token and use it as the password.
5. In Core Hub, enter the account hostname (for example XYZ-123.snowflakecomputing.com on port 443 with TLS), the database, the user's credentials, and the warehouse the agent runs on.

Compute you can see, and Core Hub around it

Point the agent at its own warehouse and ingestion compute stays separate from BI and transformation workloads, so you size it, schedule it, and read its credit consumption on its own. Query Studio, the SQL workbench inside Core Hub, opens the same Snowflake connection with autocomplete, a read-only session by default, and a cost prevention banner, so checking landed rows does not need another client. See Query Studio.

Lightweight agents sit close to each source; Core Hub orchestrates them through its web UI and REST APIs and routes changes to the Snowflake agent. A pipeline groups a source agent, the Snowflake agent, and the entities they replicate. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud.

Explore the general CDC streaming architecture →

Any Gluesync source agent can feed Snowflake, each with its own native capture technique. Open the integrations finder with Snowflake pre-selected to see every source you can pair with it, from IBM i and Oracle to MongoDB and Couchbase.

One Core Hub runs Oracle to Snowflake, SQL Server to Snowflake, and MongoDB to Snowflake side by side, with the same snapshot, monitoring, and write settings for each. Gluesync keeps pace with your change volume at any scale, and you choose the write path and the warehouse per table. MOLO17 Professional Services can tune both with your team.

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