Read Skew is acceptable only during application runtime

Read Committed Isolation provides sufficient transaction guarantees, like allowing aborts, preventing transactions from reading incomplete results, and avoiding concurrent writes from getting intermingled. However, there are still a few types of concurrency bugs that can occur.

An excellent example of an anomaly that frequently occurs in this isolation level is the Read Skew.

A Read Skew is a special case of Non-repeatable Reads: database queries executed within a transaction fetch results that are not in sync. This could happen if a transaction changed and committed data in the time gap between the query runs.

Read Skew is considered acceptable under run-time conditions for most applications. The rare occurrence combined with the easy solution of a refresh makes it a small issue.

But Read Skew is not tolerable under non-run-time conditions:

• Database backups that happen when the database is still under use need to capture data as it was at the start of the backup process. Read Skew can result in corrupt data. If the backup is ever restored, the inconsistencies will become permanent.
• Reporting and Analytics queries can take a long time to run as they scan large parts of the database. Read Skews can result in data discrepancies, rendering the reports untrustworthy.
• Integrity checks built into the system to verify data sanctity can trigger false alarms when they encounter Read Skews.

While these issues seem trivial at first glance, their impact size expands as the system grows in users and data size.