What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.)
Don't get me wrong, Postgres has gotten a lot better since 2006. But most of the improvements have been in terms of more advanced query functionality, or optimizations for those advanced queries, or administration/operational features (e.g. replication, backups, security).
And hardware has gotten a lot better too. As TFA writes: it's 2026.
That being said, Oracle Database SE2 is $17,500 per core pair on x86, and Enterprise is $47,500 per core pair. XE has hard limits on size and limits on active CPUs. XE also does not get patches; if there is a critical vulnerability, it might be years before an upgrade is released.
Nobody would deploy Oracle Database for new systems. You only use this for sunk costs.
Postgres itself has a manual that is 1,500 pages. There is a LOT to learn to run it well, comparable to Oracle.
For simple things, SQLite is fine. I use it as my secrecy manager.
Postgres requires a lot of reading to do the fancy things.
They left much out, so many important things that I learned later, as I saw harmful things happening.
The very biggest thing is "nologging," the ability to commit certain transactions that are omitted from the recovery archived logs.
"You are destroying my standby database! Kyte is explicit that 'nologging' must never be used without the cooperation of the DBA! Why are you destroying the standby?"
It was SSIS, and they could never get it under control. ALTER SYSTEM FORCE LOGGING undid their ignorant presumption.
> XE has hard limits on size and limits on active CPUs
So no, it can't be used for free, you will pay for that with your time to keep it in usable state. We had to use it as our dev dbs because our customers used it and the size limit was a huge PITA. We mostly use MSSQL as dev db now because the other half of customers use that (we have to support both in the end) and it is way worse in every other way but there is no size limit for dev use.
Here is how I did it with SQLite, which was problematic with anything but basic types.
https://www.linuxjournal.com/content/sqlite-extraction-oracl...
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.
This is well within my budget, but it sounds like there might be room for improvements?