Infrastructure is rarely improved by being interesting. A database earns trust by being predictable, easy to inspect when something goes wrong, well understood, and able to survive the product ideas nobody mentioned in the kickoff meeting.
Boring infrastructure gives the team more time to build interesting products.
“Boring” is an engineering compliment
Teams love discussing databases at the beginning of a product because the choice feels foundational. It is also easy to confuse novelty with advantage. A database should make common product work straightforward: transactions, constraints, joins, indexes, backups, migrations, reporting and reliable operations.
PostgreSQL keeps winning that conversation for us. It handles a remarkably wide range of ordinary product work, and it does not make the team invent a new data strategy every six months.
Relational data is still everywhere
Users belong to organisations. Orders have items. Appointments have clinicians and patients. Subscriptions have invoices. Permissions belong to roles. Most business software is full of relationships, and relational databases are very good at expressing them.
The important benefit is not that SQL is fashionable. It is that the database can enforce truths the application should not be allowed to forget: uniqueness, foreign keys, valid transactions and consistent updates.
Transactions save you from interesting incidents
A payment record and an order status often need to change together. A stock movement may need to succeed with the reservation that caused it. When a workflow needs several writes to behave as one business action, a transaction — all of them succeed or none of them do — is not academic database theory. It is the difference between a clean rollback and a reconciliation spreadsheet.
If the product team is manually fixing half-completed business operations every Monday, the architecture has created an operations feature nobody requested.
JSON is useful — and not an excuse to abandon structure
PostgreSQL can store JSON where flexibility is genuinely useful: data arriving from another system, patchy metadata, settings that keep changing, or a snapshot of an event. That does not mean every table should become id plus one enormous JSON column.
Use structure where the business has structure. Use JSON where variability is the point. The database is allowed to know things about your domain.
Indexes are product work
Performance discussions often arrive too late. A query that feels instant with 5,000 rows can become a customer-facing problem with 20 million. Indexes are the shortcuts a database uses to find rows without reading the whole table. They, and the query plans around them, should evolve with real usage.
Do not pre-optimise every hypothetical query. Do watch for slow queries in production, so the database can tell you where reality differs from your assumptions.
The ORM does not remove the database
An ORM turns the objects in your code into SQL for you. Prisma, query builders and repositories all make life easier, but PostgreSQL still does the work. Developers still need to understand transactions, indexes, constraints, joins, locking and query plans.
Abstraction is useful when it removes repetition. It is dangerous when it removes understanding.
Choose boring on purpose
There are workloads where another database is clearly better: specialised analytics, globally distributed key-value access, graph traversal or extreme time-series workloads. Use them when the workload earns the complexity.
For a large class of web and mobile products, PostgreSQL is a strong default. It lets the team postpone exotic infrastructure until the product actually needs it. That is not a lack of ambition. It is focus.