Hyperdrive: ต่อ PostgreSQL เดิมกับ Cloudflare Workers โดยไม่ต้องย้ายฐานข้อมูล

คำตอบสั้น: Hyperdrive คือ connection pooler บวก query cache ที่คั่นระหว่าง Cloudflare Workers กับ PostgreSQL หรือ MySQL ที่คุณมีอยู่แล้ว มันมีอยู่เพราะ Worker หนึ่ง invocation เปิด connection ออกนอกได้แค่ 6 ตัว และเพราะฐานข้อมูลแบบเดิมรับ connection ได้จำกัด คุณไม่ต้องย้ายฐานข้อมูล ไม่ต้องเปลี่ยน schema ไม่ต้องทิ้ง extension แค่เอา connection string เดิมมาสร้าง config แล้ว bind เข้า Worker แต่ต้องเข้าใจกับดักของ cache ที่ไม่ invalidate หลังการเขียน

ทีมส่วนใหญ่ที่สนใจ Cloudflare Workers ไม่ได้อยากทิ้ง PostgreSQL เขามีฐานข้อมูลที่ทำงานดีอยู่แล้ว มี schema ที่นิ่ง มี report ที่อิงกับมัน มี backup ที่ทดสอบ restore มาแล้ว สิ่งที่เขาอยากได้คือเอา compute ขึ้น edge เพื่อลด latency และเลิกจ่ายค่าเครื่องที่ว่างงาน

ปัญหาคือเมื่อคุณต่อ Postgres จาก Worker ตรง ๆ คุณจะเจอกำแพงสองอันทันที หนึ่งคือ Worker เปิด connection ออกนอกพร้อมกันได้แค่ 6 ตัวต่อ invocation สองคือ Worker ทำงานกระจายอยู่ทั่วโลก ถ้าทุก invocation เปิด connection ใหม่ไปที่ Postgres เครื่องเดียว คุณจะ exhaust connection limit ของมันภายในนาที

Hyperdrive เกิดมาเพื่อแก้เรื่องนี้โดยเฉพาะ บทความนี้อธิบายว่ามันทำอะไร มีข้อจำกัดอะไรจริง ๆ (ตัวเลขจากเอกสาร Cloudflare ตรวจสอบ ณ กรกฎาคม 2026) และกับดักที่คุณจะเจอถ้าเปิดมันทิ้งไว้ตามค่าเริ่มต้นโดยไม่อ่านเอกสาร

ปัญหาที่ Hyperdrive แก้

เพดาน 6 connection ต่อ invocation

Workers จำกัด simultaneous outgoing connections ไว้ที่ 6 ต่อหนึ่ง invocation เหตุผลคือ Worker ไม่ใช่เซิร์ฟเวอร์ที่มี process ค้างอยู่ตลอด และเก็บ pool ไว้ในหน่วยความจำของตัวเองได้ มันคือ isolate ที่เกิดขึ้นและตายไปตาม request ด้วยหน่วยความจำ 128 MB ที่แชร์กันไม่ได้ข้าม invocation

แปลว่า คอนเซ็ปต์ connection pool ที่ backend engineer ทุกคนคุ้นเคย เปิด pool ขนาด 20 connection ตอน boot แล้วใช้ซ้ำไปเรื่อย ๆ ใช้กับ Workers ไม่ได้ เมื่อทราฟฟิกเข้ามาจาก ะ0 กว่าเมืองทั่วโลก แต่ละที่อาจเปิด connection ของตัวเองไปที่ฐานข้อมูล และ Postgres ก็จะตอบกลับมาว่า too many connections

Connection setup ที่ต้อง round trip หลายรอบ

การเปิด connection ไปยัง PostgreSQL ไม่ใช่ request เดียว มันคือ TCP handshake ตามด้วย TLS handshake ตามด้วย authentication ของโปรโตคอล Postgres เอง ถ้า Worker ของคุณทำงานที่ edge ในกรุงเทพ แต่ฐานข้อมูลอยู่ที่อื่น ทุก round trip คือ latency ข้ามทวีปหนึ่งรอบ ก่อนที่ query แรกจะได้วิ่งเสียด้วยซ้ำ

Hyperdrive ดัน connection setup นั้นมาทำใกล้ Worker มากที่สุด แล้วเก็บ pool ของ connection จริงไว้ในภูมิภาคที่ใกล้ฐานข้อมูลของคุณ การจับมือระหว่าง Worker กับ Hyperdrive จึงเร็ว ส่วนช่วงที่ช้าคือ Hyperdrive กับฐานข้อมูล ก็เป็น connection ที่อุ่นอยู่แล้วและถูกใช้ซ้ำ

Hyperdrive ทำอะไรจริง ๆ สามอย่าง

หนึ่ง Edge connection setup

แทนที่ Worker จะทำ handshake ข้ามทวีปกับ Postgres มันทำ handshake กับ Hyperdrive ที่อยู่ใน location เดียวกัน ค่า latency ของขั้นตอนนี้จึงเกือบหายไป

สอง Connection pooling ใกล้ฐานข้อมูล

Hyperdrive เก็บ pool ไว้ใน region ที่ใกล้ฐานข้อมูลต้นทางที่สุด และจำกัดจำนวน connection ที่วิ่งไปหาฐานข้อมูลจริง ๆ ที่ประมาณ 20 connection ต่อ config บนแผนฟรี และประมาณ 100 connection บนแผน Paid สิ่งที่ Hyperdrive ไม่จำกัดคือจำนวน client connection จากฝั่ง Workers คุณจะมี Worker กี่หมื่น isolate ก็ได้ มันบีบทุกอย่างเข้า pool เดียวที่ขนาดควบคุมได้

เอกสารระบุว่า Hyperdrive เป็นระบบแบบกระจาย ถ้า client เข้า pool เดิมไม่ได้ มันจะสร้าง pool ใหม่ที่มีโควตา connection ของตัวเอง แปลว่าจำนวน connection จริงอาจเกินตัวเลขที่ระบุได้บ้าง เพราะระบบเลือก availability มาก่อนการบังคับเพดานอย่างเคร่งครัด ตั้ง max_connections ของ Postgres เผื่อไว้ด้วย

สาม Query caching

Hyperdrive อ่าน wire protocol ของฐานข้อมูลเพื่อแยกว่า query ไหนอ่านอย่างเดียว query ไหนเขียน แล้ว cache เฉพาะผลของ query ที่อ่านอย่างเดียว ค่าเริ่มต้นคือ max_age 60 วินาที และ stale_while_revalidate 15 วินาที และตั้ง max_age ได้สูงสุด 1 ชั่วโมง caching เปิดมาตั้งแต่ต้น

ข้อจำกัดจริงของ Hyperdrive

ตัวเลขที่คนมักชนคือ 25 config ต่อบัญชีบนแผน Paid ถ้าคุณอยากมี config หนึ่งที่เปิด cache และอีก config ที่ปิด cache ต่อหนึ่งฐานข้อมูล นั่นคือ 2 config ต่อหนึ่งฐานข้อมูลทันที และ response ที่ใหญ่เกิน 50 MB จะไม่ถูก cache แต่ยังส่งกลับมาที่ Worker ตามปกติ

ราคา ณ กรกฎาคม 2026

สรุปง่าย ๆ คือบนแผน Workers Paid (5 ดอลลาร์ต่อเดือน) Hyperdrive ไม่มีค่าใช้จ่ายเพิ่ม คุณยังจ่ายค่า Postgres ของคุณเหมือนเดิม และจ่ายค่า Workers ตามปกติ นี่ทำให้การคำนวณ ROI ง่ายมาก เพราะค่าใช้จ่ายส่วนเพิ่มของการเอา Hyperdrive เข้ามาคือศูนย์

ตัวอย่าง: ระบบ e-commerce ที่ Postgres อยู่ที่สิงคโปร์

สมมติคุณมีร้านค้าออนไลน์ที่ขายทั้งในไทยและอาเซียนตะวันออกเฉียงใต้ ฐานข้อมูล PostgreSQL หลักอยู่ที่ ap-southeast-1 มี catalog สินค้า 200,000 SKU มี PostGIS สำหรับค้นหาสาขาใกล้ผู้ซื้อ และมี report ที่ทีม finance เขียนไว้เป็น SQL ยาวสิบหน้า

การย้ายทั้งหมดนี้ไป D1 ไม่เกิดขึ้นแน่ ๆ PostGIS อย่างเดียวก็ปิดประตูแล้ว แต่สิ่งที่คุณอยากได้คือหน้าร้านค้าที่ render จาก edge เร็วขึ้น โดยไม่ต้องแตะฐานข้อมูลเลย

สิ่งที่คุณทำ

คุณสร้าง Hyperdrive config สองตัว ตัวแรกเปิด cache สำหรับ query อ่านที่ทนความเก่าได้สักครู่ เช่น รายละเอียดสินค้า หน้าหมวดหมู่ และหน้าค้นหา ตัวที่สองสร้างด้วย --caching-disabled สำหรับสิ่งที่ห้ามผิดเด็ดขาด คือ authentication, session, สิทธิ์การเข้าถึง, ตะกร้าสินค้า, สถานะคำสั่งซื้อ และทุกการอ่านทันทีหลังเขียน

จากนั้น bind ทั้งสองตัวเข้า Worker เดียวกัน แล้วสร้าง client ของไดรเวอร์แยกกันสองตัว ส่ง client ตัวที่ปิด cache ให้กับโมดูล auth และ checkout ส่วนตัวที่เปิด cache ให้กับหน้า catalog สำคัญมากถ้าคุณใช้ ORM เพราะ ORM เป็นคนสร้าง SQL เอง คุณควบคุมมันได้ที่ระดับ client เท่านั้น

สิ่งที่คุณได้

Query หน้า catalog ที่ซ้ำกันทั้งวันจะตอบจาก cache ที่ edge ไม่ต้องวิ่งกลับไปหาฐานข้อมูล และภาระที่ลงไปที่ Postgres ก็ลดตาม ส่วน connection ที่เคยระเบิดเวลามี traffic ก็ถูก Hyperdrive คุมไว้ในหลักร้อย คุณไม่ต้องตั้ง PgBouncer เอง ไม่ต้องดูแลมัน ไม่ต้อง patch มัน

สิ่งที่ต้องระวัง

ถ้า Worker ของคุณยิง query หลายครั้งต่อหนึ่ง request แบบต่อเนื่อง การรัน Worker ที่ edge จะทำให้ทุก query จ่ายค่า round trip ข้ามทวีปซ้ำแล้วซ้ำอีก เอกสาร Cloudflare ระบุว่าแต่ละ query เพิ่ม latency ประมาณ 20 ถึง 30 มิลลิวินาทีเมื่อรันจาก region ที่อยู่ไกล เทียบกับ 1 ถึง 3 มิลลิวินาทีเมื่อ Worker อยู่ใกล้ฐานข้อมูล ทางแก้คือตั้ง Smart Placement ให้ Worker รันใกล้ฐานข้อมูล แต่ถ้า Worker ยิง query เดียวต่อ request Placement จะไม่ช่วยอะไร เพราะเวลารวมเท่าเดิม

กับดักที่ต้องรู้ก่อนเปิดใช้

Cache ไม่ invalidate เมื่อคุณเขียน

นี่คือเรื่องที่ทำให้ทีมเจ็บตัวมากที่สุด เอกสารระบุชัดว่า Hyperdrive ไม่ purge หรือ invalidate ผลที่ cache ไว้เมื่อแอปเขียนลงฐานข้อมูล แปลว่า SELECT ที่ match กันหลังจากเขียน ยังอาจคืนค่าเก่าจนกว่า max_age จะหมด และยังอาจคืนค่าเก่าต่อในช่วง stale_while_revalidate อีก

ถ้าคุณเปิด cache ทิ้งไว้ตามค่าเริ่มต้นแล้วเอา Hyperdrive มาต่อกับตาราง permission หรือตาราง session คุณเพิ่งสร้างช่องโหว่ด้านความปลอดภัยขึ้นมา 60 วินาที คำแนะนำของ Cloudflare ตรงนี้ชัดเจน ให้ใช้ config ที่ปิด cache สำหรับ auth, session, permission, billing state และ read ที่ตามหลัง write ทันที

ฟังก์ชันอย่าง NOW() ทำให้ query ไม่ถูก cache

Hyperdrive cache เฉพาะ query ที่ใช้ฟังก์ชันที่ PostgreSQL จัดเป็น IMMUTABLE เท่านั้น ฟังก์ชันที่เป็น STABLE หรือ VOLATILE เช่น NOW(), CURRENT_DATE, CURRENT_TIMESTAMP, RANDOM() และ LASTVAL() จะทำให้ query นั้น cache ไม่ได้เลย

ถ้า dashboard ของคุณเขียน WHERE created_at > NOW() – INTERVAL 1 hour คุณจะไม่ได้ cache เลยสัก query เดียว ทางแก้คือย้ายการคำนวณเวลาไปไว้ที่โค้ดแอปแล้วส่งค่าเข้ามาเป็น parameter และอย่าเขียนชื่อฟังก์ชันเหล่านี้ไว้ในคอมเมนต์ของ SQL ด้วย เอกสารเตือนว่า parser อาจจับชื่อฟังก์ชันในคอมเมนต์แล้วถือว่า query นั้น cache ไม่ได้

Transaction mode หมายความว่า SET ไม่ติดข้าม query

Hyperdrive ทำงานในโหมด transaction pooling connection จะถูกคืน pool เมื่อ transaction จบ และจะถูก RESET แปลว่าคำสั่ง SET ที่คุณรันจะไม่มีผลกับ query ถัดไป คุณต้อง SET ใหม่ทุก transaction หรือรวม SET เข้ากับ query เดียวกัน และ Cloudflare ไม่แนะนำให้ครอบ transaction ยาว ๆ เพื่อรักษาสเตต เพราะมันจะล็อก connection ไว้ไม่ให้ isolate อื่นใช้ ซึ่งขัดกับจุดประสงค์ของ Hyperdrive โดยตรง

เมื่อไหร่ที่ connection ธรรมดาหรือเซิร์ฟเวอร์ติด region เดิมดีกว่า

Hyperdrive ไม่ใช่คำตอบสำหรับทุกคน

ถ้า backend ของคุณเป็นเซิร์ฟเวอร์ที่รันตลอดเวลาอยู่ใน region เดียวกับ Postgres เช่น API บน ECS หรือ EC2 ที่ ap-southeast-1 คุณมี connection pool ของ process เองอยู่แล้ว มี latency ระดับหนึ่งหลักมิลลิวินาทีอยู่แล้ว การยัด Hyperdrive เข้ามาคั่นกลางมีแต่จะเพิ่ม hop โดยไม่ได้อะไรกลับมา

ถ้าระบบของคุณต้องการ transaction ยาวที่มี SET หรือ advisory lock หรือ LISTEN/NOTIFY หรือ prepared statement ที่ต้องอยู่ข้าม request โมเดล transaction pooling จะขัดกับคุณ นี่ไม่ใช่ข้อจำกัดของ Hyperdrive โดยเฉพาะ มันเป็นข้อจำกัดของ connection pooler ทุกตัวที่ทำงานโหมดนี้ รวมถึง PgBouncer แต่คุณต้องรู้ล่วงหน้า

และถ้า workload ของคุณเป็นงาน batch ที่รันนานกว่า 60 วินาทีต่อ query เช่น ETL หรือการ backfill ข้อมูลก้อนใหญ่ Hyperdrive จะตัด query ที่เกิน 60 วินาทีทิ้ง งานพวกนี้ควรรันจากเซิร์ฟเวอร์ที่ต่อ Postgres ตรง ไม่ใช่จาก Worker เราเขียนเรื่องขอบเขตเหล่านี้ไว้ใน เมื่อไหร่ที่ไม่ควรใช้ Cloudflare Workers แล้ว

สรุป

Hyperdrive ไม่ได้ทำให้ Postgres ของคุณเร็วขึ้นด้วยเวทมนต์ มันลบเหตุผลสองข้อที่ทำให้ Workers ต่อฐานข้อมูลเดิมไม่ได้ คือเพดาน 6 connection ต่อ invocation กับค่า connection setup ที่แพง แล้วแถม cache มาให้ นั่นคือคุณค่อย ๆ ย้าย compute ขึ้น edge ได้โดยไม่ต้องแตะฐานข้อมูลเลย

Cipher ออกแบบและ implement ระบบบน Cloudflare Developer Platform ให้ธุรกิจในประเทศไทย ถ้าคุณมี PostgreSQL ที่ทำงานดีอยู่แล้วและกำลังดูว่าควรย้าย compute ส่วนไหนขึ้น Workers เราประเมินสถาปัตยกรรมและบอกตรง ๆ ได้ว่าส่วนไหนคุ้ม และส่วนไหนที่ควรอยู่ที่เดิม

คำถามที่พบบ่อย

ใช้ Hyperdrive แล้วต้องย้ายฐานข้อมูลไหม

ไม่ต้อง Hyperdrive เชื่อมต่อกับ PostgreSQL หรือ MySQL ที่คุณมีอยู่แล้ว ไม่ว่าจะเป็น RDS, Cloud SQL, Azure Database หรือเครื่องที่คุณดูแลเอง คุณแค่เอา connection string เดิมมาสร้าง config แล้ว bind เข้า Worker ไม่ต้องเปลี่ยน schema หรือทิ้ง extension ใด

Hyperdrive คิดเงินเท่าไหร่

ราคา ณ กรกฎาคม 2026 Hyperdrive รวมอยู่ในแผน Workers ทั้ง Free และ Paid แผนฟรีจำกัด database query ที่ 100,000 ครั้งต่อวัน ส่วนแผน Paid ไม่จำกัดจำนวน query ทั้ง connection pooling และ query caching รวมอยู่ในแผนโดยไม่คิดค่าใช้จ่ายเพิ่ม และไม่มีค่า egress

Cache ของ Hyperdrive ทำให้อ่านข้อมูลเก่าหลังเขียนไหม

ใช่ เอกสารระบุชัดว่า Hyperdrive ไม่ purge หรือ invalidate cache เมื่อแอปเขียนลงฐานข้อมูล ค่าเริ่มต้นคือ max_age 60 วินาที และ stale_while_revalidate 15 วินาที สำหรับ authentication, session, permission หรือการอ่านทันทีหลังเขียน ให้สร้าง Hyperdrive config อีกตัวที่ปิด cache แล้ว bind ควบคู่กัน

ทำไม query ที่มี NOW() ถึงไม่ถูก cache

Hyperdrive cache เฉพาะ query ที่ใช้ฟังก์ชันที่ PostgreSQL จัดเป็น IMMUTABLE เท่านั้น ฟังก์ชันอย่าง NOW(), CURRENT_DATE และ RANDOM() ถูกจัดเป็น STABLE หรือ VOLATILE จึง cache ไม่ได้ วิธีแก้คือคำนวณค่าเวลาในโค้ดแอปแล้วส่งเข้ามาเป็น parameter

Hyperdrive ช่วยลด latency ได้จริงไหม

ช่วยได้เมื่อ connection setup เกิดใกล้ Worker และ pool อยู่ใกล้ฐานข้อมูล แต่ถ้า Worker ยิงหลาย query ต่อ request แบบต่อเนื่อง คุณควรใช้ Placement ให้ Worker รันใกล้ฐานข้อมูลด้วย เอกสารระบุว่าแต่ละ query เพิ่ม latency ประมาณ 20 ถึง 30 มิลลิวินาทีจาก region ที่ไกล เทียบกับ 1 ถึง 3 มิลลิวินาทีเมื่ออยู่ใกล้กัน