Live data from Hacker News

It's 2026, Just Use Postgres

tigerdata.com

331–340 of 349 posts

Re: It's 2026, Just Use Postgres

#331
post #250

Earlier quoted context omitted.

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 utilisa…

Ack, agreed. But there’s a better way to communicate than making blanket statements like “just use Postgres.” For example, you could say “Postgres is the default database,” etc. Don’t get me wrong—I’m a huge huge fan of Postgres. I’ve worked at Postgres companies for a decade, started a Postgres company, and now lead a Postgres service within a company! But I prefer being real rather than doing marketing hype and bla…

"Just" doesn't solely mean "only", this phrase is using it in the spirit of "just do it" - meaning "stop dawdling around".

"Just use postgres" is the snappy phrase you're looking for.

Re: It's 2026, Just Use Postgres

#332
post #311

Earlier quoted context omitted.

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.

https://medium.com/@tusharmalhotra_81114/how-ssds-transforme...

That blog post is very light on details can be condensed to a single line/paragraph. LSM trees are more efficient for SSDs and modern databases use them.

I don't know enough to comment yet but will go read about it.

Re: It's 2026, Just Use Postgres

#333
post #145

Earlier quoted context omitted.

Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions. It would not pass the Jepsen test suite. This is very hard to fix and requires significant architectural changes (like Yugabyte or Neon have done).

> Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions. Argument is that partitioning almost never happens, because of network reliably rerouting traffic.

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 there yet.

[1]: https://aphyr.com/posts/288-the-network-is-reliable

Re: It's 2026, Just Use Postgres

#334
post #333

Earlier quoted context omitted.

> Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions. Argument is that partitioning almost never happens, because of network reliably rerouting traffic.

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.

Re: It's 2026, Just Use Postgres

#335

Earlier quoted context omitted.

If you think Postgres has idiosyncrasies… https://sqlite.org/quirks.html

Which one is an issue?

NUL in the middle of a string is fine, types have no meaning, VARCHAR limits are just suggestions…

The flexible typing is the biggest WTF to me, especially because it necessitates insane affinity rules[0]. For example, you can declare that a column is of type “CHARINT” (or “VARCHARINT”, for that matter), and while that will match the rule for TEXT affinity (contains the string “CHAR”), it also matches the rule for INTEGER affinity (contains the string “INT”), and since that rule matches first, the column is given INTEGER affinity. "FLOATING POINT" maps to INTEGER since it ends in "INT", and "STRING" maps to NUMERIC since it doesn't match anything else.

Then there are the comparison rules (same link). NULL This is particularly galling considering that most of sqlite3's display types (this is `markdown`) don't visually differentiate between string-types and numeric-types - I manually added the strings on rows (by PK) 2 and 4 to assist the explanation.

  sqlite> CREATE TABLE foobar (id INTEGER NOT NULL PRIMARY KEY, b BLOB NOT NULL);
  sqlite> INSERT INTO foobar (b) VALUES (10), ('10'), (0xA), ('0xA');
  sqlite> SELECT id, b, 15 > b, '15' > b, 0xF > b, '0xF' > b FROM foobar ORDER BY b;
  | id |  b    | 15 > b | '15' > b | 0xF > b | '0xF' > b |
  |----|-----  |--------|----------|---------|-----------|
  | 1  | 10    | 1      | 1        | 1       | 1         |
  | 3  | 10    | 1      | 1        | 1       | 1         |
  | 4  | '0xA' | 0      | 1        | 0       | 1         |
  | 2  | '10'  | 0      | 1        | 0       | 0         |

SQLite is great, if and only if you use STRICT mode (and enable FK checks, if applicable). Otherwise, best of luck.

0: https://sqlite.org/datatype3.html

Re: It's 2026, Just Use Postgres

#336
post #122

Earlier quoted context omitted.

MySQL is definitely easier to use if you don’t want to ever have to think about DB maintenance; on the other hand, you’re giving up a TON of features that could make your queries enormously performant if your schema is designed around them - like BRIN indices, partial indices, way better partition management, etc. OTOH, if and only if you design your schema to exploit MySQL’s clustering index (like for 1:M, make the…

As someone who learned to think in MySQL, this is really true, at the time Postgres was a viable alternative too, only the tooling to get started reached me a little easier and quicker. The major thing I advocate for is don't pick a NOSQL database to avoid relational dbs, only to try and do a bunch of relational work in NOSQL that would have been trivial in an RBDMS. Postgres can even power graph query results which…

> The major thing I advocate for is don't pick a NOSQL database to avoid relational dbs, only to try and do a bunch of relational work in NOSQL that would have been trivial in an RBDMS.

It has always felt to me like devs will gravitate towards doing the opposite of what makes sense for their DB. If they have a Document DB, they'll try to use it relationally. If they have a relational database, they'll shove everything into a JSON column. Then in both cases, they complain that it's slow.

Re: It's 2026, Just Use Postgres

#337
post #331

Earlier quoted context omitted.

Ack, agreed. But there’s a better way to communicate than making blanket statements like “just use Postgres.” For example, you could say “Postgres is the default database,” etc. Don’t get me wrong—I’m a huge huge fan of Postgres. I’ve worked at Postgres companies for a decade, started a Postgres company, and now lead a Postgres service within a company! But I prefer being real rather than doing marketing hype and bla…

"Just" doesn't solely mean "only", this phrase is using it in the spirit of "just do it" - meaning "stop dawdling around". "Just use postgres" is the snappy phrase you're looking for.

Ack, makes sense. When making public posts that reach a large audience, it’s better to be clear with the messaging rather than risk it being blurry for even a subset of the audience, especially if that could lead to misguidance and affect their day-to-day work.

Re: It's 2026, Just Use Postgres

#338
post #272

Earlier quoted context omitted.

I hear there's a great tool for this, DB null or something like that.

MySQL actually has a BLACKHOLE storage engine designed specifically for universe-scale data storage for those who don't care about persistence.

It does have its use cases :)

Re: It's 2026, Just Use Postgres

#339
post #328
post #277

Earlier quoted context omitted.

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,…

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.

Re: It's 2026, Just Use Postgres

#340

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…

My opinion use the database that is the most compatible with the software you are currently using. Don't shoehorn in a database that is less compatible.
Post reply on HN