> Engineers often see a database simply as a place to store things, it's just a box..
Oh man, I had an edit right after posting where I almost attached an addendum about this specifically, but then decided against it to avoid distracting from my core point. There's a totally bizarre allergy to actually using database features, for fear of "lock-in" or something, yet most programs are more likely to be re-written on top of the same database than to have the database swapped out from under it, unless someone made a really god-awful choice of DB, or load scales tremendously (which falls under "good problem to have, and you can afford the migration"). The result is that we as an industry waste an awful lot of time and money creating often-buggy application-layer solutions to things that could have been solved by leveraging features of, for example, PostgreSQL, with results that'd be cheaper, less-buggy, and better-performing. Drives me absolutely nuts.
Or, like, we have nginx in our stack and it could do something we need done, with a config change or a little Lua... but no, we'll spend 10-100x as long to make a worse-performing custom solution to this problem that a thing we're already using can trivially solve for us, but we'll do it in Javascript or Ruby or Python or whatever, as part of our "app". Ugh.
And don't get me started on system-level tools and daemons. Like, we're already using Linux or FreeBSD or whatever, which come with a stupid-large set of great, proven tools, so how about we actually use it rather than just using it as a fancy DOS and paying for SaaS to do things that our OS or distro can already do, probably more reliably? But no, we don't even bother to configure a recipient for root alert emails more often than not, and we just treat the whole thing as a dumb application runner that needs some complex external support system to keep it working right.