DBSync

Cross-database schema comparison, hash-based row validation, migration tooling, and CDC pipelines when engines or schemas differ.

PostgreSQL · MySQL · Oracle · Schema Compare · CDC · Debezium · Kafka

Problem

Teams moving data between databases need two answers before cutover: what differs in the schema, and whether the rows themselves match. Row counts are not enough. Manual spreadsheets and one-off scripts do not scale.

What it does

DBSync compares source and target schemas—tables, columns, types, and row counts—and produces a clear diff. When counts agree, it validates values with column hashes and row hashes so silent drift still shows up. For same-engine PostgreSQL pairs it can drive logical replication. When schemas differ or the path is MySQL, Oracle, or another engine into PostgreSQL (or beyond), it defines a Debezium and Kafka CDC path instead.

DBSync schema comparison flowSource DBschema + rowsCompare enginetables · columns · typesTarget DBschema + rowsDiff · counts · hash drift
Schema, type, and row-count comparison before hash validation.

Cross-database comparison

  • Side-by-side inventory of objects and attributes
  • Highlight of missing tables, type mismatches, and row-count drift
  • Output meant for operators: what to fix before migration, not a raw dump of catalogs

Row validation with hashes

Counts can match while values do not. After the schema and inventory pass, DBSync fingerprints data:

  • Column hashes — a digest per selected column, so a mismatch points at the field that drifted
  • Row hashes — a digest of the whole row, so a moved or rewritten value is visible even when the table still has the same number of rows
  • Validation report — matched rows, column-level drift, and row-level mismatches, without copying the raw payload into the narrative
DBSync row validation with column and row hashesSource rowsColumn hashper-field digestRow hashwhole-row digestTarget rowsValidation reportmatched · column drift · row mismatch
After counts match, column hashes isolate drifted fields and row hashes catch mismatched values.

Migration and CDC

Logical replication fits PostgreSQL → PostgreSQL with matching shapes. Cross-engine or remapped schemas use CDC:

  1. Capture changes at the source with Debezium
  2. Stream through Kafka topics
  3. Apply with a sink connector, including schema mapping when names or layouts differ

Large loads can use phased snapshots (waves of tables) so the pipeline stays gentle on production systems—without exposing hostnames or internal endpoints in the design.

DBSync CDC pipelineSource DBMySQL / PG / OracleDebeziumchange captureKafkatopicsSink connectorschema mapTarget DBmapped store
Cross-database CDC path when schemas differ or engines are not the same.

Design principles

  • Prefer the simplest replication method that fits the case
  • Keep comparison, hash validation, and migration as separate, inspectable steps
  • Never require private infrastructure details in the architecture narrative—only roles: source, connect, broker, sink, target