คำตอบสั้น: ใช้ R2 สำหรับไฟล์และ object ขนาดใหญ่ เพราะค่า egress เป็นศูนย์เสมอ ใช้ D1 เมื่อต้องการ SQL จริง ๆ แต่ชุดข้อมูลเล็กพอจะอยู่ในเพดาน 10 GB ต่อฐานข้อมูลซึ่งเพิ่มไม่ได้ ใช้ KV เมื่องานเป็น read-heavy อย่างมาก เขียนน้อย และยอมรับ eventual consistency ได้ และใช้ Hyperdrive เมื่อคุณมี PostgreSQL หรือ MySQL อยู่แล้วและไม่ต้องการย้ายมัน แต่ต้องเข้าใจก่อนว่า cache ของมันไม่ล้างตัวเองเมื่อมีการเขียน
ความผิดพลาดที่เจอบ่อยที่สุดคือมอง D1 เป็น Postgres ที่รันที่ edge หรือมอง KV เป็น Redis ทั้งสองการเปรียบเทียบนี้ผิด และมันพาทีมไปสู่สถาปัตยกรรมที่ต้องมารื้อทำใหม่ตอนขึ้นโปรดักชัน
บทความนี้มีหน้าที่เดียวคือช่วยให้คุณเลือกตัวเก็บข้อมูลที่ถูกตัว ทุกหัวข้อจะจบด้วยเงื่อนไขการใช้ที่ชัดเจน ตัวเลขทั้งหมดมาจากเอกสารทางการของ Cloudflare ราคา ณ กรกฎาคม 2026
R2: object storage ที่ไม่คิดค่า egress
R2 คือ object storage ที่ API เข้ากันได้กับ S3 จุดขายของมันมีอยู่ข้อเดียว ค่า egress เป็นศูนย์ ตลอดเวลา ไม่มีข้อยกเว้น
ราคาเก็บอยู่ที่ 0.015 ดอลลาร์ต่อ GB ต่อเดือน มี free tier ที่ 10 GB บวก Class A 1 ล้านครั้ง และ Class B 10 ล้านครั้งต่อเดือน ส่วนเกินคิด Class A ที่ 4.50 ดอลลาร์ต่อล้านครั้ง และ Class B ที่ 0.36 ดอลลาร์ต่อล้านครั้ง ถ้าข้อมูลนาน ๆ อ่านที มี Infrequent Access ที่ 0.01 ดอลลาร์ต่อ GB ต่อเดือน บวกค่าดึงข้อมูล 0.01 ดอลลาร์ต่อ GB โดยมีเงื่อนไขเก็บขั้นต่ำ 30 วัน
ตัวอย่างเลข: เก็บไฟล์ 500 GB คิดเป็น 7.50 ดอลลาร์ต่อเดือน ไม่ว่าผู้ใช้จะดาวน์โหลดกี่เทราไบต์ก็ตาม ค่า egress ยังคงเป็นศูนย์ นี่คือเหตุผลที่ทีมที่มีทราฟฟิกดาวน์โหลดสูงย้ายมา R2 เราเทียบทั้งสองตัวไว้ใน Cloudflare R2 vs Amazon S3
ใช้เมื่อ คุณเก็บไฟล์ขนาดใหญ่ ภาพ วิดีโอ ไฟล์ที่ผู้ใช้อัปโหลด แบ็กอัป หรือ data lake โดยเฉพาะเมื่อมีการอ่านออกมาบ่อย
อย่าใช้เมื่อ คุณต้อง query หรือ filter ข้อมูล R2 ไม่ใช่ฐานข้อมูล การดึง object มาทั้งก้อนเพื่ออ่านค่าเดียวคือพาทเทิร์นที่ผิด
D1: SQL ที่มีเพดาน 10 GB
D1 คือ SQLite แบบ serverless คุณเขียน SQL จริง มี index มี transaction และเรียกจาก Worker ได้โดยตรง
ข้อจำกัดที่ต้องออกแบบรอบตั้งแต่วันแรกคือหนึ่งฐานข้อมูลเก็บได้สูงสุด 10 GB และเพิ่มไม่ได้ นี่ไม่ใช่ข้อจำกัดที่ขอเพิ่มได้ มันคือเพดาน แต่สิ่งที่คนมองข้ามคือ D1 ไม่ได้ถูกออกแบบมาให้เป็นฐานข้อมูลก้อนเดียวของทั้งระบบ มันถูกออกแบบมาให้ shard ต่อผู้เช่าหรือต่อผู้ใช้ คุณสร้างหลายฐานข้อมูลได้โดยตั้งใจ และนั่นคือวิธีใช้ที่ถูกต้อง
การคิดเงินนับเป็น rows ไม่ใช่ query
D1 คิดเงินตาม rows read และ rows written บนแผน Paid รวม rows read 25,000 ล้านแถวต่อเดือน ส่วนเกินคิด 0.001 ดอลลาร์ต่อล้านแถว รวม rows written 50 ล้านแถวต่อเดือน ส่วนเกินคิด 1.00 ดอลลาร์ต่อล้านแถว ส่วนที่เก็บรวม 5 GB ส่วนเกินคิด 0.75 ดอลลาร์ต่อ GB ต่อเดือน
สิ่งที่ทำให้บิลของทีมพุ่งคือ rows read นับจำนวนแถวที่ query สแกน ไม่ใช่จำนวนแถวที่คืน ถ้าตารางมี 5,000 แถว แล้วคุณ SELECT โดย filter คอลัมน์ที่ไม่มี index ถึงแม้จะคืนมาแค่แถวเดียว คุณก็จ่าย 5,000 rows read การสร้าง index จึงไม่ใช่แค่เรื่อง performance แต่เป็นเรื่องเงินโดยตรง
ใช้เมื่อ คุณต้องการ SQL จริง ๆ และชุดข้อมูลต่อฐานเล็กกว่า 10 GB เหมาะมากกับระบบ multi-tenant ที่แยกฐานข้อมูลต่อผู้เช่า หรือแอปที่ข้อมูลต่อผู้ใช้มีจำกัด
อย่าใช้เมื่อ คุณมีฐานข้อมูลก้อนเดียวที่โตเกิน 10 GB ต้องการ JOIN ซับซ้อนข้ามหลายตารางขนาดใหญ่ หรือต้องการฟีเจอร์ของ PostgreSQL เช่น PostGIS หรือ full-text search ขั้นสูง เราเทียบทั้งสองไว้ใน Cloudflare D1 vs PostgreSQL
KV: อ่านเยอะ เขียนน้อย และยอมรับความหน่วง
KV คือ key-value store ที่ออกแบบมาเพื่อการอ่านที่เร็วมากจากทุกที่ในโลก โดยแลกกับการเป็น eventually consistent
โครงสร้างราคาบอกทุกอย่างว่ามันถูกออกแบบมาเพื่ออะไร บนแผน Paid การอ่านรวม 10 ล้านครั้งต่อเดือน ส่วนเกินคิดเพียง 0.50 ดอลลาร์ต่อล้านครั้ง แต่การเขียน การลบ และการ list รวมอย่างละ 1 ล้านครั้งต่อเดือน ส่วนเกินคิดถึง 5.00 ดอลลาร์ต่อล้านครั้ง แพงกว่าการอ่านสิบเท่า
ขีดจำกัดที่ต้องจำ การเขียนคีย์เดิมซ้ำทำได้ 1 ครั้งต่อวินาทีเท่านั้น ทั้งแผน Free และ Paid ขนาด key สูงสุด 512 ไบต์ ขนาด value สูงสุด 25 MiB ค่า cacheTtl ต่ำสุดคือ 30 วินาที และ Worker หนึ่งครั้งทำ operation ได้สูงสุด 1,000 รายการ
สิ่งที่คนมักลืมคือทุก operation โดนคิดเงิน รวมถึงการอ่าน key ที่ไม่มีอยู่แล้วคืน null กลับมา เพราะคำขอนั้นยังวิ่งผ่านโครงสร้างพื้นฐานของ KV อยู่ดี
ใช้เมื่อ งานอ่านเยอะเขียนน้อยและยอมรับความหน่วงได้ เช่น feature flag ค่า config ตาราง routing หรือ cache ของ API response ที่ไม่เปลี่ยนบ่อย
อย่าใช้เมื่อ คุณต้องอ่านค่าที่เพิ่งเขียนไปกลับมาทันที ต้องนับหรือเพิ่มค่าแบบ atomic หรือต้องเขียนคีย์เดิมถี่กว่า 1 ครั้งต่อวินาที งานเหล่านี้คือของ Durable Objects
Hyperdrive: เก็บ Postgres ไว้ที่เดิม
Hyperdrive ไม่ใช่ฐานข้อมูล มันคือ connection pooling บวก query caching ที่ทำให้ Worker เรียก PostgreSQL หรือ MySQL ที่คุณมีอยู่แล้วได้โดยไม่ต้องย้ายฐานข้อมูล มันฟรีบนแผน Workers Paid
กับดักที่ต้องรู้ก่อนเปิดใช้
Hyperdrive ไม่ล้าง cache ของตัวเองเมื่อมีการเขียน ค่าเริ่มต้นของ max_age คือ 60 วินาที และ stale_while_revalidate คือ 15 วินาที แปลว่าถ้าคุณชี้ config ที่เปิด cache ตามค่าเริ่มต้นไปที่ตาราง sessions หรือ permissions คุณกำลังเปิดช่องโหว่ด้านความถูกต้องนาน 60 วินาที ผู้ใช้ที่คุณเพิ่งถอนสิทธิ์ออกไปอาจยังเข้าถึงข้อมูลได้อีกหนึ่งนาทีเต็ม
วิธีที่ถูกคือเปิด cache เฉพาะกับข้อมูลที่เปลี่ยนช้า เช่น แคตตาล็อกสินค้า หรือตารางอ้างอิง และปิด cache สำหรับทุกอย่างที่ความถูกต้องสำคัญกว่าความเร็ว รายละเอียดการตั้งค่าอยู่ใน Cloudflare Hyperdrive กับ PostgreSQL
ใช้เมื่อ คุณมี Postgres หรือ MySQL ที่ใช้งานอยู่แล้ว ไม่อยากย้าย และต้องการให้ Worker เข้าถึงมันโดยไม่เปิด connection ใหม่ทุกคำขอ
อย่าใช้เมื่อ คุณกำลังสร้างระบบใหม่ทั้งหมดและยังไม่มีฐานข้อมูลเดิม หรือคุณเปิด cache โดยไม่เข้าใจว่าข้อมูลชุดไหนทนต่อความเก่า 60 วินาทีได้
ตารางเปรียบเทียบ (ราคา ณ กรกฎาคม 2026)
| บริการ | ชนิด | Consistency | เพดานที่สำคัญ | ราคาหลัก |
|---|---|---|---|---|
| R2 | Object storage | Strong ต่อ object | ไม่มีเพดานขนาดฐานข้อมูล | 0.015 ดอลลาร์/GB/เดือน + egress ศูนย์ |
| D1 | SQL (SQLite) | Strong | 10 GB ต่อฐานข้อมูล เพิ่มไม่ได้ | 0.001 ดอลลาร์/ล้าน rows read, 1.00 ดอลลาร์/ล้าน rows written |
| KV | Key-value | Eventual | value 25 MiB, เขียนคีย์เดิม 1 ครั้ง/วินาที | อ่าน 0.50 ดอลลาร์/ล้าน, เขียน 5.00 ดอลลาร์/ล้าน |
| Hyperdrive | Proxy หน้าฐานข้อมูลเดิม | ขึ้นกับฐานข้อมูล แต่ cache ไม่ล้างตอนเขียน | max_age 60 วินาที (ค่าเริ่มต้น) | ฟรีบน Workers Paid |
ตารางตัดสินใจ
| ถ้าคุณต้องการ | ให้ใช้ |
|---|---|
| เก็บไฟล์ที่ผู้ใช้อัปโหลด ภาพ วิดีโอ | R2 |
| ส่งข้อมูลออกนอกปริมาณมาก (กลัวค่า egress) | R2 |
| เก็บแบ็กอัป หรือไฟล์ที่นานๆเข้าถึงที | R2 Infrequent Access |
| SQL ต่อผู้เช่า ชุดข้อมูลต่ำกว่า 10 GB | D1 (หนึ่งฐานต่อ tenant) |
| ฐานข้อมูลก้อนเดียวที่โตเกิน 10 GB | PostgreSQL ผ่าน Hyperdrive |
| Feature flag, config, routing table | KV |
| Cache ของ API response ที่ไม่เปลี่ยนบ่อย | KV |
| ตัวนับที่เพิ่มค่าแบบ atomic ห้ามนับพลาด | Durable Objects (ไม่ใช่ KV) |
| Session หรือ permission ที่ต้องอัปเดตทันที | Postgres ผ่าน Hyperdrive โดยปิด cache |
| มี Postgres อยู่แล้วไม่อยากย้าย | Hyperdrive |
| Vector สำหรับ semantic search | Vectorize |
ตัวอย่างจริง: SaaS แบบ multi-tenant
สมมติคุณทำ SaaS สำหรับคลินิก มีลูกค้าองค์กร 300 ราย แต่ละรายมีข้อมูลคนไข้ของตัวเอง การกระจายเก็บข้อมูลจะเป็นแบบนี้
ไฟล์แนบ ภาพสแกน เอกสารที่อัปโหลด ไป R2 เพราะข้อมูลเหล่านี้ถูกอ่านซ้ำๆ โดยผู้ใช้ และค่า egress ที่เป็นศูนย์ทำให้ต้นทุนคาดเดาได้ เก็บ 500 GB คิดเป็น 7.50 ดอลลาร์ต่อเดือนไม่ว่าจะมีคนดาวน์โหลดกี่ครั้ง
ข้อมูลการสัมภาษณ์ต่อคลินิก ไป D1 หนึ่งฐานต่อหนึ่งคลินิก เพดาน 10 GB กลายเป็นข้อดีตรงนี้ มันบังคับให้คุณแยกข้อมูลลูกค้าออกจากกัน ซึ่งเป็นสิ่งที่ทีม SaaS ส่วนใหญ่ควรทำอยู่แล้วด้วยเหตุผลด้านความปลอดภัย คลินิกหนึ่งจะไม่มีทางอ่านข้อมูลของอีกคลินิกได้เลย แม้ query จะพลาด
Feature flag และ config ของแต่ละคลินิก ไป KV อ่านทุกคำขอ เขียนนานๆครั้ง เป็นโปรไฟล์ที่ KV ทำได้ดีที่สุด และความหน่วงไม่กี่วินาทีไม่เสียหาย
ตารางลูกค้าหลัก การเรียกเก็บเงิน และบัญชี อยู่ใน PostgreSQL เดิมของทีม เข้าถึงผ่าน Hyperdrive ไม่ต้องย้าย ไม่ต้องเขียนใหม่
จุดที่ต้องระมัดระวังคือตาราง sessions และ permissions อย่าชี้ Hyperdrive config ที่เปิด cache ตามค่าเริ่มต้นไปที่ตารางเหล่านี้ เพราะ max_age 60 วินาทีแปลว่าการเพิกถอนสิทธิ์จะมีผลช้าหนึ่งนาที ให้แยก config ออกเป็นสองตัว ตัวหนึ่งเปิด cache สำหรับข้อมูลที่เปลี่ยนช้า อีกตัวปิด cache สำหรับทุกอย่างที่ต้องถูกต้องทันที
เมื่อไหร่ที่ทางเลือกอื่นดีกว่า
Cloudflare ไม่ได้ชนะทุกกรณี และตรงนี้คือจุดที่มันแพ้
ถ้าฐานข้อมูลหลักของคุณโตเกิน 10 GB และแยกต่อ tenant ไม่ได้ D1 จบที่ตรงนั้น ไม่มีทางเลี่ยง คุณต้องใช้ PostgreSQL หรือ MySQL จริง ๆ แล้วให้ Hyperdrive เป็นสะพานเข้าถึง
ถ้าคุณต้องการฟีเจอร์ขั้นสูงของ PostgreSQL เช่น PostGIS สำหรับงาน geospatial, window function ที่ซับซ้อน หรือ full-text search ที่จริงจัง D1 จะทำให้คุณผิดหวัง
และถ้าทีมของคุณต้องการ write ที่มีความถี่สูงมากต่อคีย์ เกิน 1 ครั้งต่อวินาที KV ไม่ใช่คำตอบ และการเขียนที่ 5.00 ดอลลาร์ต่อล้านครั้งจะแพงอย่างรวดเร็วถ้าคุณใช้มันเป็นที่เก็บข้อมูลทั่วไป
สรุป
การเลือกตัวเก็บข้อมูลบน Cloudflare จบด้วยสามคำถาม ข้อมูลนี้เป็นไฟล์หรือเป็นระเเบบตาราง ต้องการอ่านทันทีหลังเขียนหรือยอมหน่วงได้ และมีฐานข้อมูลเดิมอยู่แล้วหรือเปล่า ตอบสามคำถามนี้ได้ก็เหลือทางเลือกเดียว
Cipher ออกแบบและพัฒนาระบบบน Cloudflare Developer Platform ให้ธุรกิจในประเทศไทย และรับประเมินสถาปัตยกรรมการเก็บข้อมูลที่มีอยู่เพื่อดูว่าข้อมูลชุดไหนควรอยู่ที่ไหน
คำถามที่พบบ่อย
D1 เก็บข้อมูลได้สูงสุดเท่าไหร่
หนึ่งฐานข้อมูล D1 เก็บได้สูงสุด 10 GB และเพิ่มไม่ได้ นี่ไม่ใช่ข้อจำกัดที่ขอเพิ่มได้ แต่เป็นเพดานของตัวผลิตภัณฑ์ D1 ถูกออกแบบมาให้ shard ต่อผู้เช่าหรือต่อผู้ใช้ จึงควรสร้างหลายฐานข้อมูลแทนที่จะยัดทุกอย่างไว้ฐานเดียว
R2 คิดค่า egress หรือไม่
ไม่คิด ค่า egress ของ R2 เป็นศูนย์เสมอ คุณจ่ายเฉพาะค่าเก็บที่ 0.015 ดอลลาร์ต่อ GB ต่อเดือน และค่า operation ที่ Class A 4.50 ดอลลาร์ต่อล้านครั้ง และ Class B 0.36 ดอลลาร์ต่อล้านครั้ง ราคา ณ กรกฎาคม 2026
KV กับ D1 ต่างกันอย่างไร
KV เป็น key-value ที่ eventually consistent ออกแบบมาเพื่อการอ่านที่มากและการเขียนที่น้อย ส่วน D1 เป็น SQL จริงที่ strongly consistent มี index และ transaction กฎง่าย ๆ คือ ถ้าคุณต้อง query ข้อมูลให้ใช้ D1 ถ้าคุณแค่ดึงค่าตามคีย์ให้ใช้ KV
Hyperdrive ล้าง cache เมื่อมีการเขียนหรือไม่
ไม่ล้าง Hyperdrive ไม่ invalidate cache เมื่อมีการเขียน ค่าเริ่มต้นของ max_age คือ 60 วินาที และ stale_while_revalidate คือ 15 วินาที การชี้ config ที่เปิด cache ตามค่าเริ่มต้นไปที่ตาราง sessions หรือ permissions เท่ากับการเปิดช่องโหว่ด้านความถูกต้องนาน 60 วินาที
ควรใช้ D1 หรือ PostgreSQL
ใช้ D1 เมื่อชุดข้อมูลต่อฐานเล็กกว่า 10 GB และคุณแยกข้อมูลต่อ tenant ได้ ซึ่งเป็นรูปแบบที่ D1 ถูกออกแบบมารองรับ ใช้ PostgreSQL เมื่อฐานข้อมูลก้อนเดียวโตเกิน 10 GB หรือคุณต้องการฟีเจอร์ขั้นสูง เช่น PostGIS หรือ full-text search แล้วใช้ Hyperdrive เป็นสะพานเข้าถึงจาก Worker
