diff --git a/apps/www/_blog/2023-08-11-supavisor-1-million.mdx b/apps/www/_blog/2023-08-11-supavisor-1-million.mdx index 8d17ae98f59..d357806d44a 100644 --- a/apps/www/_blog/2023-08-11-supavisor-1-million.mdx +++ b/apps/www/_blog/2023-08-11-supavisor-1-million.mdx @@ -26,7 +26,7 @@ Supavisor is a scalable, cloud-native Postgres connection pooler. It has been de diagram of supavisor architecture Supavisor will enable us to build some exciting new features for your Postgres cluster: @@ -56,7 +56,7 @@ In the first test, we set up a single ARM 16-core Supavisor instance on Ubuntu 2 diagram supavisor 1 instance dark We wanted to assess the capacity of a single Supavisor instance. We achieved: @@ -67,18 +67,18 @@ We wanted to assess the capacity of a single Supavisor instance. We achieved: diagram supavisor 1 instance dark With this setup the database is the bottleneck - 20,000 QPS was the maximum this instance could handle. Increasing QPS would have been possible with a larger instance or read-replicas, but we wanted to focus on the scalability of Supavisor's connection limit (not Postgres's). Since Supavisor is built with multi-tenancy, addition of read-replicas is as easy as sending a single post request.
- chart connections baseline light - chart connections baseline dark The system showed no signs of instability or performance degradation. QPS remained constant at 20,000, proving that an increased number of connections doesn't negatively affect Supavisor's overall performance (this is generally expected from a [BEAM-based language](https://stressgrid.com/blog/webserver_benchmark/) like Elixir).
- chart connections vertical scaling light - chart connections vertical scaling dark - cpu load vertical scaling light - cpu load vertical scaling dark In the Supavisor architecture, only a single node holds direct connections to each database instance. When you add more Postgres databases or read-replicas, Supavisor spreads the connections to the replicas. Every Supavisor instance can accept incoming connections and either execute queries themselves (if they directly connected) or relay to another node (if not). @@ -143,12 +143,12 @@ This setup successfully handled: - **20,000 QPS** or **1.2 million queries per minute.** Each connection executed a `select` query once every 50 seconds.
- chart connections 1 million light - chart connections 1 million dark - cpu load 1 million light - cpu load 1 million dark ### Supavisor's impact on query duration @@ -205,12 +205,12 @@ We found with Supavisor median query duration was less than 2ms. And this includ | p99 | 23ms |
- chart query duration for 5k qps light - chart query duration for 5k qps dark - chart query duration for 20k qps light - chart query duration for 20k qps dark _Supavisor architecture_ @@ -268,7 +268,7 @@ In the future, you connect to a distinct multi-tenant Supavisor cluster through diagram supavisor 1 instance dark We ran 5,000 queries per second for each configuration, this time experimenting with `insert` query. To make the expreriment more realistic, we enabled the PostGIS extension to store coordinates: @@ -305,13 +305,13 @@ We observed an additional 2ms required each query to be executed on the Supaviso | p99 | 5ms | 3ms |
- chart query duration for 5k qps inserts with supavisor light - chart query duration for 5k qps inserts with supavisor dark
- chart query duration for 5k qps inserts with pgbouncer light -