PostgreSQL for Everything • Hacker News Board

Re: PostgreSQL for Everything

#141

Post by stackskipton » Wed, Aug 19, 2026, 5:59 PM UTC

cyh555 wrote: post #105

stackskipton wrote: post #94

Earlier quoted context omitted.

As SRE dealing with this at current company, a benefit of using well known software like Kafka is a lot of problems you will run into have solutions/guidance already available vs you having to explore solutions which a lot of time end with “Kafka could easily do this. “

100% except when Kafka goes wrong, who maintains it?

I mean, with this custom thing, you have that question as well with downside is you cannot pick up the knowledge from off the street.

I became the Kafka guy at my current company, it took me about a week of reading and every time I had further question, I didn't have to bother anyone, I could Google and get data I needed.

When it's some NIH thing, you have to bother coworkers and knowledge is whatever is in YOUR company knowledge base with no ability to get knowledge from outside the company.

EDIT: You could also leverage contractors or outside support if not homegrown software.

Re: PostgreSQL for Everything

#142

Post by mikkelam » Wed, Aug 19, 2026, 6:02 PM UTC

Except horizontal scaling.

But a lot of companies are trying to solve that, notably multigres, neki and even pgdog.

Re: PostgreSQL for Everything

#143

Post by seki285 » Wed, Aug 19, 2026, 6:02 PM UTC

andai wrote: post #140

psadauskas wrote: post #139

My general rule of thumb is "Use Postgres until you've discovered why you can't use Postgres." Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.

Doesn't the same argument apply even more to using SQLite instead?

In a lot of cases using SQLite means you write queries incompatible with RDBMS. No need to worry about race conditions or the amount of queries you make, when 100 selects are uber fast.

Re: PostgreSQL for Everything

#144

Post by cheesemayo » Wed, Aug 19, 2026, 6:18 PM UTC

> Contrary to popular belief - the answer to everything is NOT 42

42 is not the answer to everything.

42 is the Answer to the Ultimate Question about Life, the Universe, and Everything.

Re: PostgreSQL for Everything

#145

Post by [deleted] » Wed, Aug 19, 2026, 6:20 PM UTC

joshuamoyers wrote: post #116

0cf8612b2e1e wrote: post #108

Earlier quoted context omitted.

I think it would be helpful if some of these posts included scale. There are almost always two groups talking past each other - I run my B2B application, Postgres only, and it is perfect for my 50k MAU. No complaints, sleeping soundly with the low complexity and a two man team. - I work at FAANG, where we have 1 billion DAU, and this is a joke. Would fall over immediately. The dedicated ops teams for Kubernetes, Elas…

i think 1 billion DAU is the exception here, so I would not expect everyone to constantly caveat personally.

[deleted]

Re: PostgreSQL for Everything

#146

Post by cheesemayo » Wed, Aug 19, 2026, 6:20 PM UTC

I really want a daemonless PostgreSQL, in the style of SQLite.

Re: PostgreSQL for Everything

#147

Post by SoftTalker » Wed, Aug 19, 2026, 6:25 PM UTC

seki285 wrote: post #143

andai wrote: post #140

Earlier quoted context omitted.

Doesn't the same argument apply even more to using SQLite instead?

In a lot of cases using SQLite means you write queries incompatible with RDBMS. No need to worry about race conditions or the amount of queries you make, when 100 selects are uber fast.

Yes, for very small or embedded, single-purpose systems sqlite is usually a good choice. It's very well tested, and there's nothing extra to run or manage. But be careful if the system starts growing beyond that, you'll want a real RDBMS before you abuse sqlite too much.

Re: PostgreSQL for Everything

#148

Post by sgt » Wed, Aug 19, 2026, 6:36 PM UTC

Intrigued by this

> After some performance checks it became clear that PostgreSQL was even faster than reading from the file system for our use-case. PostgreSQL uses the file system very efficiently for its data - and it adds a lot of caching and efficient reading and writing strategies that can outperform writing and reading raw data on a file system.

This goes against conventional knowledge. I've always heard (and followed best practice) to avoid storing binary data in BYTEA columns that should otherwise be put on a filesystem or an object storage like S3.

I'd like to find out more about this, because in many cases it would be very convenient indeed to store it in the database itself.

Re: PostgreSQL for Everything

#149

Post by bluGill » Wed, Aug 19, 2026, 6:38 PM UTC

fabian2k wrote: post #28

Ozzie_osman wrote: post #9

I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned…

MySQL had some problematic design decisions initially. They might be fixed now, but the impression remained. And later there was the added complication that they were bought by Oracle, so you didn't really know how this would turn out in the end. PostgreSQL also had more features back then, e.g. the JSON support is very nice if you need to do anything that doesn't neatly fit into the relational model.

Not only where the problematic design decisions, but large numbers of people said for years "nobody will never need/want that anyway so stop talking about it". That is they didn't even attempt to talk about trade offs, you were just wrong if you suggested anything else.

Then people who knew something got involved (or likely were involved all along - but I never followed MySQL so I'm not sure) and fixed those because they matter and suddenly the crowd shut up.

Re: PostgreSQL for Everything

#150

Post by tyg13 » Wed, Aug 19, 2026, 6:41 PM UTC

stackskipton wrote: post #141

cyh555 wrote: post #105

Earlier quoted context omitted.

100% except when Kafka goes wrong, who maintains it?

I mean, with this custom thing, you have that question as well with downside is you cannot pick up the knowledge from off the street. I became the Kafka guy at my current company, it took me about a week of reading and every time I had further question, I didn't have to bother anyone, I could Google and get data I needed. When it's some NIH thing, you have to bother coworkers and knowledge is whatever is in YOUR comp…

Yup, and every time it breaks, you've got to pester someone whose job probably isn't maintaining that thing actively.

I worked at a startup with massive NIH syndrome, once. We even used our own in-house programming language, because it was "better than anything else out there on the market." It did have a lot of nifty features that others don't have: a pretty novel type system, programmatic macros, a built-in build system and other fun bells and whistles -- but also not-so-fun ones like having no syntax highlighter, LSP, or debugger, and having to constantly shuffle around your code to avoid ICEs in the compiler.

The compiler wasn't the product, but we found ourselves fighting that thing more actively than any of the real problems our custom programming language was supposed to solve. The CTO found himself spending all his nights and weekends mostly trying to get the compiler to not explode.

A few years later, after I had long left (for that reason, among many) I heard they switched to Python. Can't imagine how long it took them to get that all rewritten.