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.
It's 2026, Just Use Postgres
341–349 of 349 posts
Re: It's 2026, Just Use Postgres
#342Earlier 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.
Re: It's 2026, Just Use Postgres
#343No, 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,…
Re: It's 2026, Just Use Postgres
#344Earlier 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
Re: It's 2026, Just Use Postgres
#345Earlier 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.
> 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
#346Earlier 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.
Re: It's 2026, Just Use Postgres
#347Re: It's 2026, Just Use Postgres
#348I’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…
Using new technology is probably too risky unless Postgres is not capable
Re: It's 2026, Just Use Postgres
#349I’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…