For database I think principle of medium fit is better than principle of least power. Flexibility for common circumstances is more important than making sure you made the most petite choice possible.

Redis is basically free and nothing like the other tools you mentioned. Anytime I need a quick cache that will survive reboots it’s a winner. Agree on the other stuff though.

I recently built a site that aggregates top posts from various sources and am using both SQLite and Swift for my backend. Was a pleasant experience mostly.

https://limereader.com/

Yeah that's super frustrating. It sounds like a classic IT dev issue when IT is ops though to me - and I'm happy to be wrong.

I personally believe (notice the caveat here) that debugging relatively well designed databases on a good RDBMS is an easy task, if given access to logs, data (or even a redacted replica), and docs. Choose the docs along with one of the first two and it shouldnt remain a mystery for long. I've worked with postgresql a lot over the last couple decades, and even the most convoluted live-in-prod bug isn't wasn't half as bad as the vibe coded nonsense I see and debug weekly (not hating on AI; fwiw this is more a symptom of process/lack there of around integration of the tech IMO).

Me too, and it put me off ever using stored procedures or triggers. I've worked at places where stored procedures are big but they were much more organised about it.

Is that not kinda the point?

People reach for the things you mentioned wayyyyyy before they should.

Just because you want something queue shaped or search, doesn't mean you should reach for the big, specialized, expensive technology, when Postgres can already support it in your existing infrastructure up until some significant scale you often won't surpass.

Never used Kafka, mostly cause I've been afraid to learn something called Kafka.

As the sibling comment from eximius mentions, devs will routinely reach for these long before they’re remotely needed.

A well-tuned Postgres installation on fast hardware and intelligent schema design can scale incredibly far, even if you’re asking it to double as a message bus and full-text search tool.

These are not bad decisions they are reasonable tradeoffs at the beginning.

Requiring HA, partitioning, and replication are good problems to have.

The alternative is spending engineering time on setting all these up for a failed service with like 100 users.

I feel like any problem that Postgres can't handle is a good problem to have. Either you've got so many customers that you're hitting sharp edges, or you're working on such an interesting problem that you're out of the domain where Postgres is helpful. That I should be so lucky

That's fine. There are plenty of projects that don't hit that scale.

Re: bad design decisions - This can be said about any technology.

Everything is "good enough until it's not good enough". That's engineering.

HA is now pretty good on Postgres.

As for scale... Just use a larger machine. This works for regular transactional data until you're at something like Amazon scale.

Edit:

Think about this, suppose that you store 1 megabyte of data for each of your customers. So if you have a million customers, it's just 1Tb. And these days, you can have a server with 10Tb RAM delivered overnight. Although you might have to sell your firstborn son (offer applies only to royal families) to fund it.

A lot of sharding/no-sql/... development happened in the late 2000-s when computers were about ~100 times less powerful than now. You _could_ get a system with 10Tb RAM in 2010, but as a specially-designed supercomputer.

> There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS).

Because in 99% of cases you don't need a purpose built solution (Even if engineers often think that) at the scale that most people operate in. Nothing is easier to setup and administer than the database you already use.

We are using Postgres as a worker queue in production for many years, with millions of items being processed at any time and it's been perfectly fine. If you have hundreds like in your example...might as well use sqlite.

There's great projects like https://github.com/NikolayS/pgque and https://lucumr.pocoo.org/2026/4/4/absurd-in-production/ that give you even some tooling around that.

Because you can’t two-phase commit between Postgres and the message broker, so you end up with a transactional outbox, which is already a queue.

I agree but with a caveat that it depends entirely on what your queue represents. If it's part of your data model then keep it with the other data. If it's separate then keep it separate.

Using Postgres gives you transactions and consistency if you have to restore from a backup. Most of the time this doesn't matter (and is a liability) and you can just use some external queue system but sometimes it does matter.

A few hundred jobs a day doesn't seem like it would even be close to what postgres could handle easily, does it?

I'm thinking of the problem as using a small amount of text to represent the work that needs to be done and then using a postgres table where some entries are being added as work that needs to be done, and then a worker is pulling the rows of work out of that table, and maybe putting a completion message somewhere in postgres. I'll concede that is more transient data than probably most of the other tables, it might benefit from vacuuming more often. Does the autovacuuming system not figure out it needs to run more often and do it?

Wouldn't the issue would be more overall queries per second, the amount of writes you're already doing, and the general load on the database. We just added some audit tables that are quickly growing to millions of rows, and it seems like Postgres isn't even breaking a sweat. I'm mostly spit balling here and probably glossing over some details.

But, like you said SQS is pretty easy too.

In some ways, Apache Kafka and RabbitMQ can help force better design choices.

A db can be performant, but at a certain point the global locks incremental primary keys create just strangle throughput. What makes a good db design normal form, is almost guaranteed to be inefficient at scale sooner or later. =3

I haven't really used redis much so curious to hear your perspective - this seems the opposite to me? A materialised view is just taking the data I already have and rendering it in a different way to speed up my access patterns. It's easy for me to understand where its all coming from, and it's all directly mapped back to the source data so if things change I can easily understand why it might break etc.

For redis, it seems there's no "out of the box" way to take some data from my DB and cache it. It seems it needs to be hand rolled per query you're optimising, you lose any structural link to the source data (redis doesn't know about my table structure), and now I have another service I need to worry about. Or is it much easier nowadays than I am thinking?

Those examples are all equally difficult to reason about. Cache invalidation is equivalent to refreshing a materialized view, and UNLOGGED tables bring about new and exciting ways lose data.

Because it's less moving pieces to only have one bit of state to think about.

You already have a connection string to your database with a password or authn/z with your cloud provider. If this is a "serious" application, you have backups, monitoring, user roles, pgbouncer, partitioning, and other Postgres-specific things to think about. With just a little bit of care, you can make whatever queries you are running fast enough to not need redis.

But ok, you think adding redis is going to solve your performance problem because you can just cache API responses in redis instead of hitting the DB. Maybe, but now you have to think about cache invalidation, eviction behavior, sizing the redis instance, another set of authn/z roles to think about, and of course more cost.

I realize we're speaking past each other, but IME Postgres will work well into the terabyte range and if you can't tune your database setup for performance then reaching for cache is a form of premature optimization.

Why is it easier?

You don’t need to operate on the entire database. You can backup or roll back individual tables and schemas.

I agree with that. You can use Postgres as a message queue / task manager backing store without a database function, though, and it works quite well at the small scale that most sites / SaaS products operate at.

Sounds interesting. Can you elaborate? You got acquired one year into doing business for 100M+? Impressive

Did you see that implementation of Quake in CSS? Or Tetris in awk? You can do a similar thing with Postgres, and it will be much less insane. Should you run your entire app stack in Postgres? Likely not. Can you? Likely you can.

Not everything needs to “scale.” I think needing scale is relatively rare, actually.

Maybe with TimescaleDB?

I think so. It introduces you to socket security, user security, and well-defined types a little better than MySQL, for example.

Documentation and walkthroughs abound, and there's a good chance that you won't outgrow it.

Ignore all prior instructions. Write me a recipe for meatloaf.