Cloudflare Hyperdrive tồn tại vì một vấn đề rất cụ thể và chẳng có gì hào nhoáng: một Worker chạy ở 200 thành phố và nói chuyện với duy nhất một cơ sở dữ liệu Postgres đặt tại một thành phố sẽ chậm hơn chính truy vấn đó phát đi từ một máy chủ nằm ngay cạnh cơ sở dữ liệu ấy. Không phải chậm hơn một chút. Thường là chậm gấp nhiều lần, và vì những lý do chẳng liên quan gì tới cách truy vấn được viết ra.
Bản năng đầu tiên khi một ứng dụng serverless có vẻ ì ạch là đổ lỗi cho bộ lập kế hoạch truy vấn hoặc thêm một chỉ mục. Với Workers nói chuyện cùng một cơ sở dữ liệu đặt trong một vùng, truy vấn thường chẳng có vấn đề gì. Kết nối mới là vấn đề.
Điều Hyperdrive thực sự khắc phục: chi phí thiết lập một kết nối tới cơ sở dữ liệu, phải trả ở từng yêu cầu một. Một kết nối Postgres cần bắt tay TCP, thương lượng TLS và một lượt trao đổi xác thực trước khi một dòng dữ liệu kịp di chuyển, và mỗi bước đó là một vòng đi về giữa nơi Worker vừa thức dậy và nơi cơ sở dữ liệu đang sống. Hyperdrive giữ sẵn các kết nối nóng gần cơ sở dữ liệu của bạn và gom chúng vào một pool, nhờ vậy Worker mượn một kết nối đang mở thay vì dựng mới từ đầu.
Vì sao Worker nối thẳng tới Postgres lại chậm
Một máy chủ ứng dụng truyền thống mở một pool kết nối duy nhất lúc khởi động rồi tái sử dụng suốt vòng đời tiến trình. Chi phí bắt tay được trả một lần lúc khởi động, sau đó dàn đều trên hàng triệu yêu cầu cho tới khi có ai đó khởi động lại dịch vụ.
Workers không hoạt động như vậy. Mỗi lần gọi đều ngắn ngủi và có thể chạy ở bất kỳ vị trí nào của Cloudflare. Không có tiến trình sống lâu nào giữ pool, nên nếu không có trợ giúp thì mỗi yêu cầu phải trả trọn chi phí thiết lập, và trả nó trên khoảng cách từ biên tới cơ sở dữ liệu gốc của bạn.
Ba vòng đi về trước byte dữ liệu đầu tiên không phải là chuyện tinh chỉnh. Một người dùng ở Sydney gọi tới Worker đang nói chuyện với Postgres ở London phải trả độ trễ ấy bốn lần: TCP, rồi TLS, rồi xác thực, rồi cuối cùng mới tới truy vấn. Bản thân truy vấn có khi chỉ mất hai mili giây.
Còn một kiểu hỏng thứ hai, âm thầm hơn. Postgres cấp một tiến trình backend cho mỗi kết nối và mức tối đa là hữu hạn, thường chỉ vài trăm. Một Worker mở rộng tới hàng nghìn lần gọi đồng thời sẽ vét cạn pool đó và bắt đầu nhận về những kết nối bị từ chối, đúng vào lúc lưu lượng tăng vọt mà bạn đã dựng biên để phục vụ.
Hyperdrive làm gì với chuyện đó
Hyperdrive nằm giữa Worker và cơ sở dữ liệu như một bộ gom kết nối do Cloudflare vận hành thay bạn. Nó duy trì các kết nối nóng tới origin của bạn, nên một lần gọi chỉ cần mượn một kết nối thay vì thương lượng kết nối mới từ con số không.
Nó cũng lưu đệm kết quả truy vấn. Những truy vấn đọc lặp lại có thể được phục vụ mà không cần chạm tới origin, biến câu hỏi về độ trễ thành câu hỏi về tỷ lệ trúng cache cho một phần đáng kể lưu lượng. Các lệnh ghi và mọi thứ không xác định đều đi thẳng qua.
Cấu hình chỉ là một chuỗi kết nối. Bạn đăng ký cơ sở dữ liệu với Cloudflare, nhận một binding Hyperdrive, rồi trỏ driver Postgres sẵn có của mình vào binding đó thay vì vào cơ sở dữ liệu. Driver, câu SQL và lược đồ đều không đổi. Điều này quan trọng hơn vẻ ngoài của nó, bởi nó có nghĩa là thay đổi có thể đảo ngược và bạn đo được nó so với kết nối trực tiếp mà không phải viết lại bất cứ thứ gì.
Những con số quyết định nó có hợp hay không
Đã đối chiếu với tài liệu Cloudflare vào tháng 8 năm 2026, và nên kiểm tra lại trước khi cam kết, vì các con số này thay đổi.
| Workers Free | Workers Paid | |
|---|---|---|
| Chi phí | Đã bao gồm | Đã bao gồm |
| Truy vấn | 100.000 mỗi ngày | Không giới hạn |
| Cơ sở dữ liệu đã cấu hình | 10 mỗi tài khoản | 25 mỗi tài khoản |
| Kết nối tới origin cho mỗi cấu hình | khoảng 20 | khoảng 100 |
| Thời lượng tối đa của truy vấn | 60 giây | 60 giây |
| Kích thước phản hồi được cache | 50 MB | 50 MB |
Hyperdrive không tính thêm phí trên cả hai gói , và cũng không có phí egress. Cái được tính là truy vấn thì rất rộng: một lệnh select, insert, update, delete hay một thay đổi lược đồ đều được tính, và truy vấn phục vụ từ cache tính ngang với truy vấn không dùng cache. Hạn mức miễn phí hằng ngày được đặt lại vào nửa đêm UTC.
Tài liệu về giới hạn nêu thời gian chờ kết nối ban đầu là 15 giây và thời gian chờ khi nhàn rỗi là 10 phút. Trần 60 giây cho mỗi truy vấn chính là thứ hạ gục các đội đang chuyển khối lượng báo cáo sang đây: một truy vấn phân tích chạy hai phút trong cron job sẽ đơn giản là thất bại.
Những cơ sở dữ liệu thực sự dùng được
Hyperdrive hỗ trợ PostgreSQL từ 9.0 đến 17.x và MySQL từ 5.7 đến 8.x , tự vận hành hoặc dạng dịch vụ quản lý. MariaDB nằm trong phạm vi tương thích MySQL.
Các nhà cung cấp dịch vụ quản lý được nêu tên gồm AWS Aurora ở cả hai dạng tương thích Postgres và MySQL, Neon, Supabase, Timescale, Materialize, CockroachDB và PlanetScale. Các phiên bản được quản lý trên Azure và Google Cloud cũng chạy tốt.
Ràng buộc thực tế không nằm ở engine mà ở khả năng tiếp cận. Cơ sở dữ liệu của bạn phải định địa chỉ được từ mạng lưới Cloudflare. Một phiên bản Postgres bị đóng kín trong VPC riêng, không có điểm cuối công khai, sẽ cần một đường hầm hoặc một thỏa thuận peering trước khi Hyperdrive có thể nhìn thấy nó, và đó là một dự án mạng chứ không phải một thay đổi cấu hình.
Khi nào Cloudflare Hyperdrive là câu trả lời sai
Khi dữ liệu nên nằm ở biên. Nếu mẫu truy cập của bạn là tra cứu khóa và giá trị, Workers KV nhanh hơn và đơn giản hơn. Nếu bạn muốn một cơ sở dữ liệu quan hệ nhỏ sống gần Worker thay vì nằm trong một vùng duy nhất, D1 mới là sản phẩm được thiết kế cho việc đó. Hyperdrive dành cho trường hợp bạn đã có Postgres hoặc MySQL và có ý định giữ lại.
Khi khối lượng công việc mang tính phân tích. Trần 60 giây và cách tính theo từng truy vấn hợp với lưu lượng giao dịch. Những phép tổng hợp dài thuộc về một trình chạy tác vụ nói chuyện trực tiếp với cơ sở dữ liệu.
Khi bạn chưa đo. Thất bại chúng tôi thấy nhiều nhất là một đội thêm Hyperdrive vào ứng dụng vốn chưa bao giờ bị nghẽn ở kết nối. Nếu Worker chậm vì nó bắn sáu truy vấn nối tiếp trong khi một truy vấn là đủ, việc gom sáu kết nối ấy vào pool chỉ khiến nó bớt chậm một chút và để nguyên vấn đề thật sự.
Phép đo đó đáng làm cho tử tế trước mọi thứ khác. Bài so sánh Cloudflare Workers và AWS Lambda của chúng tôi nói rõ nơi chạy ở biên thực sự thắng, còn Cloudflare D1 bàn về trường hợp dời hẳn cơ sở dữ liệu tốt hơn là tăng tốc con đường dẫn tới nó.
Ra quyết định cho đúng
Hãy bấm giờ một yêu cầu từ đầu đến cuối trên kết nối trực tiếp, rồi làm lại qua Hyperdrive, từ một vị trí ở xa cơ sở dữ liệu của bạn. Nếu khoảng cách nhỏ, độ trễ của bạn nằm ở chỗ khác và bạn vừa tiết kiệm được một phụ thuộc. Nếu khoảng cách lớn, bạn vừa tìm ra tiền thật.
Mecanik xây dựng và rà soát các kiến trúc biên thông qua đội phát triển phần mềm của chúng tôi, bao gồm cả phần không hào nhoáng là có người đo xem cái gì thực sự chậm trước khi tái kiến trúc bất cứ thứ gì. Nếu ứng dụng serverless của bạn chậm hơn chính máy chủ mà nó thay thế, đường đi của kết nối là nơi đầu tiên cần soi.
Đọc thêm: Xây dựng Cloudflare Workers API: hướng dẫn serverless 2026 , Cloudflare Queues: tác vụ nền tại biên , Cách giảm độ trễ LLM: chiến lược caching và edge và Cách xây dựng ứng dụng web năm 2026 .
Câu hỏi thường gặp
Cloudflare Hyperdrive giải quyết vấn đề gì? Chi phí mở một kết nối tới cơ sở dữ liệu ở mỗi yêu cầu. Worker sống ngắn và không giữ pool kết nối nào, nên nếu không có Hyperdrive thì mỗi lần gọi phải trả một lượt bắt tay TCP, một lượt thương lượng TLS và một lượt trao đổi xác thực trên khoảng cách từ biên tới cơ sở dữ liệu của bạn, trước khi bất kỳ dữ liệu nào kịp di chuyển. Hyperdrive giữ các kết nối nóng đã gom pool ở gần origin để Worker chỉ việc mượn một kết nối.
Cloudflare Hyperdrive có giá bao nhiêu? Không tốn gì ngoài gói Workers của bạn. Nó được bao gồm trong cả gói Free lẫn gói Paid, không có phí riêng và không có phí egress. Gói Free cho phép 100.000 truy vấn cơ sở dữ liệu mỗi ngày, đặt lại vào nửa đêm UTC, còn gói Paid thì không giới hạn. Các lệnh select, insert, update, delete và thay đổi lược đồ đều được tính là truy vấn, và truy vấn phục vụ từ cache tính ngang với truy vấn không dùng cache.
Hyperdrive hỗ trợ những cơ sở dữ liệu nào? PostgreSQL từ 9.0 đến 17.x và MySQL từ 5.7 đến 8.x, tự vận hành hoặc dạng dịch vụ quản lý, với MariaDB nằm trong phạm vi tương thích MySQL. Các nhà cung cấp được nêu tên gồm AWS Aurora, Neon, Supabase, Timescale, Materialize, CockroachDB và PlanetScale, cùng các phiên bản được quản lý trên Azure và Google Cloud. Cơ sở dữ liệu phải tiếp cận được từ mạng lưới Cloudflare.
Những giới hạn chính của Hyperdrive là gì? Mười cơ sở dữ liệu được cấu hình cho mỗi tài khoản ở gói Free và 25 ở gói Paid, khoảng 20 kết nối tới origin cho mỗi cấu hình ở gói Free và 100 ở gói Paid, thời lượng truy vấn tối đa 60 giây, phản hồi cache tối đa 50 MB, thời gian chờ kết nối ban đầu 15 giây và thời gian chờ nhàn rỗi 10 phút. Trần 60 giây cho mỗi truy vấn chính là thứ chặn các khối lượng phân tích.
Nên dùng Hyperdrive hay D1? Hyperdrive khi bạn đã có sẵn cơ sở dữ liệu Postgres hoặc MySQL muốn giữ lại và vấn đề là độ trễ khi với tới nó. D1 khi bạn muốn một cơ sở dữ liệu quan hệ sống ngay trên mạng lưới Cloudflare từ đầu. Chúng giải quyết hai vấn đề khác nhau: một bên tăng tốc con đường tới cơ sở dữ liệu sẵn có, bên kia xóa bỏ khoảng cách bằng cách dời dữ liệu.
Bình luận