> > we are evaluating PostgreSQL for our productions,
> > for a system with 1000 updates per second,
> > 1000 inserts per sec,
> > ~1000 deletes per second1
> That adds up to 3000 transactions per second, but this:
>
> > 250,000 transactions per day
>
> only results in about 3 transactions per second.
>
> But even 3000 transactions per second can be sustained with good hardware (especially fast SSDs) without problems
> as long as there are at least some "quiet" times where autovacuum can catch up with the updates and deletes.
>
> > we are looking for “active-active (r/w) (r/w)” , “active(r/w) -active(read) “
> > and “active(r/w) stand-by” high availability solution,
>
> Postgres only supports read-only replicas where you can distribute the load of SELECT queries.
> It does not offer a solution to distribute write load over multiple nodes.
i can recommend BDR extension which comes at a prices if you need a proper Master-Master cluster setup. But you could also setup a couple of standalone postgresql
instances which replicate the written data via logical replication to a central database. this way you can scale IO load and have many master nodes for redundancy.
if this approach works for you depends on your use cases.
> > what High availability solutions ( PG internal or 3rd party) are used successfully, keeping up with the similar rates? double of those rates?
>
> A master/slave system (including multiples slaves) can be set up without the need of 3rd party tools.
>
> If you want to distribute read requests across slaves you will need a 3rd part tool, e.g. pgPool or pgBouncer.
>
> To sustain a high write throughput on a single node you need a fast I/O system.
> Typically this is done with several really fast SSDs or NVMe disks nowadays.
>
> The more CPUs you have, the better.
Cheers, stephan