Data Migration & CDC from MySQL to VeloDB vs ClickHouse: Data Migration & CDC Compared

1. Executive Summary

This reportdocuments a hands-ontechnical evaluation of two capabilities that are core to any MySQL-to-OLAP adoption: (a) one-time data migration, and (b) continuous live datastreaming (Change Data Capture / CDC). Both capabilities were evaluated againstthe same MySQL source database on VeloDB Cloud and on a self-managed ClickHousedeployment.

Across both areas, VeloDB Cloud consistently required less configuration, fewer moving parts, and produceda working result faster and more reliably than the equivalent ClickHousesetup.

• Migration: VeloDB'sCatalog feature connected to MySQL and loaded data through a single guidedworkflow, with no server-side configuration changes required.ClickHouse required manual network/config-file edits, and one edit briefly took the ClickHouse service downentirely.
• Live Streaming (CDC): VeloDB's managedCDC pipeline capturedMySQL inserts, updates,and deletes in real time outof the box. ClickHouse's native CDC engine (MaterializedMySQL) has been removedin current versions; replicating the same capability required standing up anexternal Kafka + Debezium stack, which failed on the available compute due tomemory constraints.

2. Architecture

3. Objective

• Evaluate the real-world steps, tooling, and infrastructure requiredto (a) migrate an existingMySQL dataset and (b)stream ongoing MySQL changes in real time, into VeloDB Cloud and intoClickHouse
• Identify frictionpoints, configuration overhead, and reliability issuesencountered on each platform.
• Provide a factual basis for selectinga MySQL-to-OLAP migrationand streaming target for future client projects.

4. Test Environment

PART A - One-TimeData Migration

A.1  Migration Path: VeloDB Cloud

• Opened the VeloDB Cloud console and navigated to Catalogs.
• Created a new MySQLCatalog by enteringHost, Port, Username, Password, and targetdatabase - no config files,no server restarts.
• Clicked ‘Test Connection’ - connected successfully on the first valid credential attempt.
• Ran a single CREATETABLE … AS SELECT statement per table in the built-inSQL Editor to physically copy datafrom the MySQL catalog into VeloDB's native storage.
• Verified row counts matchedthe source (city:4,080; country: 239; countrylanguage: 984) on the first attempt

Verification query results in VeloDB Cloud's SQL Editor confirming successful row counts and the newly created countrylanguage table under the geopits database.

A.2 Migration Path: ClickHouse

• Provisioned a dedicated EC2 instance and installed ClickHouse Server via apt.
• Initial attemptto connect to the sourceMySQL instance failed- MySQL was not yet configured for external access.
• Edited MySQL'sserver configuration (bind-address) and restarted the MySQL serviceto permit remoteconnections.
• Created a CREATETABLE … ENGINE = MySQL(…) pass-through table, then a second CREATE TABLE …ENGINE = MergeTree() AS SELECTstatement to physically copy the data - a two-step processrather than VeloDB's single guided workflow.
• Verified row counts matchedthe source after the second(physical copy) step.

A.3 Migration - Side-by-Side Comparison

PART B - Live Data Streaming (Change Data Capture)

Beyond a one-time migration, both platforms were evaluated for their abilityto continuously reflectongoing changes (inserts, updates, deletes) made to thesource MySQL database in near real time.

B.1  Live Streaming Path: VeloDB Cloud

• Enabled MySQLbinlog (row-based format)and granted replication privileges to the connecting user - a one-timesource-side prerequisite common to any CDC approach.
• Configured VeloDB'slive-streaming ingestion againstthe same MySQL source used for the Catalog connection.
• Validated the pipeline by performing INSERT,UPDATE, and DELETE operations directlyon the MySQL source and confirming each change appeared inVeloDB automatically, without any manual re-sync.

VeloDB Cloud's Import Data interface, offering native connectors for MySQL/PostgreSQL databases, S3 object storage, and event streams (Kafka, Confluent, MSK) to support continuous data ingestion.

VeloDB's "Add Import Job – MySQL" wizardcapturing the sourceMySQL connection details,including host, port, JDBC URL, and credentials.

Table configuration step, targeting a new Geopits database with "Initial Load + Incremental Sync" selected and the city, country, and countrylanguage tables chosen for migration.

Sync settings step, configuring a 60-second sync interval with Strict Mode enabled and a 0% max filter ratio.

Verify and Confirm step,showing all pre-flight checks - MySQLconnectivity, source configuration, target connectivity, and target permissions - succeeded beforestarting the job.

Import Data dashboard confirming the  mysql_world_cdc job is actively running, streaming from the world MySQL source into the Geopits destination database.

B.1  Live Streaming Path: ClickHouse

• ClickHouse's previousnative CDC mechanism, the MaterializedMySQL databaseengine, returned an ‘Unknowndatabase engine’ error - this engine has been officially removed from currentClickHouse releases.
• The currentrecommended path for MySQL CDC into ClickHouse is an externalDebezium + Kafkapipeline (MySQL binlog →Debezium → Kafka → ClickHouse Kafka table engine).
• Kafka and Kafka Connect (Debezium) containers were deployed via Docker. Kafka repeatedly crashed with an out-of-memory error, as the available compute instance did not have sufficient RAM to run ClickHouse and a full Kafka/Debezium stack simultaneously.
• A workingDebezium → Kafka capture of MySQL binlog events was independently validated(change events were confirmed flowing into a Kafkatopic), demonstrating the approach is technically sound- but completing the pipeline into ClickHouse requiresmaterially more infrastructure than a single small instance provides.

B.2  Live Streaming - Side-by-Side Comparison

5. Conclusion & Recommendation

Across both one-time migration and live streaming, VeloDB Cloud delivered a materially simpler,faster, and more reliablepath from MySQL to an analytical (OLAP) platform, with no additionalinfrastructure to design, provision, or operate.

• Migration into VeloDB required zero server-side configuration and completed without error; migration into ClickHouse required multiple manual configuration edits, one of which caused a service outage.
• Live streaming into VeloDB worked immediately using a built-in, managed capability; the equivalent ClickHouse capability has been discontinued in current releases and its replacement (Debezium + Kafka)requires standing up and operating a separate distributed system, which could not be completed on the available test compute.

Recommendation: For MySQL-to-OLAP projects that require both a straight forward initial migration and ongoing real-time synchronisation, VeloDB Cloud is the recommended platform based on this evaluation - it materially reduces engineering time, infrastructure ownership, and operational risk compared to a self-managed ClickHouse + Kafka + Debezium stack.