What is PostgreSQL, and why do products still bet on it?

James L. Cowan Jr. · @jameslcowan

Last updated April 29, 2026, 1:28 PM·7 min read Like

postgresql product-engineering

Every few months someone declares that databases are solved and the real work moved somewhere else. The hot layer changes. The durable layer does not. PostgreSQL, usually called Postgres, is still where teams put the records that must survive a bad deploy, a bad quarter, and a bad hire. If your product handles money, ownership, permissions, or anything a regulator might ask about later, Postgres is the default serious answer. Not because it is fashionable. Because it keeps promises when the rest of the stack is still arguing about frameworks.

What Postgres actually is

Postgres is an open source relational database. Rows live in tables. Tables connect through foreign keys. Queries run inside transactions that either commit as a unit or roll back cleanly. That sounds academic until a payment half posts or a report from last month no longer matches the dashboard. Postgres exists to prevent that class of failure.

The project is old in software years and young in infrastructure years. It predates most of the companies reading this article. It outlasted plenty of "Postgres killers" because the killers optimized for demos while Postgres optimized for operators who wake up to pages at 3 a.m. Extensions, mature backup tooling, replication, and a huge ecosystem of drivers mean you are rarely the first team to hit your particular edge case.

Postgres does not speak HTTP to browsers. It speaks SQL over a wire protocol. Your application, an API layer, or a tool like PostgREST sits in front of it. That separation matters when you are buying software. The database is not the whole backend. It is the vault. Everything else is doors, guards, and business rules.

Why products still bet on it

Founders do not choose Postgres because their engineers want résumé keywords. They choose it because the product needs a long memory with clear rules.

Correctness under load. When two users try to claim the same resource, when inventory counts matter, when a refund must undo exactly what a charge did, you want a database that enforces constraints and transactions without hand rolled locking in application code. Postgres gives you that baseline.

A schema you can reason about. Tables, columns, types, indexes, and constraints are visible artifacts. Non database experts can review a migration diff in Git and understand that a new column is nullable or that a foreign key now protects orphan rows. That reviewability becomes a product discipline. Teams that treat the schema as a contract, often with tools like Drizzle, ship fewer silent data bugs.

Operational maturity. Managed providers, runbooks, point in time recovery, and monitoring integrations exist because millions of deployments already paid the learning tax. A five person product team should not spend its first year inventing backup strategy from blog posts.

Escape hatches without rewrites. JSON columns, full text search, geographic types, and extensions such as pgvector let you stay on one engine longer than the pitch deck assumes. You might outgrow a single Postgres instance someday. You rarely outgrow the model of storing relational truth in Postgres first.

Scaling paths that do not start with a rewrite. Read replicas, connection poolers, and partitioning strategies are well trodden. You can defer sharding conversations until metrics prove you need them. For most SMB products, the first scaling work is indexing, query shape, and caching hot reads, not abandoning Postgres for a document store that punts constraints to application code.

Where Postgres fits in a modern stack

Think in layers:

Postgres is the center of the data row. Hosting choices change how quickly you get preview databases and how you pay for idle environments. Schema tools change how migrations ride alongside application code. The database engine itself stays the anchor.

If you are comparing Postgres to a schema driven HTTP layer, read What is the difference between Postgres and PostgREST?. That article separates the vault from the door. This one is about why the vault is still Postgres.

What Postgres will not do for you

Honesty saves quarters.

Postgres will not replace product judgment. A perfect schema with bad naming still confuses every new engineer. Postgres will not fix missing indexes when traffic arrives. It will expose them. Postgres will not choose your authorization model. Row level security is powerful and easy to misconfigure. Postgres will not make serverless cold starts disappear. Connection discipline still matters, especially when functions spin up often.

Teams sometimes treat Postgres as interchangeable with "any SQL cloud." The wire protocol is similar. The operational details are not. Extensions you rely on, backup windows, connection limits, and migration workflows differ by host. Pick the engine first because your data model deserves it. Pick the host second because your shipping cadence deserves that.

Preview environments and the shipping loop

The old pain was not Postgres itself. It was copying production shaped data safely, standing up a database for each pull request, and tearing it down before the bill became a line item on a board deck. That pain pushed teams toward shared staging databases that everyone broke, or toward skipping integration tests because the environment was too heavy.

Modern Postgres hosts attack that bottleneck. Neon branches databases the way Git branches code. A preview app can point at an isolated database that shares storage ancestry with production shaped fixtures without sharing production credentials. That changes how often teams run migrations before merge and how confidently they demo work in progress.

Postgres remains the contract for what is true. Neon changes how cheaply you test changes against that truth.

Schema as the product's spine

Application code churns every sprint. The schema changes more slowly and more painfully, which is a feature. When the schema drifts from what the code assumes, users feel it as broken flows and silent corruption. Strong teams make schema changes visible, reviewable, and reversible.

That is why Postgres pairs well with migration first workflows. SQL migrations are the source of truth. Application types derive from the schema instead of the other way around. Drizzle popularized that inversion for TypeScript teams: define tables in code that generates SQL, check diffs into Git, and let CI prove the application and database agree before deploy.

Postgres rewards this discipline because constraints live in the database, not in a comment someone forgot to update.

A decision guide for founders

Use Postgres when:

• Multiple features read and write the same records of truth.
• You need transactions across more than one table.
• Auditors, investors, or customers will ask what happened to data on a given date.
• You expect the product to live longer than the current front end framework.

Think twice before reaching for something else when:

• The workload is genuinely ephemeral and loss is acceptable.
• You are prototyping disposable demos with no migration path.
• Your team lacks anyone who will own backups and access control.

Even then, many teams prototype on Postgres anyway because promoting a prototype to production without a migration fire drill is worth the modest overhead.

Ask vendors concrete questions:

1. Where do backups live and how do you test restores?
2. Who can connect from where, and how are credentials rotated?
3. How do preview or staging databases get created and destroyed?
4. Which extensions do you support, and what happens if we need one you do not?

The answers tell you whether you are buying Postgres or buying a logo that happens to say Postgres on the slide.

The bet that still pays

Products still bet on Postgres because independent builders and large companies share one constraint: once data belongs to users, you cannot treat it as disposable. The fashionable layers above the database will keep changing. HTMX today, something else tomorrow. The records of who paid, who owns what, and what the system knew at close of business need a home that survives those swaps.

Postgres is that home for a huge slice of serious software. Not because the internet lacks alternatives. Because when the demo ends and the product has to run for years, teams want the boring engine that already proved it can.

Work with Kleto

I am James Cowan, a product engineer and the founder of Kleto. Kleto is a product engineering agency that ships production software from strategy through handoff. We help teams choose Postgres well, wire it into preview workflows, and keep the schema honest as the product grows. If that matches your stack, contact Kleto and we will scope a sensible first step.