On my current project, we've tried to achieve a balance. The standard "build" that happens after normal editing runs the in-memory subset of our unit tests. (On a fast laptop, it adds less than 7 seconds to the build.) And I've arranged to fail the build if any test fails. Nobody complains, and large parts of our application stay unbroken.
The "live data" tests run separately, since they required creating a test schema and populating it with test data (and this requires access to a server, which isn't guaranteed for various semi-legimate reasons). This separation of tests works fairly well except that I can't get people to run the damn database tests on a regular basis. Waiting for the overnight build to catch problems takes too long; problems can multiply unseen in the interim.
There are technical aspects of this problem (e.g., we could, for a small expenditure of time, set up a continuous integration and test environment), but I think the bigger problem here is social.
Social pressure works well in colocated projects. One need only walk a few steps before applying a bitchslap. And "Whoever checks in broken code has to wear the funny hat to the morning meeting" can be very effective. I'm looking for techniques for applying pressure in a distributed team.