คำตอบสั้น: ใช้ D1 เมื่อข้อมูลของคุณแตกออกเป็นก้อนเล็ก ๆ ได้ตามธรรมชาติ เช่น หนึ่งฐานข้อมูลต่อหนึ่งลูกค้า หนึ่งต่อหนึ่งผู้ใช้ หรือหนึ่งต่อหนึ่งอุปกรณ์ และแต่ละก้อนไม่เกิน 10 GB ซึ่งเป็นเพดานที่เพิ่มไม่ได้ ไม่ควรใช้ D1 เมื่อคุณมีตารางกลางก้อนเดียวที่โตไม่หยุด ต้อง join ข้ามตารางหนัก ๆ หรือพึ่ง extension อย่าง PostGIS และ pgvector กรณีเหล่านี้ PostgreSQL ยังเป็นคำตอบที่ถูกต้อง และคุณยังต่อมันเข้ากับ Workers ได้อยู่ดีผ่าน Hyperdrive
ทีมวิศวกรรมในไทยที่เริ่มมอง Cloudflare Workers อย่างจริงจังมักจะติดคำถามเดียวกันเสมอ ถ้าย้าย compute ขึ้นไปอยู่บน edge แล้วฐานข้อมูลจะอยู่ตรงไหน คำตอบที่ Cloudflare เสนอมาคือ D1 ฐานข้อมูล SQL แบบ serverless ที่ผูกเข้ากับ Worker ด้วย binding ไม่ต้องจัดการ connection pool ไม่ต้องเปิดพอร์ต ไม่ต้องจ่ายค่าอินสแตนซ์ที่นั่งว่างอยู่ตอนตีสาม
ปัญหาคือคนจำนวนมากอ่านคำว่า ฐานข้อมูล SQL แบบ serverless แล้วแปลในใจว่า PostgreSQL ที่ไม่ต้องดูแล ซึ่งไม่ใช่เลย D1 คือ SQLite และมันมีเพดานที่แข็งพอจนสถาปัตยกรรมของคุณต้องออกแบบรอบเพดานนั้นตั้งแต่วันแรก ไม่ใช่ค่อยมาแก้ตอนลูกค้ารายที่สามร้องว่าระบบช้า
บทความนี้จะบอกว่าเพดานพวกนั้นคืออะไร ตัวเลขทั้งหมดมาจากเอกสารทางการของ Cloudflare (ตรวจสอบ ณ กรกฎาคม 2026) และงานประเภทไหนที่ควรอยู่บน Postgres ต่อไปโดยไม่ต้องรู้สึกผิดว่าตัวเองตกยุค
D1 คืออะไรกันแน่
D1 คือ SQLite ที่ Cloudflare รันให้บนโครงสร้างพื้นฐานของตัวเอง แต่ละฐานข้อมูล D1 หนึ่งตัวถูกหนุนหลังด้วย Durable Object หนึ่งตัว นี่ไม่ใช่รายละเอียดปลีกย่อยทางเทคนิค แต่เป็นสิ่งที่อธิบายพฤติกรรมเกือบทั้งหมดของ D1 ตั้งแต่เพดานขนาด ไปจนถึงเรื่อง throughput
เพดาน 10 GB ที่เพิ่มไม่ได้
ฐานข้อมูล D1 หนึ่งตัวเก็บข้อมูลได้สูงสุด 10 GB บนแผน Workers Paid และ 500 MB บนแผนฟรี เอกสารของ Cloudflare เขียนกำกับไว้ตรง ๆ ว่าเพดาน 10 GB นี้เพิ่มไม่ได้ ไม่ใช่ ติดต่อฝ่ายขายแล้วคุยกันได้ แต่คือ เพิ่มไม่ได้
ถ้าคุณอ่านประโยคนั้นแล้วคิดว่า 10 GB ก็เยอะอยู่นะ ให้ลองคิดใหม่ในบริบทของตารางที่โตแบบ append-only เช่น ตาราง events, audit log, หรือ order line items ของ e-commerce ที่มีทราฟฟิกจริง ตารางแบบนั้นชน 10 GB ภายในไม่กี่เดือน แล้วคุณจะเจอ SQLITE_FULL ตอนที่คุณไม่อยากเจอที่สุด
สิ่งสำคัญคือ Cloudflare ไม่ได้มองว่านี่เป็นข้อบกพร่อง เอกสารระบุตรง ๆ ว่า D1 ออกแบบมาเพื่อ scale out ในแนวนอนด้วยฐานข้อมูลเล็ก ๆ หลายตัว เช่น หนึ่งฐานข้อมูลต่อหนึ่งผู้ใช้ ต่อหนึ่ง tenant หรือต่อหนึ่ง entity คุณสร้างได้ถึง 50,000 ฐานข้อมูลต่อบัญชีบนแผน Workers Paid และขอเพิ่มได้ถึงระดับหลายล้านฐานข้อมูล โดยพื้นที่จัดเก็บรวมทั้งบัญชีเริ่มต้นที่ 1 TB (ขอเพิ่มได้เช่นกัน) พูดอีกแบบคือ D1 ไม่ได้เป็นฐานข้อมูลกลางหนึ่งก้อนที่คุณคุ้นเคย มันคือกล่องเครื่องมือสำหรับสร้างฐานข้อมูลเป็นหมื่นก้อน
หนึ่งฐานข้อมูล คือ หนึ่งเธรด
เพราะ D1 แต่ละตัวคือ Durable Object ตัวเดียว มันจึงเป็น single-threaded และประมวลผล query ทีละตัว เอกสารของ Cloudflare อธิบายผลลัพธ์ของเรื่องนี้ไว้ชัดมาก throughput ของคุณผูกตรงกับระยะเวลาของ query
ถ้า query เฉลี่ยใช้เวลา 1 มิลลิวินาที คุณจะรันได้ประมาณ 1,000 query ต่อวินาที ถ้า query เฉลี่ยใช้เวลา 100 มิลลิวินาที คุณจะเหลือประมาณ 10 query ต่อวินาที เมื่อฐานข้อมูลรับ request พร้อมกันมากเกินไป มันจะพยายามเข้าคิวก่อน และเมื่อคิวเต็มมันจะคืน error overloaded กลับมา
นี่คือเหตุผลว่าทำไม index ใน D1 ไม่ใช่ nice to have แต่เป็นเรื่องเป็นเรื่องตาย query ที่ full table scan ไม่ได้แค่ทำให้บิลแพงขึ้น (D1 คิดเงินตาม rows read) แต่มันกินเวลาของเธรดเดียวที่ฐานข้อมูลนั้นมี และทำให้ทุกคนที่ต่อฐานข้อมูลเดียวกันรอ
ข้อจำกัดระดับ SQL ที่คนมักลืมอ่าน
นอกจากเพดานขนาด ยังมีข้อจำกัดอีกชุดที่จะกัดคุณตอน implement ไม่ใช่ตอนออกแบบ ตารางหนึ่งมีได้สูงสุด 100 คอลัมน์ แถวหนึ่ง หรือค่า string หรือ BLOB หนึ่งค่า ใหญ่ได้สูงสุด 2 MB คำสั่ง SQL หนึ่งคำสั่งยาวได้สูงสุด 100 KB bound parameter ต่อหนึ่ง query มีได้สูงสุด 100 ตัว และ query หนึ่งตัวรันได้นานสูงสุด 30 วินาที
ที่สำคัญไม่แพ้กันคือ Worker หนึ่ง invocation เปิด connection ไปหา D1 พร้อมกันได้สูงสุด 6 connection ซึ่งเป็นเพดานเดียวกับ simultaneous outgoing connections ของ Workers และจำนวน query ต่อหนึ่ง invocation จำกัดที่ 1,000 บนแผน Paid (50 บนแผนฟรี) ถ้าโค้ดของคุณมีลูปที่ยิง query ต่อหนึ่งแถว คุณจะชนเพดานนี้เร็วกว่าที่คิด
D1 กับ PostgreSQL ต่างกันตรงไหนบ้าง
ตารางนี้เทียบเฉพาะจุดที่มีผลต่อการตัดสินใจจริง ๆ ไม่ใช่ feature checklist ที่ไม่มีใครใช้
| ประเด็น | Cloudflare D1 | PostgreSQL (RDS / Cloud SQL / self-hosted) |
|---|---|---|
| เอนจิน | SQLite | PostgreSQL |
| ขนาดสูงสุดต่อฐานข้อมูล | 10 GB (Workers Paid) เพิ่มไม่ได้ | จำกัดด้วยดิสก์ที่คุณจ่ายไหว หลายเทระไบต์เป็นเรื่องปกติ |
| จำนวนฐานข้อมูล | 50,000 ต่อบัญชี (Workers Paid) ขอเพิ่มได้ | ปกติไม่กี่ตัว การมีเป็นหมื่นตัวคือฝันร้ายด้าน operation |
| รูปแบบการ scale | Scale out แตกเป็นฐานข้อมูลเล็กหลายตัว | Scale up เครื่องใหญ่ขึ้น บวก read replica |
| Concurrency | Single-threaded ต่อหนึ่งฐานข้อมูล ประมวลผลทีละ query | Multi-process รับ connection พร้อมกันได้จำนวนมาก |
| Extension | ไม่มี ไม่มี PostGIS ไม่มี pgvector ไม่มี TimescaleDB | ระบบ extension ที่โตเต็มวัย |
| ชนิดข้อมูล | ชุดพื้นฐานของ SQLite (ไม่มี native enum, array, jsonb, uuid) | ครบ รวมถึง jsonb, array, range, uuid, custom type |
| Stored procedure / trigger ซับซ้อน | ไม่รองรับแบบ PL/pgSQL | รองรับเต็มรูปแบบ |
| การเชื่อมต่อจาก Workers | Binding ตรง ไม่มี connection pool ให้จัดการ | ต้องผ่าน Hyperdrive หรือ HTTP proxy เพราะ Workers เปิดได้แค่ 6 connection ต่อ invocation |
| Point-in-time recovery | Time Travel ย้อนได้ 30 วัน (Workers Paid) | ขึ้นกับผู้ให้บริการ ปกติ 7 ถึง 35 วัน |
| เครื่องมือและ ecosystem | ยังบาง Wrangler บวก ORM ที่รองรับ D1 | สามสิบปีของเครื่องมือ ทีมที่รู้จริงหาง่าย |
ราคา ณ กรกฎาคม 2026
โมเดลราคาของ D1 ต่างจาก Postgres แบบสิ้นเชิง คุณไม่ได้จ่ายค่าเครื่องรายชั่วโมง คุณจ่ายตามจำนวนแถวที่อ่าน แถวที่เขียน และพื้นที่ที่ใช้ ถ้าไม่มีใครยิง query ก็ไม่มีค่า compute
| รายการ | Workers Free | Workers Paid |
|---|---|---|
| Rows read | 5 ล้านแถวต่อวัน | 25,000 ล้านแถวต่อเดือนรวมในแผน ส่วนเกิน 0.001 ดอลลาร์ต่อล้านแถว |
| Rows written | 100,000 แถวต่อวัน | 50 ล้านแถวต่อเดือนรวมในแผน ส่วนเกิน 1.00 ดอลลาร์ต่อล้านแถว |
| พื้นที่จัดเก็บ | 5 GB รวมทั้งบัญชี | 5 GB รวมในแผน ส่วนเกิน 0.75 ดอลลาร์ต่อ GB ต่อเดือน |
| ค่า egress | ไม่มี | ไม่มี |
| ค่า compute ของฐานข้อมูลเอง | ไม่มี | ไม่มี (แต่ Worker ที่เรียก D1 คิดตามราคา Workers ปกติ) |
ตัวเลขที่ควรจำคือ rows read ถูกมาก แต่ rows written แพงกว่าพันเท่า ระบบที่เขียนหนักและอ่านน้อยจึงเป็นระบบที่ D1 คิดเงินคุณแรงที่สุด และอย่าลืมว่า index ที่คุณสร้างก็เพิ่ม rows written ด้วย เพราะเขียนหนึ่งครั้งลงตาราง และอีกหนึ่งครั้งลง index
อีกจุดที่คนพลาดคือคำว่า rows read หมายถึงแถวที่ถูก scan ไม่ใช่แถวที่ถูกส่งกลับ ถ้าตารางมี 5,000 แถวแล้วคุณรัน SELECT ที่ filter บนคอลัมน์ที่ไม่มี index ต่อให้ได้ผลลัพธ์กลับมาแถวเดียว คุณก็โดนนับ 5,000 rows read
ตัวอย่างที่แมปกับระบบจริงได้: SaaS multi-tenant 5,000 ราย
สมมติคุณทำระบบ SaaS จัดการสต็อกสำหรับร้านค้าปลีก มีลูกค้า 5,000 ราย แต่ละรายเป็นร้านค้าอิสระที่ไม่มีเหตุผลใดต้องเห็นข้อมูลของกันและกันเลย ข้อมูลของร้านที่ใหญ่ที่สุดอยู่ที่ราว 2 GB ร้านทั่วไปอยู่แถว 50 ถึง 300 MB
รูปแบบ database-per-tenant
นี่คือรูปทรงที่ D1 ถูกออกแบบมาเพื่อรองรับตรง ๆ คุณสร้าง D1 หนึ่งฐานข้อมูลต่อหนึ่งร้าน 5,000 ฐานข้อมูล ซึ่งอยู่ในเพดาน 50,000 ต่อบัญชีสบาย ๆ แล้วให้ Worker route request ไปยังฐานข้อมูลของ tenant ที่ถูกต้องตาม subdomain หรือ JWT claim
สิ่งที่คุณได้มาฟรี ๆ คือการแยกข้อมูลระดับ physical ไม่มีทางที่ bug ใน WHERE clause จะทำให้ร้าน A เห็นข้อมูลร้าน B เพราะข้อมูลมันคนละฐานข้อมูลกันจริง ๆ ทีมที่เคยเขียน row-level security บน Postgres แล้วนอนไม่หลับจะเข้าใจว่าเรื่องนี้มีค่าแค่ไหน คุณยังได้ blast radius ที่เล็กลงด้วย ร้านหนึ่งยิง query โง่ ๆ ที่ full table scan ก็ทำให้ช้าเฉพาะร้านตัวเอง ไม่ลากทั้งระบบลงไปเหมือนตอนที่ทุกคนใช้ Postgres instance เดียวกัน
ต้นทุนคร่าว ๆ
สมมติทั้งระบบอ่านรวมกัน 2,000 ล้านแถวต่อเดือน และเขียน 20 ล้านแถวต่อเดือน พื้นที่รวม 400 GB ตามราคา ณ กรกฎาคม 2026 rows read และ rows written ยังอยู่ในโควตาที่รวมมาในแผน Workers Paid ทั้งคู่ (25,000 ล้าน และ 50 ล้าน ตามลำดับ) เหลือแต่พื้นที่ 400 GB ลบ 5 GB ที่รวมมา คูณ 0.75 ดอลลาร์ต่อ GB ต่อเดือน เท่ากับราว 296 ดอลลาร์ต่อเดือน บวกค่า Workers Paid 5 ดอลลาร์ และค่า request ของ Worker เอง
ประเด็นไม่ใช่ว่ามันถูกกว่า RDS เสมอ (บางเคสไม่ถูกกว่าเลย) ประเด็นคือคุณไม่ต้องจ่ายค่าเครื่องที่ว่างอยู่ และคุณไม่ต้องจ้างคนมาดูแล connection pool, failover, กับ vacuum
สิ่งที่คุณต้องเขียนเอง
อย่ามองข้ามข้อนี้ พอคุณมี 5,000 ฐานข้อมูล การ migrate schema ไม่ใช่การรัน migration ครั้งเดียวอีกต่อไป มันคือการรัน 5,000 ครั้ง คุณต้องมีระบบที่ทำ migration แบบทยอย ติดตามสถานะว่าฐานข้อมูลไหนอยู่ schema version ไหน และ rollback ได้เมื่อพัง
รายงานรวมข้าม tenant ก็เป็นอีกเรื่อง คุณ join ข้ามฐานข้อมูล D1 ไม่ได้ ถ้าอยากรู้ว่าสินค้าตัวไหนขายดีที่สุดทั้งแพลตฟอร์ม คุณต้องมี pipeline ที่ดึงข้อมูลออกไปกองไว้ที่อื่น เช่น R2 บวก analytics engine หรือ Postgres สักตัวสำหรับงาน analytics โดยเฉพาะ นี่คือต้นทุนวิศวกรรมจริงที่ต้องเอาไปใส่ในสมการตั้งแต่ต้น
เมื่อไหร่ที่ PostgreSQL คือคำตอบที่ถูกต้อง
ส่วนนี้สำคัญที่สุดในบทความ เพราะกรณีที่ D1 เป็นตัวเลือกผิดนั้นมีเยอะกว่าที่คนขาย Cloudflare จะยอมบอกคุณ
ข้อมูลก้อนเดียวที่โตเกิน 10 GB
ถ้าโดเมนของคุณไม่มีเส้นแบ่งตามธรรมชาติ เช่น social network ที่ผู้ใช้ทุกคนเชื่อมถึงกัน หรือ marketplace ที่ต้องค้นหาข้ามผู้ขายทั้งหมด คุณจะแตก shard ไม่ได้โดยไม่สร้าง distributed join ขึ้นมาเอง ซึ่งเป็นงานที่ยากและคุณจะทำได้แย่กว่าที่ Postgres ทำอยู่แล้ว ในกรณีนี้ 10 GB คือกำแพงตัน ไม่ใช่ความท้าทาย
Query ที่ join หนักและงาน analytics
SQLite เก่งเรื่อง lookup ด้วย index มันไม่ได้เก่งเรื่อง query แบบ join เจ็ดตารางพร้อม window function และ CTE ซ้อนกันสามชั้น query planner ของ PostgreSQL สุกงอมกว่ามาก มี statistics ที่ละเอียดกว่า มี parallel query execution และคุณมี EXPLAIN ANALYZE ที่บอกได้จริง ๆ ว่าเกิดอะไรขึ้น ถ้าธุรกิจของคุณอยู่บนรายงานที่ซับซ้อน D1 จะทำให้ชีวิตคุณแย่ลง ไม่ใช่ดีขึ้น
Extension: PostGIS, pgvector, TimescaleDB
ระบบโลจิสติกส์ที่ต้องหาคนขับที่ใกล้ที่สุดในรัศมี 3 กิโลเมตรต้องการ spatial index ระบบ RAG ที่ต้องหาเอกสารที่ใกล้เคียงที่สุดจาก embedding ต้องการ vector index ระบบ IoT ที่เก็บ time series ต้องการ hypertable D1 ไม่มีอะไรเลยในสามอย่างนี้ และจะไม่มี เพราะ SQLite ไม่มีระบบ extension แบบเดียวกับ Postgres นี่ไม่ใช่ช่องว่างที่รอเติม แต่เป็นความต่างเชิงสถาปัตยกรรม
ทีมและเครื่องมือ
เรื่องที่ไม่ค่อยมีใครพูดถึงในบทความเทคนิค ถ้าทีมของคุณมี DBA ที่รู้ Postgres ลึก มีระบบ monitoring ที่ตั้งไว้แล้ว มี runbook สำหรับทุก incident การย้ายไป D1 คือการทิ้งทุนก้อนนั้นทั้งหมดแล้วเริ่มใหม่ Cloudflare มี Time Travel ที่ย้อนได้ 30 วันซึ่งดีมาก แต่ ecosystem ของเครื่องมือรอบ D1 ยังบางกว่า Postgres หลายขุม การ debug query ที่ช้าบน D1 ยังลำบากกว่ามาก
งานที่ต้องเขียนหนักและอ่านเบา
ดูราคาอีกครั้ง rows written คิด 1.00 ดอลลาร์ต่อล้านแถว ระบบที่ ingest ข้อมูลเป็นสิบล้านแถวต่อวัน เช่น telemetry หรือ clickstream จะจ่ายเงินก้อนใหญ่ให้ D1 โดยที่ Postgres บนเครื่องขนาดกลางทำงานเดียวกันได้ในราคาที่ถูกกว่ามาก งานประเภทนี้ควรอยู่บน Postgres หรือไปที่ R2 บวก analytics store ไปเลย
ทางสายกลางที่ทีมส่วนใหญ่ลงเอย
คำถาม D1 หรือ Postgres มักเป็นคำถามผิด คำถามที่ถูกกว่าคือ ข้อมูลชิ้นไหนควรอยู่ที่ไหน
รูปทรงที่เราเห็นบ่อยคือ ข้อมูล operational ของ tenant ที่ต้องอ่านเร็วและแยกขาดจากกัน อยู่บน D1 หนึ่งฐานข้อมูลต่อหนึ่ง tenant ส่วนข้อมูลกลางที่ต้อง join ข้าม tenant ทำ analytics และใช้ extension อยู่บน PostgreSQL เดิมที่คุณมีอยู่แล้ว โดย Worker คุยกับ Postgres ผ่าน Hyperdrive ซึ่งแก้ปัญหา connection pool exhaustion ที่เกิดจากการที่ Worker เปิด connection ได้แค่ 6 ตัวต่อ invocation และช่วย cache query ที่อ่านซ้ำ ๆ ด้วย
ถ้าคุณยังไม่แน่ใจว่าควรเอา compute ขึ้น Workers ตั้งแต่แรกหรือเปล่า เราเขียนเรื่อง เมื่อไหร่ที่ไม่ควรใช้ Cloudflare Workers ไว้แล้ว และถ้ากำลังเทียบกับ serverless เจ้าอื่นอยู่ ลองอ่าน Cloudflare Workers เทียบกับ AWS Lambda ประกอบ
เช็คลิสต์ก่อนตัดสินใจ
ตอบสามคำถามนี้ให้ได้ก่อน ถ้าตอบไม่ได้แปลว่ายังไม่ถึงเวลาย้าย
หนึ่ง คุณแบ่ง shard ตามอะไร ถ้าคำตอบคือ ยังไม่รู้ ให้อยู่กับ Postgres ก่อน สอง ฐานข้อมูลก้อนที่ใหญ่ที่สุดของคุณจะโตถึงเท่าไหร่ใน 24 เดือน ถ้าคำตอบเกิน 10 GB D1 ไม่ใช่คำตอบสำหรับข้อมูลชุดนั้น สาม คุณใช้ extension หรือชนิดข้อมูลเฉพาะของ Postgres อะไรอยู่บ้าง ให้ไล่ดู schema จริง ไม่ใช่เดา ทุกตัวที่เจอคือหนี้ที่คุณต้องจ่ายด้วยโค้ดในฝั่งแอปพลิเคชัน
Cipher ออกแบบและ implement ระบบบน Cloudflare Developer Platform ให้ธุรกิจในประเทศไทย ถ้าคุณกำลังชั่งใจระหว่าง D1, Hyperdrive กับ PostgreSQL เดิมที่มีอยู่ เรารับประเมินสถาปัตยกรรมและบอกตรง ๆ ได้ว่าอันไหนเหมาะกับข้อมูลของคุณจริง รวมถึงกรณีที่คำตอบคือ อยู่กับ Postgres ต่อไปเถอะ
คำถามที่พบบ่อย
ขยายฐานข้อมูล D1 ให้เกิน 10 GB ได้ไหม
ไม่ได้ เอกสารของ Cloudflare ระบุชัดว่าเพดาน 10 GB ต่อหนึ่งฐานข้อมูลบนแผน Workers Paid นั้นเพิ่มไม่ได้ ทางออกเดียวคือแตกข้อมูลออกเป็นหลายฐานข้อมูล เช่น หนึ่งฐานข้อมูลต่อหนึ่ง tenant ซึ่ง D1 ออกแบบมาเพื่อรูปแบบนี้โดยเฉพาะ และรองรับได้ถึง 50,000 ฐานข้อมูลต่อบัญชีบนแผน Workers Paid โดยขอเพิ่มได้อีก
D1 ใช้ PostGIS หรือ pgvector ได้ไหม
ไม่ได้ เพราะ D1 รันบน SQLite ไม่ใช่ PostgreSQL จึงไม่มีระบบ extension ของ Postgres เลย ถ้าระบบของคุณต้องการ geospatial index หรือ vector search ให้เก็บข้อมูลชุดนั้นไว้บน PostgreSQL ต่อไป แล้วให้ Workers ต่อเข้าไปผ่าน Hyperdrive
D1 รับ traffic ได้เท่าไหร่ต่อวินาที
เอกสารของ Cloudflare อธิบายว่าแต่ละฐานข้อมูล D1 เป็น single-threaded และประมวลผล query ทีละตัว ดังนั้น throughput ผูกตรงกับระยะเวลาของ query ถ้า query เฉลี่ย 1 มิลลิวินาที จะได้ราว 1,000 query ต่อวินาที ถ้าเฉลี่ย 100 มิลลิวินาที จะเหลือราว 10 query ต่อวินาที การใส่ index ให้ถูกจุดจึงมีผลต่อ throughput โดยตรง
ย้ายจาก PostgreSQL มา D1 ต้องแก้อะไรบ้าง
ต้องแปลง schema ให้เป็น SQLite ซึ่งหมายถึงตัด extension, stored procedure แบบ PL/pgSQL, materialized view และชนิดข้อมูลเฉพาะของ Postgres อย่าง jsonb กับ array ออก แล้วออกแบบวิธีแบ่ง shard ใหม่ให้แต่ละฐานข้อมูลไม่เกิน 10 GB ถ้าคุณยังตอบไม่ได้ว่าจะแบ่ง shard ตามอะไร แปลว่ายังไม่ควรย้าย
D1 คิดเงินอย่างไร
ราคา ณ กรกฎาคม 2026 แผน Workers Paid รวม rows read 25,000 ล้านแถวต่อเดือน และ rows written 50 ล้านแถวต่อเดือน ส่วนเกินคิด 0.001 ดอลลาร์ต่อล้าน rows read และ 1.00 ดอลลาร์ต่อล้าน rows written พื้นที่จัดเก็บรวมมา 5 GB ส่วนเกินคิด 0.75 ดอลลาร์ต่อ GB ต่อเดือน และ D1 ไม่คิดค่า egress
