Mengenal Edge Database: Database Cepat di Banyak Kota

Ketika sebuah aplikasi hanya memiliki pengguna di satu wilayah, menempatkan database di satu pusat data biasanya tidak menjadi masalah besar. Namun, situasinya berubah ketika aplikasi mulai digunakan oleh pengguna dari Indonesia, Jepang, Eropa, hingga Amerika Serikat.

Permintaan pengguna yang berada jauh dari lokasi database harus menempuh perjalanan jaringan yang lebih panjang. Akibatnya, meskipun query SQL sebenarnya sederhana, aplikasi tetap dapat terasa lambat karena waktu habis dalam perjalanan data melalui jaringan.

Masalah inilah yang ingin dikurangi oleh konsep edge database.

Alih-alih mengandalkan satu lokasi database untuk melayani seluruh dunia, arsitektur edge dapat menempatkan data atau replika database lebih dekat dengan pengguna. Pendekatan ini membuat aplikasi global berpotensi memberikan respons lebih cepat tanpa setiap permintaan harus bolak-balik melintasi benua.

Teknologi berbasis SQLite juga ikut berkembang ke arah ini. SQLite yang terkenal ringan dan sederhana kini menjadi fondasi atau inspirasi bagi beberapa sistem database terdistribusi modern.

Lantas, apa sebenarnya edge database dan bagaimana cara kerjanya?

Apa Itu Edge Database?

Edge database adalah pendekatan database yang menempatkan data, salinan data, atau kemampuan pemrosesan database lebih dekat dengan lokasi aplikasi dan pengguna.

Tujuannya sederhana: mengurangi jarak antara pengguna dan data.

Bayangkan sebuah aplikasi memiliki database utama di Amerika Serikat.

Ketika pengguna dari Indonesia membuka dashboard, arsitektur tradisional dapat terlihat seperti:

Pengguna Indonesia → Server aplikasi → Database Amerika → Server → Pengguna

Permintaan tersebut harus melewati jaringan dengan jarak geografis yang cukup jauh.

Pada arsitektur dengan read replica yang tersebar, alurnya bisa berubah menjadi:

Pengguna Indonesia → Replica Asia → Hasil Query

Sementara pengguna Eropa dapat membaca dari replica yang lebih dekat ke Eropa.

Cloudflare menjelaskan bahwa D1 Global Read Replication membuat salinan read-only dari primary database di beberapa region. Query baca kemudian dapat dilayani oleh database yang lebih dekat dengan pengguna sehingga latency jaringan dapat berkurang dan kapasitas read meningkat.

Inilah salah satu gagasan utama di balik database modern yang semakin dekat dengan edge.

Mengapa Lokasi Database Memengaruhi Kecepatan?

Developer terkadang hanya melihat kecepatan query dari sisi database.

Misalnya:

SELECT selesai dalam 5 ms.

Sekilas terlihat sangat cepat.

Namun, waktu eksekusi query hanyalah salah satu bagian dari total waktu yang dirasakan pengguna.

Ada pula network latency.

Jika database berada ribuan kilometer dari pengguna atau server yang menjalankan aplikasi, paket data tetap harus melakukan perjalanan melalui jaringan.

Secara sederhana:

Total waktu ≈ perjalanan jaringan + proses aplikasi + query database + perjalanan respons

Artinya, mengoptimalkan query dari 10 ms menjadi 5 ms tidak selalu menghasilkan perubahan besar jika perjalanan jaringan justru membutuhkan waktu jauh lebih lama.

Edge database mencoba memperbaiki bagian tersebut dengan mendekatkan data kepada tempat data itu digunakan.

Masalah Database Tradisional Satu Region

Arsitektur database konvensional biasanya memiliki satu primary database.

Contohnya:

                    ┌─────────────────┐
                    │ Primary Database│
                    │    Singapore    │
                    └────────┬────────┘
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
     Indonesia            Jepang            Amerika

Model seperti ini sebenarnya tidak salah. Bahkan untuk banyak aplikasi, arsitektur tersebut sudah lebih dari cukup.

Masalah mulai terlihat ketika pengguna tersebar secara global.

Pengguna yang dekat dengan database mungkin memperoleh respons cepat. Sebaliknya, pengguna yang berada di sisi dunia lainnya harus berkomunikasi dengan database yang jauh.

Karena itu, muncul gagasan untuk membuat replica di sejumlah wilayah.

Bagaimana Edge Database Bekerja?

Salah satu pendekatan yang umum adalah menggunakan primary database + read replicas.

Primary menjadi sumber utama data, sementara salinannya ditempatkan di region lain.

Arsitekturnya kurang lebih:

                         PRIMARY
                       DATABASE
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
         Replica Asia  Replica Eropa  Replica Amerika
              │            │            │
              ▼            ▼            ▼
           User Asia    User Eropa   User Amerika

Ketika pengguna hanya ingin membaca data, sistem dapat mengarahkan query menuju replica yang sesuai.

Contohnya:

SELECT * FROM products;

Query semacam ini tidak mengubah database sehingga dapat dilayani oleh read replica.

Namun ketika pengguna melakukan:

UPDATE products
SET stock = 15
WHERE id = 100;

operasi tersebut mengubah data dan, pada arsitektur primary/read-replica tertentu, harus diproses oleh primary.

Cloudflare D1 menggunakan pendekatan tersebut. Dokumentasinya menjelaskan bahwa read replica dapat melayani query baca, sedangkan query tulis tetap diteruskan ke primary database.

Mengapa SQLite Menarik untuk Edge Database?

SQLite awalnya bukan database terdistribusi.

Bahkan cara kerjanya berbeda dari database client-server seperti PostgreSQL atau MySQL.

SQLite merupakan database engine SQL yang self-contained, serverless, zero-configuration, dan transactional. Aplikasi mengakses file database secara langsung tanpa harus berkomunikasi dengan proses database server terpisah.

Karakter tersebut membuat SQLite sangat ringan.

Secara sederhana:

Database Client-Server

Application
    │
    ▼
Database Server
    │
    ▼
Storage

Sedangkan SQLite:

Application
    │
    ▼
SQLite
    │
    ▼
database.db

SQLite juga menggunakan format database satu file dan memiliki footprint relatif kecil.

Sifat inilah yang membuat konsep database kompatibel SQLite menarik untuk sistem lokal, embedded, serverless, dan kemudian berbagai pendekatan distributed database.

Namun perlu dibedakan: SQLite sendiri bukan otomatis sebuah global edge database. Lapisan replikasi, sinkronisasi, routing, dan infrastruktur tambahanlah yang memungkinkan pola tersebut.

Contoh Edge Database: Cloudflare D1

Salah satu contoh menarik adalah Cloudflare D1.

D1 menggunakan SQL semantics SQLite dan menyediakan fitur Global Read Replication.

Saat read replication digunakan, sistem memiliki primary database serta beberapa salinan read-only di berbagai region.

Ketika pengguna berada jauh dari primary tetapi dekat dengan replica, query baca dapat dilayani replica tersebut. Cloudflare menyebut dua manfaat utama pendekatan ini: latency query baca yang lebih rendah dan read throughput yang lebih tinggi.

Namun ada detail penting.

Aplikasi harus menggunakan D1 Sessions API agar read replication digunakan. Tanpanya, query tetap dieksekusi pada primary.

Jadi konsepnya bukan sekadar:

“Aktifkan database global, kemudian semuanya otomatis lokal.”

Developer tetap harus memahami cara kerja routing dan consistency yang digunakan platform.

Turso, libSQL, dan Embedded Replica

Contoh lain datang dari Turso.

libSQL merupakan fork open-source dari SQLite yang menambahkan kemampuan seperti remote access dan embedded replicas.

Konsep embedded replica cukup menarik.

Database dapat memiliki salinan yang berada langsung dekat dengan aplikasi.

Application
     │
     ▼
Local Replica
     │
     │ synchronization
     ▼
Remote Database

Pada model embedded replica libSQL, read dilayani dari replica lokal, sementara secara default write dikirim ke remote primary. Setelah write berhasil, perubahan dapat diperbarui kembali pada replica lokal.

Hasilnya, aplikasi tidak harus menghubungi database remote untuk setiap pembacaan.

Dokumentasi Turso saat ini juga perlu diperhatikan: Embedded Replicas berbasis libSQL merupakan fitur legacy untuk Turso Cloud, dan untuk proyek baru yang membutuhkan sinkronisasi Turso mengarahkan developer ke Turso Sync, yang menawarkan model local-first dengan push/pull.

Ini menunjukkan bahwa teknologi database terdistribusi terus berkembang, bukan konsep yang berhenti pada read replica saja.

Read Cepat, Tetapi Bagaimana dengan Write?

Ini salah satu pertanyaan terpenting dalam memahami edge database.

Misalnya sebuah toko memiliki data:

Stok Produk = 10

User di Indonesia membeli satu barang.

Primary kemudian berubah:

Stok Produk = 9

Tetapi bagaimana jika replica di Eropa masih menyimpan:

Stok Produk = 10

Di sinilah muncul persoalan replication lag.

Ketika replikasi dilakukan secara asynchronous, perubahan pada primary membutuhkan waktu untuk mencapai replica.

Cloudflare juga menjelaskan bahwa replica D1 dapat tertinggal dari primary karena perubahan direplikasi secara asynchronous.

Karena itu, database terdistribusi tidak hanya menghadapi masalah performa.

Ada persoalan lain yang sama pentingnya:

consistency.

Consistency: Tantangan Besar Database Terdistribusi

Semakin banyak salinan database yang dimiliki, semakin penting menentukan data versi mana yang boleh dilihat pengguna.

Bayangkan urutan berikut:

1. User mengubah nama profil
2. Primary menyimpan nama baru
3. User membuka profil kembali
4. Request masuk ke replica lama
5. Nama lama muncul kembali

Dari perspektif pengguna, aplikasi terlihat bermasalah.

D1 menangani skenario semacam ini melalui Sessions API dan konsep bookmark.

Dalam sebuah session, sistem menjaga sequential consistency. Jika aplikasi sudah melihat versi database tertentu, query berikutnya dalam konteks tersebut tidak seharusnya kembali membaca versi yang lebih lama.

Ini memperlihatkan satu prinsip penting:

Database yang lebih dekat belum tentu cukup. Data yang diberikan juga harus memiliki tingkat konsistensi yang sesuai kebutuhan aplikasi.

Edge Database vs Database Tradisional

Aspek	Database Tradisional Satu Region	Edge/Distributed Database
Lokasi data	Terpusat	Dapat memiliki replica/data di banyak lokasi
Pengguna global	Bisa mengalami network latency lebih tinggi	Data baca dapat ditempatkan lebih dekat
Arsitektur	Relatif sederhana	Lebih kompleks
Replication	Opsional	Sering menjadi bagian penting
Consistency	Lebih mudah dikelola	Perlu strategi consistency
Read scalability	Bergantung arsitektur pusat	Bisa dibagi ke beberapa replica
Operasional	Lebih mudah dipahami	Membutuhkan perhatian pada routing dan sinkronisasi

Artinya, edge database bukan otomatis pengganti database tradisional.

Ia merupakan pilihan arsitektur untuk kebutuhan tertentu.

Kapan Edge Database Sangat Berguna?

Edge database semakin menarik ketika sebuah aplikasi memiliki pengguna yang tersebar secara geografis dan workload baca yang besar.

Contohnya aplikasi SaaS global, katalog produk internasional, CMS dengan pengguna lintas wilayah, dashboard, aplikasi kolaborasi, API global, maupun aplikasi yang membutuhkan akses data dekat dengan lingkungan komputasinya.

Misalnya sebuah platform memiliki pelanggan di:

🇮🇩 Indonesia
🇯🇵 Jepang
🇩🇪 Jerman
🇺🇸 Amerika
🇦🇺 Australia

Jika semua permintaan harus menuju satu database yang jauh dari sebagian besar pengguna, latency jaringan menjadi faktor penting.

Replica regional dapat membantu mengurangi perjalanan tersebut.

Namun manfaat akhirnya tetap bergantung pada arsitektur aplikasi, lokasi compute, pola query, caching, dan cara provider menjalankan replication.

Kapan Edge Database Tidak Dibutuhkan?

Tidak semua website harus menggunakan edge database.

Bayangkan website perusahaan Indonesia dengan hampir seluruh pengguna berada di Indonesia dan server aplikasinya sudah ditempatkan dekat dengan database.

Arsitektur:

User Indonesia
      ↓
Server Singapore/Jakarta
      ↓
Database Singapore/Jakarta

bisa saja sudah memberikan performa yang sangat baik.

Memaksakan database global justru dapat menambah kompleksitas:

Replication
Consistency
Routing
Observability
Failover
Data residency
Biaya

Untuk aplikasi sederhana, database konvensional yang dirancang dengan baik sering kali merupakan pilihan yang lebih praktis.

Edge Database Bukan Pengganti CDN

Edge database juga perlu dibedakan dari CDN.

CDN biasanya sangat efektif untuk mendistribusikan konten seperti gambar, CSS, JavaScript, video, atau respons yang dapat di-cache.

Database menangani data yang lebih dinamis.

Contohnya:

Logo website
      ↓
     CDN

Data stok produk
      ↓
   Database

Dalam aplikasi modern, keduanya justru dapat bekerja bersama.

USER
 │
 ▼
EDGE / CDN
 │
 ▼
APPLICATION
 │
 ▼
EDGE DATABASE / REPLICA
 │
 ▼
PRIMARY DATABASE

Dengan demikian, optimasi tidak berhenti pada frontend atau CDN. Lapisan data pun dapat dirancang agar lebih dekat dengan pengguna.

Kelebihan dan Kekurangan Edge Database

Keuntungan utama edge database adalah peluang untuk mengurangi latency jaringan, terutama bagi aplikasi global. Read replica juga dapat membantu membagi beban pembacaan sehingga primary tidak harus menangani seluruh read traffic sendiri.

Namun keuntungan tersebut datang bersama tantangan.

Developer perlu memahami replication lag, consistency model, write routing, lokasi primary, sinkronisasi, observability, biaya, dan karakteristik masing-masing provider.

Karena itu, slogan:

“Taruh database di seluruh dunia dan website otomatis cepat.”

terlalu sederhana.

Arsitektur database terdistribusi selalu memiliki trade-off.

Apakah Semua Query Akan Terasa Instan?

Tidak selalu.

Edge database hanya menyelesaikan sebagian dari persoalan performa.

Website masih dapat lambat karena query SQL buruk, terlalu banyak request, ukuran response besar, rendering frontend berat, API eksternal lambat, indeks database tidak tepat, atau aplikasi melakukan terlalu banyak pekerjaan.

Jadi performa aplikasi modern sebenarnya merupakan kombinasi:

Frontend + CDN + Compute + Network + Database + Query + Caching + Architecture

Edge database terutama membantu mengurangi persoalan jarak antara compute/user dan data.

Masa Depan Database Semakin Dekat dengan Pengguna

Selama bertahun-tahun, developer terbiasa dengan pola:

aplikasi datang ke database.

Sekarang mulai berkembang pola lain:

data atau replica database mendekati tempat aplikasi dijalankan.

Perubahan ini semakin relevan karena aplikasi web tidak lagi hanya melayani satu kota atau satu negara.

Cloud infrastructure, serverless computing, edge runtimes, replication, local-first architecture, dan database kompatibel SQLite membuat batas antara database lokal dan database cloud semakin menarik untuk dieksplorasi.

SQLite sendiri tetap merupakan database engine kecil dan self-contained yang berjalan langsung bersama aplikasi.

Tetapi teknologi yang dibangun di sekitarnya menunjukkan bahwa model SQLite dapat dikembangkan menjadi arsitektur data yang jauh lebih luas—mulai dari remote database, embedded replica, hingga sistem sinkronisasi lokal-cloud.

Edge database merupakan pendekatan untuk mendekatkan data atau kemampuan database kepada pengguna dan aplikasi. Pada arsitektur tertentu, primary database tetap berada di satu lokasi, sementara read replica tersebar di beberapa region agar permintaan baca tidak selalu harus melakukan perjalanan jaringan yang panjang.

Cloudflare D1 memperlihatkan bagaimana database dengan SQL semantics SQLite dapat menggunakan global read replication, sementara ekosistem Turso menunjukkan bagaimana teknologi SQLite-compatible berkembang melalui libSQL, embedded replicas, dan pendekatan sinkronisasi yang lebih baru.

Namun edge database bukan teknologi ajaib. Semakin terdistribusi sebuah database, semakin penting pula memahami replication lag, consistency, routing, dan pola read/write.

Karena itu, inti revolusi edge database sebenarnya bukan sekadar “database berada di banyak kota”, melainkan:

menempatkan data sedekat mungkin dengan tempat data dibutuhkan, tanpa mengorbankan konsistensi yang dibutuhkan aplikasi.

Bagi aplikasi global, prinsip sederhana tersebut dapat menjadi salah satu fondasi untuk membangun pengalaman web yang terasa lebih cepat dan responsif.