When we start a new project, the first conversation is almost never about tech. It's about what the client is trying to do, who their users are, and what's broken about how they're doing it today. The tech conversation happens later, and when it does, we tend to land in the same place every time: use the thing that works.
This is a deliberate choice. There are engineers who find new tools exciting, who want to use the latest database or the newest framework on every project. We are not those engineers, at least not when we're building for a client.
The hidden cost of new technology
New tech has a cost that doesn't show up on the pricing page: learning. Not learning for its own sake, which is fine on personal time. Learning on a client project, which means slower velocity, less predictable bugs, and fewer answers on Stack Overflow when something breaks at 2am.
When you hit a problem with Postgres, there is a decade of forum posts describing the exact same problem and how to fix it. When you hit a problem with a database that was released two years ago, you might be writing the forum post yourself. That's a bad place to be when a production system is down.
The same logic applies to frameworks. Express, Django, Rails, Next.js: these are boring choices. They have large communities, clear documentation, and hiring pools that don't require a niche job post. When we hand off a codebase, the client can hire someone to maintain it without looking for a specialist in something obscure.
What Postgres actually handles
The question we get sometimes is: "but doesn't X database do this better?" Sometimes the answer is yes, for specific workloads. But Postgres handles relational data, JSON documents, full-text search, time-series data, geospatial queries, and arrays without installing anything extra. For the vast majority of projects, it is not the bottleneck, and it will not become the bottleneck.
We've seen projects rewritten from Postgres to something newer because a technical decision-maker found the new thing interesting. In most of those cases, the migration took months, introduced new bugs, and solved a problem that didn't exist at the project's actual scale.
When we do reach for something new
It happens. When the boring option genuinely cannot do what the project needs, and we've confirmed that through actual testing rather than assumption, we'll use something newer. The threshold is higher than most engineers want it to be. "It's faster in benchmarks" is not a reason. "We've hit a specific wall with the existing tool on this specific workload" is.
Things earn their boring status by being good for a long time. At some point, Postgres was the exciting new option. React was a controversial choice. Node.js was a toy. They became the default because they kept being useful. That's the pattern we trust.
The goal on a client project
Ship something that works, that the client can maintain, and that doesn't break in surprising ways. Boring technology optimizes for all three. Exciting technology optimizes for the engineer's interest and the demo, and often falls apart after both of those have faded.
We find the interesting part of this work in the problem, not in the tools. The constraint of using reliable technology doesn't make the work less interesting. It removes a category of problems that aren't worth having so we can focus on the ones that are.