This is a not great start. I assume it refers to MyISAM which has not been relevant for over a decade at this point. InnoDB made different design than PG decisions and was (and perhaps still is) faster at point lookups.

https://github.com/seanwevans/pg_gpt2

https://github.com/seanwevans/pg_shell

https://github.com/seanwevans/pg_os

NVMe drives + Litestream + object storage(S3/R2..). sqlite simplifies things for the entire long tail of apps/services that aren't the Ubers and AirBNBs of the world.

MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues.

That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned.

For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.

* No need for a connection pool, while many use cases with Postgres require PgBouncer and Co.

* Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations.

* No need to VACUUM, which can be a hard problem (it was, the last time I used Postgres).

For full text search, I once worked on a project that considered several alternatives for this, including Postgres. Manticore Search was finally chosen because it was more performant, with better search results.

0: https://www.postgresql.org/docs/19/ddl-property-graphs.html

1: https://www.postgresql.org/docs/19/queries-graph.html

multiple processes connected to it.

No deamon. Single file per DB. Less configuration overhead.

The relational model and sql force us to simplify our data models too much by eliminating relationships or just not dealing with them.

Think about a nested json blob from some web service api and storing it in SQL in normalized tables. No one is going to do that. Everything just becomes a denormalized mess and everything is hacked around it.

Instead of modeling things in the proper way, most of the world's data is modeled in a way so that we don't have join explosions in sql queries because they look scary. Data pipelines become these scary batch transformations where data is dumped somewhere else without anyway to trace back where it came from.

I encounter so many end-user applications and systems where you wonder: "why couldn't they allow a list of items here instead of a single box" or "why can't this reference this other thing".

Looking down the list it is pretty easy to go: Yes, postgres can be used instead of that for extremely basic use cases, but it all goes out the window you actually need any of the power of these other tools.

* As a message queue: Only if your required features are very basic, like if you need cluster communication and run your own coordination protocol on top.

* High Volume Time Series: TimeScale works, but composes badly with other workloads on the same DB server ( from an operational perspective at scale )

* Vector Database: The same issues as with TimeScale.. PgVector for example lives in its own seperate "world" and the query planner sees it as a very opaque thing. Forget about adding vector storage to an existing high volume db, that must server other complex queries.. PGVector will either trash your caches, or take over your cpu so that workloads that used to work fine stall. This is IMO not a pgvector problem itself ( Kudos to those guys ) but rather that postgresql extension apis are not very good at exposing custom costs and tradeoffs to the system as a whole.

* Raw Data: Works for small files... why anyone would want to store large amounts of data in it would be a mystery, where it shines is accessing LOTS of small files where internal caching etc help a lot compared to raw filesystem access ( also a bit dependent on the filesystem and its tuning though )

* Microservice: If your service is ONLY exposing json data from some database model, then it should not exist at all IMO. Create a view and be done with it.