Yes and no. I have a "standard talk" that I do to explain the details, and I don't have time to reproduce that here, but I appreciate the reminder to record it or write it down! :)
The "No" part comes from writing integrated tests only at the point of actually integrating with third-party software with the express goal of checking that integration. If you write integrated tests, then write them to check that the last layer of Your Stuff integrates well with Their Stuff.
The "Yes" part comes from ignoring the duplication in the production code at this integration point. I wrote about this in detail in _JUnit Recipes_, in the chapter on testing databases. You probably don't need to test 100 times that you can execute an SQL query or update and can clean up database resources and so on. (1) Check that once and (2) Use a library for it. (In the Java world, for example, I still like Spring JDBC templates, as long as we use them as a library, and don't inherit everything else from Spring.) So I recommend this to you: start relentlessly removing duplication among your modules that talk to the database directly, and see what happens. What kinds of duplication can you extract? Some of it will be specifically talking to the database without worrying about your domain model and some of it will be specifically working with your domain model without talking to the database. Both of these options are easier to test individually than putting both together. When we check database integration using our domain model or when we run the database just to check our domain model, that's where the scam returns. Don't do that.
But, as always, do whatever you find helpful until it becomes less helpful, then try removing more duplication. That almost always helps me. :)