Boring technology is a budget decision
Choosing Postgres over the interesting option is not conservatism. It is deciding where you want to spend the finite amount of novelty a project can absorb.
Every project has a novelty budget. Spend it on things that differentiate you and the unfamiliar parts are worth the cost. Spend it on infrastructure and you have bought yourself a second hard problem alongside the one you were hired to solve.
Where the cost actually lands
Unfamiliar technology is not expensive because it is bad. It is expensive because:
- Nobody on the team has debugged it at 3am
- The failure modes are not in anyone's muscle memory
- The answers are not on the internet yet
- Hiring for it is harder and slower
- You will discover the operational sharp edges in production
None of that shows up in the evaluation spreadsheet, and all of it shows up in the year after launch.
Where to spend the budget instead
On the thing that is actually your product. If your differentiator is a matching algorithm, spend the novelty there and run it on Postgres. If it is a real-time collaboration model, spend it there and deploy on the boring platform your team already knows.
The exception worth naming
Sometimes boring genuinely will not do the job. Then take the interesting option deliberately: write down what problem it solves, what it would take to back out, and who on the team owns operating it.
That is a different decision from drifting into it because it was on the conference circuit. Deliberate novelty is fine. Accidental novelty is what you are still paying for three years later.