4 ms·

Do you need separate systems when you already have Postgres?

104 points by b-man 3mo ago

PaulHoule 3mo ago
... 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 3mo 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 3mo 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 https://arango.ai/wp-content/uploads/2025/11/ADB-Community-License_31OCT2023.pdf 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.
    - tudorg 3mo ago
      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.
    - sarchertech 3mo ago
      The license you linked was too much for me because it included limitations 100 GB of data and providing audit logs for the company to inspect. But I don’t have a problem with people inserting clauses to prevent Amazon from taking over. I don’t expect free work from people forever. If I’m going to use an open source project to build a commercial product, I would only do so if I’m ok forking and maintaining the project myself if necessary.
      - PaulHoule 3mo ago
        The license wasn't like that when I first got involved or I wouldn't have gotten involved. I don't have any fear that Postgres will get relicensed with a worse license than it has. But I see any relicensing or license that is more restrictive than a standard license as a slippery slope that makes me think "I don't want to invest in this platform" thanks to that experience. I'm a software developer, not a lawyer. I understand standard software licenses and don't feel I have to re-read them or think too much about them. By using one and being dependent on systems that use them I feel like I'm reducing the burden on people who might adopt my open source.
        sarchertech 3mo ago
        There's a couple of different issues here. The first is that there are many what most people would call standard licenses that contain tons of restrictions. Many of them like AGPL (and GPL to a lesser extent) aren't even fully understood by lawyers. Second, when people are talking about standard open source licenses, they are generally talking about licensees approved by the OSI. The problem is that the OSI is primarily financed by tech companies including Amazon, Microsoft, and Google. They're not ever going to add a new category of licenses or promote anything that harms those companies business interests. As far as relicensing being a slippery slope. There's no such thing as relicensing. Once software is released under a certain license, it is always available under that license. Anyone can choose to license future work using a different license. That is functionally equivalent to the original authors of a project ceasing work, and someone else starting work on a new fork with a different license. Nothing about Postgres using a standard license prevents this (for what it's worth Postgres is released under its own custom "PostgreSQL License" even if it is very similar to other open source licenses). What you are actually worried about is that someone stops doing free work, which is the practical consequence of "relicensing". If that's the case you need to look into much more than the license of a project, you need to look into size of the organization, funding, size of the community, time in operation etc... I don't know if operating under a non-standard license is even in any way correlated with an organization or person relicensing or any other form of ceasing development.
  - ubercore 3mo ago
    It's also postgres, but timescaledb's licensing (and therefore its lack of good support in azure managed postgres) is a bummer.
  - throwaway7356 3mo 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.
    - sarchertech 3mo ago
      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?
samrus 3mo ago
Reminds me Kai Lentit's ffmpeg video https://youtu.be/9kaIXkImCAM https://youtu.be/9kaIXkImCAM
polycancel 3mo 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 3mo 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.
goosethe 3mo ago
agree: https://github.com/seanwevans/pg_os https://github.com/seanwevans/pg_os https://github.com/seanwevans/pg_git https://github.com/seanwevans/pg_git https://github.com/seanwevans/pg_gpt2 https://github.com/seanwevans/pg_gpt2 etc...
- Sharlin 3mo ago
  https://thombrown.blogspot.com/2026/07/load-plcbmbasic81-commodore-64-basic.html https://thombrown.blogspot.com/2026/07/load-plcbmbasic81-com...
pavel_lishin 3mo 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 3mo 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.
- AnatolySkuba 3mo ago
  [flagged]
simonbarker87 3mo 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.
h1fra 3mo 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?
- JsonDemWitOster 3mo ago
  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.
devin 3mo 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. [1]: https://mcfunley.com/choose-boring-technology 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.
- CodesInChaos 3mo ago
  I like keeping the number of stateful systems minimal, since those are the most annoying from a reliability perspective. In practice I use one database and object storage (S3). If that database is postgres is secondary.
chestervonwinch 3mo ago
what about for blob storage too?
dpc10 3mo ago
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.
- Xeoncross 3mo 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 3mo 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.
  - wuliwong 3mo ago
    OK, but it is relatively easy to setup. Obviously, nobody thinks it is _literally_ effortless.
    - munk-a 3mo 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.
      - wuliwong 3mo ago
        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. ₍₍(˶>ᗜ<˶)⁾⁾
CodesInChaos 3mo 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 3mo ago
  Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?
  - CodesInChaos 3mo 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.
- singron 3mo ago
  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).
otabdeveloper4 3mo ago
Postgres sucks. It does a little bit of everything, but badly and with much manual intervention.
- dimgl 3mo 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.
- nilamo 3mo 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 3mo 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.
  - otabdeveloper4 3mo ago
    Depends on what you want. Postgres doesn't do replication, HA or columnar/OLAP workloads, for example.
ComputerGuru 3mo 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.
- ozim 3mo ago
  Basically people can do it in Postgres but at least run separate instances for each purpose. Don't just throw all in single instance.
ubercore 3mo 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.
- pooloo 3mo ago
  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.
valentynkit 3mo 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 3mo 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 3mo 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.
JsonDemWitOster 3mo 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.
- Onavo 3mo ago
  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).
- PaulHoule 3mo 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. 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 https://sqlite.org/fasterthanfs.html
  - JsonDemWitOster 3mo ago
    I can no longer edit my comment above so I'm just leaving this here, picking you arbitrarily out of the handful that addressed my filesystem suggestion: I am being sarcastic to show what a ridiculous idea it is to shoehorn everything into Postgres. If you find eschewing a relational DB for the filesystem incredulous, you should maybe reconsider if eschewing specialized software in favor of Postgres is advisable.
DonsDiscountGas 3mo ago
I suspect a lot of this is resume driven design.
bitbasher 3mo ago
I was on the Postgres train for 10+ years. Then I fell in love with Sqlite and have been using it for everything.
mrkeen 3mo 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.
- munk-a 3mo ago
  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.
  - mrkeen 3mo ago
    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.
bijowo1676 3mo ago
lets take it one step further: Do you really need Postgres when you already have SQLite?
- whstl 3mo ago
  For 90%, maybe 99% of projects: not really. Postgres is a good middle ground, though.
wuliwong 3mo 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.
stickfigure 3mo ago
Fun fact for people whose scaling plan anticipates moving from Postgres to CRDB: SELECT FOR UPDATE SKIP LOCKED works great for turning Postgres into a job queue. It does not work the same way on CRDB and you will likely have to rewrite those queries or use an external job queue.
armdave 3mo ago
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."
- c0_0p_ 3mo ago
  I agree, the inevitable feedback loops will be painful to watch play out. AI written blog -> AI training set -> repeat.
  - raverbashing 3mo ago
    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
DarkCrusader2 3mo ago
Given the unanimous consensus on HN that Postgres is all you will ever need. I will present 2 resources which I came across recently which changed my perspective on this blind reverence for Postgres for everything. First is this Oxide and Friends episode [1] where Bryan and gang explains war stories related to operating Postgres during their Joyent days and why they went with Cockroach DB for Oxide. Second is this amazing blog from brandur which explains several issues with using Postgres as high throughput queue and some mitigations. Online forums like Hacker news can be a bit echo chamber-y. It is always good to ensure that the people you are taking advice from are solving the same problem as you. [1] https://oxide-and-friends.transistor.fm/episodes/whither-cockroachdb/ https://oxide-and-friends.transistor.fm/episodes/whither-coc... [2] https://brandur.org/postgres-queues https://brandur.org/postgres-queues
- pythonaut_16 3mo ago
  These are valid push-backs on the "postgres everywhere" argument. The two critical questions IMO are: 1. At what scale do these issues arise? 2. Does Postgres make it harder to solve them when you reach that scale than another solution would have? Some of that probably depends on the libraries or tools you use on top of Postgres but being able to easily swap to Redis or a proper queue at scale should mitigate the risk of starting with Postgres if you don't already have the scale.
tudorg 3mo ago
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.
alphainfo 3mo ago
[flagged]
ivolimmen 3mo ago
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.

104 points by b-man 3mo ago

... 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 3mo 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 3mo 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 https://arango.ai/wp-content/uploads/2025/11/ADB-Community-License_31OCT2023.pdf 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.
  - tudorg 3mo ago
    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.
  - sarchertech 3mo ago
    The license you linked was too much for me because it included limitations 100 GB of data and providing audit logs for the company to inspect. But I don’t have a problem with people inserting clauses to prevent Amazon from taking over. I don’t expect free work from people forever. If I’m going to use an open source project to build a commercial product, I would only do so if I’m ok forking and maintaining the project myself if necessary.
    - PaulHoule 3mo ago
      The license wasn't like that when I first got involved or I wouldn't have gotten involved. I don't have any fear that Postgres will get relicensed with a worse license than it has. But I see any relicensing or license that is more restrictive than a standard license as a slippery slope that makes me think "I don't want to invest in this platform" thanks to that experience. I'm a software developer, not a lawyer. I understand standard software licenses and don't feel I have to re-read them or think too much about them. By using one and being dependent on systems that use them I feel like I'm reducing the burden on people who might adopt my open source.
      - sarchertech 3mo ago
        There's a couple of different issues here. The first is that there are many what most people would call standard licenses that contain tons of restrictions. Many of them like AGPL (and GPL to a lesser extent) aren't even fully understood by lawyers. Second, when people are talking about standard open source licenses, they are generally talking about licensees approved by the OSI. The problem is that the OSI is primarily financed by tech companies including Amazon, Microsoft, and Google. They're not ever going to add a new category of licenses or promote anything that harms those companies business interests. As far as relicensing being a slippery slope. There's no such thing as relicensing. Once software is released under a certain license, it is always available under that license. Anyone can choose to license future work using a different license. That is functionally equivalent to the original authors of a project ceasing work, and someone else starting work on a new fork with a different license. Nothing about Postgres using a standard license prevents this (for what it's worth Postgres is released under its own custom "PostgreSQL License" even if it is very similar to other open source licenses). What you are actually worried about is that someone stops doing free work, which is the practical consequence of "relicensing". If that's the case you need to look into much more than the license of a project, you need to look into size of the organization, funding, size of the community, time in operation etc... I don't know if operating under a non-standard license is even in any way correlated with an organization or person relicensing or any other form of ceasing development.
- ubercore 3mo ago
  It's also postgres, but timescaledb's licensing (and therefore its lack of good support in azure managed postgres) is a bummer.
- throwaway7356 3mo 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.
  - sarchertech 3mo ago
    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?

samrus 3mo ago

Reminds me Kai Lentit's ffmpeg video https://youtu.be/9kaIXkImCAM https://youtu.be/9kaIXkImCAM

polycancel 3mo 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 3mo 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.

goosethe 3mo ago

agree: https://github.com/seanwevans/pg_os https://github.com/seanwevans/pg_os https://github.com/seanwevans/pg_git https://github.com/seanwevans/pg_git https://github.com/seanwevans/pg_gpt2 https://github.com/seanwevans/pg_gpt2 etc...

Sharlin 3mo ago
https://thombrown.blogspot.com/2026/07/load-plcbmbasic81-commodore-64-basic.html https://thombrown.blogspot.com/2026/07/load-plcbmbasic81-com...

pavel_lishin 3mo 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 3mo 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.
AnatolySkuba 3mo ago
[flagged]

simonbarker87 3mo 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.

h1fra 3mo 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?

JsonDemWitOster 3mo ago
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.

devin 3mo 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. [1]: https://mcfunley.com/choose-boring-technology 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.

CodesInChaos 3mo ago
I like keeping the number of stateful systems minimal, since those are the most annoying from a reliability perspective. In practice I use one database and object storage (S3). If that database is postgres is secondary.

chestervonwinch 3mo ago

what about for blob storage too?

dpc10 3mo ago

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.

Xeoncross 3mo 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 3mo 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.
- wuliwong 3mo ago
  OK, but it is relatively easy to setup. Obviously, nobody thinks it is _literally_ effortless.
  - munk-a 3mo 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.
    - wuliwong 3mo ago
      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. ₍₍(˶>ᗜ<˶)⁾⁾

CodesInChaos 3mo 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 3mo ago
Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?
- CodesInChaos 3mo 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.
singron 3mo ago
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).

otabdeveloper4 3mo ago

Postgres sucks. It does a little bit of everything, but badly and with much manual intervention.

dimgl 3mo 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.
nilamo 3mo 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 3mo 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.
- otabdeveloper4 3mo ago
  Depends on what you want. Postgres doesn't do replication, HA or columnar/OLAP workloads, for example.

ComputerGuru 3mo 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.

ozim 3mo ago
Basically people can do it in Postgres but at least run separate instances for each purpose. Don't just throw all in single instance.

ubercore 3mo 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.

pooloo 3mo ago
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.

valentynkit 3mo 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 3mo 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 3mo 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.

JsonDemWitOster 3mo 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.

Onavo 3mo ago
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).
PaulHoule 3mo 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. 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 https://sqlite.org/fasterthanfs.html
- JsonDemWitOster 3mo ago
  I can no longer edit my comment above so I'm just leaving this here, picking you arbitrarily out of the handful that addressed my filesystem suggestion: I am being sarcastic to show what a ridiculous idea it is to shoehorn everything into Postgres. If you find eschewing a relational DB for the filesystem incredulous, you should maybe reconsider if eschewing specialized software in favor of Postgres is advisable.

DonsDiscountGas 3mo ago

I suspect a lot of this is resume driven design.

bitbasher 3mo ago

I was on the Postgres train for 10+ years. Then I fell in love with Sqlite and have been using it for everything.

mrkeen 3mo 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.

munk-a 3mo ago
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.
- mrkeen 3mo ago
  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.

bijowo1676 3mo ago

lets take it one step further: Do you really need Postgres when you already have SQLite?

whstl 3mo ago
For 90%, maybe 99% of projects: not really. Postgres is a good middle ground, though.

wuliwong 3mo 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.

stickfigure 3mo ago

Fun fact for people whose scaling plan anticipates moving from Postgres to CRDB: SELECT FOR UPDATE SKIP LOCKED works great for turning Postgres into a job queue. It does not work the same way on CRDB and you will likely have to rewrite those queries or use an external job queue.

armdave 3mo ago

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

c0_0p_ 3mo ago
I agree, the inevitable feedback loops will be painful to watch play out. AI written blog -> AI training set -> repeat.
- raverbashing 3mo ago
  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

DarkCrusader2 3mo ago

Given the unanimous consensus on HN that Postgres is all you will ever need. I will present 2 resources which I came across recently which changed my perspective on this blind reverence for Postgres for everything. First is this Oxide and Friends episode [1] where Bryan and gang explains war stories related to operating Postgres during their Joyent days and why they went with Cockroach DB for Oxide. Second is this amazing blog from brandur which explains several issues with using Postgres as high throughput queue and some mitigations. Online forums like Hacker news can be a bit echo chamber-y. It is always good to ensure that the people you are taking advice from are solving the same problem as you. [1] https://oxide-and-friends.transistor.fm/episodes/whither-cockroachdb/ https://oxide-and-friends.transistor.fm/episodes/whither-coc... [2] https://brandur.org/postgres-queues https://brandur.org/postgres-queues

pythonaut_16 3mo ago
These are valid push-backs on the "postgres everywhere" argument. The two critical questions IMO are: 1. At what scale do these issues arise? 2. Does Postgres make it harder to solve them when you reach that scale than another solution would have? Some of that probably depends on the libraries or tools you use on top of Postgres but being able to easily swap to Redis or a proper queue at scale should mitigate the risk of starting with Postgres if you don't already have the scale.

tudorg 3mo ago

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.

alphainfo 3mo ago

[flagged]

ivolimmen 3mo ago

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.