Choosing the dull, proven tool is usually the most innovative decision you can make.
Every team has a limited budget of novel, unproven decisions it can absorb before operational risk piles up. Spend that budget on the thing that's actually core to the product — not on the database, the queue, or the deployment pipeline, where boring and proven is a feature.
The team that picks Postgres instead of the trendy new database isn't being unambitious. It's saving its risk budget for the one or two decisions that actually differentiate the product.
Boring technology comes with a decade of documented failure modes, a large hiring pool, and known answers to the operational questions that show up at 2am. New technology comes with none of that — you discover its failure modes live, in production, usually at the worst time.
This isn't an argument against ever adopting something new. It's an argument for making that decision deliberately, with a clear reason, rather than by default because it's the current trend.
Adopt the new tool when it removes a category of problem entirely, not when it's marginally faster or more elegant. A genuine step-change in capability is worth the risk budget; a 15% improvement on something that already works usually isn't.
Before adopting something new, ask whether the team could debug it at 2am without external help. If the honest answer is no, that's not necessarily a reason to avoid it — but it's a reason to be deliberate about where in the stack it goes.