> I don’t agree with the blanket advice of “just use Postgres.”

I take it as meaning use Postgres until there's a reason not to. ie build for the scale / growth rate you have not "how will this handle the 100 million users I dream of." A simpler tech stack will be simpler to iterate on.

▲

pclmulqdq 4 hours ago | parent | next [-]

Postgres on modern hardware can likely service 100 million users unless you are doing something data intensive with them.

You can get a few hundred TB of flash in one box these days. You need to average over 1 MB of database data per user to get over 100 TB with only 100 million users. Even then, you can mostly just shard your DB.

▲

direwolf20 3 hours ago | parent [-]

What about throughput? How many times can postgres commit per second on NVMe flash?

▲

pclmulqdq 3 hours ago | parent [-]

You can do about 100k commits per second, but this also partly depends on the CPU you attach to it. It also varies with how complicated the queries are.

With 100 million DAU, you're often going to have problems with this rate unless you batch your commits. With 100 million user accounts (or MAU), you may be fine.

	▲	direwolf20 2 hours ago \| parent [-]
		That should be enough for most apps.

▲

quotemstr 5 hours ago | parent | prev [-]

Yes. That's a good framing. PostgreSQL is a good default for online LOB-y things. There are all sorts of reasons to use something other than PostgreSQL, but raw performance at scale becomes such a reason later than you think.

Cloud providers will rent you enormous beasts of machines that, while expensive, will remain cheaper than rewriting for a migration for a long time.