Liquibase vs DBConvert Streams
Liquibase manages database schema change through a versioned changelog with rollback and governance.
DBConvert Streams moves and replicates the data itself with Load mode, CDC, and a built-in IDE. They solve different problems and are commonly used together — Liquibase governs the schema, DBConvert Streams moves the data.
Quick answer
Choose by job
Choose Liquibase if
- Your job is governed, auditable schema (DDL) change management.
- You need rollback and a database-agnostic changelog (XML/YAML/JSON/SQL).
- You apply schema changes through CI/CD with approvals and policy checks.
- Schema drift, parity, and change governance are the problems you are solving.
Choose DBConvert Streams if
- Your job is moving or replicating table data, not governing schema DDL.
- You need initial Load plus ongoing CDC between MySQL/PostgreSQL, files, or S3.
- You want to inspect and validate source vs target data, not manage changesets.
- You are migrating data into an environment whose schema is managed separately.
At a glance
Side-by-side facts
Where Liquibase wins
Govern schema change with rollback and audit
A versioned changelog with rollback, contexts, and labels gives controlled, auditable DDL change — the problem Liquibase exists to solve, which DBConvert Streams does not.
Stay database-agnostic across engines
Changesets in XML/YAML/JSON abstract DDL across databases, so the same changelog targets multiple engines.
Enforce policy in CI/CD
Quality checks, approvals, and policy gates run as part of the pipeline, keeping schema change compliant across environments.
Roll back a bad change
Defined rollback for changesets gives a recovery path that script-only approaches do not provide out of the box.
Track and diff schema state
Drift detection and schema diff keep environments in parity and make the change history auditable.
Where DBConvert Streams wins
Move the data, not just the schema
Load mode and CDC transfer rows between MySQL/MariaDB, PostgreSQL, files, and S3 — the part Liquibase does not address at all.
Capture ongoing changes after the schema is governed
Native MySQL binlog and PostgreSQL logical replication keep the target in sync continuously, with checkpointed state and resume.
Validate data, not just schema
Built-in Compare checks row counts and sample data between source and target. Liquibase diffs schema, never the data itself.
Inspect data in the same product that moves it
Browse schemas, run SQL, and inspect ER diagrams alongside the migration. Liquibase is a CLI/build step with no data UI.
Treat files and S3 as real endpoints
CSV, JSONL, and Parquet are first-class sources and targets — outside Liquibase’s scope entirely.
Configure migration without changesets
Table mapping and filters are stream configuration, not authored changelog entries — a different model for a different job.
Workflow
Migrate data into an environment whose schema Liquibase governs
- 1Let Liquibase apply the changelog so the target schema is at the governed version.
- 2Install DBConvert Streams as a self-contained desktop app or Docker distribution.
- 3Connect source and target in Data Explorer and inspect both schemas side by side.
- 4Run a Load-mode stream to populate the Liquibase-governed target with data.
- 5Open Compare to validate the target, then switch to CDC mode to keep it in sync.
Liquibase governs the schema version and policy; DBConvert Streams moves and keeps the data in sync. They are not alternatives — they cover adjacent halves of the same delivery pipeline.
Also supported
The same workflow runs for other source/target combinations:
- PostgreSQL → MySQL/MariaDB (reverse direction, Load + CDC)
- MySQL/MariaDB ↔ MySQL/MariaDB (homogeneous replication)
- PostgreSQL ↔ PostgreSQL (homogeneous replication)
- MySQL/PostgreSQL → files (CSV, JSONL, Parquet)
- MySQL/PostgreSQL → S3-compatible storage
- Files / S3 → MySQL or PostgreSQL
FAQ
Frequently asked questions
Is DBConvert Streams a Liquibase replacement?
No. They solve different problems.
- Liquibase — Governs schema (DDL) change through a versioned changelog with rollback and policy.
- DBConvert Streams — Moves and replicates table data with Load mode, CDC, and a built-in IDE.
You would not pick one over the other — many teams run Liquibase for schema governance and DBConvert Streams for data movement.
Can DBConvert Streams manage schema change like Liquibase?
No. DBConvert Streams does not manage a versioned changelog, rollback, or policy gates for DDL. It moves data between endpoints. For schema change management, Liquibase (or Flyway) is the right tool, and it complements rather than competes with DBConvert Streams.
Can Liquibase move table data between databases?
Not as its job. Liquibase applies schema (and limited reference-data) changesets you define; it does not perform bulk data transfer, change data capture, or row-level source/target comparison between two live databases. That is what DBConvert Streams does.
Liquibase or Flyway — and where does DBConvert Streams fit?
Liquibase and Flyway are the schema-versioning choice; DBConvert Streams is orthogonal.
- Liquibase — Database-agnostic changelog with rollback and governance — heavier, more controlled.
- Flyway — SQL-first, simple linear versioning — lighter, lower learning curve.
Either one manages schema; DBConvert Streams moves and syncs the data into that schema regardless of which you pick.
When should I not use DBConvert Streams?
When the problem is purely schema change management — governed DDL, rollback, CI/CD policy, drift prevention — and no data movement is involved. In that case Liquibase or Flyway is the right tool.