There will be a series of articles on Linkedin https://www.linkedin.com/company/icegatetech in the near future, where we will tell you more about the technical side and show benchmarks.
Since the state is not stored in compute, fault tolerance is more likely to be transferred to S3. For compute fault tolerance (ingest + query), it is better to place 3 nodes in different AZ or different regions.
> I am wondering, why it took so long for something like this to happen for Postgres
We were thinking about adding PostgreSQL support to Vitess several years ago. However, we realized that it would be more efficient if each tool was focused on a specific task.
> High concurrency can become a problem due to the 1 process per connection architecture.
If I understand correctly what you mean, then this is no longer a problem. You will simply need to use a connection pool, such as Odyssey or PgBouncer. Even SPQR has its own pool of connections for each shard.
PgBouncer just pools the connection, but each connection still needs its own process in PostgreSQL itself. Each query blocks the whole process. That limits the amount of queries that can run in parallel/concurrently to the amount of connections. Long-running queries can easily clog up everything. No tool can fix this, you need to be aware of it and consider it in your design.
It's not really about the processes. Even if each query ran on a thread within a process, or some form of greenthreading were in use, there are I/O constraints and locking to consider.
What I talk about is blocking of limited resources. Processes/connections are expensive and therefore you want/have to limit the max amount of them. Each query/transaction requires its own process and blocks it for everyone else until it is done.
I/O or compute constraints are another issue, if your CPU or disc is already saturated you get probably no additional benefit.
But if you wait for something (locks, I/O) the connection/process can't do other things. High latency between app/database and long running transactions can also use up your available processes, even if they don't consume a lot of CPU or I/O or fight for the same locks.
Lock contention is its own problem, but makes the blocking of processes/connections worse.
What I meant is, even if processes had no cost, you will probably bottleneck on the I/O. So it doesn't matter a lot how many Postgres connections you have.
Sure, it’s not the most common problem to experience, just something that’s useful to know once you have more and more clients. It did happen to me, all connections used up for long running transactions (for multiple reasons) and then nothing else was able to run, CPU and I/O nearly idling at <5%, no significant lock contention.
Wow, that's awesome! Do you have any public benchmarks?