Test speed is not the only limiting factor in your ability to produce better software faster. Readability, comprehensibility, and approachability all matter too, and this architectural technique is bad for all of those.

> Readability, comprehensibility, and approachability all matter too, and this architectural technique is bad for all of those.

That's a matter of opinion.

> To get your tests to run in < 5ms

In principle, the current Rails architecture can support that. Rails permits the test environment to use a different database adapter. There's nothing stopping anyone from decoupling the database at that level. I.e. you can pick a super-fast persistence strategy for the test database adapter, if you so choose. If there isn't an adapter you find fast enough, you can even create one. (Such a project would not doubt be well-received.)

Anyway, for my part, I prefer to run my tests against the same kind of DB I use in production. It gives me greater assurances. Especially when a web app can sometimes depend on the peculiarities of a certain persistence layer. E.g., your app has a search engine that runs custom SQL--you really want to test that against the DB.

Would it be nice to run some of my tests without the DB? Absolutely. Some tests just don't need to test anything DB-related. My guess is that Rails' support for that use case will grow organically over time.