Postgres 18 defaults to checksums on. This is a good feature for data integrity but might catch you off guard with an upgrade.

CrunchyData's platform is a central hub for PostgreSQL professionals and database administrators, offering insights into PostgreSQL deployment, administration, and optimization. Through articles, tutorials, and case studies, CrunchyData offers insights into PostgreSQL features, replication strategies, and high availability architectures. Readers can learn about database performance tuning, backup and recovery procedures, and security best practices to ensure the reliability and security of their PostgreSQL deployments.

Crunchy Data

Postgres 18 now enables data checksums by default during database initialization, providing automatic protection against silent data corruption. Data checksums work by calculating and storing a digital fingerprint for each 8KB data page, then verifying it on read to detect corruption. While this improves data integrity out-of-the-box, it creates a compatibility challenge for pg_upgrade users: both old and new clusters must have matching checksum settings. Existing databases without checksums can either use the new --no-data-checksums flag during upgrade initialization, or preferably enable checksums beforehand using the pg_checksums utility (though this requires downtime).

Postgres 18 New Default for Data Checksums and...

The new default --data-checksums for initdb

Data checksums are a game-changer for silent corruption detection, but the real operational value comes in monitoring and response. A data corruption detection at page-read time can manifest as:
<ol>
<li>Unexpected query errors in production (worst time to discover it)</li>
<li>Cascading failures as the corruption spreads through application logic</li>
<li>Replication lag or replication breaks if corruption exists in WAL segments</li>
</ol>
What CrunchyData/Postgres aren’t explicitly discussing is the incident response side: once you detect a checksum failure, you have minutes to decide whether to failover, restore from backup, or isolate the affected pages. Without proper monitoring and context correlation (when did the corruption appear, which queries touched it, what changed recently), you’re operating blind during a critical incident.
The teams that benefit most from checksums are those with proper observability: detecting the error early, understanding blast radius immediately, and having automation to trigger graceful failover before users see impact.