From 25bbab48ff9e7b25e8e022e18d3a641f88f8edbf Mon Sep 17 00:00:00 2001 From: Francesco Sansalvadore Date: Fri, 11 Aug 2023 18:04:40 +0200 Subject: [PATCH] fix prettier --- apps/www/_blog/2023-08-11-supavisor-1-million.mdx | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) 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 3f9fb69a6e6..f947f590638 100644 --- a/apps/www/_blog/2023-08-11-supavisor-1-million.mdx +++ b/apps/www/_blog/2023-08-11-supavisor-1-million.mdx @@ -253,8 +253,7 @@ The scalability can be further enhanced by adding more databases (or read-replic We compared our current PgBouncer setup with the new Supavisor setup to assess any impact on query duration. - -*Current architecture* +_Current architecture_ Currently, every Supabase project comes with its own PgBouncer server running on the same instance as the Postgres database to ensure that the latency is as low as possible. But this setup comes with a trade-off: it uses the same compute resources as your database. @@ -263,7 +262,7 @@ Currently, every Supabase project comes with its own PgBouncer server running on src="/images/blog/launch-week-8/day-5/supavisor-tests--pgbouncer.svg" /> -*Supavisor architecture* +_Supavisor architecture_ In the future, you connect to a distinct multi-tenant Supavisor cluster through a load-balancer. The Supavisor cluster maintains a connection pool to your database. In this case the pooler doesn't consume additional CPU and RAM resources on the database server, but it does involve extra network latency.