Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do you need separate systems when you already have Postgres?

postgresisenough.dev

Post reply on HN
Print view View original

71–80 of 90 posts

Re: Do you need separate systems when you already have Postgres?

#71

Post by preisschild »

gentlewater wrote: post #63
dpc10 wrote: post #13

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 g…

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.

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

Re: Do you need separate systems when you already have Postgres?

#72

Post by singron »

CodesInChaos wrote: post #15

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…

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

Re: Do you need separate systems when you already have Postgres?

#73

Post by b-man »

dpc10 wrote: post #13

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 g…

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.

Re: Do you need separate systems when you already have Postgres?

#74

Post by raverbashing »

c0_0p_ wrote: post #70
armdave wrote: post #51

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

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

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

Re: Do you need separate systems when you already have Postgres?

#75

Post by mrkeen »

munk-a wrote: post #53
mrkeen wrote: post #37

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.

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.

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.

Re: Do you need separate systems when you already have Postgres?

#76

Post by tudorg »

PaulHoule wrote: post #21
sarchertech wrote: post #11

Earlier quoted context omitted.

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.

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 (…

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.

Re: Do you need separate systems when you already have Postgres?

#77

Post by sarchertech »

PaulHoule wrote: post #21
sarchertech wrote: post #11

Earlier quoted context omitted.

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.

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 (…

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.

Re: Do you need separate systems when you already have Postgres?

#78

Post by PaulHoule »

sarchertech wrote: post #77
PaulHoule wrote: post #21

Earlier quoted context omitted.

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 (…

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…

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.

Re: Do you need separate systems when you already have Postgres?

#79

Post by mattmanser »

alex_smart wrote: post #62
dpc10 wrote: post #13

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 g…

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.

Maybe for the other stuff, but not Redis.

Re: Do you need separate systems when you already have Postgres?

#80

Post by pythonaut_16 »

DarkCrusader2 wrote: post #54

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 am…

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.

Post reply on HN