Well, to write a high performance payroll system with lots of concurrent users it helps a lot to know how the database you’re using works internally.

There are situations where one uses a full featured abstraction like a database without needing to understand fully or modify it's internals. This is simply not one of them.

This is a situation where building a new applications with handmade layers that produce the outcome you want is more efficient than gluing together existing code.

You're coming at a complex problem by initially filtering the solution space. This discards much of the potential solution space for which the average case may be more expensive than The average case in the space after culling. However in many situations that solution space has many gems which are more efficient. Companies' tolerance to selecting those rather than using existing technology varies.

You have the quote slightly wrong, in order to understand a payroll system you first need to know how to create a database.

Knowing how a database is constructed and having to building one for the project are two different things. Yes friend, if a database is a major component of your system you should know how it works under the hood. They’re quite complicated and impose significant constraints on the system you’re building.

Well, yes, you should know _how_, even if you’ve never actually taken the time to do it.

If you are making a commericial product that features an in-memory database that can store non-standard types of data perhaps.

More often than not you would just use an existing product if you are not going to add any value.

That’s what they say, if they require a CS degree to work there.