Benchmark report

Supabase thumbnail

Is supabase.com slow?

Page load times from 4 cities

Fast globally

Supabase responds quickly from all 4 test locations. Montreal was fastest at 41 ms; Amsterdam took 67 ms.

Fastest
41 ms
Montreal
Slowest
67 ms
Amsterdam
Successful requests
100%
4 locations

Response time around the world

Amsterdam 67ms typicalMontreal 41ms typicalSan Francisco 47ms typicalSingapore 49ms typical
  • CanadaMontreal
    41 ms
  • United StatesSan Francisco
    47 ms
  • SingaporeSingapore
    49 ms
  • NetherlandsAmsterdam
    67 ms

Even everywhere, with one slow tail in Amsterdam

The four cities stayed within 26 ms of one another, from 41 ms in Montreal to 67 ms in Amsterdam. Most of each request is the server preparing the page and the secure handshake; finding and reaching the server take almost nothing. Amsterdam is the one city with a rough tail: its typical time is fine, but single requests occasionally reached 354 ms.

Click the location to see each stage.

ConnectTLSServer waitDownload
NetherlandsAmsterdam
99 ms
Reaching the server
4 ms
Setting up security
16 ms
Waiting for the server: most of the time
69 ms
Receiving the response
15 ms
Total
99 ms

Each part is its own worst case, so they do not add up to the total. Why

Compare all locations

Click a city to see its stage-by-stage breakdown.

ConnectTLSServer waitDownload
NetherlandsAmsterdam
99 ms
Reaching the server
4 ms
Setting up security
16 ms
Waiting for the server: most of the time
69 ms
Receiving the response
15 ms
Total
99 ms
CanadaMontreal
66 ms
Reaching the server
5 ms
Setting up security
5 ms
Waiting for the server: most of the time
55 ms
Receiving the response
8 ms
Total
66 ms
United StatesSan Francisco
64 ms
Reaching the server
7 ms
Setting up security
10 ms
Waiting for the server: most of the time
48 ms
Receiving the response
12 ms
Total
64 ms
SingaporeSingapore
68 ms
Reaching the server
5 ms
Setting up security
10 ms
Waiting for the server: most of the time
50 ms
Receiving the response
11 ms
Total
68 ms

Each part is its own worst case, so they do not add up to the total. Why

Supabase still feels slow?

Check Supabase’s status page
Incidents with the platform or a project region are posted there. The homepage can be fine while a project is not.
This is not a project benchmark
Your project’s API, Auth, Realtime, Storage and Edge Functions live in the one region you chose when you created it. Distance to that region sets query time, and this page does not measure it.
The homepage is served by Vercel
supabase.com is cached at Vercel’s edge. A slow homepage points at Vercel’s edge for your location, not at Supabase’s database.

Response time over the last 8 days

Daily median of 5 requests per location, 5 September 2026 to 12 September 2026.
0100200 ms5 Sept12 SeptMumbai joined
Show the numbers
DayAmsterdamSan FranciscoMontrealSingaporeTokyoMumbai
5 September 2026108 ms69 ms55 ms79 ms66 ms—
6 September 2026104 ms67 ms60 ms94 ms59 ms—
7 September 202690 ms82 ms61 ms65 ms64 ms77 ms
8 September 202697 ms99 ms64 ms69 ms59 ms61 ms
9 September 202692 ms68 ms59 ms62 ms62 ms60 ms
10 September 202696 ms86 ms62 ms62 ms67 ms68 ms
11 September 202694 ms86 ms68 ms76 ms64 ms61 ms
12 September 2026113 ms82 ms56 ms72 ms67 ms62 ms

About this measurement

GET supabase.com · 20 requests per location · 1 March 2026

What we tested · Marketing website. The supabase.com marketing homepage, about 1.3 MB of HTML served from Vercel's cache, not from Supabase's own infrastructure.

How LatencyRadar measures response time →

Technical details

Doesn’t measure: Your project's API (PostgREST), Auth, Realtime, Storage or the management API. A control API surface is planned.

This page measures the supabase.com marketing homepage. It shows how quickly that HTML document arrived, before a browser loads scripts and other assets. The current homepage is served through Vercel. These numbers therefore do not describe a database query against a Supabase project, even though both requests carry the Supabase name.

The main results are from 1 March 2026 and four test locations. The history chart comes from later daily collection and has its own dates. Keep those periods separate when reading the page. In the March run, Montreal received the page in 41 ms typical and Amsterdam in 67 ms. Neither number predicts the time a user will wait for your application’s data.

Your project’s API, Auth, Realtime, Storage and Edge Functions need their own tests. The project region, request and configuration matter. We have not published a project measurement here, so a slow query needs investigation at your project endpoint rather than a comparison with this homepage.

Test locationTypical response timeSlower response timeRequests
Amsterdam67 ms99 ms20
Montreal41 ms66 ms20
San Francisco47 ms64 ms20
Singapore49 ms68 ms20

Typical: half of the requests finished within this time (technical: p50). Slower: 95% of requests finished within this time (technical: p95). Statistics

Request
GET supabase.com
Measured from
Amsterdam · Montreal · San Francisco · Singapore
Requests
80 requests · 20 from each of 4 cities · 1 March 2026
Timings taken
DNS, connect, TLS, waiting for the server, download

Supabase

https://supabase.com

Independent measurement by LatencyRadar. Not affiliated with Supabase. · How we measure (v1.3)

How fast is your Supabase project compared to this?

This test measured supabase.com itself, and your own database and API endpoints are a different story. Run a free speed test and find out where your users are really waiting.

Test my project

No account required · Takes about 30 seconds.

More benchmarks

All benchmarks →