I would argue that a lot of weaker elements in the stack (e.g. PHP) work well because of a stronger database. A good database system does a lot to catch errors

I would argue that a lot of weaker elements in the stack (e.g. PHP) work well because of a stronger database. A good database system does a lot to catch errors (including consistency problems), isolate them, and roll them back. Moreover, it will allow you to move performance problems into the database, where it's likely to be handled more efficiently with less application code (e.g. joining in the database is likely to be more efficient than a naive join algorithm implemented in the application). Some will argue that these are misfeatures and should be handled in the application. In some cases, that is true; but you are probably going to need some other aspects of the stack to be very robust and performant to get reasonable results. In other words (please excuse my examples as they are intended for illustration and not flamebait), PHP over Posgres might be fine; Haskell over MongoDB might be fine; but PHP over MongoDB is playing with fire. I'd still say that, in most cases, the database layer is the first place to start to work toward a robust system. Even a proven-correct Haskell program can fail miserably if there was a minor bug three versions ago that wrote some bogus data that wasn't caught by a good database layer.