Edge database và sự đánh đổi: khi latency là lời nói dối

Hãy tưởng tượng một người dùng ở Sydney. App của bạn chạy trên Cloudflare Workers, backed bởi database D1 — lựa chọn bạn đưa ra chính vì lý do low-latency truy cập toàn cầu. Khi người dùng đó đọc feed của họ, một replica trả lời trong vòng dưới 5 ms. Khi họ đăng ký — ghi account lần đầu tiên vào database — request phải vượt Thái Bình Dương về primary ở Mỹ. Round-trip: khoảng 150 ms. Một instance Postgres đặt ở Sydney sẽ xử lý xong dưới 5 ms.

Đó là sự đánh đổi, và phần marketing hiếm khi đề cập tới. Edge database giải quyết bài toán read-latency cho người dùng phân tán toàn cầu. Chúng không giải quyết được bài toán write-latency, vì bài toán đó là vật lý.

Bài này dành cho ai

Developer đang đánh giá Cloudflare D1, Turso, Neon, hoặc PlanetScale — hoặc bất kỳ ai đang chạy edge deployment và thắc mắc tại sao write cảm thấy chậm. Nếu người dùng của bạn tập trung ở một quốc gia và bạn không vận hành ở quy mô toàn cầu, hãy bỏ qua và đọc thẳng phần decision matrix. Edge story có thể không áp dụng cho bạn.

”Edge database” thực ra nghĩa là gì

Thuật ngữ này bao phủ bốn kiến trúc khác nhau, mỗi cái có hồ sơ đánh đổi riêng.

Read replica ở edge. Một write primary duy nhất đặt tại một region. Replica được deploy gần người dùng. Đọc nhanh; write thì đi tới primary dù người dùng ở đâu. Cloudflare D1 hoạt động theo cách này từ khi ra mắt global read-replication beta vào tháng 4 năm 2025.

Multi-primary distributed database. Không có primary đơn lẻ; node nào cũng nhận write và replication sang các node còn lại. Các hệ thống multi-primary thực thụ — CockroachDB, AlloyDB Omni — có thể nhận write từ mọi nơi. Không có nền tảng nào trong bốn nền tảng bài này đề cập là multi-primary hoàn toàn. D1, Turso, Neon, và PlanetScale đều có một write path chính quyền duy nhất.

Serverless với cold start. Neon tách storage khỏi compute và tự động suspend compute khi nhàn rỗi. Bạn không trả tiền cho thời gian idle. Cái giá: query đầu tiên sau khi suspend mất 300–800 ms. Nó không phải “edge” theo nghĩa địa lý, nhưng chia sẻ billing model serverless mà người ta hay gán cho edge database.

Embedded và local replica. Model hiện tại của Turso: một file SQLite nằm trên server của bạn, đồng bộ với remote primary. Đọc trực tiếp từ local disk — dưới một millisecond. Write đồng bộ lên primary qua mạng. Bạn có read tốc độ local nhưng phải quản lý sync model.

Hiểu database thuộc category nào sẽ cho bạn biết chính xác latency sẽ ảnh hưởng ở đâu.

Các sự đánh đổi

Read latency — phần hoạt động tốt

Nếu người dùng trải rộng trên nhiều châu lục và read chiếm phần lớn workload (90%+ là ngưỡng thực tế), edge database mang lại kết quả thực sự.

Dữ liệu beta của Cloudflare, công bố trong đợt triển khai D1 read-replication, cho thấy replica confirm lag giữa các region:

Primary → Replica	Lag
US East → US West	45 ms
US East → EU West	55 ms
US East → EU East	67 ms
US West → EU East	75 ms

Một warm replica đặt cùng vị trí với Cloudflare Worker trả lời read trong 0.5–5 ms ở p50 đến p99. Replication lag ở trên là khoảng thời gian sau một write trước khi replica phản ánh nó — không phải bản thân read latency.

Benchmark embedded replica của Turso đo được khoảng 624 µs latency read trung bình — nhanh hơn bất kỳ network query nào. Nếu bạn kiểm soát server và có thể nhúng file SQLite vào, read local thực sự thuộc một đẳng cấp hiệu năng khác.

Một điểm cần lưu ý: Neon branching là công cụ development, không phải tính năng read-scaling. Branch dùng copy-on-write storage và tạo nhanh, nhưng không đưa read lại gần người dùng hơn. Đừng xây chiến lược phân phối read xung quanh chúng.

Write latency — phần không hoạt động

Mọi nền tảng trong bài này đều serialize write qua một primary duy nhất. Điều đó có nghĩa write latency là địa lý: chi phí round-trip giữa request của người dùng và nơi primary đặt.

D1: Cloudflare không công bố số đo write-latency trực tiếp cho người dùng ở region xa. Con số SYD→US-primary (~150 ms) được ước tính từ dữ liệu replication lag D1 và số liệu round-trip mạng Thái Bình Dương — không phải D1 write được đo trực tiếp. Hãy xem đây là mức sàn để lập kế hoạch. Nếu primary của bạn ở Mỹ và bạn có lượng đáng kể traffic từ AU hoặc SA, hãy đo trong môi trường của bạn trước khi commit vào kiến trúc này.

Trong các kịch bản co-located (Worker và write primary ở cùng region), D1 write chạy trong 5–30 ms ở p50. Khi bạn vượt ranh giới region, mức sàn đó tăng theo thời gian round-trip vật lý.

Turso: Read từ embedded replica dưới một millisecond, nhưng write đồng bộ về primary trong 20–100 ms tùy khoảng cách server của bạn tới Turso primary. Sync model có nghĩa code của bạn cần explicit về khi nào read cần phản ánh write mới nhất — bạn có thể gọi sync() để ép fresh data. Để so sánh trực tiếp Turso và D1, xem Turso vs D1.

Neon: Là PostgreSQL chuẩn qua mạng. Mọi query — read và write — đều đi qua khoảng cách giữa client và server. Không có edge shortcut trên cả hai đường. Với ứng dụng có người dùng phân tán toàn cầu, đây là hạn chế; với ứng dụng có người dùng theo vùng, điều này không quan trọng.

PlanetScale: Phủ 13 vùng AWS và 7 vùng GCP, cho bạn nhiều lựa chọn đặt primary hơn hầu hết. Write vẫn đi tới primary. PlanetScale Vitess nhắm vào workload MySQL write nặng, không phải phân phối write toàn cầu — sharding là horizontal trong một region, không phải cross-region.

Consistency — điều gì xảy ra giữa write và read tiếp theo

Nền tảng	Model	Điểm cần chú ý
Cloudflare D1	Sequential consistency qua Sessions API	Không dùng Sessions API, stale read sau write là có thể xảy ra. Sessions API chỉ hoạt động qua Worker binding — không phải REST API.
Turso	ACID trên primary, eventual trên embedded replica	Read từ replica có thể lag đến khi bạn gọi `sync()`.
Neon	Full PostgreSQL ACID	Read replica dùng streaming replication; lag thường dưới 1 s.
PlanetScale (Vitess)	ACID trong một keyspace/shard	Cross-shard operation không có distributed 2PC. Cross-keyspace join và transaction là application-level saga.

Ràng buộc D1 Sessions API là thứ có khả năng cao nhất sẽ bất ngờ gặp phải. Nếu bạn truy cập D1 ngoài Cloudflare Worker — trực tiếp qua REST API, từ môi trường không phải Cloudflare, hoặc qua custom routing layer — consistency guarantee giảm xuống “read committed.” Bạn có thể đọc write của chính mình; có thể không. Ứng dụng ghi rồi ngay lập tức đọc lại (phổ biến trong cập nhật profile, shopping cart, notification counter) cần Sessions API hoặc chiến lược retry-on-stale.

Cross-shard gotcha của PlanetScale cũng hay bị đánh giá thấp. Vitess mạnh cho sharding một dataset MySQL lớn — schema change không downtime, horizontal scale. Nhưng nếu data model của bạn cần join hay transaction qua ranh giới keyspace, bạn sẽ phải viết code consistency ở application layer. Đây không phải điều ngăn bạn dùng, nhưng không phải thứ hầu hết team kỳ vọng từ managed database.

Cold start và connection overhead

Auto-suspend của Neon là behavior cold-start có ý nghĩa vận hành lớn nhất trong nhóm này. Free tier: 300–800 ms đến query đầu tiên sau khi idle (ngưỡng idle 5 phút). Khuyến nghị cho production là tắt auto-suspend trên plan trả phí. Nếu bạn có latency SLO, cold start của Neon free tier sẽ vi phạm nó.

D1 bên trong Cloudflare Workers không có connection overhead. Database binding nằm in-process với Worker. Không có TCP handshake. Không có connection pooling middleware. Với kiến trúc serverless vốn đã gặp khó với connection limit trên Postgres truyền thống, đây là một đơn giản hóa vận hành thực sự.

Turso đã deprecated scale-to-zero vào tháng 1 năm 2025 cho người dùng mới (tài khoản cũ giữ nguyên behavior cũ). Kiến trúc mới chạy always-on. Điều đó loại bỏ rủi ro cold start nhưng thay đổi cost model — bạn trả cho uptime thay vì per-invocation. Tùy traffic pattern, điều này có thể đắt hơn hoặc rẻ hơn model trước.

Độ phức tạp vận hành

D1 có hai hard limit quyết định trần nâng cấp trước khi bạn bắt đầu: 10 GB mỗi database và 50.000 database mỗi account. D1 xử lý write single-threaded trên mỗi database; write throughput thực tế phụ thuộc vào thời gian query (dữ liệu cộng đồng đặt write đơn giản ở mức hàng trăm đến vài nghìn mỗi giây). Nếu bạn đụng giới hạn storage, bạn phải tự shard qua nhiều database. Lên kế hoạch cho điều này ngay từ đầu nếu data của bạn tăng có thể dự đoán.

Turso yêu cầu bạn hiểu sync model trong application layer. Read từ embedded replica có thể stale đến khi sync. Điều này có chủ đích — bạn gọi sync() để pull mới nhất từ primary — nhưng là sự thay đổi mental model so với database network chuẩn, nơi read luôn phản ánh trạng thái server hiện tại.

Neon là thay thế trực tiếp cho PostgreSQL nhất trong nhóm. Driver chuẩn, psql chuẩn, pg_dump chuẩn. Branching là additive — bạn không cần dùng nếu không cần. Mối lo vận hành chính là compute auto-suspend và behavior connection pooling (Neon dùng proxy dựa trên PgBouncer; transaction-mode pooler có hàm ý với prepared statement và advisory lock). Nếu bạn đang cân nhắc giữa Neon và Supabase, xem Neon vs Supabase.

PlanetScale (Vitess) có learning curve lớn nhất với team MySQL. Schema change đi qua branching-and-deploy workflow của PlanetScale thay vì ALTER TABLE trực tiếp. Điều này thực sự hữu ích cho zero-downtime migration trên table lớn, nhưng team của bạn cần hiểu quy trình. Với team đang chạy MySQL chuẩn, migration đầu tiên sẽ cảm thấy xa lạ.

Snapshot giá (2026-05-27)

Nền tảng	Free tier	Entry paid
Cloudflare D1	5M hàng đọc/ngày, 100K hàng ghi/ngày, 5 GB tổng	$5/tháng (Workers Paid): 25B read + 50M write/tháng
Turso	500M read/tháng, 10M write/tháng, 5 GB	$4.99/tháng: 2.5B read, 25M write, 9 GB
Neon	100 compute-unit-hour/tháng, 0.5 GB storage	Không có monthly minimum; $0.106/CU-giờ, $0.35/GB-tháng storage
PlanetScale Postgres	Không có (free plan bị xóa tháng 4 năm 2024)	$5/tháng: single-node Postgres (PS-5 non-HA)

Storage của Neon giảm 80% cuối năm 2025 sau thương vụ Databricks mua lại. Những con số này thay đổi. Kiểm tra lại trước khi đưa ra cam kết ngân sách.

Dữ liệu benchmark cộng đồng

Benchmark capaj trên GitHub so sánh PlanetScale, Neon, và Turso từ Cloudflare Workers tại Frankfurt, dùng query SELECT đơn giản qua Drizzle ORM:

PlanetScale (Scaler Pro) luôn dưới 67 ms.
Neon (free tier) chậm hơn — cold start làm lệch kết quả đáng kể.
Turso (free tier) bắt kịp PlanetScale tại một số thời điểm, nhưng có lúc tăng vọt lên 400 ms — nhiều khả năng do WAL sync jitter.

Hãy đọc kết quả này như thông tin định hướng, không phải kết luận chính thức. Cả ba đều ở free hay hobby tier; cold start của Neon riêng đã làm so sánh không công bằng. Kết quả chỉ từ Frankfurt không khái quát được cho region khác.

Ma trận quyết định

Dùng D1 hoặc Turso nếu:

Read chiếm 90%+ volume query của bạn.
Người dùng trải rộng trên nhiều châu lục.
Write ít và chịu được latency cao — cài đặt người dùng, nội dung được publish, không phải giao dịch tài chính hay inventory.
Bạn đang xây dựng trên Cloudflare Workers (D1 là lựa chọn tự nhiên — nếu bạn còn đang cân nhắc Workers với runtime khác, xem Cloudflare Workers vs Vercel Edge).
Kích thước database không vượt 10 GB mỗi logical database (giới hạn D1).
Bạn có thể làm việc với eventual consistency hoặc sẵn sàng implement Sessions API đúng cách.

Dùng Neon, PlanetScale Postgres, hoặc managed Postgres truyền thống nếu:

Write thường xuyên và người dùng thấy ngay kết quả (checkout, thanh toán, xác nhận đặt chỗ).
Bạn cần full ACID trên nhiều table và foreign key relationship.
Người dùng tập trung ở một hoặc hai region — lợi ích read từ edge không đáng kể với app theo vùng.
Database vượt 10 GB.
Người dùng chủ yếu ở Úc, Đông Nam Á, hoặc Nam Mỹ, và primary của bạn sẽ đặt ở Mỹ hoặc EU — write của bạn với edge database sẽ chậm hơn một regional database đặt đúng chỗ.
Bạn cần full SQL feature set: CTE, window function, lateral join, advisory lock. SQLite (D1, Turso) hỗ trợ SQL dialect khá năng lực nhưng hẹp hơn.

Embedded replica của Turso phù hợp đặc biệt với ứng dụng server-rendered nơi bạn kiểm soát môi trường deployment và muốn read tốc độ local mà không cần co-locate app vào bên trong Cloudflare. Nếu bạn chạy trên Fly.io VM hoặc VPS ở một region cụ thể, embedded replica cho read dưới millisecond và write sync có thể quản lý được.

Lưu ý

Xata không được đề cập trong đợt nghiên cứu này. Nó định vị là serverless Postgres cộng built-in search, và thuộc về bất kỳ so sánh edge database toàn diện nào — sẽ có bài riêng.

Con số write latency SYD→US (~150 ms) được suy ra từ dữ liệu replication lag Cloudflare và benchmark mạng công khai. Cloudflare chưa công bố số đo write-latency trực tiếp từ Sydney cho D1. Nếu ứng dụng của bạn có lượng traffic đáng kể từ AU/SA/SEA, hãy tự đo trong staging environment trước khi commit.

Hoa hồng affiliate của Turso chưa được xác nhận. Turso ra mắt partner program vào tháng 5 năm 2026. Chi tiết hoa hồng được tiết lộ sau khi xem xét đăng ký. Chúng tôi đang làm việc về điều này — chưa có affiliate link của Turso cho đến khi mọi thứ rõ ràng.

Toolchew đã nộp đơn tham gia Neon Open Source Program. Nếu được chấp thuận, referral link sẽ đi qua /go/neon — toolchew kiếm $20 cho mỗi người dùng được giới thiệu chi tiêu $20+ trên Neon, không tốn thêm gì của bạn. Phần affiliate disclosure đầu bài này bao phủ quan hệ này.

Kết luận

D1 là lựa chọn vận hành đơn giản nhất nếu bạn xây dựng trên Cloudflare Workers. Không có connection pooling overhead, không cold start, global read mà không cần infrastructure thêm. Trần của nó có thật — 10 GB, ~2K write/giây — nên hãy đánh giá workload của bạn có fit không trước khi commit.

Turso có câu chuyện read thú vị nhất hiện tại. Sau pivot tháng 1 năm 2025 rời xa Fly.io edge replica, pitch là “nhúng database vào server của bạn” thay vì “deploy gần người dùng.” Microsecond read từ local disk, write đồng bộ lên cloud. Hoạt động tốt nhất khi bạn kiểm soát môi trường deployment và muốn local-first semantics.

Neon là lựa chọn đúng khi bạn muốn PostgreSQL mà không muốn tự chạy Postgres. Full SQL, tooling chuẩn, cold start biến mất trên plan trả phí (always-on compute). Thương vụ Databricks mua lại vào tháng 5 năm 2025 tạo ra bất ổn định giá dài hạn — hãy theo dõi sự thay đổi.

PlanetScale phù hợp với workload MySQL write nặng cần Vitess-scale sharding, hoặc team muốn managed Postgres mà không có serverless billing. Tính $5/tháng ngay từ ngày đầu.

Không cái nào trong số này đánh bại được một Postgres single-region đặt đúng chỗ nếu người dùng của bạn theo vùng. Lợi ích latency từ edge distribution đòi hỏi người dùng thực sự phân tán. Nếu 90% traffic của bạn đến từ Đức, database của bạn thuộc về Frankfurt, đơn giản vậy thôi. Edge là giải pháp cho vấn đề mà địa lý tạo ra, không phải nâng cấp hiệu năng tổng thể.