Database consistency without downtime.
Compare verifies whether source and target databases stay aligned across replication, migration, backup, reporting, and active-active topologies, while both systems remain online.
What is Compare?
Compare is built for teams that need a dependable answer to one operational question: is the target still faithful to the source, even while replication and business traffic continue?
Compare is a module of the GIFRÖST platform that ensures data consistency between a source database and target databases — backups, reporting databases, active-active configurations, and other systems holding a redundant copy of the data. Throughout this documentation, we refer to these systems collectively as target databases.
The need for high data availability and near 24/7/365 access has driven organizations to maintain distributed, redundant copies of their data. In a complex IT environment, however, keeping them fully consistent is difficult, and discrepancies are a real risk. "Bad" data that goes undetected leads to poor decisions and missed SLAs, and ultimately to operational, financial, and legal risk.
Compare enables periodic comparisons — as frequent as needed — between source and target without taking either system offline. It is an easy-to-use yet high-performance tool for detecting out-of-sync data before it affects the business. It can be deployed alongside a real-time replication mechanism or independently.
Replication is running, but trust is not enough. You need proof that the copy still matches the source.
Downtime is not acceptable. Validation must happen while both sides remain online and useful.
The target influences decisions or recovery. Reporting, DR, migration, and active-active setups all need verified consistency.
Challenges in maintaining data consistency
Replication can be healthy and still leave the target incorrect. The most common failure modes are operational, architectural, and human at the same time.
Initial load tools and replication tools may serialize the same value differently, or miss open transactions during cutover.
Lift-and-shift programs introduce new cross-location consistency and compliance concerns between on-premises and cloud environments.
Character sets, locales, endianness, or incompatible date and time handling can quietly distort the target copy.
Missing primary keys, unique keys, jobs, scripts, or triggers can create duplicates or missing behavior on the target side.
Replication can behave exactly as configured and still violate data-quality expectations, without showing errors in replication logs.
Some operations, such as bulk loads that bypass transaction logging, may never reach the replication stream.
Asynchronous replication always leaves a delay between source change and target visibility, which can break SLAs and audits.
Reporting or standby databases are often opened for writes, and user or administrator changes can corrupt the expected copy.
A target-connected application can introduce new inconsistency later, even if the environment is aligned today.
Requirements for the solution
A useful consistency-management tool is not just accurate. It also has to be fast, selective, safe for production, and clear enough to support audit and remediation work.
Compare combines low-impact execution with selective comparison logic, live-replication awareness, and production-ready reporting. It complements replication by adding verified consistency rather than assuming it.
How does Compare work?
Compare avoids the brute-force “read everything, compare everything” model. It narrows the work down to the data that matters and separates temporary delay from actual inconsistency.
Rows are fetched from source and target, and cross-engine data is normalized so that the comparison is meaningful.
Primary keys are compared value-by-value, while non-key columns use a signature by default to reduce network transfer.
In replicated environments, suspicious rows are queued because the target may simply be behind the source for a moment.
Rows are rechecked after the configured replication threshold so that Compare can tell delay apart from persistent drift.
The row changed after the preliminary comparison, so Compare cannot confirm a stable inconsistency yet.
The row is confirmed as consistent after the follow-up check.
The row remains inconsistent even after the latency-aware confirmation step.
Hash-first comparison keeps network overhead low, while the confirmation stage filters out rows that are only temporarily out of sync because replication is still catching up.
Architecture
A typical Compare deployment is intentionally modular. Components may run on one host or many, all links are bidirectional, and the repository stores configuration only — not user data.
Configures jobs, launches comparisons, and exposes reports through the web interface.
Runs comparison jobs from repository configuration and fits scheduled or scripted execution.
Sit close to the source and target databases, fetch rows, and pass them to the comparison process.
Store configuration, support import and export, and keep operational tooling separate from business data.
Compare components
Databases
JDBC Direct database connectivity
TCP/IP + SSL Encrypted agent-to-server traffic
Supported databases
Compare is aimed at enterprise databases that commonly appear in replication, modernization, and disaster-recovery programs.
Compare currently supports the following enterprise-class databases:
PostgreSQL
Oracle
Informix
IBM DB2
Homogeneous and heterogeneous comparisons
The comparison model works both for same-engine validation and for cross-platform migrations where normalization is required before any result is trustworthy.
Use it when source and target run the same database type, such as Oracle to Oracle, and you need confirmation that replication or recovery stayed aligned.
Use it when moving between engines, such as Oracle to PostgreSQL or Informix to Db2, and Compare must normalize values before checking them.
The same workflow can validate steady-state replication, cloud migration, and gradual platform modernization without forcing a separate toolchain for each scenario.
Benefits
The main business value is not the comparison itself. It is the confidence to keep critical copies online, auditable, and safe to use in real decisions.
Detect migration gaps and replication errors before they turn into reporting mistakes or recovery failures.
Validate consistency without long re-instantiation windows or disruptive manual copy procedures.
Shorten the time between discovering an inconsistency and understanding exactly where action is needed.
Confirm that production or test databases are safe to bring back into service after incidents or migration work.
Cut operational, financial, and legal risk created by inaccurate copies of critical data.
Use reporting, standby, or cloud targets with confirmed consistency instead of assumption-based confidence.
How it works
Prefer a short walkthrough before diving into configuration details? This video summarizes the product flow and the confirmation logic on live data.
Watch the end-to-end flow before you configure anything.
Short walkthrough of the Compare workflow, configuration surface, and confirmation stage for live data streams.