Our HA cloud offerings, outlined on fusionauth.io/pricing are aimed at the following use cases:

Large production needs Reliability required Higher monthly active users

Development doesn't typically fall into any of these :).

With HA you get an SLA, a custom URL (auth.example.com instead of example.fusionauth.io) and an architecture capable of handling more users.

You might want a custom URL to test your DNS/cookie config. Or you might want to load test (please don't load test with a basic cloud deployment, it won't tell you anything about production performanc).

If you want to derisk this early, in both these cases, we recommend standing up a temporary HA instance, applying your configuration, testing, and then tearing down the HA instance.

I think you are looking for kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

Here's how to run configure Kickstart to run when you are using docker: https://fusionauth.io/docs/v1/tech/installation-guide/docker/#kickstart

I'm not sure how you are starting your containers, but I imagine you could create and make a kickstart file available in other deployment environments also.

Hmmm.

Here's an issue tracking digitalocean database issues--some managed databases don't work right now: https://github.com/FusionAuth/fusionauth-issues/issues/95

The number of open connections should be around 10. I believe that is per fusionauth instance.

What were the specs you were seeing the issues with?

what version of fusionauth how many pods running it what version of postgres what size were the pods (in terms of memory and CPU) what are the replication steps to trigger the negative performance impacts

We've seen FusionAuth (the application) run in 64M of RAM. You can specify the maximum amount of memory used in the configuration file or via environment args. More here: https://fusionauth.io/docs/v1/tech/reference/configuration

Note that if you don't need advanced search functionality, you can use the database search engine and avoid running elasticsearch: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines talks about how to switch between them. That may eliminate some of the memory pressure if you were running elastic.

You could look at kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

Kickstart only works if the other devs' fusionauth instances are going to be starting from scratch.

Otherwise you might want to vote for https://github.com/FusionAuth/fusionauth-issues/issues/560

You could look at kickstart: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

This would be a good fit if the other devs fusionauth instances are going to be starting from scratch.

Otherwise you might want to vote for https://github.com/FusionAuth/fusionauth-issues/issues/560 which talks about a different path forward (which is as of now unimplemented).

Note that with version 1.16.x, elastic search is no longer required to run FusionAuth. More here about how you might make the choice: https://fusionauth.io/community/forum/topic/67/what-is-the-advantage-of-using-elasticsearch-as-the-search-engine