When writing, it needs to fsync to ensure ACID
If that's the problem, we should say "Postgres isn't slow, you're just on ACID".
I think I'm a bit of an outlier here on that k never really understood why durability requires fsync. It doesn't help you if the storage dies. If durable storage is important to you, then isn't the only solution to synchronously replicate to a quorum of machines at which point an fsync isn't that relevant? What am I missing?
"Storage dies" is a broad set of causes. If there is power loss or a server crash due to a multitude of reasons, you want committed transactions to actually be committed.
Having replicas doesn't change the problem. If the orchestrator requires at least N replicas to be done committing the data, you'll have to wait for fsync in N of them.
Without fsync, the data anywhere could be sitting on a write back cache in memory instead of being flushed to the disk.
fsync itself doesn't guarantee your data will survive, so it is not essential.
Other ideas to try: you have N replicas, and you ask them to do in-memory commit. M server simultanious death is probably more unlikely compared to single server storage system death.
Yes, there are various levers you can pull and it's rare to find a solution that will be optimal for every use case. But, in general, sticking with the most mainstream solution is usually better than going off-piste unless you are very certain that it doesn't cover your niche.