Why Postgres is still our default database in 2026, and the extensions that make it one

Almost every client backend we build starts with the same decision: PostgreSQL. Not MySQL, not a document store, not whatever database a framework’s starter template happens to default to. We’ve used Supabase, which is Postgres with auth, realtime, and storage layered on top, on client work including Fairslice, and it’s the default we reach for unless a project gives us a specific reason not to.

The reason isn’t nostalgia for a database that’s been around since 1996. It’s that Postgres in 2026 does more jobs than it used to, without you adding more moving parts.

The part people underrate: it’s one database that does five jobs

A few years ago, a typical SaaS stack needed a relational database, a separate vector database for AI features, a job scheduler, and maybe a geospatial or time-series store bolted on for whatever the product needed. Each one is a separate service to provision, secure, back up, and keep patched.

Postgres’s extension system means most of that collapses into one database. You add an extension with a single SQL command, CREATE EXTENSION, and the functionality lives inside the same database, the same backups, the same connection pool, the same access controls you already have. For a small team, that’s not a minor convenience. It’s the difference between operating one piece of infrastructure and operating five.

The extensions actually worth knowing

pgvector, for AI features. It adds a vector column type and similarity-search operators directly to Postgres, which means embeddings for search, recommendations, or retrieval-augmented generation live next to your regular relational data instead of in a separate vector database. Half-precision vectors (halfvec), which roughly halve storage with minimal accuracy loss, and parallel HNSW index builds for large datasets are both part of it now, along with iterative index scans, which fix the long-standing problem where a filtered vector query returned fewer rows than you asked for because the filter was applied after the index scan finished. It’s become common enough that Supabase, Neon, and AWS RDS all treat it as a headline feature rather than a niche add-on. For most small and mid-size apps doing AI search or RAG, a separate vector database is no longer necessary. Postgres with pgvector handles it.

pg_cron, for scheduled jobs. A cron-style job scheduler that runs inside the database, using ordinary cron syntax, to fire off SQL on a schedule: purging expired sessions, refreshing a materialized view overnight, sending a daily digest query. The alternative is standing up a separate job runner or relying on a serverless cron trigger that has to reach back into the database anyway. Keeping the schedule next to the data it operates on is simpler to reason about and one less thing to monitor.

PostGIS, for anything geographic. If a product needs to answer “what’s near this address” or “which delivery zone does this point fall in,” PostGIS is not one option among several, it’s close to the only serious option in the open-source world. It adds proper geographic types, spatial indexes, and the functions (distance, containment, intersection) that geo features actually need.

TimescaleDB, for time-series data. Sensor readings, event logs, usage metrics: anything where you’re storing a lot of timestamped rows and querying by time range. It adds functions like time_bucket for aggregating into intervals and can outperform vanilla Postgres by an order of magnitude or more on time-based queries at real volume. Below a few million rows it’s not worth reaching for. Above that, it’s the difference between a dashboard query that runs in milliseconds and one that runs in seconds.

pg_stat_statements, for knowing what your database is actually doing. Not glamorous, and not optional. It tracks execution statistics for every query that runs against the database, so instead of guessing why the app got slow, you can query for the actual slowest statements by total time or by call count. We turn this on for every client deployment. If it isn’t on, “why is the app slow” is a guess instead of an answer.

pg_trgm, for search that tolerates typos. Trigram-based fuzzy matching, useful for a product search box or a customer lookup where users don’t type things exactly right. It’s a smaller lift than standing up a dedicated search service like Elasticsearch, and for most small business catalogs and CRMs it’s plenty.

Where the extensions play well together

The composability is the underrated part. pgvector, PostGIS, and TimescaleDB operate on different column types and don’t step on each other. A single Postgres database can run vector search for an AI feature, geo queries for a store-locator, and time-series rollups for a metrics dashboard, all in one place, with one set of credentials and one backup job. That’s a genuinely different operational posture than juggling four managed services from four vendors, each with its own outage history and its own bill.

Where we don’t reach for it

Postgres extensions solve a lot, but not everything, and being honest about the edges matters more than the sales pitch:

• Extreme-scale vector search. Past a certain size (tens of millions of vectors with tight latency requirements), a purpose-built vector database like Pinecone or Weaviate can still outperform pgvector. Most client projects never get there. Some do, and for those, the honest answer is a dedicated service.
• Full-text search at serious scale. pg_trgm and Postgres’s built-in full-text search cover most small business needs. A large content site or marketplace with real search-relevance requirements eventually wants Elasticsearch or Meilisearch.
• Extension sprawl for its own sake. Every extension you enable is still a piece of surface area to understand and keep patched. We add one when a specific feature needs it, not because it’s available and might be handy someday.

Updates and corrections

A correction on pgvector’s timeline, August 19, 2026. The original version of the pgvector paragraph above said the 2026 releases added halfvec and parallel index builds. That was wrong, and wrong in a direction that undersells the point. halfvec and sparsevec shipped in pgvector 0.7.0 on April 30, 2024, and parallel HNSW index builds shipped in 0.6.0 on January 30, 2024. The genuinely notable addition since then is iterative index scans, in 0.8.0, which stop a filtered similarity query from quietly returning fewer rows than requested.

The dates matter because of what the paragraph is arguing. “New this year” is a reason to be cautious about a dependency. “Shipped two years ago, and has been in every managed Postgres offering since” is the actual case for putting your embeddings in the same database as everything else, and it is a stronger one. We have fixed the paragraph.

Update, August 23, 2026: the extension argument needs a second half. On August 13 the PostgreSQL project shipped a maintenance release across every supported branch that closes 28 CVEs, the largest security batch in its history and more than double the previous record. Six of the 28 are in contrib modules, and two of them are extensions this page recommends by name: pg_stat_statements (CVE-2026-14676, CVSS 8.8) and pg_trgm (CVE-2026-14678, CVSS 4.3). pgcrypto is a third, and its bug is the ugly one: for certain deprecated ciphers it silently XOR’d plaintext instead of encrypting, so data that looked encrypted never was.

We still stand behind the argument on this page. One database that does five jobs is genuinely fewer things to secure, back up and patch than five services. But the bullet above about “extension sprawl” understated the reason. An extension is not a plugin sitting beside your database; it is C code running inside the database process, with the database process’s privileges. A buffer overflow in a fuzzy-matching extension is arbitrary code execution as the operating system user running Postgres, not a contained failure in a search feature. Consolidation reduces the number of systems you operate and concentrates the blast radius of any one of them. That trade is still worth making for most small businesses, and it is a trade rather than a free win. The practical version: run SELECT extname FROM pg_extension; and take off anything you cannot name a business reason for.

Postgres 19 is coming, and your host’s calendar matters more than the release date. PostgreSQL 19 is in beta with general availability expected around September or October 2026. We wrote up the six changes that matter for a small app, including a REPACK CONCURRENTLY command that finally reclaims bloated disk space without locking the table, and two changed defaults that affect behaviour on machines nobody has touched. Nothing in it changes the argument on this page. It does change what a routine upgrade looks like, and if you are on a managed platform, when you get the choice at all.

The bottom line

The database engine matters less than people think; most of the well-known options are solid. What matters is the ecosystem around it, and Postgres’s extension ecosystem is deep enough in 2026 that it genuinely changes what a small team can build without adding headcount or vendor bills. A single Postgres database, correctly extended, replaces what used to take a relational database plus a vector database plus a job queue plus a geo service. That’s fewer things to break, fewer bills to reconcile, and fewer 2am pages.

If you’re deciding on a database for a new build, or wondering whether your current one is actually the bottleneck, send us a note and we’ll give you a straight answer.