I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of "use Postgres for everything" articles and they imply a difficulty in running other software that I just don't see.
I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange gives me a k/v store that I can thrash without worrying about performance (I know it's fast), downstream impact (am I slowing down critical-path SQL queries), etc. Especially in the age of LLMs, which I've found to be great at devops-type tasks, I feel slightly less compelled to simplify my stack.
dinkleberg 32 minutes ago [-]
Yeah I've found this quite odd. Even the LLMs want to pressure you to not use Redis and go all in on Postgres. Postgres is great, and I usually use it. But Redis is so trivial to add to your stack and it does what it does really well. Why not use the right tool for the job?
Faaak 16 minutes ago [-]
because if you already have postgres, and dont need thousands of k/v per second, then postgres can do the same ?
stickfigure 6 minutes ago [-]
If you're stressing your database, offloading some work to Redis can buy you a lot of Postgres headroom. But sure, start with YAGNI.
deepsun 8 minutes ago [-]
And Redis has auto-delete rows (aka TTL). In Postgres you need a cron job to clear stale rows.
Xeoncross 39 minutes ago [-]
Redis really is a great piece of software. Low memory, high-performance, feature-rich, and stable. Really hard to beat it for places where you want a durable cache even if technically you can use something else.
stavros 36 minutes ago [-]
Oh no, redis is super simple to set up and use. It's just that setting it up is not as simple as not setting it up.
tracker1 25 minutes ago [-]
For smaller projects and locally, I'm running background services via a compose file... it's a few lines of configuration, and just works. Redis is crazy low hanging fruit.. even job queues that run over Redis make a bit more sense than with Postgres more often than not.
I'm far more hesitant to throw a more formal MQ in the mix though... mostly from experience in that a lot of mid level ("senior") developers don't really understand queues very well at all. Even if conceptually, using tables for queues is more complex.
That said, I will use PG for workflows similar to K/V, Document (JSONB) and other structures over reaching for say MongoDB, etc.
wuliwong 31 minutes ago [-]
OK, but it is relatively easy to setup. Obviously, nobody thinks it is _literally_ effortless.
munk-a 28 minutes ago [-]
Every extra straw you put on the back of your ops team, especially when you're a young company, adds weight. It's good to be choosey about which technologies actually justify that expenditure.
ComputerGuru 41 minutes ago [-]
I am very much in camp “minimize your dependencies and take the utmost advantage of what you already have” but I also am in camp “your database is the most important bottleneck component.”
This has two implications:
1) make sure if you use Postgres for anything beyond core rdbms functionality that there is no dependency between the two, so you can rip out the additional functionality and move to a different platform when you end up needing to reduce the load on your db server
2) if using Postgres for non-essentials complicates your db backup workflow, risks the data integrity, makes it difficult to maintain or upgrade your Postgres instance (eg you have to wait months or years for compatibility with newer Postgres versions), or loads relatively shoddy or unstable code into the beating heart of your application, then you should either use a different Postgres server/install/container for these ancillary services or bite the bullet and introduce an alternative dependency, depending on which makes more sense.
JsonDemWitOster 30 minutes ago [-]
I'll do you one better: do you really need Postgres and all these extensions when you already have a filesystem?
> only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative
I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for the problem from the start, when the stakes are still pretty low. Why wait until, ahem, Postgres is pushed to the limit before you spin up a Redis cluster?
You don't get free opcost by using Postgres for everything. Arguably if you end up with a monolith of a database, you are paying a higher opcost (imagine if too much caching can affect all CRUD ops in your platform). Or you can manage a cluster of PG instances but that's no less complex---each plugin still comes with its own opcost!
No Silver Bullet, No Free Lunch, and all that. If your problem domain really warrants something outside of relational storage, you're gonna pay that complexity cost one way or another. You can't escape it by shoehorning everything in Postgres, fantastic as a DB as it is.
pooloo 4 minutes ago [-]
I don't understand why the answer is to always bloat the system with more specialized software and technical debt, instead of optimizing the existing system. If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on.
I guess its more the rapid start-up mindset to get it up and running fast to sell the company, and leave the problem for someone else which is why a lot of our world is falling apart...
PaulHoule 17 minutes ago [-]
Filesystems aren't efficient for small bits of data.
Like right now I am thinking about a system that has a password reset process and you need to keep track of a user id and a reset token, one or two timestamps, maybe a state variable and a flag or two. That's well under 100 bytes and the cluster size for a typical fs is 4kb or more plus there is the cost of the directory entry. If the OS is Windows it has to ask the Security Manager when ever you open it or delete it which is even more heavyweight.
Do filesystems offer ACID guarantees though? Depending on the use case, something like sqlite might work better (or write to a CAS system like S3).
wuliwong 15 minutes ago [-]
For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc.
I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice money saver. Again, not massive but it's cheaper.
The downsides of doing this in the prototype/MVP context are minimal. At the scale of prototype and MVPs, I certainly don't see any difference in performance.
I did note in the graphic it listed Kafka but in the lower table graphic I did not see any Postgres replacement for Kafka. If I am at the scale where I really want Kafka, it is probably for performance and I just can't believe there's anyway Postgres could provide that.
So, I love the flexibility and all-in-one abilities of Postgres for prototyping and making MVPs. But at my job, nobody is proposing exclusively using Postgres for persistence.
CodesInChaos 46 minutes ago [-]
I'd love the ability to mark a table as "read committed" to prevent long running transactions from keeping old versions of a tuple alive, or even "read uncommitted" to enable in-place updates. Or perhaps instead of downgrading isolation, those serializable/snapshot transactions could simply fail when reading a value from such a table that was modified after they started.
An example of a table that would benefit from this would be rate-limits / concurrency-limits, which are commonly implemented using Redis instead of Postgres.
xnorswap 40 minutes ago [-]
Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?
CodesInChaos 4 minutes ago [-]
The limiter itself should be able to ensure consistency via pessimistic row level locking, even at lower isolation levels.
What I don't want is long running unrelated transactions keeping old tuples alive just it case they're needed. My third suggestion where transactions attempting to read old versions fail is probably better than the first two where isolation gets silently downgraded, since it avoid that problem.
ubercore 36 minutes ago [-]
I love postgres, but the complexity of using it for everything starts to get pretty high, compared to more tailor-suited tools. We should probably use it for _more_, in general, but the cost of "everything in postgres" is generally higher than I see acknowledged in articles like these.
mrkeen 23 minutes ago [-]
The reason for separate systems is that some of them go down. And by "go down", that includes you wanting to deploy a new version. Or restore from backup as the article suggested.
devin 56 minutes ago [-]
> This isn't about dogma. Sometimes you genuinely need specialized infrastructure. But the bar should be high: only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative.
I've seen a few "Use Postgres for Everything!" posts lately. It seems to be fashionable. It reminds me of the Choose Boring Technology[1] thing from 2018 or so, but more specific to a database.
I think the ideas of "don't add unnecessary dependencies" and "ruthlessly evaluate tradeoffs" and "prefer simplicity" and so on are general and have very little to with postgres, so when I see things like "All you need is X" I roll my eyes a little, because these decisions are highly dependent on your use case, and taken as blanket advice it is generally _bad_ advice even if the underlying rationale is sound.
ETA: I am going through their list and so much of this means that you are going to manage your own PG cluster and not take advantage of Aurora or RDS, which means you're already committing to a major tradeoff if you want to use a lot of these custom extensions.
pavel_lishin 1 hours ago [-]
Are the various plugins easier to set up, configure, troubleshoot, etc. than the other software options? If I'm paged awake at 2am, will I have an easier time figuring out pgmq than I will RabbitMQ?
nhumrich 33 minutes ago [-]
For these specifically? Way easier than rabbitMQ. I love rabbitmq. It's an amazing technology, and if you need a high throughout message bus, it's still a better goto. But.. it does require quite a lot of expertise and know how to operate. Paged at 2am, you will likely get very frustrated.
Pgmq though, is "just a bunch of tables". It's going to be a lot easier to figure out what's going on. You already understand transactional DBs.
Unless of course, you already know how to operate rabbitmq.
bitbasher 24 minutes ago [-]
I was on the Postgres train for 10+ years. Then I fell in love with Sqlite and have been using it for everything.
h1fra 1 hours ago [-]
I have yet to have used UNLOGGED table in production, but I really want to try at some point. Anybody actually replaced a large Redis instance with this?
valentynkit 34 minutes ago [-]
The thing that usually pushes you off Postgres is rarely raw throughput, it's two workloads that want opposite tuning on the same box.
Kinrany 30 minutes ago [-]
The solution might be to move to separate Postgres boxes everything that needs performance tuning at all.
I'm not in the "use Postgres for everything" camp, but only because I think it's too complex to be used like that. It should be replaced with a bunch of simple primitives in this role. No SQL and query planning magic please.
mamcx 18 minutes ago [-]
YES!
The problem of all the datastores is that are applications (like Wordpress) so you are too late to fix anything deep.
We need "frameworks" (so each sub-component can be used as-is or even swapped) and even wondering what a "system level" data engine could be.
simonbarker87 1 hours ago [-]
Couple that with a framework with decent server side rendered template support and htmx for network based interactions and you’ve got 90% of the <acronym_of_the_moment> stack with 10% of the complexity.
DonsDiscountGas 25 minutes ago [-]
I suspect a lot of this is resume driven design.
polycancel 1 hours ago [-]
> Document store -> FerretDB
Love FerretDB, but it doesn't really replace MongoDB's GridFS which is main reason why most people who are really using Mongo now day. Anyone knows a good replacement for GridFS?
matharmin 47 minutes ago [-]
Why would anyone use GridFS for any serious use case? It costs 10-20x as much as storing the files on S3. If unless you already have all your data in MongoDB and don't want an additional dependency for a small number of files it makes sense, but it definitely is not a case for using MongoDB by itself.
bijowo1676 22 minutes ago [-]
lets take it one step further: Do you really need Postgres when you already have SQLite?
... and unlike all the new databases, Postgres has a decent license. Everybody else is so afraid of being co-opted by AWS that they won't let you run them the way the way you want.
sarchertech 52 minutes ago [-]
Is there something specific you wanted to do that was prohibited by a license. I thought most of the licenses you’re talking about just prohibited you from reselling the database as a service.
PaulHoule 38 minutes ago [-]
A client introduced me to Arangodb which I felt was a "secret weapon" that I used for a lot of side projects. Then this came out
and it is dead to me. I want my head! I can accept GPL, Apache, MIT or some legit open source license. For my projects I see two possible paths which I want to have open: (1) building a commercial service on top of a database (like my RSS reader) where you can't necessarily draw a clear line between what is allowed and what is not allowed, for instance I have an adaptation layer that makes postgres look like the part of arangodb that I actually use (I do manually rewrite AQL queries into a DSL that extends AlchemyAPI) and if I did something similar over arango is this reselling? (2) an open source project where I want to tell people "go forth and use this code" and not have to hire a lawyer to know what they can and can't do.
Once a vendor has shown they have this attitude, I expect them to change their license for the worse in the future -- I just don't want to invest my time and energy in their platform.
throwaway7356 30 minutes ago [-]
Yes, that condition makes it no longer open source software.
It also has the effect of making software adopting such licenses getting removed from open source distributions.
ubercore 33 minutes ago [-]
It's also postgres, but timescaledb's licensing (and therefore its lack of good support in azure managed postgres) is a bummer.
otabdeveloper4 43 minutes ago [-]
Postgres sucks. It does a little bit of everything, but badly and with much manual intervention.
nilamo 23 minutes ago [-]
Wild statement, imo. There is no better open source database, so I'm very curious what you prefer and what your use cases are...
PaulHoule 15 minutes ago [-]
It's boring but the last thing you want is excitement over data that's important to your business!
All the eng. managers I've worked with in the last decade have sworn by Postgres, in the decade before that they were swearing at mongo and getting betrayed by Arangodb switching to a restrictive license and seeing other innovative databases going down the same path means for new side projects I go postgres.
dimgl 40 minutes ago [-]
I've come to this conclusion too. It's a bit disappointing. I fully realize this is more than likely just user error. And now with AI agents the maintenance of a Postgres instance is likely less of a burden. But I can't help but yearn for the simplicity of a single SQLite file and bespoke solutions for things like queues, pub/sub, caching, etc.
Rendered at 16:53:24 GMT+0000 (Coordinated Universal Time) with Vercel.
I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange gives me a k/v store that I can thrash without worrying about performance (I know it's fast), downstream impact (am I slowing down critical-path SQL queries), etc. Especially in the age of LLMs, which I've found to be great at devops-type tasks, I feel slightly less compelled to simplify my stack.
I'm far more hesitant to throw a more formal MQ in the mix though... mostly from experience in that a lot of mid level ("senior") developers don't really understand queues very well at all. Even if conceptually, using tables for queues is more complex.
That said, I will use PG for workflows similar to K/V, Document (JSONB) and other structures over reaching for say MongoDB, etc.
This has two implications:
1) make sure if you use Postgres for anything beyond core rdbms functionality that there is no dependency between the two, so you can rip out the additional functionality and move to a different platform when you end up needing to reduce the load on your db server
2) if using Postgres for non-essentials complicates your db backup workflow, risks the data integrity, makes it difficult to maintain or upgrade your Postgres instance (eg you have to wait months or years for compatibility with newer Postgres versions), or loads relatively shoddy or unstable code into the beating heart of your application, then you should either use a different Postgres server/install/container for these ancillary services or bite the bullet and introduce an alternative dependency, depending on which makes more sense.
> only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative
I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for the problem from the start, when the stakes are still pretty low. Why wait until, ahem, Postgres is pushed to the limit before you spin up a Redis cluster?
You don't get free opcost by using Postgres for everything. Arguably if you end up with a monolith of a database, you are paying a higher opcost (imagine if too much caching can affect all CRUD ops in your platform). Or you can manage a cluster of PG instances but that's no less complex---each plugin still comes with its own opcost!
No Silver Bullet, No Free Lunch, and all that. If your problem domain really warrants something outside of relational storage, you're gonna pay that complexity cost one way or another. You can't escape it by shoehorning everything in Postgres, fantastic as a DB as it is.
I guess its more the rapid start-up mindset to get it up and running fast to sell the company, and leave the problem for someone else which is why a lot of our world is falling apart...
Like right now I am thinking about a system that has a password reset process and you need to keep track of a user id and a reset token, one or two timestamps, maybe a state variable and a flag or two. That's well under 100 bytes and the cluster size for a typical fs is 4kb or more plus there is the cost of the directory entry. If the OS is Windows it has to ask the Security Manager when ever you open it or delete it which is even more heavyweight.
It's common now for applications that handle lots of little "files" to store them as blobs in SQLlite! See https://sqlite.org/fasterthanfs.html
I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice money saver. Again, not massive but it's cheaper.
The downsides of doing this in the prototype/MVP context are minimal. At the scale of prototype and MVPs, I certainly don't see any difference in performance.
I did note in the graphic it listed Kafka but in the lower table graphic I did not see any Postgres replacement for Kafka. If I am at the scale where I really want Kafka, it is probably for performance and I just can't believe there's anyway Postgres could provide that.
So, I love the flexibility and all-in-one abilities of Postgres for prototyping and making MVPs. But at my job, nobody is proposing exclusively using Postgres for persistence.
An example of a table that would benefit from this would be rate-limits / concurrency-limits, which are commonly implemented using Redis instead of Postgres.
What I don't want is long running unrelated transactions keeping old tuples alive just it case they're needed. My third suggestion where transactions attempting to read old versions fail is probably better than the first two where isolation gets silently downgraded, since it avoid that problem.
I've seen a few "Use Postgres for Everything!" posts lately. It seems to be fashionable. It reminds me of the Choose Boring Technology[1] thing from 2018 or so, but more specific to a database.
I think the ideas of "don't add unnecessary dependencies" and "ruthlessly evaluate tradeoffs" and "prefer simplicity" and so on are general and have very little to with postgres, so when I see things like "All you need is X" I roll my eyes a little, because these decisions are highly dependent on your use case, and taken as blanket advice it is generally _bad_ advice even if the underlying rationale is sound.
[1]: https://mcfunley.com/choose-boring-technology
ETA: I am going through their list and so much of this means that you are going to manage your own PG cluster and not take advantage of Aurora or RDS, which means you're already committing to a major tradeoff if you want to use a lot of these custom extensions.
Unless of course, you already know how to operate rabbitmq.
I'm not in the "use Postgres for everything" camp, but only because I think it's too complex to be used like that. It should be replaced with a bunch of simple primitives in this role. No SQL and query planning magic please.
The problem of all the datastores is that are applications (like Wordpress) so you are too late to fix anything deep.
We need "frameworks" (so each sub-component can be used as-is or even swapped) and even wondering what a "system level" data engine could be.
Love FerretDB, but it doesn't really replace MongoDB's GridFS which is main reason why most people who are really using Mongo now day. Anyone knows a good replacement for GridFS?
https://github.com/seanwevans/pg_os
https://github.com/seanwevans/pg_git
https://github.com/seanwevans/pg_gpt2
etc...
https://youtu.be/9kaIXkImCAM
https://arango.ai/wp-content/uploads/2025/11/ADB-Community-L...
and it is dead to me. I want my head! I can accept GPL, Apache, MIT or some legit open source license. For my projects I see two possible paths which I want to have open: (1) building a commercial service on top of a database (like my RSS reader) where you can't necessarily draw a clear line between what is allowed and what is not allowed, for instance I have an adaptation layer that makes postgres look like the part of arangodb that I actually use (I do manually rewrite AQL queries into a DSL that extends AlchemyAPI) and if I did something similar over arango is this reselling? (2) an open source project where I want to tell people "go forth and use this code" and not have to hire a lawyer to know what they can and can't do.
Once a vendor has shown they have this attitude, I expect them to change their license for the worse in the future -- I just don't want to invest my time and energy in their platform.
It also has the effect of making software adopting such licenses getting removed from open source distributions.
All the eng. managers I've worked with in the last decade have sworn by Postgres, in the decade before that they were swearing at mongo and getting betrayed by Arangodb switching to a restrictive license and seeing other innovative databases going down the same path means for new side projects I go postgres.