Having your main code write, read back, and then compare, is self-validating code. Yet you should write some unit tests that such logic works correctly. If you have a unit test that round trips your data to a database, and confirms the validation code works, then you don't need to deploy the self-validating code. You would know the logic to round trip data is correct so you no longer have a need to deploy the self-validating code. You can avoid the computational overhead of deploying self-validating code. Better yet your unit tests would find any bugs before they went live and disappointed your users.
With the self-validating approach you should write both positive and a negative unit tests. The negative one would have to return bad data from the database. That might require you to mock the database to return bad data. So it not clear that properly testing the self-validating code would be less programing effort than writing some basic test that your database access logic works as expected.
There are extreme cases where self-validating code might be justified such as life support systems. Clearly they must also be fully unit tested and integration tested. The self-validating logic is more to protect against things like hardware failures.
What is likely the true problem here is that working with your database seems too hard. Yet there are lots of tools and frameworks that try to make it easier to write some data access tests. It's probably a good investment in time to look into some frameworks to make testing against a database easier.
With Java I have seen applications that use Oracle or DB2 have database access tests that run against in memory databases like H2 or Apache Derby. This was a valid approach as the tests were checking that objects could be queried and saved using an object mapping technology (e.g., Hibernate or JPA). It prevented human error of modifying application code or the database schema in a way that broke database persistence. In effect the tests trusted that the object mapping technology worked consistently with different database drivers and backend relational databases.
Such tests worked well as the majority of bugs were either column name bugs, or column type bugs, within in the database mapping configuration. Those are caught running against any database. The sort of bugs that were not properly tested using different databases in the unit tests are things like numerical precision that varies between database engines.