A 'database' is a disputed term. It describes, depending on who is using it, a transactional store that preserves records under concurrent modification; an analytical engine that scans and aggregates data at speeds incompatible with transactional workloads; a vector index that retrieves semantically similar embeddings by geometry rather than by key; and, by 2026, an ephemeral compute unit that comes into existence in under a second to hold one session's worth of state and then disappears. These four things have, for most of the past fifteen years, been collapsed into a single answer: PostgreSQL, the open-source relational database whose popularity increased steadily from around 2015 until it became, at some point in the early 2020s, the starting assumption of most backend engineering decisions. The Stack Overflow Developer Survey records this: PostgreSQL ranked as the most-used database among professional developers in every annual edition from 2023 through 2025, reaching 55.6 per cent usage in 2025 compared with 45.6 per cent in 2023. That is a consensus result, and it deserves examination both as an achievement and as a warning.
The achievement is genuine. The transition from the database pluralism of the 2010s to the Postgres default has produced systems that are, in aggregate, better maintained, better understood by the engineering labour market, and less likely to fail in ways that cannot be diagnosed by a generalist. The warning is structural: when a default replaces a decision, the reasoning that produced the default stops being accessible to the engineers who inherit it. They know what to do. They do not always know why, and they cannot always recognise the conditions under which the default becomes the wrong answer.
The agent generation is beginning to identify those conditions. Not because agents are doing something architecturally novel in the abstract, but because they are doing something that exerts specific, predictable pressure on the Postgres model in the places where that model made deliberate design choices calibrated for a different kind of workload. Understanding those pressures requires understanding the argument that produced the Postgres default; the argument that preceded it, which was also a genuine engineering argument and not a fashion cycle; and the specific architectural decisions that Postgres made that the agent generation will need to revisit.
The revolt that was half right
The NoSQL wave that began around 2009, named at an event in San Francisco that Johan Oskarsson organised to discuss non-relational, distributed, and open-source databases, was not primarily a fashion. It was a response to a specific and real problem: the relational model, as it was typically deployed in the late 2000s, did not scale horizontally without substantial engineering work at the application layer, or without significant operational complexity. The databases carrying most of the world's application data at that time were MySQL and Oracle, running on single machines or small clusters with shared-nothing replication architectures that required careful manual management of write amplification, replication lag, and the topology of failover. For the kind of workload a company like Facebook or Amazon was running, these systems were not merely inconvenient. They were genuinely insufficient.
The document stores and key-value caches that emerged from this period, MongoDB, Cassandra, CouchDB, and Redis among them, were offering something coherent: horizontal scale by design, flexible schema, and explicit trade-offs between consistency and availability under partition. The CAP theorem, which Eric Brewer presented as a conjecture at PODC in 2000 and which Seth Gilbert and Nancy Lynch formalised in 2002, gave the intellectual architecture for understanding those trade-offs. You can have at most two of consistency, availability, and partition tolerance simultaneously. The NoSQL systems were making an explicit choice about which two to prioritise. For write-heavy, horizontally distributed workloads where eventual consistency was acceptable, that choice was defensible.
What happened over the decade that followed is worth reading carefully, because the post-mortem tends to be written as a story about fashion, and the fashion reading misses the structural reason for the reversion. The organisations that had built on document stores discovered that the constraints they had escaped were not arbitrary. Referential integrity, when removed from the database layer, moves into the application layer. Every query that joins data across collections becomes either an application-side join, which is expensive and fragile, or the data is denormalised, which multiplies writes and creates the consistency problems the relational model was designed to prevent. Engineers who had welcomed schema flexibility found themselves writing schema validation code in their applications; or, more precisely, they found that the implicit schema their application assumed had been made invisible until it was wrong. The secondary index problem, which early MongoDB versions handled poorly, produced query plans that surprised teams who had assumed that document access patterns would remain simple.
By around 2015, the retrospectives were appearing. Organisations whose analytics teams could not join data across MongoDB collections without moving it into a separate store. Companies whose Cassandra clusters had grown into operational liabilities requiring specialist knowledge to maintain. The reversion to SQL was not a fashion correction. It was evidence. The relational model's constraints were load-bearing in precisely the way that structural elements in a building are load-bearing: invisible when present, very visible when removed.
The return and what it established
By 2018, the direction was clear: Postgres first, unless there is a documented reason for something else. PostgreSQL had accumulated fifteen years of consistent development that no individual company controlled; the licensing was permissive; the extension ecosystem was deep and growing deeper; and the behaviour under load was well enough understood by a large enough engineering population that finding someone who could diagnose a slow query plan was not the specialist hire it had been in 2010. Amazon RDS for PostgreSQL, launched in 2013, had lowered the operational overhead of running it at scale. Google Cloud SQL and Azure Database for PostgreSQL followed. By 2020, the argument for starting a new project on MongoDB required justification in a way it had not required in 2012.
The extension ecosystem deserves more attention than it typically receives in discussions of Postgres's rise, because it is what allowed Postgres to absorb the workload classes that had previously required separate systems. The TimescaleDB extension, first released in 2017, brought time-series workloads into Postgres by adding columnar compression and continuous aggregates without requiring a separate deployment. The pgvector extension added vector similarity search to Postgres; the HNSW indexing capability it gained in 2023 brought approximate nearest-neighbour query performance within reach of purpose-built vector databases for most team-scale workloads. The PostGIS extension, which had existed since 2001, meant that spatial workloads did not require a separate geospatial database. PostgreSQL had become, by accumulation, a general-purpose data platform capable of handling workload classes that had once required specialist tools. PostgreSQL 18, released in September 2025, introduced an asynchronous I/O subsystem that delivers substantially better performance on storage-bound workloads than its predecessors. The project remains under active development by a foundation no single company controls.
This is not a comfortable achievement to examine critically, because the extension story is, in many respects, a genuine success. Operators who can run one database system rather than three have fewer operational concerns, simpler runbooks, and a smaller attack surface. The problem is not the tool. The problem is the distance between the default and the reasoning that produced it. A trade that spent a decade learning that referential integrity and ACID transactions are not arbitrary constraints should apply the same rigour to the architectural assumptions embedded in the Postgres model itself. Those assumptions were made for a reason. They do not hold universally.
Three places the default conceals a decision
PostgreSQL's connection model allocates a process per connection. A client connecting to Postgres spawns a backend process on the server; that process holds state for the duration of the connection; when the connection closes, the process exits. This design produces predictable, isolated query execution. It also has a practical ceiling: each backend process carries a memory overhead, and maintaining several hundred simultaneous backend processes becomes measurable in context-switching cost on any reasonable server configuration. Well-established practitioner guidance places the practical limit for a single Postgres instance at somewhere in the range of two to six hundred simultaneous connections before pool management becomes the dominant operational concern. Connection poolers like PgBouncer address this by multiplexing many application connections onto a smaller number of backend processes, but the multiplexing introduces its own constraints: prepared statements that depend on connection-level state require additional configuration under session-level pooling; long-running transactions hold a backend process for their full duration; and the pooler itself becomes a component in the operational topology that must be sized, monitored, and maintained.
For traditional web applications, these constraints are well understood and the pooling pattern is mature. An agentic system is a different kind of caller. An orchestrating agent spawning tool-use subagents, each of which may need a database read or write in the middle of a longer computation, produces a connection demand profile that is bursty, concurrent, and difficult to predict at design time. The agent's connection holds open for the duration of a tool call that might pause for confirmation, or for the duration of a chain of reasoning that might take several minutes. The pooler's behaviour under this kind of workload requires different configuration reasoning than the same pooler serving a conventional OLTP application. The connection handling decision was made by the engineers who designed Postgres; it was correct for the workload it addressed, and it is not always correct for the workload that followed. The engineers inheriting the default have not been shown the decision.
The second place concerns multi-tenancy. Row-level security in Postgres allows tenant isolation within a shared database by attaching a security policy to each table that restricts which rows a given session can access. This is the correct tool for a product with dozens or low hundreds of enterprise tenants: one database, one schema, isolation enforced at the database layer without touching application code. The limitation is that query planning overhead scales with the complexity and quantity of RLS policies, and that index build times on large tables with row-level filtering become slow enough to affect operational windows at higher tenant counts. For a product whose tenants are increasingly AI agents or automated systems rather than human organisations, the unit of tenancy may be a session, a task, or a run rather than a company. The tenant count can grow to a scale where per-row policy evaluation becomes a material cost in every query plan, without the team understanding why their planner is producing unexpected estimates. They are reaching for RLS because it is the Postgres answer, without having examined whether the Postgres multi-tenancy model was designed for the tenant profile their system is going to produce.
The third and most structural is the provisioning model. Postgres was designed as a long-running server. Its autovacuum daemon is calibrated for continuous operation. Its planner statistics accumulate over time and become more accurate as the database ages; PostgreSQL 18 introduced improvements to statistics persistence across major version upgrades specifically because the planner of a newly initialised database does not reflect the actual data distribution. The checkpoint and write-ahead log configuration is designed for a system that stays up and whose data grows incrementally over months or years. These are not flaws. They are the correct design for the workload the system was designed for. They produce unexpected behaviour when the database is provisioned for a single task, populated, queried once or twice, and then discarded; which is the workload pattern the agent generation is beginning to normalise.
When the database becomes an ephemeral unit
In May 2025, Databricks closed its acquisition of Neon, a serverless PostgreSQL platform, for a reported one billion dollars. One year after the acquisition, Databricks reported more than seven hundred thousand databases on the platform, against six thousand at the time of the deal. Databricks reduced storage pricing by eighty per cent in the year following the acquisition. The figure worth attending to is not the storage price; it is this: by mid-2026, more than eighty per cent of the databases being provisioned on Neon were being created by AI agents rather than human operators. That proportion had been thirty per cent less than twelve months earlier.
Neon's architecture was designed for exactly this pattern: compute separated from storage, branch and fork operations completing in under five hundred milliseconds, instances that scale to zero when not in use and wake without perceptible delay. A coding agent that needs a database for the duration of a task can provision one, populate it with the schema and data relevant to that task, query it, and discard it. The Postgres wire protocol and SQL dialect are the same as on any other PostgreSQL deployment. The operational model, the performance characteristics under connection churn, the durability assumptions, and the backup and recovery story are not the same as those of a database running on managed Postgres with standard block storage. An engineer who has run Postgres at scale on a managed service and assumes that their knowledge transfers directly to Neon without adjustment is making an assumption that will produce surprises: not catastrophic ones, but the kind of surprise that takes an hour to diagnose if you know what to look for, and longer if you do not.
The lesson of that decade was not 'use Postgres'; it was 'understand what your database needs to guarantee, and verify that the system you have chosen guarantees it'.
The Neon story is significant not because Neon replaces Postgres but because it demonstrates that the abstraction called 'Postgres' now contains at least two meaningfully different systems underneath the same protocol, and that the agent wave is moving the majority of new database provisioning events onto the variant whose operational model differs most from the one that informed the engineering knowledge of the people deploying it. SQLite, which has undergone its own resurgence through the libSQL fork, the Turso distributed platform, and Cloudflare's D1 edge database, represents a third variant: the database as a file local to the compute, with replication handled by the infrastructure layer. These are not marginal choices. They are the default for specific workload classes, and those workload classes are growing.
“The lesson of that decade was not 'use Postgres'; it was 'understand what your database needs to guarantee, and verify that the system you have chosen guarantees it'.”
The parallel to the NoSQL decade is not precise, and pointing to it risks the same pattern of reasoning it is meant to illuminate. The argument here is not that Postgres will fail as MongoDB failed, or that the specialist databases emerging around specific workload classes will displace it the way document stores briefly appeared to displace relational systems. The argument is more specific: the default replaces the decision, and the conditions under which the default was correct are not permanently stable. A trade that spent a decade learning that referential integrity and ACID transactions are not arbitrary constraints will need to apply the same rigour to the architectural assumptions embedded in the Postgres model.
The teams most exposed are not the ones running Postgres for traditional OLTP workloads. Those teams have fifteen years of accumulated operational knowledge and a deep ecosystem of tooling, monitoring, and personnel to draw on. The teams most exposed are the ones building agentic systems on a Postgres foundation because Postgres is the default, without having examined which properties of that foundation are necessary for their workload and which properties are conventions that will not hold at the scale or workload profile they are building toward. The check is not complicated. It requires asking, for each property the database provides, whether that property is needed; and for each property needed, whether the variant of Postgres in use actually provides it under the workload conditions the system will encounter. That question was not asked often enough in 2009, and the absence of it was expensive. The absence of it in 2026 will be less dramatic and harder to attribute, but not less costly.