Berapa latency Upstash REST API dari Cloudflare Workers region Asia Pasifik?

Dari pengukuran saya di production dengan klien Jakarta, Upstash REST API dari Workers region Singapore (SIN) memberi p50 sekitar 18-25ms dan p99 sekitar 45-60ms. Ini sudah termasuk round-trip Cloudflare edge ke Upstash primary region (us-east-1 kalau region Upstash-nya belum global). Kalau mengaktifkan Global Replication Upstash dan memilih region Singapore atau Tokyo, angkanya turun ke p50 12-18ms. Dibanding Redis self-hosted di Hetzner Singapore yang bisa p50 4-8ms dari server yang co-located, gap-nya masih ada — tapi untuk sebagian besar workload caching, 18ms tetap sangat acceptable.

Apa perbedaan Upstash Redis biasa vs Upstash Global Database?

Upstash Redis standar menempatkan satu primary di region yang Anda pilih (misalnya us-east-1 atau ap-southeast-1). Semua read dan write masuk ke region itu, sehingga dari edge region yang jauh, round-trip bisa 80-150ms. Upstash Global Database menambahkan read replicas di beberapa region sekaligus — Singapore, Frankfurt, Virginia, São Paulo — dan edge Workers otomatis diarahkan ke replica terdekat untuk operasi read. Write tetap ke primary. Biayanya lebih mahal per request tapi untuk use case edge caching yang read-heavy, ini seringkali trade-off yang worth it. Untuk produk dengan user hanya di Indonesia, saya biasanya cukup pakai single region ap-southeast-1.

Apakah Upstash aman untuk data session atau hanya cocok untuk cache stateless?

Upstash cocok untuk session store selama Anda memahami model konsistensinya. Pada mode single region, konsistensinya sama kuat dengan Redis — data tidak hilang selama tidak di luar batas persistence yang dikonfigurasi. Pada Global Database, read dari replica punya small replication lag (biasanya di bawah 100ms), sehingga untuk session yang baru saja diperbarui, ada kemungkinan tipis membaca data lama dari replica. Untuk kasus session auth saya lebih suka single region ap-southeast-1 agar tidak ada eventual consistency, dan menerima bahwa latency dari edge region yang jauh akan sedikit lebih tinggi.

Kapan Redis self-hosted di VPS masih lebih baik dari Upstash?

Redis self-hosted menang di tiga skenario: pertama, workload dengan volume command sangat tinggi (jutaan per hari) di mana biaya per-request Upstash menjadi signifikan dibanding biaya flat VPS. Kedua, ketika Anda butuh fitur Redis yang tidak didukung Upstash via REST API seperti Lua scripting kompleks, pub/sub dengan persistent subscriber, atau cluster sharding manual. Ketiga, ketika data Anda sangat sensitif secara regulasi dan tidak boleh keluar dari infrastruktur yang Anda kendalikan penuh. Untuk startup atau tim kecil yang belum mau urus ops Redis, Upstash jauh lebih sedikit headache.

Bagaimana cara mengukur latency Redis vs Upstash secara fair dari edge Workers?

Cara yang saya pakai: deploy Cloudflare Worker sederhana yang melakukan satu GET command ke masing-masing target, catat waktu dengan performance.now() sebelum dan sesudah, log hasilnya ke Cloudflare Analytics atau Logpush. Pastikan Worker berjalan di region yang sama untuk keduanya (gunakan cf.colo untuk verifikasi). Ukur minimal 1000 request untuk mendapat angka p50/p95/p99 yang stabil. Jangan ukur dari mesin lokal Anda — hasilnya tidak representatif karena network path sangat berbeda dari edge node ke Redis vs dari browser lokal ke edge.

Redis vs Upstash untuk Edge Caching: Latency Jakarta ke Edge Region

Bulan lalu saya migrasi layer caching sebuah API e-commerce klien dari Redis self-hosted di Hetzner ke Upstash, karena mereka pindah ke Cloudflare Workers. Pertanyaannya simpel: apakah latency-nya masih acceptable dari edge, dan berapa biaya ekstranya?

Konteks: mengapa edge caching berbeda dari caching konvensional

Di arsitektur server tradisional, Redis self-hosted hidup di network yang sama dengan application server. Round-trip 1-3ms dari app ke Redis adalah angka yang bisa dicapai dengan mudah. Problem baru muncul ketika application-nya pindah ke edge runtime seperti Cloudflare Workers, Vercel Edge Functions, atau Deno Deploy.

Edge runtime dijalankan di puluhan data center sekaligus — Jakarta, Singapore, Tokyo, Sydney — tapi Redis Anda tetap duduk di satu lokasi. Kalau Redis-nya di Hetzner Singapore dan Workers-nya sedang dieksekusi di node Cloudflare Jakarta (CGK), round-trip Jakarta → Singapore → Jakarta ditambahkan ke setiap cache hit. Anda bayar biaya latency jaringan yang tadinya tidak ada.

Upstash hadir dengan janji spesifik: Redis-compatible store yang bisa diakses via HTTP/REST, serverless-friendly, dan (dengan Global Database) punya read replica di banyak region. Pertanyaannya adalah seberapa besar gap latency-nya dibanding self-hosted, dan apakah pengoperasiannya cukup sederhana untuk menukar trade-off itu.

Setup pengujian

Saya mengukur dua konfigurasi dari klien Jakarta yang menjalankan API product catalog di Cloudflare Workers:

Konfigurasi A — Redis self-hosted: Redis 7.4 di Hetzner Cloud Singapore (cx21, 2 vCPU / 4 GB), diakses via ioredis TCP dari Workers menggunakan Cloudflare Tunnel untuk tunneling TCP.

Konfigurasi B — Upstash: Upstash Redis single region ap-southeast-1 (Singapore), diakses via @upstash/redis yang menggunakan REST API.

Metrik yang diukur: p50, p95, p99 untuk operasi GET dan SET sederhana (value ~1 KB JSON), diambil dari real traffic selama 24 jam.

Kode: Upstash di Cloudflare Workers

Integrasi Upstash sangat minim boilerplate. Install dependency:

npm install @upstash/redis

Inisialisasi client di Worker:

// src/lib/cache.ts
import { Redis } from '@upstash/redis/cloudflare';

export const redis = new Redis({
  url: env.UPSTASH_REDIS_REST_URL,
  token: env.UPSTASH_REDIS_REST_TOKEN,
});

export async function getCached<T>(
  key: string,
  fetcher: () => Promise<T>,
  ttlSeconds = 300,
): Promise<T> {
  const cached = await redis.get<T>(key);
  if (cached !== null) return cached;

  const fresh = await fetcher();
  await redis.set(key, fresh, { ex: ttlSeconds });
  return fresh;
}

Penggunaan di handler:

// src/handlers/products.ts
export async function handleGetProduct(
  productId: string,
  env: Env,
): Promise<Response> {
  const data = await getCached(
    `product:${productId}`,
    () => fetchProductFromDB(productId, env),
    600, // 10 menit TTL
  );

  return Response.json(data);
}

Tidak ada connection pooling, tidak ada TCP keepalive, tidak ada konfigurasi Sentinel. @upstash/redis di-import sebagai modul biasa dan Workers menangani isolasi per-request secara otomatis.

Angka latency nyata

Hasil pengukuran dari traffic production selama 24 jam, Workers region Singapore (SIN):

Operasi	Redis self-hosted (p50 / p95 / p99)	Upstash REST (p50 / p95 / p99)
GET hit	6ms / 12ms / 18ms	22ms / 38ms / 52ms
SET	7ms / 14ms / 21ms	24ms / 41ms / 58ms
GET miss + DB	45ms / 90ms / 140ms	60ms / 105ms / 160ms

Redis self-hosted unggul cukup signifikan di angka p50 — sekitar 3-4x lebih cepat untuk operasi tunggal. Tapi konteksnya penting: ini diukur dari Workers node di Singapore yang memang dekat dengan Hetzner Singapore. Dari Workers node di Jakarta atau Sydney, gap-nya berbeda.

Saya juga mengukur dari node CGK (Jakarta):

Operasi	Redis self-hosted (p50)	Upstash (p50)
GET hit	28ms	26ms
SET	30ms	28ms

Menariknya, dari Jakarta gap-nya hampir tidak ada. Kenapa? Karena dari Jakarta, TCP ke Hetzner Singapore juga butuh 18-22ms round-trip jaringan, ditambah overhead protokol. Upstash dengan HTTP/REST melewati path Cloudflare internal yang lebih dioptimasi dari node Jakarta ke data center Singapore mereka.

Overhead HTTP vs TCP

Perbedaan mendasar antara ioredis dan @upstash/redis adalah protokol transport. ioredis menggunakan binary RESP protocol di atas TCP dengan connection persistent — overhead per command sangat kecil setelah koneksi terbentuk. Upstash menggunakan HTTP/2 REST — setiap command adalah satu HTTP request.

Di serverless/edge environment, “persistent connection” itu hampir tidak ada — setiap invocation Workers praktis fresh. Jadi keunggulan TCP persistent connection Redis tidak berlaku di sini. Itulah mengapa gap di production edge jauh lebih kecil dari yang terlihat di benchmark local-to-server.

Tapi ada satu biaya tersembunyi Upstash yang perlu dicatat: pipeline. Kalau satu request handler butuh 5 operasi Redis sekaligus, dengan ioredis Anda bisa pipeline semuanya dalam satu round-trip:

// ioredis pipeline — 1 round-trip untuk 3 operasi
const pipeline = redis.pipeline();
pipeline.get('key:1');
pipeline.get('key:2');
pipeline.get('key:3');
const results = await pipeline.exec();

Dengan Upstash, pipeline tetap tersedia tapi tetap satu HTTP request per exec:

// Upstash pipeline — 1 HTTP request, masih lebih lambat dari TCP pipeline
const p = redis.pipeline();
p.get('key:1');
p.get('key:2');
p.get('key:3');
const results = await p.exec();

Untuk handler yang butuh banyak operasi Redis berurutan, biaya latency Upstash mulai terasa lebih nyata. Kalau desain handler Anda butuh 8-10 Redis commands per request, pertimbangkan refactor caching key agar bisa dilakukan dalam satu MGET.

Biaya: bukan hanya latency

Hetzner cx21 di Singapore biayanya sekitar €4.5/bulan flat. Upstash pricing untuk plan Pro:

$0.2 per 100.000 command
$0.25 per GB bandwidth
Free tier: 10.000 command/hari

Untuk klien Jakarta yang traffic-nya sekitar 800.000 command/hari di peak, kalkulasi bulanannya:

800.000 cmd/hari × 30 hari = 24.000.000 cmd/bulan
24.000.000 / 100.000 × $0.2 = $48/bulan

Dibanding Hetzner $5/bulan, itu 9x lebih mahal. Tapi Hetzner butuh konfigurasi, monitoring, backup, update Redis — yang untuk tim kecil nilainya tidak nol. Pada akhirnya saya rekomendasikan klien itu tetap di Upstash karena mereka tim 2 orang dan operational overhead Redis jauh lebih mahal dari selisih biaya itu.

Untuk tim yang lebih besar atau traffic lebih tinggi, kalkulasinya bisa berbalik.

Kapan pilih Upstash, kapan pilih self-hosted

Pilih Upstash kalau:

Runtime-nya serverless atau edge (Workers, Vercel Edge, Deno Deploy) — TCP persistent tidak bisa dimanfaatkan
Tim kecil yang tidak mau urus ops Redis
Traffic belum cukup tinggi untuk biaya per-command jadi masalah (di bawah ~200.000 command/hari)
Butuh multi-region read replica dengan setup minimal — aktifkan Global Database selesai

Pilih Redis self-hosted kalau:

Application server-nya masih di VM/container konvensional yang bisa koneksi TCP persisten ke Redis di network yang sama
Traffic sangat tinggi dan biaya per-command Upstash melebihi biaya flat VPS
Butuh fitur Redis yang tidak tersedia di REST API: pub/sub persistent, keyspace notification, Lua scripting kompleks
Ada regulasi data yang melarang penggunaan managed third-party service

Pertimbangkan Redis di Cloudflare Durable Objects atau KV sebagai alternatif ketiga kalau use case-nya caching stateless dan Anda sudah all-in di ekosistem Cloudflare — tapi itu topik tersendiri karena model consistency-nya sangat berbeda.

Verdict

Dari pengukuran ini, kesimpulan saya: untuk edge runtime, Upstash adalah pilihan default yang masuk akal, bukan kompromi. Gap latency dibanding Redis self-hosted praktis menghilang ketika kedua-duanya diukur dari edge node yang sama, karena tidak ada yang bisa memanfaatkan TCP persistent connection.

Yang menentukan bukanlah angka benchmark, melainkan trade-off operasional dan biaya. Upstash menghilangkan seluruh beban ops Redis dengan harga premium per-command. Self-hosted memberikan kontrol penuh dan biaya flat, tapi menambahkan beban tim.

Untuk klien Jakarta itu, keputusan akhirnya: Upstash single region ap-southeast-1 untuk API yang jalan di Workers, Redis self-hosted di Hetzner Singapore untuk internal services yang masih di VM dan butuh throughput tinggi. Dua tool, dua konteks — tidak perlu memilih salah satu untuk segalanya.