Note that sometimes the right DB is one specific one. Other times it is enforcing everyone use a DB abstraction so that you can switch DB. If you choose the later make sure you have 3 databases at all times to enforce using the abstraction. Ideally one isn't sql.

Likewise sometimes you choose the language (or maybe two), sometimes you choose an inter language communication protocol and allow any language. Either can be good or bad. The right answer for you is important.

Some choices above are hard to undo if you are wrong. However the hardest to undo often have significant advantages if it all works out.

I agree with the idea that you should take most seriously the decisions that will be hardest to undo.

However, using a database abstraction layer in this way is counter to optimizing for simplicity, and in a way is not making a decision at all.

If you are using a database abstraction layer so thoroughly that you really can switch between different database implementations, then you are almost certainly not leveraging the strengths of any underlying database engine to begin with. So you are limiting your performance, at the same time as introducing complexity.

That is exactly the trade off. Which is why sometimes it is wrong despite the obvious advantages of being able to change

Moving from a DB engine to another, even if technically possible (right abstractions and everything), is often extremely painful once you have a few years of data.

(I'm currently involved in migrating quite a few large DBs, and it's a pain for everyone: SREs, support teams and the customers).

But yes, there is no "one size fits all", it depends pretty much on how your org is operating.

That isn't the only reason to support more than one engine. Sometimes you don't need to move data to change the engine.

If you sell a product that needs a database you probably want an abstraction so you can use the customer's database and schema.