Earlier quoted context omitted.
20 years ago was 2006? Oh no...
Don't get me started on when the 90's were.
"The peak of your human society" in the words of The Matrix
It's 2026, Just Use Postgres
241–250 of 349 posts
Re: It's 2026, Just Use Postgres
#242I recently started digging into databases for the first time since college, and from a novice's perspective, postgres is absolutely magical. You can throw in 10M+ rows across twenty columns, spread over five tables, add some indices, and get sub-100ms queries for virtually anything you want. If something doesn't work, you just ask it for an analysis and immediately know what index to add or how to fix your query. It…
what are you comparing this to btw?
Re: It's 2026, Just Use Postgres
#243It's 20xx just use sqlite. Almost no-one needs all that power; they sure do think they do, but really don't. And will never. SQLite + Duck is all you need even with a million visitors; when you need failover and scaling you need more, but that is a tiny fraction of all companies.
Having built production apps on SQLite I can say it's not all sunshine and roses, the complexity explodes the moment you need multiple workers that can all write. You better hope you dont have any big indexes or your writes will queue and you start getting "database is locked" errors. Good luck queueing writes properly at the application layer without rebuilding a full distributed queue system / network interface / q…
Oh I didn't say that, but nor is postgres. Use the right tool for the job I agree with, just people are making their lives difficult (expensive as well) by just blindly picking postgres.
Re: It's 2026, Just Use Postgres
#244I have a colleague who (inexplicably) doesn't trust Postgres for "high performance" applications. He needed a database of shared state for a variable number of running containers to manage a queue, so he decided to implement his own bespoke file-based database, using shared disk. Lo and behold, during the first big (well-anticipated) high-demand event, that system absolutely crawled. It ran, but it was a total bottleneck during two days of high demand. I, who has made a New Years resolution to no longer spend political capital on things that I can't change, looked on with a keen degree of schadenfreude.
Just. Use. Postgres.
Re: It's 2026, Just Use Postgres
#245No, 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...
Re: It's 2026, Just Use Postgres
#246Earlier quoted context omitted.
I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can become misleading for teams that are hitting or even close to hitting—the limits of Postgres, who may continue tuning Postgres spending not only time but also significant $$. IMO…
I think that the key point being made by this crowd, of which I'm one, is somewhere in the middle. The way I mean it is "Make Postgres your default choice. Also *you* probably aren't doing anything special enough to warrant using something different". In other words, there are people and situations where it makes sense to use something else. But most people believing they're in that category are wrong.
> Also you probably aren't doing anything special enough to warrant using something different".
I always get frustrated by this because it is never made clear where the transition occurs to where you are doing something special enough. It is always dismissed as, "well whatever it is you are doing, I am sure you don't need it"
Why is this assumption always made, especially on sites like HackerNews? There are a lot of us here that DO work with scales and workloads that require specialized things, and we want to be able to talk about our challenges and experiences, too. I don't think we need to isolate all the people who work at large scales to a completely separate forum; for one thing, a lot of us work on a variety of workloads, where some are big enough and particular enough to need a different technology, and some that should be in Postgres. I would love to be able to talk about how to make that decision, but it is always just "nope, you aren't big enough to need anything else"
I was not some super engineer who already knew everything when I started working on large enough data pipelines that I needed specialized software, with horizontal scaling requirements. Why can't we also talk about that here?
Re: It's 2026, Just Use Postgres
#247"juSt use PoStGreS" is spoken like a true C-level with no experience on the ground with postgres itself or its spin offs.
yes pg is awesome and it’s my go to for relational databases. But the reason why mongo or influx db exists is because they excel in those areas.
I would use pg for timeseries for small use cases, testing. But scaling pg for production time series workloads is not worth it. You end up fighting the technology to get it to work just because some lame person wanted to simplify ops
Re: It's 2026, Just Use Postgres
#248No, 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...
and it’s up voted 400+ on hn. This place has truly lost its way.
Re: It's 2026, Just Use Postgres
#249No, 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...
I just pasted the first paragraph in an "AI detector" app and it indeed came back as 100% AI. But I heard those things are unreliable. How did you determine this was LLM-generated? The same way?
Re: It's 2026, Just Use Postgres
#250Earlier quoted context omitted.
The point is really that you can only evaluate which of alternatives is better once you have working product with data big enough - else it's just basically following trends and hoping your barely informed decision won't be wrong.
Agree to disagree here. I see a world where developers need to think about (reasonable) scale from day one, or at least very early. We’ve been seeing this play out at ClickHouse - the need for purpose-built OLAP is reducing from years to months. Also integration with ClickHouse is few weeks of effort for potentially significantly faster performance for analytics.
I see a world where developers need to think about REASONABLE scale from day one, with all caps and no parentheses.
I've sat in on meetings about adding auth rate limiting, using Redis, to an on-premise electron client/Node.js server where the largest installation had 20 concurrent users and the largest foreseeable installation had a few thousand, in which every existing installation had an average server CPU utilisation of less than a percent.
Redis should not even be a possibility under those circumstances. It's a ridiculous suggestion based purely on rote whiteboard interview cramming. Stick a token_bucket table in Postgres.
I'm also not convinced that thinking about reasonable scale would lead to a different implementation for most other greenfield projects. The nice thing about shoving everything into Postgres is that you nearly always have a clear upgrade path, whereas using Redis right from the start might actually make the system less future-proof by complicating any eventual migration.