... annnnd then the database technology changes, and your benchmark results of three years ago are now actively hosing you. Or you have to change databases but you can't because you embedded a lot of logic in your database layer that can't be easily ported (somewhere, a salesman for your current database product is crying tears of joy and shouting his cash-register shout, "Ka-ching! Customer lock-in! Ka-CHING baby!". Avoid these people).
Unless you have really compelling reasons to get snuggly with a particular vendor's technology, be conservative.
[This still applies if you're using a "free" database engine; you're just not paying MS or Oracle or whomever, and it's "just" your own time]
>Unless you have really compelling reasons to get snuggly with a particular vendor's technology
I'll never understand this mentality. You bought it, so why not use it? Even OSS databases have some very compelling features. Take advantage. Use the hell out of your tools.
This is tantamount to saying "I'm using Go, but I can't use goroutines, because some day I might want to use Python instead." Don't want to get too attached to the technology, right?
The only time I ever tried to go abstract is when I sold on-premises software that had to support multiple enterprise-size clients' vendor choices. You know what happened? It took forever, everyone was unhappy, and ultimately it turned into 2 vendor-specific versions and dropping the least popular 3rd. Life was better after that.
Unless you have really compelling reasons to get snuggly with a particular vendor's technology, be conservative.
[This still applies if you're using a "free" database engine; you're just not paying MS or Oracle or whomever, and it's "just" your own time]