Choosing boring technology on purpose
The most interesting thing about a product should be the product. Picking dull, well-understood tools is how you keep it that way.
There is a version of engineering culture that treats novelty as skill — reach for the newest database, the newest framework, the newest deployment story. It reads as ambition. It usually means the team will spend the next year debugging the tools instead of the product.
Boring technology is a deliberate choice, and it is usually the right one.
Boring means understood
A tool that has been in production for a decade has had its failure modes documented by other people. When it breaks — and it will — the answer is a search away rather than a weekend of first-principles discovery.
Novelty has a budget
Every project gets roughly one genuinely new thing it can absorb without slowing down. Spend it on the part that is actually your product. If the interesting idea is the pricing model, the database does not need to also be an experiment.
Boring is not the same as outdated
This is not an argument for refusing to upgrade. It is an argument for choosing tools whose novelty is not the point: a relational database, a mainstream framework, a container, a queue. The bar is not "old" — it is "well understood by a lot of people, including whoever inherits this."
The test
Before adopting something, ask: if the person maintaining this leaves, how expensive is that? If the honest answer is "very", and the tool is not core to the product, pick the boring option.
Your users will never notice the choice. That is the entire goal.