This isn't just theory either, for example: Revolut is a bank that does all its event persistence and streaming on top of postgres. No traditional message queues/brokers in their stack.

https://medium.com/revolut/recording-more-events-but-where-w...

My general rule of thumb is "Use Postgres until you've discovered why you can't use Postgres."

Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.

This kind of post (Postgres! It's all you need!) is getting pretty tiresome. Postgres does not even come close to a full replacement for Elastic, and that's just the first bullet.

Looking down the list it is pretty easy to go: Yes, postgres can be used instead of that for extremely basic use cases, but it all goes out the window you actually need any of the power of these other tools.

For full text search you could also use pg_search (Tantivy) which looks very cool.

But at scale you probably don't want to manage a bunch of mission critical systems that were jacked into your database server. The database is slow? How do we monitor that?

So I would definitely begin like this, but you need to have a plan to break all of these out sooner or later.

I use SQLite for everything, and I'm perfectly happy with it. I'm aware of the concurrent writer issues, but at my scale it doesn't even matter.

This article seems like a reaction to DuckDB's surge in popularity. Having multiple DB engines to choose from is good and it often doesn't matter which one you use. One could make the same argument about DuckDB. Many database engines are multi-purpose. Though of course there are specific use cases where a different DB may be more appropriate...

Anyway databases nowadays are a commodity. A sticky commodity but nonetheless they are replaceable; increasingly so in the age of AI where data migrations are easier than ever.

PostGIS is also another very useful addition for storing, indexing, and querying geospatial data.

http://www.postgis.net

Tetris on postgres? Not doom? So not a candidate for everything!

Just kidding. Of course there's doom for postgres: https://github.com/cedardb/DOOMQL (pure SQL) and https://github.com/DreamNik/pg_doom (extension).

Oh and there's https://github.com/snaplet/postgres-wasm that allows to run everything else in postgres ^^

I tend to agree with quite a few points in the article, but some topics warrant some careful scrutiny.

* As a message queue: Only if your required features are very basic, like if you need cluster communication and run your own coordination protocol on top.

* High Volume Time Series: TimeScale works, but composes badly with other workloads on the same DB server ( from an operational perspective at scale )

* Vector Database: The same issues as with TimeScale.. PgVector for example lives in its own seperate "world" and the query planner sees it as a very opaque thing. Forget about adding vector storage to an existing high volume db, that must server other complex queries.. PGVector will either trash your caches, or take over your cpu so that workloads that used to work fine stall. This is IMO not a pgvector problem itself ( Kudos to those guys ) but rather that postgresql extension apis are not very good at exposing custom costs and tradeoffs to the system as a whole.

* Raw Data: Works for small files... why anyone would want to store large amounts of data in it would be a mystery, where it shines is accessing LOTS of small files where internal caching etc help a lot compared to raw filesystem access ( also a bit dependent on the filesystem and its tuning though )

* Microservice: If your service is ONLY exposing json data from some database model, then it should not exist at all IMO. Create a view and be done with it.

Anecdotally:

The main caveat as someone who works on mostly average web CRUD apps, is that "Use PG/SQLite for everything" usually falls flat when the tools I use day to day don't support that use case super well or have rougher edges.

If your framework/ORM/whatever of choice doesn't support the full feature set of that driver compared to Redis/ES/Whatever you're replacing, you'll find yourself going down rabbit holes doing workarounds instead of staying with the "happy path" and just using separate tech for what it's specialised in.

If you already are doing most of these sorts of features by yourself instead of with frameworks, maybe it's fine, but this does start to feel like a time-to-release hindrance if you don't want to fiddle with the minutia.

Intrigued by this

> After some performance checks it became clear that PostgreSQL was even faster than reading from the file system for our use-case. PostgreSQL uses the file system very efficiently for its data - and it adds a lot of caching and efficient reading and writing strategies that can outperform writing and reading raw data on a file system.

This goes against conventional knowledge. I've always heard (and followed best practice) to avoid storing binary data in BYTEA columns that should otherwise be put on a filesystem or an object storage like S3.

I'd like to find out more about this, because in many cases it would be very convenient indeed to store it in the database itself.

Bona Fides: I learned c on with the K&R book on an Amiga (and transitioned to enterprise software engineering from there).

This seems like one more "When all you have is a hammer, everything looks like a nail" take. I agree with the other commenters who advocate for best-of-breed (e.g. Kafka, etc. for a message queue). PS I freakin love PostgreSQL as a relational (or even a time-series or OLAP) DB.

These types of articles needed to be written because we have gone way too much in the other direction. The issue is that people use too many tools prematurely when they are not needed at their stage. So yea, in most cases, you are probably better off just with Postgres. I m a culprit of this myself so I wouldn't say that I know better. It is just too tempting to setup too many tools to feel cooler or feeling that "we must use elasticsearch as no one does search in db".

> PostgreSQL Replacing Your Microservice

I've done that before and the code was a mess. It works at the beginning but APIs do much more than piping data from the database. When you start dealing with ACL, external calls, code reuse, etc. It's just nice to have all the tools available to you from something like Python or Go.

No mention of https://postgis.net/ - shameful

> PostgreSQL allowed us to use a fulltext search plugin to do everything in one system. No need to sync any data. No need to maintain and run two systems. It just worked and made us smile (after some tweaks of course). Simplicity.

I found MariaDB to be wonderfully simple to use for somewhat casual use cases: https://mariadb.com/docs/server/ha-and-performance/optimizat... and still reach for it in some personal projects, however the whole growing MySQL incompatibility is a big issue if the tech you use only officially supports MySQL and you can't (easily) get MariaDB specific DB drivers.

Personally, one of the best things about PostgreSQL is transactional DDL, every DB should support it. Also they handle JSON pretty nicely (though I'd prefer not to store data like that unless necessary) alongside excellent plugins like pgvector and PostGIS.

On the other hand, for things like queues, or even any sort of blob storage, I'd look at things like RabbitMQ or Garage (S3 compatible). Sometimes specialized software is nice for keeping things logically separated. I maintain that it's good to be able to divide your stack up by mechanisms/concerns (rather than business domain necessarily).

as someone who loves postgres, this take is getting pretty old. yes we can do quite a bit with extensions but extensions often need to interface with external systems and even then managed providers don't consistently support all extensions. some gaps: bm25 indexes, olap support, also extensions also run into licensing restrictions.

I use Postgres for a lot of things where textbooks say not to, but not caching. I'm not going to do it with triggers. Maybe if it supported TTL properly, even then, probably don't want to think about whether caching will bog down the rest of the DB.

At Comper we have a very hot key-value store for annotating git data. We maintain a parallel git-blame data structure so we can do incremental "git blame -w -M -C -C". Typically a very expensive operation, but if you make it incremental, you can make it very cheap when new commits need to be analyzed. However, building the git blame tree is still pretty intensive for large repos.

We currently use rocksdb with storage on the same node, and hit rocksdb 1000s of times per second during our analysis. About 20% writes, 80% reads. The issue is that we need to start scaling horizontally, for burstable workers and zero-downtime deployment. So we're thinking to offload to an external kv service instead of a local rocksdb.

TiKV seems a good replacement, about 3-4x slower, but very scalable. Reading this article, I think a separate postgres cluster with unlogged tables might be a good idea. If anyone has some experience to share, let me know!

My go-to has been replicas for each use case, with well defined semantics for replication lags. I'm working on something that does most of this seamlessly (transactional,search, columnar & time series, vectors and queues) without having to bother about extension management, replication setup or tuning.

Hopefully there is some value in this - one click multipurpose postgres fleet.

I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it.

MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues.

That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned.

Use case matters.

I use a SQL databases as needed. I've used Postgres, Sqlite, Duckdb, Json files with AWS Athena, Oracle enterprise for ERP systems (a multitude of schemas and objects with interoperability), and others.

I'm currently, deploying Duckdb with AWS S3 Tables (Iceberg) to see how it fits for a use case I have.

IT is great and always changing. Keep trying new things.

Cheers

It's more "what one tool can do everything", not that its ideal. Like why people use Microsoft Teams even though its terrible.

The relational model and sql force us to simplify our data models too much by eliminating relationships or just not dealing with them.

Think about a nested json blob from some web service api and storing it in SQL in normalized tables. No one is going to do that. Everything just becomes a denormalized mess and everything is hacked around it.

Instead of modeling things in the proper way, most of the world's data is modeled in a way so that we don't have join explosions in sql queries because they look scary. Data pipelines become these scary batch transformations where data is dumped somewhere else without anyway to trace back where it came from.

I encounter so many end-user applications and systems where you wonder: "why couldn't they allow a list of items here instead of a single box" or "why can't this reference this other thing".

> Timescale lately released the pgvector extension, that turns your PostgreSQL into a vector database.

I don't think this is accurate and smells like an LLM hallucination to me.

From the Timescale/Tiger Data _pgvectorscale_ project's README:

> pgvectorscale builds on pgvector with higher performance embedding search and cost-efficient storage for AI applications.

I think this is where the confusion originates. I believe pgvector is primarily Andrew Kane (@ankane) and a cadre of OSS contributors.

As an aside, I've used Timescale/Tiger Data products and was very happy with them and their support. Their team was very engaged and responsive to all of our questions. They also fixed a pretty gnarly indexing bug I uncovered in pgvectorscale in an impressively short amount of time.

if you are searching for something similar but with more meat: https://ebellani.github.io/blog/2026/all-you-need-is-postgre...

Postgres is great, but I certainly don't think it's great for everything. For instance, while you can in theory implement OLAP aggregation you're going to be hand-rolling a bunch of stuff that something like Clickhouse gives you for free declaratively.

This is exactly how tightly coupled, unmaintainable software is constructed.

By picking the tools before understanding the model and building bespoke architecture.

You pick the tools that the business model requires. It might be a relational data store. It might not be. You might want an event store. You might want to reduce costs with lambdas and DynamoDB. You may need a pub/sub event broker.

The OP clearly loves Postgres. Cool. They also have limited experience with complex systems architectures because if they had that experience, they would have never written this article.

Why write a fanboy text with unfair comparisons that hide the Postgres limitations?

For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.

* No need for a connection pool, while many use cases with Postgres require PgBouncer and Co.

* Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations.

* No need to VACUUM, which can be a hard problem (it was, the last time I used Postgres).

For full text search, I once worked on a project that considered several alternatives for this, including Postgres. Manticore Search was finally chosen because it was more performant, with better search results.

> Contrary to popular belief - the answer to everything is NOT 42

42 is not the answer to everything.

42 is the Answer to the Ultimate Question about Life, the Universe, and Everything.

Funny. I was just this joking this morning with a colleague about using Postgres for everything.

Considering adding mongo for unstructured data? Just use postgres jsonb.

Building a search index? Postgres is fine too.

Considering using redis for fragment caching? Just use an unlogged table in postgres with key value columns. Need pub/sub? Well just use postgres listen/notify.

Using postgres for everything has served me very well.

Ive built data warehouses and job queues on postgres. The DW got replaced with bigquery when we started doing more tracking. We still run postgres as an app-facing cache of the aggregated data from bigquery though.

The job queue runs on the cache db, scheduling jobs to move data from bigquery into postgres. It’s pretty neat.

Now we’ve run into near-real-time requirements so clickhouse is getting thrown into the mix.

It’s pretty funny the lengths we go to to implement user facing analytics that’s basically just “you are visitor number X” from 1995.

As usual, it depends on the scale, but it's a sane default for 99% of use cases.

Different use cases have different scalability limits in PG, when you get to them you need to deal with them.

It would be perfect if it had somewhat transparent sharding, I mean a way to add another instance and distribute load without having to stop everything.

There are solutions, but they tend to be involved and when you get to that point in many cases it makes sense to just move that workload to something else that scales better.

I like Postgres. It is a good general purpose database. I like other databases too. Other databases can do some things that Postgres can't do as well.

For "replacing your microservice" you should checkout PostgREST. It basically turns PostgreSQL into a microservice.

- mind coming and enligtening about PostgreSQL and XML?

- https://www.reddit.com/r/PostgreSQL/comments/1vbo5j8/raw_xml...

- your post did not have a single word on XML hence my comment

One addition: Postgres for all your GPU-based machine learning training and inference needs: https://github.com/postgresml/postgresml

Nice one re: flatbuffers in `blob` column. Have been working with flatbuffers a lot and that's a neat idea in general.

Not 100% sure about using PG for file system at scale however. I'd love to hear more on the challenges (vacuum, toast, anything else?)

sqlite for everything

NVMe drives + Litestream + object storage(S3/R2..). sqlite simplifies things for the entire long tail of apps/services that aren't the Ubers and AirBNBs of the world.

Surprised it doesn't mention LISTEN / NOTIFY.

Hey Raphael Bauer, if you're reading this, I suggest you change the color of hrefs on your website, all of them are purple and underlined, which usually is indicator for "Already visited URL". For me that's not that much of a problem, but it was something i kept noticing when reading the article. I wonder if anyone else also had this thought or am I alone as I didn't see anyone else mention this in the comments. But I wanted to signal that nevertheless :)

yes. my people.

https://github.com/seanwevans/pg_gpt2

https://github.com/seanwevans/pg_shell

https://github.com/seanwevans/pg_os

Honorable mention - https://postgrest.org/

to risk sounding like a madman - if you're a solo individual- serving b2b small businesses.

then Sqlite works as well too. can run the whole thing on Cloudflare.

running Postgres isn't difficult. but dealing with a VPS for low traffic is a headache that's not necessary.

SQLite has so many advantages over PostgreSQL.

No deamon. Single file per DB. Less configuration overhead.

Can Partitioning be used to move data to S3 Storage, for long term archiving?

"MySQL was also potentially faster as it did not implement all features of the SQL standard. "

This is a not great start. I assume it refers to MyISAM which has not been relevant for over a decade at this point. InnoDB made different design than PG decisions and was (and perhaps still is) faster at point lookups.

How many production system has serious queues using PostgreSQL?

true to that - currently using psql (in a single monolithic codebase) as: sql db, json db, vector store, logs store, full-text search, queue, message bus.

multiple processes connected to it.

there is also https://postgresforeverything.com/

The older I get the more I agree with this

I'm waiting for the followup contrarian shitpost: "Firebird for Everything".

How do you implement HA in postgres, i found MySQL HA stack pretty straight forward with Innodb cluster, MySQL router and Shell.

Years ago I used PostgreSQL under Django to drive an industrial test and inspection robotic cell (which I also designed and built) at a major technology company. It worked very well. PostgreSQL maintained machine state, path planning, sensor readings, faults, operator input, etc.

I wanted to see how far I could push that toolset. It worked surprisingly well. Django's capabilities meant such things as multi-user login pages, access controls and remote monitoring were very easy.

isn't the process per connection restriction pretty heavyweight though?

Hardware is so far nowadays to make people with little systems knowledge confident to make such claims at least from their use cases. However it is neither generally reasonable nor efficient.

In my experience, it still kinda sucks if you want to store blobs. Anything on this front?

Except horizontal scaling.

But a lot of companies are trying to solve that, notably multigres, neki and even pgdog.

the more ive coded the more this is true

For the graph database idea in Postgres, PG 19 has native support for property graphs [0]. You can set up your tables and their relationships as nodes/edges, then query against them using Cypher-esque [1] syntax.

0: https://www.postgresql.org/docs/19/ddl-property-graphs.html

1: https://www.postgresql.org/docs/19/queries-graph.html

I really want a daemonless PostgreSQL, in the style of SQLite.

> My tip: Start with PostgreSQL as a queueing system. Only when that does no longer perform well switch to other systems like Kafka, RabbitMQ or SQS.

My tip: store your company's source code on a samba file server. Only when that no longer performs well, switch to other systems like Git.

i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on arbitrary analytics queries - like 60s to 0.5s for some gnarly queries. truly amazing software that just works without any tuning for this kind of exploratory analytics workload.

so yes, i'm still a postgres maximalist (worker queues still in pg [1]) but (especially in the age of quick LLM prototypes) it's always worth measuring the more purpose-built approach.

[0]: https://setoku.com

[1]: https://worker.graphile.org