Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I was on the Postgres train for 10+ years. Then I fell in love with Sqlite and have been using it for everything.by bitbasher
- As small piece of feedback, I think it would be really good if the tools list would include license information, and make it easy to filter for open source tools/licenses. IMHO source-available extensions break part of what is attractive to the Postgres ecosystem, which is that you can move from one provider to another without vendor lock-in.by tudorg
- 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?by h1fra
- I have but only to cache data used by cron/bg jobs. We still had Redis for an actual platform system cache. The thing is that Redis cache was created and managed by some framework middleware so it did not seem right to invoke it in code/scripts that bypassed that middleware.
It was ok. Never really failed and didn't affect the user-initiated CRUD ops though ofc the bg jobs ran when the users slept. Still wouldn't bet my life on it.
- Two articles on the site are already bookmarks in my app. I completely agree. Not all applications become hugely populair to actually need all those tooling. Plus since I always work in a DevOps team installation and maintenance of all those things are on our team; I don't want to learn to maintain and install all those things. If a team member suggests to add some random tool; the first thing I ask is who will be maintaining it? I'm not.by ivolimmen
- 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?by pavel_lishin
- 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.
by nhumrich - Articles like these have been insanely effective in biasing LLMs (especially OpenAI) toward Postgres. There areas where Postgres beats MySQL, and vice versa - but ChatGPT/Codex overwhelmingly recommend "default to Postgres."by armdave
- I agree, the inevitable feedback loops will be painful to watch play out. AI written blog -> AI training set -> repeat.by c0_0p_
- 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.by ubercore
- 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.by pooloo
- 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.
by wuliwong - 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.
- 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.by scuff3d
- 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.
by buremba - 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).by Onavo
- 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
by PaulHoule - 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...
by pooloo - 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.
by CodesInChaos - Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?by xnorswap
- 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).
by singron - 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.
by ComputerGuru - Basically people can do it in Postgres but at least run separate instances for each purpose. Don't just throw all in single instance.by ozim
- 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.
by dpc10 - 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.
by b-man - 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.by gentlewater
- And Redis has auto-delete rows (aka TTL). In Postgres you need a cron job to clear stale rows.by deepsun
- 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.by Xeoncross
- 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.by alex_smart
- 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?by dinkleberg