I'm wondering if it has the same scalability concerns - sticking everything in Postgres is fine at small-ish scale, but what happens when you outgrow Postgres, either because you have higher availability requirements (can't handle primary DB restarts) or because of the sheer volume of the workload?
Very few. But there's a difference between having control over the codebase where you can start to split up the monolith, adopt event-based architectures down the line, i.e. having a strategy on how to deal with the problem if and when it becomes a problem, versus tightly coupling your business logic to a vendor that is tightly coupled to Postgres and therefore your options on how to switch away will be extremely fragile and expensive at best and straight up impossible at worst.
Temporal can also run on Cassandra, which scales much larger than Postgres (if you put in enough effort). It can also be replicated across regions for high availability. It's already running some pretty huge use cases.
You're looking at the docs for "visibility". Visibility is a separate eventually-consistent data store off to the side that's used for certain queries so it can be scaled independently of the main data store, and indexed in fancier ways. The main data store for all the stateful and transactional stuff has always, and probably will always, support Cassandra. For visibility, the recommendation for high scalability is currently Elasticsearch.
Temporal may have properties that make it not a good fit for a particular use case, but scalability is really not one.
I'm wondering if it has the same scalability concerns - sticking everything in Postgres is fine at small-ish scale, but what happens when you outgrow Postgres, either because you have higher availability requirements (can't handle primary DB restarts) or because of the sheer volume of the workload?