This is a great question. Today there isn’t a prescriptive guide to sizing PosgreSQL for Temporal, so the answer will ultimately be determined by conducting performance tests that simulate your anticipated workload.
Temporal relies on the underlying data store to persist the incremental state of your workflows, which generally makes it a write-heavy workload for a database engine. The volume of database write operations directly correlates to the workflow complexity and concurrency.
Temporal’s Production Deployment guide covers the broader considerations of configuring Temporal and the underlying data store. That page includes references to performance testing.
This post details a team’s evaluation and benchmarking of PostgreSQL and Temporal. This article may give you a good baseline of DB server size and scale of workflows.
An important, but more advanced consideration is Sharding. To enable database scalability, Temporal provides Sharding configuration for the History service to tune parallelism. Sharding today can only be set at the time of cluster setup, so forecasting the load and conducting testing will be important.
Mikhail Shilkov published a blog post describing the implications of Sharding configuration.