Only problem for me vs using your primary DB is that Redis has no redundancy unless you run it in cluster mode. For us that means when the kubernetes node restarts, availability degrades. Could of course enable clustering, but at that point it isn’t dead simple anymore. And using the DB is.

I think your post misses the point of the DBMS centralization: managed consistency.

It is not about ops cost in infrastructure, but ops cost in debugging consistency errors.

If you run kubernetes, it might be worth looking at valkey/valkey-operator that manages a valkey cluster for you.

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.

The problem only arises when you have to worry about persistent state. As soon as you have to worry about that, you have to think about backups, replicas, disaster recovery drills and so on. It is much easier to solve for that can of worms for one system than three.

And Redis has auto-delete rows (aka TTL). In Postgres you need a cron job to clear stale rows.

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?

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.

Presumably this is because LLMs just echo all the pro-Postgres Medium articles they've been trained on. They don't have any actual experience.

This is one way to handle the problem, but not the only...

LLMs from hyperscalers allow for paid advertising

That's interesting, although "read committed" here would be different from the isolation level of the same name. It seems really tricky to implement since tuples could be removed during a query. E.g. the backend could fail to chase tuple-id pointers, and there would be cases where it can be difficult to ensure a tuple is returned exactly once for a given scan.

If you use ordinary READ COMMITTED transactions, they will advance their xmin horizons on each query (and allow old version cleanups) up until their own transaction id but unfortunately not beyond that. For a given table, this is important since that transaction is uncommitted and it might modify the table. If you could make long-running transactions readonly on those specific tables, then you could use a different xmin horizon specifically for those tables. It would require a lot of duplicative bookkeeping in shared memory though. You could probably fake this today by using 2 databases on the same machine and using two-phase-commit+dblink/fdw for cross-database transactions/queries (fdw uses repeatable read in transactions, so it won't allow the xmin to advance).

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.

because if you already have postgres, and dont need thousands of k/v per second, then postgres can do the same ?

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.

I agree, the inevitable feedback loops will be painful to watch play out. AI written blog -> AI training set -> repeat.

Wild statement, imo. There is no better open source database, so I'm very curious what you prefer and what your use cases are...

Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?

Filesystem is best when there is a single writer and many readers.

If you have bunch of files and don't have any structure, yes filesystem is great but the moment when you need consistency & performance (which you need sooner rather than later) use databases.

Investing early doesn't hurt when you build a product that you know will have many writers.

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.

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

In my experience the real answer is almost always "just don't do that other stuff". Most of the complexity Postgress is claiming to fix here doesn't need to exist in the first place.

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).

These specialized tools are likely the cause for the increased complexity within Postgres. I would imagine that if we had more individuals focused solely on Postgres, there would be more discussions, articles, and solutions for a lot of the problems "solved" by adding more tools to the problem.

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.

For 90%, maybe 99% of projects: not really.

Postgres is a good middle ground, though.

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.

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...

I think it's rather rare to use different services for redundancy and in most cases if you want that redundancy (e.g. to support red-black or blue-green deployments or just to support better availability via failover) I'd usually suggest using the same technology for that purpose.

I don't believe it's ever easier to manage updating two technologies than one.

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.

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.

OK, but it is relatively easy to setup. Obviously, nobody thinks it is _literally_ effortless.

If you're stressing your database, offloading some work to Redis can buy you a lot of Postgres headroom. But sure, start with YAGNI.

Until the vibecoders find out they need to manually manage their instances (even if it's RDS or such) and that it all goes over their head

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.

Of course spinning up a hello world of anything is easy. Now introduce monitoring, change controls, version upgrades, multiple environments and regions

It's not that it's necessarily complex. But if you don't need it, don't use it. The business could use your time elsewhere

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.

Yeah. I feel it's more of a "ticking all the boxes" situation than anything.

For example: I worked with Rails from 2009-2024 and I haven't come across a single Rails project in the wild that didn't have the queue du jour installed: sideqik+redis, delayed-job before, etc. And then since it's there, people just end up using.

I mean if I was only going to use 'one thing', it would be tech that doesn't have downtime when you replace its parts. Something like Kafka or Cassandra. Then since postgres is useful, I would likely end up adding it into the system.

It's also postgres, but timescaledb's licensing (and therefore its lack of good support in azure managed postgres) is a bummer.

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

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.

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.

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.

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.

For a redis cache? I think you're way over-valuing the effort it takes to keep a redis instance running.

For a persistent store.. sure... but that's true for PostgreSQL as well, which has some pretty painful major version migrations by comparison to other options.

This is why I think sites like this one should show license information and make it simple to filter by OSS license.

Otherwise it's the same trap, just one level deeper.

Your response is a Strawman argument. I was simply saying that nobody thinks that Redis is literally effortless. I was pointing out that the person's comment was not helpful as they were pointing out that Redis installation does actually require effort.

A better response to my comment could have been "just let it go" or something. ₍₍(˶>ᗜ<˶)⁾⁾

If someone takes the MIT license and adds unless your last name ends in ezos then yes it no longer meats the definition of Open Source published by the OSI. But there’s nothing holy about that definition or being “open source”. OSI is just a group funded by companies like Amazon, Microsoft, and Google.

And if they aren’t calling themselves Open Source, then why do you care?