Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Data integrity asks whether a record is unaltered. Data quality asks whether it is fit for use. The comparison table, the edge cases, and who owns each one.
Updated on
Data integrity is about whether a record is structurally sound and unaltered. Data quality is about whether that record is fit for the use you are putting it to. They are two different questions, and they are settled by two different tests. Integrity can be checked from inside the database, against rules the engine itself enforces. Quality can only be checked against something outside the database: a threshold, an expected pattern, or a source of truth in the world. A dataset can hold perfect integrity and still be useless, because nothing about a record being unaltered makes the number in it correct or the field in it meaningful.
That is the whole distinction, and most pages on this question never commit to it. They define both terms, list the dimensions of each, note that the two are related, and leave the reader exactly where they started. This page draws the line and then defends it, including the cases where it is genuinely hard to place.
Each term gets one sentence here, because each already has a page of its own. For the full definition of data integrity and the types it breaks into, physical, logical, entity, referential and domain, read what data integrity is and why it matters. For the practice of running a quality program, read how data quality management works.
The table below is the same distinction applied to eight practical questions. Read the middle column as the systems view and the right column as the business view of the same data.
| Question | Data integrity | Data quality |
|---|---|---|
| What it asks | Is this record structurally sound and unaltered? | Is this data fit for the use it is put to? |
| What it is measured against | Rules inside the system: constraints, keys, data types, checksums, transaction logs | A reference outside the record: a threshold, an expected pattern, a source of truth |
| Where the test runs | Inside the database or the storage layer, at write time | On top of the data, on a schedule or on pipeline run, after the write |
| Typical failure | Orphaned foreign key, duplicate primary key, truncated write, silent corruption, a change nobody can account for | Stale figures, wrong units, free text that cannot be grouped, a field that is populated but wrong |
| Who usually owns it | Platform engineering, database administration, security | Data engineering, analytics engineering, the business owner of the domain |
| What counts as evidence | Constraint violations, transaction and audit logs, checksum comparison between source and copy | Monitor results, test pass rates, incident counts, reconciliation against a source |
| When it is checked | Continuously, enforced by the engine, refusing the write | On a schedule you set, by a monitor you configured, reporting after the fact |
| What it cannot tell you | Whether the value is correct or useful | Whether the value was altered on the way through |
This is the most useful version of the distinction, because it tells you where the test has to live rather than arguing about definitions.
Integrity rules are enforceable by the storage engine. The PostgreSQL documentation lists six of them: check, not null, unique, primary key, foreign key and exclusion constraints. Its own description of what they do is blunt. Constraints give you as much control over the data in your tables as you wish, and if a user attempts to store data in a column that would violate a constraint, an error is raised. The database knows the rule, the database checks it on every write, and the bad row never lands. Nobody has to notice.
Quality rules cannot work that way, because the database has no opinion about whether a number is right. An order total of 4,000 is a legal positive number. Whether it is a correct order total depends on something the database cannot see: what the source system recorded, what the currency was, what a normal order looks like this month. Every quality test therefore imports a reference from outside the record, and every quality test has a threshold somebody chose.
That is also why the two disciplines fail in different ways. An integrity rule that is wrong blocks writes and you find out in minutes. A quality threshold that is wrong either says nothing for months or fires so often that people mute it, and a muted monitor protects nobody.
The monitor types in a data observability platform split along the same line. Schema drift and job failure monitors watch structure and pipeline health and can be switched on the moment a source is connected, because the system already knows what the structure is. Freshness, volume, field health and custom SQL monitors have to be configured, because each one needs a reference: how often this table normally updates, what a normal row count looks like, which values are allowed in this field, what query defines correct here. The short walkthrough below shows both halves being set up in the Decube Config module, including the freshness monitor learning each table own update pattern rather than taking a fixed schedule from you.
If you want the longer argument for why quality monitoring belongs in an observability layer rather than in scattered pipeline tests, we set it out in data quality and data observability.
Ownership is where the distinction stops being academic. Integrity is owned by the teams who own the systems, because the controls are system controls: schema design, keys and constraints, backup and restore, access management, audit logging. In practice that means platform engineering, database administration and security. Their evidence is a constraint definition and a log entry.
Quality is owned by the teams who own the meaning: data engineering and analytics engineering, with the business owner of each domain deciding what good enough looks like. Nobody in platform engineering can say whether a customer segment is defined correctly or whether yesterday figures are current enough for a pricing decision. Their evidence is a monitor result and a reconciliation. A wider data governance program is what stops those two groups from writing rules that contradict each other.
When ownership is unclear, one question settles it: who gets paged when this breaks? If the answer is the on call engineer for the platform, it is an integrity rule. If the answer is the analyst or the domain owner who has to explain the number, it is a quality rule. If nobody gets paged, the rule is decorative and it is not being enforced by anyone.
A payments table has a not null constraint on the amount column and a check constraint requiring the amount to be positive. In March the upstream system is upgraded and starts sending amounts in cents rather than dollars. Every row still satisfies every constraint. The transaction log shows no unauthorized change and no corruption. Integrity is perfect and every revenue figure downstream is a hundred times too large, until somebody notices that the quarter looks improbable. A hundred times the correct number is still a positive number, so no integrity control could have refused it. Only a volume or range expectation held outside the database catches this.
An analyst finds a wrong figure the evening before a board meeting and updates the warehouse table directly to fix it. The number is now more accurate than it was, so by the accuracy dimension of data quality the data improved. Integrity is gone: there is no record of who changed the value or why, the change contradicts the source system, and the next pipeline run silently overwrites it. This is the case that shows the two are not ranked versions of the same idea. One went up while the other went down.
Two rows for the same customer are an integrity failure in a table with a primary key on the customer identifier, because the system was told the rule and the rule was broken. In a landing table with no key defined, the same two rows are a quality problem, because nobody ever told the system that duplicates were illegal, and the defect has to be found by a test that counts distinct values. The defect is identical. Which discipline owns it depends entirely on whether the rule was ever written into the schema, which is a design decision somebody made and can revisit.
The confusion is not carelessness. There are three reasons for it and two of them are legitimate.
The overlap that is real sits in the middle: a defect that is caused by an integrity failure and detected as a quality failure. A truncated load produces a table that is structurally fine and quietly missing a third of its rows. The volume monitor is what notices, and the root cause is an integrity problem in the load. That is the case for running both, and for reading them together rather than in separate reports. Accuracy is the dimension where the two collide most often, and we cover it on its own in why data accuracy matters to the business.
One boundary worth stating plainly, because it draws the third circle people put on this diagram: security is about who is allowed to reach the data, not about whether the data is what it was. Unauthorized change destroys integrity, but so does a truncated write with no attacker anywhere near it. We separate those two in data integrity versus data security.
Both failure modes are common and each one has a signature.
Measuring integrity and assuming quality is the platform led failure. The database reports zero constraint violations, backups restore cleanly, access is controlled and audited, and the reporting layer on top is not trusted by anyone who uses it. Every system level indicator is green while analysts maintain private spreadsheets because they have learned the warehouse numbers need checking. Nothing in the integrity toolkit can detect that, because none of those numbers is corrupt. They are just wrong.
Measuring quality and assuming integrity is the analytics led failure, and it is the more expensive of the two because it surfaces during an audit rather than during a meeting. A team builds a wall of passing quality tests on a warehouse where several people hold write access, manual corrections are normal, and nothing records who changed what. Every test passes on data that cannot be traced back to a source. The dashboard is fine. The evidence does not exist.
The AI case is where the gap between the two has started to cost money directly. Research published on 18 September 2024 by Precisely with Drexel University LeBow College of Business, surveying more than 565 data and analytics professionals worldwide, found that only 12 percent report that their data is of sufficient quality and accessibility for effective AI implementation. Sufficient quality and accessibility, not sufficient integrity. A model trained on records that are unaltered but mislabeled, stale or measured in the wrong units learns the defect faithfully, and an agent acting on that data acts on it at machine speed. Before putting an agent on a dataset, the question worth answering is whether anyone can state what good looks like for each field and show a test that has been checking it, rather than whether the rows are intact.
The practical method is to stop sorting concepts and start sorting rules. Take every rule your team believes about a dataset, write each one as a single sentence, and put it through three questions.
Run that pass once against your five most used tables and the argument about definitions usually disappears, because most rules sort themselves. The ones that do not sort cleanly are the interesting ones, and they are almost always the duplicate case above: a rule that could be enforced in the schema but currently is not.
Decube runs both halves in one place, which is the reason we take this position rather than a neutral one. Column level lineage and the catalog record what the data is and where it came from, while the data observability module runs the schema drift, job failure, freshness, volume, field health and custom SQL monitors against it, so a quality incident can be traced to the structural change that caused it without moving between two tools. If you want to see that on your own tables, request a demo.
Integrity is a property of the record. Quality is a judgment about the record, made against a purpose. That is why integrity can be enforced and quality can only be measured, why integrity failures block a write and quality failures raise an incident, and why the two sit with different teams holding different evidence.
If you only have appetite for one change after reading this, make it the rule sorting pass. Most organizations discover they have been paying a monitoring tool to detect defects a constraint would have prevented, while the rules that genuinely need judgment have no owner at all. Fixing that costs nothing and it moves work from detection to prevention, which is the only direction in which this problem gets cheaper.
Data integrity is about whether a record is structurally sound and unaltered. Data quality is about whether that record is fit for the use it is put to. Integrity is tested against rules the system itself enforces, such as constraints, keys and transaction logs. Quality is tested against a reference outside the system, such as a threshold, an expectation or a source of truth. A dataset can hold perfect integrity and still be useless, because nothing about being unaltered makes a number correct.
The word is quality. Data quality involves the accuracy, completeness, consistency, validity and timeliness of data, judged against the use the data is put to. Data integrity is the separate question of whether the record stayed structurally sound and unaltered through storage, processing and transfer.
Yes, and this is the most common way the two come apart. If an upstream system starts sending an amount in cents rather than dollars, every row still satisfies its not null and positive value constraints, the transaction log shows no unauthorized change, and every figure downstream is a hundred times too large. Integrity is intact and quality is gone. No constraint can catch it, because a hundred times the correct number is still a positive number.
Integrity comes first in build order, not in importance. Constraints, keys and access controls are enforced at write time and stop a whole class of defect from entering the system at all. Quality monitors run after the write and catch what the rules could not express. Building quality monitoring on a system with no integrity controls means paying to detect defects you could have prevented.
Accuracy is one dimension of data quality: it asks whether a value matches the real world thing it describes. Integrity asks a different question, whether the value that was written is the value you are reading now. A value can be inaccurate from the moment it was typed and still have perfect integrity, and a value can be accurate at the source and lose integrity in transit.
Validity asks whether a value conforms to its defined format or domain, such as a date that parses or a country code that appears in the reference list. It sits inside data quality and it is usually testable without leaving the record. Integrity is broader and structural: it covers relationships between records, unauthorized change and corruption in storage or transit, none of which a single field validity check would notice.
Integrity usually belongs to the teams that own the systems: platform engineering, database administration and security, whose evidence is constraint definitions, access controls and audit logs. Quality usually belongs to the teams that own the meaning: data engineering, analytics engineering and the business owner of the domain, whose evidence is monitor results, test pass rates and reconciliation against a source. The clearest test of who owns a rule is who gets paged when it breaks.
No. Security is about who is allowed to reach the data. Integrity is about whether the data is what it was when it was written, which unauthorized access can destroy but so can a truncated write, a failed transaction or a bad migration with no attacker involved. Access control is one of the tools that protects integrity rather than a synonym for it.
Integrity is measured from inside the system: constraint violations, failed transactions, orphaned foreign keys, checksum comparisons between a source and its copy, and audit log entries for changes nobody can account for. Quality is measured against something outside the record: freshness against an expected update pattern, volume against a learned normal range, field health against an allowed set of values, and reconciliation against a system that is treated as the source of truth.
Three reasons. The vocabulary overlaps, because accuracy and consistency appear in the standard list for both. Vendors define the relationship in opposite directions, some treating quality as one part of integrity and others treating integrity as the protective layer quality is measured on top of. And in regulated manufacturing and finance, data integrity is a term of art covering the whole record lifecycle, which is wider than the database meaning most engineers use.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)