Get the best of both world by mocking the database API itself. Use the mocks to memoize the db output. Disable the mocks if you need long thorough tests. Determine if the mocks need to be disabled by comparing the date of the last thorough check with the date of the last db schema change. Instead of something global like this, one could come up with something local to the test file, using a system of cassettes. Doing something like this would require to make the database a value and memoize according to its current state, but I think it's doable.

This is my take. I have one test suite that should be able to run upon file-save and be completed in about 5 seconds. Then another suite that takes about 20 minutes that I can run in CI or locally. I suppose unit vs integration, but I don't worry about conforming to those definitions too strongly. Basically tests in the first suite should be fast and able to run in parallel. If they touch the file system or talk to a local db that's fine as long as it's fast and safe in parallel. The second suite can do whatever.

That may be the wall clock time but how parallelized is that?