Selfhosted

Caching and/or DB hosted in a region closer to your users, or perhaps even in their browsers (if the data is not sensitive).

Naturally, if you use secondary DBs you will have to deal with data replication.

Is hitting a real RDBMS absolutely necessary? Consider producing precomputed data sets which can be cached as JSON or with other non-dynamic, storage-only methods. A distributed CDN can be much cheaper than a VPS.

Also consider if Postgres is really your best option. You could use various other database engines that can optimize certain factors: some could be cheaper, or make replication easier etc.

For example (just one example out of many, may not even be applicable to you) using CouchDB on server and PouchDB on browser would make data replication and propagation extremely easy, and it's also a very efficient and scalable query engine.

Your app and DB should be deployed together in the same datacenter to minimize latency between app and DB. Nothing should be hitting your DB besides your app and any etl tools if applicable. So latency to your DB shouldn't be an issue.

If you need to add redundancy with a deployment in another region you should consider having separate environments between regions with totally separate data which allows you to better manage data protection/export regulations appropriately.

If that doesn't work you'll need a multi region database, a vendor with support for that such as aws rds would be the sanest method but you can always hack it yourself.

There's other options but those require an architecture designed to be heavily distributed and that depends a lot on the nature of your application and you'd ideally hire an architect experienced in such deployments.

You may have one psql server per region and then use Bucardo to synchronize them.

I've never done this in production, so take my advice with a grain of salt.

Who are your users? Where are they located?