A common adage for any developer choosing a database technology is“just use Postgres”. While this advice remains well-intentioned, it deserves a fresh look in 2025. Thanks to a wave of recent innovations and acquisitions, PostgreSQL providers now resemble JavaScript frameworks of the 2010s - there’s seemingly a new one to consider every six months.

Just choosing PostgreSQL isn’t enough anymore - there is anentirely new decision tree to follow before you can launch a system. 🌳

Postgres uses an elephant as its mascot. This means I have a good excuse to reminisce on my March 2025 trip to Thailand 🇹🇭

Postgres Renaissance 🎨

The saying“just use Postgres” is deliberately simplistic. It is intended to reduce analysis paralysis at a critical point in a system’s lifetime. Postgres is the “boring” choice because it has been battle-tested in production for decades by thousands of companies. Beingopen-source andextensible, it has athriving community. There is very little to gain by choosing a less-proven technology. Or one with restrictive licensing. Or adopting several solutions with their own cost models. It closes the fewest number of doors when a project’s uncertainty is at its highest.

Recent Postgres versions and extensions (e.gpgvector) have introduced and significantly improved support for vector/JSON data, which makes it even harder to justify starting with a specialised store. Extensions likepg_duckdb support column-oriented, analytical workloads inside a row-oriented, transactional system.Manyarticles exist on the versatility of Postgres. Some even go as far as stating you can host a full REST API withPostgREST (though I haven’t seen Production examples of this).

In recent times, database technologies derived from Postgres have exploded in number and seen rapid success. In the last few months alone:

• 🤑Databricks acquired Neon, a serverless Postgres provider.
• 🤑Snowflake acquired Crunchy Data, a hosted Postgres provider.
• 🎉AWS Aurora DSQL was released.
• 🎉 PlanetScale expanded on its MySQL foundation, to offer aPostgres alternative.

Below is anon-exhaustive list of recent technologies derived from Postgres, and their offerings.

Image credit:TigerData

Recent Trends 🔨

In this section, we go over the main innovations that have emerged in recent years, which have caused the explosion in providers, each with their own unique offerings. As Postgres is open-source, it is possible to cherry-pick features and compromise on some fundamental aspects in order to unlock new behaviours.

Compute <> Storage Divide ➗

Postgres pre-dates the age of cloud and distributed systems. As such, it is monolithic (combining storage and compute on the same server) and process-oriented (rather thanthread-oriented). To thrive in a cloud-native world, providers havedecoupled storage and compute layers, which allows each layer to scale independently. This change enablesserverless systems like Neon and AWS Aurora Serverless. Use of durable block storage like S3 means lightweight VMs can run the Query Engine and hold minimal state, allowing horizontal scalability. Different systems embrace this to different extents. For example, Aurora Serverless v2 incurs a 15 second cold-start whenscaling up from zero.

Besides scalability, the other by-products of standalone storage aredatabase branching andfast backups due to copy-on-write semantics. These are game-changing features that a traditional Postgres system cannot provide.

Relaxing Isolation for Speed 🏎️

Postgres is flexible in supporting 4 levels oftransaction isolation at session or transaction level. By constraining the isolation level toRepeatable Read (using something like Snapshot Isolation) rather thanSerializable, we require far less consensus before transactions can commit or return data.

In most applications, the key-set of data being read is far greater than the key-set of data being written, and reads outnumber writes by an order of magnitude. This realisation along with constraining isolation level toRepeatable Read is core to theway AWS DSQL scales. By constraining in one dimension, new technologies are unlocking scale that a traditional setup could not match.

New Data Primitives 📊️

Being a general purpose and extensible database, some providers have imposed an opinionated abstraction on top of core Postgres. For example, TigerData introduceshypertables to model time-series data, which would otherwise need manual partitioning and regular pruning via extensions likepg_partman andpg_cron.

AI companies make use of vector stores (throughpgvector andHNSW indexes) to build RAG (Retrieval Augmented Generation) pipelines. The recent Databricks and Snowflake acquisitions show that engineers increasingly value an “all-in-one” platform rather than a standalone OLAP solution.

Decision Points ⚖️

This section raises a set of questions I would consider when evaluating a Postgres provider to reduce a lot of future pain points. They are not ordered by priority. Click to expand/collapse each section.

Starting Point 📍

Having raised the important questions, it is clear that there is a lot to think about upfront. In the absence of any other information (and to avoid being overwhelmed!), I would adopt these principles.

1. Stay close to the roots 🪾: Maintain runtime compatibility with standard PosrgreSQL for as long as possible. This makes local testing and feedback loops much quicker, and means faster adoption of new versions.
2. Benchmark 📐: Measure against your own workloads - do not rely solely on online benchmarks.
3. Avoid sprawl 🐙: Default to Postgres for new use cases before reaching for new platforms or databases.
4. Know your options 🧠: Periodically evaluate which migration paths exist, their upgrade timelines, tenancy models and trends.

Once a solution is adopted at scale, migration to a new setup is always possible, but it takes significant effort (just askFigma). There is no way to know the future, but with these principles in mind you will do better than most at adopting the right flavour of Postgres for your use case.

Summary 🧵

In this post, we revisited the advice to“just use Postgres” refreshed for 2025, in the broader context of acquisitions and recent product launches. The statement still holds true, but some nuance exists to answer the question of“what next?”. These questions form a practical checklist for evaluating Postgres providers.

It is an exciting time to be a developer working with Postgres, as the technology continues to evolve almost 40 years after itsinception at Berkeley.

In future posts, I may dive into some of theidiosyncrasies of Postgres or dive into systems like AWS’ DSQL. There are some great creators in the space which make it far easier to keep up to date in the meantime. For example:

• 🎧Postgres FM
• 🎧Scaling Postgres
• 🎧Talking Postgres

Get in touch 📧

As I say in myAbout page, I would love to hear from you. If you got to the end of this post and have anything to share, please get in touch onLinkedIn orTwitter.