With default settings. I agree that keeping them as default is fairly bad, but in a growing scenario you need people who know the defaults very well anyway. After all, quiet database silliness is only one of the many ways you can quietly corrupt huge swaths of data.
It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are going to bite you. There is no escaping from knowing about the complexity, but you may escape from typing it out every single time.
Defaults count. Elsewhere I've said that I prefer to start with rigid guarantees and relax them. Default policy matters because in practice:
* The documentation isn't read.
* Even when it's read, the documentation may be incomplete.
* When it's read and complete, the crucial segment may be skimmed.
* When the documentation is complete and the crucial segment was read, it may have been misunderstood because of unclear writing.
* When the documentation is complete and the crucial segment was clearly written and read, it may be forgotten later on.
Then a new DBA or programmer arrives, and the whole thing starts all over again.
Safety mechanisms that require active effort above the baseline configuration do not work very well. Saying "there is a great mechanism" does not describe the actual properties of the actual system. The default policy is the policy that counts, because a single omission will reintroduce it.
Windows XP, buffer overflows, botched system deployments and so on all have a common property: they require positive effort by humans in order to rise above their baseline safety/security/reliability profile. There is no failsafe -- they only work by constant vigilance.
It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are going to bite you. There is no escaping from knowing about the complexity, but you may escape from typing it out every single time.