Live data from Hacker News

It's 2026, Just Use Postgres

tigerdata.com

341–349 of 349 posts

Re: It's 2026, Just Use Postgres

#341
post #339
post #328

Earlier quoted context omitted.

Hey Tom! Earnest question here - I am seeing on the order of one AI post a day on HN, sometimes more than that. It's good to know we can email in about these things, but I think most users don't understand that - certainly I didn't for the last few month as this has been going on. It would be nice if there was an affordance on the site to flag these, similar to the existing flag function. Thanks!

Just flagging them is fine. Emailing us with the link is even better. Part of me wonders if we should have a new, specific-purpose flag for generated content, but it’s not the HN way to add new features for actions that can already be satisfied by existing UI features.

I would suggest a new feature here. I have been hesitating on flagging them because I feel 'flag' is for things which are obvious rule violations. I feel a bit bad flagging a submission off the front page when I only have a vague feeling that it was AI-written. (And sometimes AI generated content isn't that bad, i.e. if an author just used AI to translate their writing into English.)

Re: It's 2026, Just Use Postgres

#342

Earlier quoted context omitted.

Huh? SQLite is designed for application databases. Postgres is designed for client-server. It's not about "power" (what does that even mean?), it's about totally different design choices that are intended for different purposes. It's an architecture question, not a "power" or "visitors" question.

We run plenty of money making SaaS on sqlite without issues. And have been for over a decade. By power I meant all the complex features postgres has. But yes, it's an architecture question; my point being, most people pick many bulldozers while they need a 1 shovel.

how did you handle HA/replication story with sqlite?

Re: It's 2026, Just Use Postgres

#343
post #277
post #245

No, seriously, people need to be punished for submitting LLM-generated garbage without specifying that it's LLM-generated garbage. 400+ points, oh my god, people, what's wrong with you...

We buried the post for seeming obviously-LLM-generated. But please email us about these (hn@ycombinator.com) rather than posting public accusations. There are two reasons why emailing us is better: First, the negative consequences of a false allegation outweigh the benefits of a valid accusation. Second and more important: we'll likely see an email sooner than we'll see a comment, so we can nip it in the bud quickly,…

This thread is a great discussion and I have kept coming back to it over the last couple days to read more of it when I have a chance. I’m kind of disappointed that it artificially ended. I think at some useful comment threshold level you just have to let it go.

Re: It's 2026, Just Use Postgres

#344
post #14

Earlier quoted context omitted.

Did someone really downvote the creator of Redis ?

All the time here in HN, I'm proud of it -- happy to have opinions not necessarily aligned with what users want to listen to. Also: never trust the establishment without thinking! ;D

As a longtime fan of your work I appreciate very much how willing you are to get into the trench with your users. It is always a delight to see you engage in an interesting, intelligent conversation with those who have a different opinion from you. Thanks for being cool, antirez.

Re: It's 2026, Just Use Postgres

#345
post #333

Earlier quoted context omitted.

Reliable networks don't actually exist[1]. Clearly, it's possible to reduce the risk to the point where many companies are willing to accept it, but it's still a problem and comes with high operational costs. And for some use cases (like finance), even a small risk of undefined database behavior or lost writes is unacceptable. The future are distributed databases with consensus, and unfortunately, Postgres isn't ther…

reliable network and partitioning are two different things. If your network is down, your clients can't connect DB too, and nothing works. State of network partitioning is harder to achieve, its more like if connection between two datacenters is down where DB replicas live, which is more rare because of all global connection redundancy.

It's really the same thing. Network partitions can (and do) occur within a single DC.

> If your network is down, your clients can't connect DB too, and nothing works

This sounds simple, but can only be achieved with high certainty using distributed consensus.

Re: It's 2026, Just Use Postgres

#346
post #344
post #14

Earlier quoted context omitted.

All the time here in HN, I'm proud of it -- happy to have opinions not necessarily aligned with what users want to listen to. Also: never trust the establishment without thinking! ;D

As a longtime fan of your work I appreciate very much how willing you are to get into the trench with your users. It is always a delight to see you engage in an interesting, intelligent conversation with those who have a different opinion from you. Thanks for being cool, antirez.

Thank you so much for this comment <3

Re: It's 2026, Just Use Postgres

#348

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work w…

Since Postgres is usually a good starting point and it's much easier to work with the same technologies. Which could lead to Postgres being pushed to weird limits later on.

Using new technology is probably too risky unless Postgres is not capable

Re: It's 2026, Just Use Postgres

#349

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work w…

But I do think there's so much marketing out there too. So it's difficult to trust certain technologies until it has been proven.
Post reply on HN