Benchmark report
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
Montreal
41 msSan Francisco
47 msSingapore
49 msAmsterdam
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.
Amsterdam99 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 locationsHide the comparison
Click a city to see its stage-by-stage breakdown.
Amsterdam99 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
Montreal66 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
San Francisco64 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
Singapore68 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
Show the numbers
| Day | Amsterdam | San Francisco | Montreal | Singapore | Tokyo | Mumbai |
|---|---|---|---|---|---|---|
| 5 September 2026 | 108 ms | 69 ms | 55 ms | 79 ms | 66 ms | — |
| 6 September 2026 | 104 ms | 67 ms | 60 ms | 94 ms | 59 ms | — |
| 7 September 2026 | 90 ms | 82 ms | 61 ms | 65 ms | 64 ms | 77 ms |
| 8 September 2026 | 97 ms | 99 ms | 64 ms | 69 ms | 59 ms | 61 ms |
| 9 September 2026 | 92 ms | 68 ms | 59 ms | 62 ms | 62 ms | 60 ms |
| 10 September 2026 | 96 ms | 86 ms | 62 ms | 62 ms | 67 ms | 68 ms |
| 11 September 2026 | 94 ms | 86 ms | 68 ms | 76 ms | 64 ms | 61 ms |
| 12 September 2026 | 113 ms | 82 ms | 56 ms | 72 ms | 67 ms | 62 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 location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 67 ms | 99 ms | 20 |
| Montreal | 41 ms | 66 ms | 20 |
| San Francisco | 47 ms | 64 ms | 20 |
| Singapore | 49 ms | 68 ms | 20 |
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.
No account required · Takes about 30 seconds.