Benchmarks
Measured latency and throughput of the live Sovaria platform: which server, how we tested, single-request latency per operation, and what we are improving next.
These numbers are measured on the production platform, not estimated. We publish the server they ran on and how we ran them, and we update this page when the numbers change. Where we are behind our own targets, it says so.
#Test setup
| Server | One AWS EC2 t3.medium in Mumbai (ap-south-1): 2 burstable vCPUs (Intel Xeon Platinum 8259CL, 2.5 GHz), 4 GB RAM. It runs the whole core: edge (nginx 1.30), gateway (2 copies), every engine, Redis and monitoring. |
| Project database | A dedicated PostgreSQL 16 container for the test project (Pro plan) on a separate database worker VM in the same region; network round trip 0.2 ms. |
| Client | From the same region (the host itself, over HTTPS through the public edge, keep-alive), so the numbers show the platform rather than an internet link. From India over home broadband add your own round trip (about 40 ms from Bengaluru). |
| Data | A 2,000-row products table with row-level security forced and a public-read policy, a document collection and a public storage file, read with the project's anon key, like a real app's visitors. |
| Method | Each operation 60 times one after another (first 5 discarded as warm-up); p50 / p95 / p99. Tools: scripts/load/ramp.py, h2load for pages. |
#Single-request latency
One request at a time, end to end: TLS, edge, gateway (auth, plan limits, WAF, policies), engine, database and back.
| Operation | p50 | p95 | p99 | Our target (p95) |
|---|---|---|---|---|
| Health check (edge + gateway) | 4.7 ms | 6.2 ms | 11.5 ms | ≤ 50 ms |
| SQL: read one row by primary key, anon key, row-level security | 21.7 ms | 41.3 ms | 127 ms | ≤ 100 ms |
| SQL: 20 rows of a category by price (indexed) | 21.8 ms | 50.9 ms | 132 ms | ≤ 100 ms |
| SQL as a signed-in team member | 20.5 ms | 31.8 ms | 63 ms | ≤ 150 ms |
| Documents: query 10 documents | 24.9 ms | 34.9 ms | 74 ms | ≤ 100 ms |
| Auth: who am I (JWT) | 21.5 ms | 50.8 ms | 65 ms | ≤ 150 ms |
| Auth: public sign-in config | 18.4 ms | 27.5 ms | 49 ms | ≤ 100 ms |
| Functions: list | 24.2 ms | 71.7 ms | 142 ms | ≤ 100 ms |
| Storage: list buckets | 62.0 ms | 92.5 ms | 120 ms | ≤ 100 ms |
| Storage: download a small public file | 91.7 ms | 132 ms | 173 ms | ≤ 500 ms |
#Website and console pages
Pages are served from an edge cache on the same server (pages held 10 s, hashed assets 1 h). Fifty thousand page requests in flight at once, HTTP/2, 500 connections:
| Page | Requests in flight | Served | Time to serve all | Pages per second |
|---|---|---|---|---|
Console (console.sovaria.in) | 50,000 | 50,000 (100 %) | 4.3 s | ~11,700 |
Docs page, 19 KB (sovaria.in/docs) | 50,000 | 50,000 (100 %) | 5.0 s | ~10,100 (190 MB/s) |
#Data throughput under load
Single requests are fast; concurrency is where this server is small. Under sustained concurrent data traffic the 2 vCPUs reach 100 % at roughly 80 data requests per second, and latency then grows with the queue. Every request is still answered or refused cleanly: in a 50,000-request burst, 8 failed with a server error, and plan limits answered 429 as designed (Pro: 6,000 data requests per minute per project).
- Where the CPU goes today: about 12 ms of gateway work and up to 11 ms of SQL-engine work per request, and around 50 Redis operations. We are cutting each of these; this page will show the new numbers.
- More capacity comes from more cores: the gateway and engines already run as several copies behind the edge, so a larger or second server multiplies throughput.
- Realtime (WebSocket) benchmarks against published industry figures are in progress and will be added here.
#Run it yourself
# Your project URL and anon key from Connect
for i in $(seq 1 20); do
curl -s -o /dev/null -w "%{time_total}\n" -X POST "$URL/api/v1/sql/query" \
-H "Authorization: Bearer $ANON_KEY" -H 'Content-Type: application/json' \
-d '{"sql":"select id, name from products where id = $1","params":[42]}'
done | sort -n | awk '{a[NR]=$1} END {print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'Run load tests against your own project only, and stay inside your plan's limits (Plans, usage and limits); requests above them are answered with 429.