Earlier quoted context omitted.
Well, take a look at the dates of when Postgres was created and when SSDs become available. Better, find articles about internal algorithms, B-trees, times of operations like seeks etc. The Postgres was initially written with disk operation timings in mind, and the point is that's changing - and I haven't heard of Postgres architecture changing with that.
Can you share examples of new database architectures and products using them that are built for SSDs? I'm sure we have different capabilities and constraints, but I am unaware of any fundamentally different approaches to indexes.
It's 2026, Just Use Postgres
311–320 of 349 posts
Re: It's 2026, Just Use Postgres
#312I am looking for a db that runs using existing json/yaml/csv files, saves data back to those files in a directory, which I can sync using Dropbox or whatever shared storage. Now I can run this db wherever I am & run the application. Postgres feels a bit more for my needs
SQLite or DuckDB if your needs are more analytical than transactional.
Re: It's 2026, Just Use Postgres
#313Earlier quoted context omitted.
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…
Nothing about my post indicated that these things shouldn't be talked about and discussed. It's worth understanding how things work, even things that one personally need to use. Continue to stash ideas away and add them to your future bag of tricks. The key issue here is that people need to be more critical and self-aware of the space where their problems lie, and not assume that because something is exceeding the envelope of what they've experienced that it's entering into special case territory.
Rather my point was that people, including myself, have a tendency to believe they're in an exceptional case when they're actually not. And thus will see discussions on sites like this and assume that's what they need to do. And of course they don't understand the tradeoffs and wind up not realizing they're actually making things harder for themselves.
The classic example is scaling issues where people, again including myself, assume they have exotic scaling needs simply because it's larger than anything they've seen before. When in fact by objective measures what they have is something that could run perfectly fine on 20 year old hardware and bog standard techniques.
Re: It's 2026, Just Use Postgres
#314Earlier quoted context omitted.
In a typical CRUD web app, any query that takes milliseconds instead of microseconds should be viewed with suspicion. In a more charitable interpretation, maybe the parent is talking about sub-100ms total round trip time for an API call over the public internet.
But OP never said it's a CRUD app. Maybe OP did some experimentation with OLAP use cases.
OP here. Roughly 50GB in db size. Fairly standard queries (full-text search + filters). Most queries are on the order of 10-100ms. Some more complex ones involving business logic exceeds 100ms.
This is well within my budget, but it sounds like there might be room for improvements?
Re: It's 2026, Just Use Postgres
#315I 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?
My outdated/incorrect mental model of how well databases work.
Re: It's 2026, Just Use Postgres
#316Earlier quoted context omitted.
Thanks Tom, I appreciate the openness. You are seemingly overriding the wishes of the community, but it your community and you have the right to do so. I still think it's a shame, but that's my problem.
> You are seemingly overriding the wishes of the community That's false. The overwhelming sentiment of the community is that HN should be free of LLM-generated content or content that has obvious AI fingerprints. Sometimes people don't immediately realize that an article or comment has a heavy LLM influence, but once they realize it does, they expect us to act (this is especially true if they didn't realize it initia…
>> You are seemingly overriding the wishes of the community
> That's false. The overwhelming sentiment of the community is that HN should be free of LLM-generated content or content that has obvious AI fingerprints.
Yeah it is indeed, and for good reason: why would I spend time reading something the author didn't spend time thinking through and writing?
It's not that people don't like Postgres articles (otherwise, the upvotes would be much lower), but once you read a bit of the article, the LLM stench it gives off is characteristic. You know: Standard. LLM. Style. It's tiresome. Irksome. Off-putting.
What I'm wondering is, if LLMs are trained on "our" (in the wider sense of the word) writing style, and spew it back at us, what data set was it that overused this superficial emphatic style to such a degree, that it's now overwhelmingly the bog-standard generative output style?
Re: It's 2026, Just Use Postgres
#317Earlier 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.
> But yes, it's an architecture question; my point being, most people pick many bulldozers while they need a 1 shovel.
Again, huh?
Client-server vs locally embedded does not map to "many bulldozers vs 1 shovel".
SQLite and Postgres aren't even really competitors. They serve extremely different use cases. I'm not aware that "most" people are picking Postgres when they "need" SQLite. What are you even basing this on? SQLite is already an extremely popular choice.
Re: It's 2026, Just Use Postgres
#318Earlier quoted context omitted.
But OP never said it's a CRUD app. Maybe OP did some experimentation with OLAP use cases.
OP here. Roughly 50GB in db size. Fairly standard queries (full-text search + filters). Most queries are on the order of 10-100ms. Some more complex ones involving business logic exceeds 100ms. This is well within my budget, but it sounds like there might be room for improvements?
Regardless of your use case, EXPLAIN ANALYZE can show you whether there's any room for improvement.
Re: It's 2026, Just Use Postgres
#319I’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…
I took it to mean “make Postgres your default choice”, not “always use Postgres no matter what”
This could be similar to defaulting to a monolith service, and breaking it into micro services only when experience demands it.
Start with Postgres for everything, then use custom solutions where you are running into the limitations of Postgres.
Re: It's 2026, Just Use Postgres
#320Earlier quoted context omitted.
Apart from the style of the prose, which is my subjective evaluation: This blog post is "a view from nowhere." Tiger Data is a company that sells postgres in some way (don't know, but it doesn't matter for the following): they could speak as themselves, and compare themselves to companies that sell other open source databases. Or they could showcase benchmarks _they ran_. Them saying: "What you get: pgvectorscale use…
I don't understand your example: pgvectorscale was built and is maintained by Tiger Data
In terms of that example: they should link to how they got those numbers, and it should state the benchmark used, the machines used, what they controlled for etc.