Postgres is the most-used transactional database in production, and its lead over the field keeps widening. By tracking application database connections, we found that the percentage of organizations with at least one production Postgres instance grew from 54% to 60% between July 2024 and May 2026.

Postgres maintains a healthy lead over every other transactional database. Its sustained growth, alongside that of its closest competitors, MySQL and MongoDB, contradicts longstanding speculation that NoSQL is poised to supplant relational databases for modern workloads. Instead, relational databases are flourishing, with Postgres at the forefront.

The growth of Postgres has been disproportionately driven by cloud deployments. As of May 2026, 65% of organizations using Postgres in production have at least one cloud-based instance, up from 62% in June 2025. Meanwhile, the proportion of organizations with at least one self-hosted instance dropped from 47.6% to 44.6%.

The growing popularity of cloud Postgres likely reflects the broader shift toward cloud-native workloads, as organizations rely on managed services to manage costs and complexity, and build at higher volume and speed with AI.

Postgres is language-agnostic by design, but its ecosystem of client libraries, ORMs, and migration tools reflects its place in the broader software landscape. The most notable shift we found in our data is the ascendance of Python and Node.js as the most common language ecosystems used to access Postgres in production, with Python in the lead and Node.js just behind, edging out Java.

As of May 2026, roughly 20% of organizations are using Python to access Postgres, and 17% are using Node.js. The Postgres footprint of both is growing at double-digit rates, with Python up 33% and Node.js up 20% over the past two years.

Python’s ascent to the top spot reflects its broader takeover of backend, data engineering, and data science work, which has been underway for several years. In the coming years, its lead over Java is likely to grow, particularly as AI coding assistants, which overwhelmingly default to Postgres when scaffolding a new application, accelerate adoption in modern languages like Python and Node.js.

Postgres owes much of its staying power to its extensibility. Rather than trying to serve every use case out of the box, Postgres exposes hooks (for custom data types, index access methods, and procedural languages) that let developers bolt on new capabilities without forking the database. A single Postgres instance can take on entirely new roles depending on which extensions a team installs, and that flexibility is widely leveraged: About half of all production Postgres instances run at least one extension that is not bundled with the core distribution. These extensions are strong indicators of how teams are actually using Postgres.

Among them, the most popular by a wide margin is pg_cron, which appears in 17% of instances and provides in-database job scheduling, supporting everything from administrative cleanup tasks to application business logic. Among domain-specific extensions, postgis is the most widely used, supporting geospatial queries in 8% of all production Postgres instances. The remaining extensions in the top 10 are largely operational: pgaudit for audit logging, pg_repack and pg_partman for table and partition management, hypopg for index experimentation, pglogical for logical replication, and provider-specific helpers like aws_commons and pgaadauth (Azure).

Meanwhile, the fastest-growing non-bundled extension is pgvector, which turns Postgres into a viable vector store for AI applications. Between December 2025 and May 2026, pgvector usage grew by 24%.

While the most popular non-bundled extensions still reflect long-established needs like scheduling and geospatial queries, pgvector’s place at the top of the growth chart shows that Postgres’s extensibility is now being used to move AI workloads from the application layer into the database itself. This is yet another indicator that Postgres’s role in modern applications is expanding, not narrowing.

As the role of Postgres in the modern stack continues to grow, so do the stakes of its performance. But, as we’ll see, the biggest opportunities for improvement may not be where most operators expect to find them.

Postgres performance tuning tends to focus on query efficiency, but one major source of latency is the time backends spend waiting on clients between queries. In fact, by aggregating wait event samples, we found that Postgres backends spend 56% of their time idle in transaction. In this state of database-side inactivity, client-side logic leaves a transaction open without sending any queries to process, which can degrade Postgres performance across the board: slowing down queries, filling up connection pools, and bloating tables by preventing autovacuuming from cleaning up dead rows.

Only 37% of total backend time is spent in Postgres itself, on tasks like I/O, query execution, and lock acquisition. Client-side latency also accounts for a significant portion of query execution time. Actively executing queries spend 8% of their time in ClientRead—in other words, waiting on applications.

Setting an idle_in_transaction_session_timeout can remedy this imbalance by limiting how long any single transaction can hold locks, connection slots, and other resources without doing useful work. When client-side logic (e.g., a slow API call, a paused background job, or an unresponsive user session) leaves a transaction open, the timeout forces a release before the situation cascades into widespread resource contention.

Overall, our findings place the application and network layers in the performance optimization spotlight. The upshot is clear: For most Postgres workloads, performance tuning should be focused at least as much on the application, network, and connection-pooling layers as on the database itself.

Postgres timeout settings are crucial but vastly underused reliability safeguards. Long-running queries, transactions, and sessions can drive up overhead, eat into critical resources, and bring down instances.

These critical failure modes are easily preventable by setting statement_timeout, idle_in_transaction_session_timeout, and idle_session_timeout (at the server level for overall coverage and at the session level for workflows that require longer-running queries, such as batch jobs). Yet our research found that the majority of instances lack these basic safeguards, meaning any bad query, idle connection, or open transaction can have runaway effects on performance and overhead. Only 15% of production instances have statement_timeout enabled, meaning that in 85% of instances, bad queries can run indefinitely, consuming CPU and I/O and potentially blocking other queries. And just 9% of instances have idle_session_timeout enabled, which prevents idle connections from accumulating and saturating connection pools. Meanwhile, 15% of instances have idle_in_transaction_session_timeout disabled, allowing open transactions to hold locks, block autovacuuming, and bog down query performance.

What’s more, 77% of instances configure max_connections above 200 and statement_timeout as 0. These instances are at high risk: Extended queries with high max-connection limits can trigger spikes in concurrency that few instances can handle.

Breaking down idle_in_transaction_session_timeout usage by cloud provider offers a more detailed picture: Only 57% of self-hosted instances have idle-in-transaction timeouts enabled versus 99% in AWS (which enables them by default), 33% in Azure, and 11% in Google Cloud. This gap reflects a broader pattern in how teams use managed infrastructure. Operators of managed database services tend to rely on providers’ default tunings and rarely revisit them, while teams with self-hosted databases configure these settings more deliberately. But those using AWS-managed Postgres shouldn’t take the default setting for granted: AWS sets idle_in_transaction_session_timeout to 24 hours, while most workloads would benefit from shorter limits tailored to their use cases. Setting shorter timeouts carries no meaningful performance cost, since these are lightweight server-side timers that add no overhead to query execution.

With Postgres workloads spending 56% of their time idle in open transactions, the widespread omission of well-tuned idle_in_transaction_session_timeout settings suggests major opportunities for reducing the risk of failure modes.

Indexes are the single most important tool for database query performance, and Postgres supports a uniquely rich set of types—B-tree, GIN, GiST, BRIN, and hash—optimized for different access patterns. It also supports advanced indexing techniques such as covering indexes, partial indexes, and expression indexes, which can dramatically improve query performance for certain access patterns.

Our research found that while more than 99% of tables in production instances use some form of indexing, there’s a world of difference between the sophisticated indexing that Postgres makes possible and what the community actually uses in production. Notably, the overwhelming majority of tables in production use just one index type. Unsurprisingly, B-tree indexes, the most versatile index type and the one best suited to the equality and range queries that power most application workloads, are pervasive.

By contrast, we found that covering indexes and partial indexes, two powerful Postgres optimization tools, are almost entirely ignored. They account for only 0.3% and 1.8% of indexes, respectively, despite the fact that they offer major performance benefits, such as index-only scans and fine-tuned query scopes.

After B-trees, GIN indexes, which are optimized for full-text and JSONB search in particular, are the clear second choice: More than half (62.1%) of organizations use them, although only 12.6% of tables carry one. Their popularity reflects the popularity of Postgres as a solution for text search and JSONB workloads in production, a role often associated with specialized solutions such as Elasticsearch. Indeed, JSONB usage is widespread: 22% of tables have at least one JSONB column. However, a mere 2% of those JSONB columns carry any index, indicating that teams are storing semi-structured data in Postgres without indexing it for efficient access.

BRIN indexes are not very widespread: 9.7% of organizations use them. But these organizations use them extensively, in 4.8% of all tables. Finally, vector indexes (HNSW and IVFFlat) remain uncommon: Fewer than 6% of organizations and less than 1% of tables use them, a finding consistent with the modest pgvector extension adoption documented in Fact 3 of this report.

Database upgrades have a reputation for being laborious, high-risk undertakings that teams put off as long as possible. Major-version Postgres upgrades in particular require either downtime or careful planning around logical replication. Meanwhile, understanding how often the community actually upgrades is essential for anyone writing tooling, extensions, or documentation that needs to stay relevant. Our research shows that organizations move through major versions much faster than conventional wisdom may predict.

As of May 2026, over 94% of Postgres instances run versions 14 through 18, with roughly half running versions 15 or 16. The median organization upgrades Postgres major versions every 6.9 months. From July 2024 through May 2026, 39% of organizations using Postgres performed at least one major-version upgrade, and a meaningful segment moves even faster: 17% of organizations have upgraded to a new major version within the first month of its release at least once, and 34% have upgraded within three months at least once.

This pace is partly driven by managed database services that simplify major-version upgrades, reduce their operational risks, and drop support for older versions. Managed instances adopt Postgres versions 17 and above at double the rate of self-hosted ones. Overall, 10% of organizations average 17 months or more between upgrades, leaving them on versions that will eventually lose community support and accumulate unpatched CVEs.

Partitioning, which splits one logical table into multiple physical segments, is the native Postgres solution for managing tables that outgrow optimal queryability. When data volume or write throughput exceeds the capacity of a single machine, sharding—distributing data across multiple machines—is the next step up. Postgres has no native sharding support, so it requires an extension or application-level logic.

We found that partitioning is a common strategy, being used by about 32% of organizations—albeit in only 9% of databases and 0.4% of tables, so the organizations that use it do so sparingly. By contrast, dedicated sharding solutions are exceedingly rare: 0.32% of organizations use Citus, the most popular of these solutions.

These findings suggest that organizations are probably using alternative strategies to scale large workloads horizontally, such as application-level sharding logic and the parceling of monolithic databases for domain-specific workloads.

Looking ahead

Postgres is the database of choice for modern applications, AI workloads, and analytics pipelines, and with AI-driven development accelerating adoption in Python and Node.js, its footprint continues to grow. Our analysis indicates widespread opportunities for performance and reliability gains for the growing number of organizations using Postgres. Surprisingly, some of the biggest opportunities are simple matters of operational hygiene: fixing application-side transaction behavior and implementing timeout settings. And, while we expected B-tree indexes to be ubiquitous, the extent to which teams are neglecting Postgres’s powerful indexing toolkit—which is among the qualities that sets it apart from other database solutions—was eye-opening.

Our data makes it clear that many teams treat Postgres like a simple managed service and, in doing so, expose themselves to avoidable performance and reliability failure modes. As Postgres becomes increasingly ubiquitous, treating its optimization as an end-to-end discipline is sure to have growing benefits. We’ll dive deeper into Postgres optimization opportunities in a forthcoming series of posts.