Performance Philosophy

Actual response times (P95)

Tested where: Home WiFi (worst case), production servers (best case).
Methodology: P95 (95th percentile) over 1,000 requests.
Honesty: If it's slow, we say it's slow. Supabase is 848ms because their API is in a different region. We can't fix that.

Performance is architecture, not optimization

You can't optimize your way out of bad architecture. Here's what actually makes us fast:

Redis Mega-Pipeline (Upstash):
├─ 1. Get API Key & Tier
├─ 2. Get Quota Status
├─ 3. Check Rate Limits
└─ Total time: 186ms (1 round trip)

Before Optimization:
├─ 4 separate Redis calls
└─ Total time: 707ms (4 round trips)

Database (Supabase):
├─ Only hit on cache MISS
└─ < 1% of requests touch DB

import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

// This is crypto (5-10ms), not an API call:
const url = await getSignedUrl(s3Client, putCommand, {
  expiresIn: 3600
});

// Compare to Vercel Blob (220ms):
const { url } = await put('file.jpg', file, {
  access: 'public',
  token: vercelToken // Requires API call to Vercel
});

// Return response immediately (15ms)
return res.json({ uploadUrl, publicUrl });

// Queue background jobs (non-blocking, 0ms to user)
queueMetricsUpdate({
  userId,
  operation: 'signed-url',
  success: true
}).catch(console.error); // Fire and forget

// User doesn't wait for this
// Response time: 15ms, not 15ms + 50ms

// BAD: Sequential (100 files × 5ms = 500ms)
for (const file of files) {
  await generateSignedUrl(file); // Blocks!
}

// GOOD: Parallel (100 files in ~50ms total)
const urls = await Promise.all(
  files.map(file => generateSignedUrl(file))
);

// 10× faster with same code quality

Where we're slow (and why)

Supabase signed URLs: 848ms-1161ms
Why: Their API is in a different region + external HTTP call + they generate URLs server-side.
Fix: None. This is Supabase's API latency, not ours. We cache aggressively to help.

Cold cache requests: 400-600ms
Why: First request has to hit database, validate everything, populate caches.
Fix: Warm caches (5min TTL), so 95% of requests are fast.

We're honest about this. If something is slow, we say it's slow and explain why. We don't hide behind "optimizing" or "coming soon."

How we measure performance

Every request logs timing:

{
  "requestId": "r2_1234567890",
  "timing": {
    "total": 186,
    "pipeline": 170,
    "cryptoSign": 12,
    "overhead": 4
  },
  "cacheHits": {
    "pipeline": true,
    "db": false
  }
}

We track:

• P50 (median) — Half of requests are faster than this
• P95 (95th percentile) — 95% of requests are faster than this (what we publish)
• P99 (99th percentile) — 99% of requests are faster (outliers included)
• Max — Worst case (usually cold cache + slow provider)

We publish P95 because it's honest. P50 looks better but hides the slow requests. P99 includes weird outliers (network hiccups, cold starts). P95 is what most users experience.

Performance under load

We've tested up to 1,000 concurrent requests (simulated load test):

Why it stays fast:

• Cloudflare auto-scales — More requests = more Workers spawned automatically
• Redis is fast — 10,000+ ops/sec on Upstash free tier
• No database bottleneck — 99.5% cache hit rate = 0.5% hits DB
• Pure crypto scales — Signing URLs is CPU-bound, Workers have plenty of CPU

At 10,000 concurrent requests, we'd probably hit Supabase connection limits (~100 concurrent connections). Solution: Connection pooling (PgBouncer) + more aggressive caching. We'll cross that bridge when we get there.

What we won't optimize

1. Supabase API latency
Not our problem. Their API is in their data center. We can cache, but we can't make their servers faster.

2. Your internet connection
If uploading a 10MB file takes 30 seconds, that's your bandwidth, not our API. We generated the signed URL in 15ms. The other 29.985 seconds is between you and R2.

3. Storage provider performance
R2 is fast (~50-200ms uploads). Vercel Blob is slower (~200-400ms). Supabase Storage varies (100-500ms). We don't control this—you choose the provider.

Performance roadmap (what we're working on)

• HTTP/3 (QUIC) everywhere
  Already supported by Cloudflare. Faster on mobile/unreliable connections. 0-RTT connection resumption.
• Aggressive prefetching
  SDK could prefetch signed URLs while user is selecting files. By the time they click "Upload," URL is ready.
• Regional failover
  If Supabase US-East is slow, try EU-West automatically. Adds complexity but could save 100-200ms.
• Batch optimizations
  Currently processing 100 files in ~500ms. Could we do 1000 in 2 seconds? Maybe with smarter parallelization.

But honestly: 5-15ms for R2 is already fast enough. We're not going to obsess over shaving 2ms when the real bottleneck is network latency or file size.

The philosophy in one sentence

Don't put files in the critical path, cache everything you can, measure what you can't, and be honest about what you can't control.

That's it. No "blazing fast," no "lightning speed," no meaningless comparisons. Just real numbers, real architecture decisions, and real honesty about tradeoffs.