คำตอบสั้น: Cloudflare Workers ไม่เหมาะกับงานที่ใช้หน่วยความจำเกิน 128 MB งานที่ต้องอ่านเขียนไฟล์ในระบบ โค้ดที่ bundle ใหญ่เกิน 10 MB งานประมวลผลที่กิน CPU เกิน 5 นาที และฐานข้อมูลที่ใหญ่กว่า 10 GB บน D1 ในกรณีเหล่านี้ Cloudflare มีบริการอื่นรองรับอยู่แล้ว ได้แก่ Containers, Workflows, Queues และ Hyperdrive
บทความส่วนใหญ่ที่พูดถึง Cloudflare Workers มักเล่าแต่ข้อดี ซึ่งไม่ผิด เพราะ Workers เป็นแพลตฟอร์มที่ดีมากในงานที่มันถูกออกแบบมาเพื่อรองรับ แต่ในฐานะทีมที่ลงมือ implement จริง เราพบว่าปัญหาที่แพงที่สุดไม่ได้เกิดตอนเขียนโค้ด แต่เกิดตอนที่ทีมเลือกเครื่องมือผิดตั้งแต่แรก แล้วมารู้ตัวตอนใกล้ขึ้น production
บทความนี้จึงเขียนในมุมกลับ คือบอกตรง ๆ ว่างานแบบไหน ไม่ควร ใช้ Workers และควรใช้อะไรแทน โดยอ้างอิงจากข้อจำกัดที่ Cloudflare ประกาศไว้อย่างเป็นทางการ ณ เดือนกรกฎาคม 2026
ข้อจำกัดจริงของ Cloudflare Workers
ก่อนจะพูดถึงสถานการณ์ ต้องเข้าใจตัวเลขจริงก่อน ตารางนี้คือข้อจำกัดที่มีผลต่อการตัดสินใจมากที่สุด
| ข้อจำกัด | Free | Paid |
|---|---|---|
| หน่วยความจำต่อ isolate | 128 MB | 128 MB |
| CPU time ต่อ request | 10 ms | 5 นาที (ค่าเริ่มต้น 30 วินาที) |
| ขนาดโค้ดหลังบีบอัด | 3 MB | 10 MB |
| ขนาดโค้ดก่อนบีบอัด | 64 MB | 64 MB |
| Startup time | 1 วินาที | 1 วินาที |
| Subrequest ต่อการเรียกหนึ่งครั้ง | 50 | 10,000 (ขยายได้ถึง 10 ล้าน) |
| การเชื่อมต่อขาออกพร้อมกัน | 6 | 6 |
| การเข้าถึงระบบไฟล์ | ไม่รองรับ | ไม่รองรับ |
ตัวเลขที่ต้องขีดเส้นใต้คือ 128 MB และ การเชื่อมต่อพร้อมกัน 6 ช่อง เพราะสองตัวนี้ เท่ากันทั้งแพ็กเกจฟรีและเสียเงิน จ่ายเงินเพิ่มก็ไม่ได้เพิ่ม ต่างจาก AWS Lambda ที่ปรับหน่วยความจำได้ตั้งแต่ 128 MB ถึง 10,240 MB
7 สถานการณ์ที่ไม่ควรใช้ Cloudflare Workers
1. งานที่ต้องโหลดข้อมูลก้อนใหญ่เข้าหน่วยความจำ
เพดาน 128 MB นับรวมทั้ง JavaScript heap และ WebAssembly ที่จองไว้ ถ้างานของคุณต้องอ่านไฟล์ CSV ขนาด 300 MB เข้ามาประมวลผลทั้งก้อน แปลงไฟล์วิดีโอ หรือโหลดโมเดล machine learning ขนาดใหญ่เข้าหน่วยความจำ Worker จะตายกลางทางและคุณแก้ด้วยการจ่ายเงินเพิ่มไม่ได้
ทางออกที่ถูกต้องคือออกแบบให้ประมวลผลแบบ stream ทีละส่วน หรือย้ายงานนั้นไป Cloudflare Containers ซึ่งจัดสรรหน่วยความจำได้มากกว่า
2. งานที่ต้องอ่านหรือเขียนไฟล์ในระบบ
Workers ไม่รองรับการเข้าถึงระบบไฟล์เลย ไม่มี /tmp ให้เขียน นี่เป็นข้อจำกัดที่ทำให้ไลบรารียอดนิยมจำนวนมากใช้ไม่ได้ทันที เช่นเครื่องมือประมวลผลภาพหรือเอกสารที่ต้องเขียนไฟล์ชั่วคราวก่อนอ่านกลับ
หลายทีมมารู้เรื่องนี้ตอนที่เขียนโค้ดไปแล้วครึ่งทาง ซึ่งเป็นจุดที่การเปลี่ยนสถาปัตยกรรมแพงที่สุด ถ้าระบบของคุณพึ่งไลบรารีที่แตะไฟล์ ให้ตรวจสอบตั้งแต่วันแรก
3. โค้ดที่ bundle ใหญ่เกินเพดาน หรือพึ่ง native Node module
แพ็กเกจ Paid จำกัดขนาดโค้ดหลังบีบอัดที่ 10 MB ซึ่งเพียงพอกับงานส่วนใหญ่ แต่ไม่พอถ้าคุณ bundle โมเดล ML หรือ dependency ขนาดใหญ่เข้าไปด้วย
ที่สำคัญกว่าคือ Workers ไม่ได้รัน Node.js เต็มรูปแบบ แม้จะมีโหมด nodejs_compat ที่ช่วยได้มาก แต่ native module ที่คอมไพล์เป็น binary ยังใช้ไม่ได้ ถ้าระบบเดิมของคุณพึ่ง native module หลายตัว การย้ายมา Workers จะไม่ใช่แค่การคัดลอกโค้ด
4. งานประมวลผลหนักที่กิน CPU เกิน 5 นาที
ต้องแยกให้ชัดระหว่าง CPU time กับเวลารอ Cloudflare นับเฉพาะเวลาที่โค้ดทำงานจริง ไม่ได้นับเวลาที่รอฐานข้อมูลหรือ API ตอบกลับ ข้อนี้เป็นข้อดีสำคัญของ Workers และเป็นจุดที่ประหยัดกว่า Lambda อย่างมีนัยสำคัญ
แต่ถ้างานของคุณ ใช้ CPU จริง นานเกิน 5 นาที เช่น การเข้ารหัสวิดีโอ การประมวลผลภาพจำนวนมากในรอบเดียว หรือ ETL ที่คำนวณหนัก Workers จะตัดการทำงานทิ้ง
งานลักษณะนี้ควรแตกเป็นขั้นตอนย่อยแล้วใช้ Workflows หรือส่งเข้า Queues ให้ทยอยประมวลผล ไม่ใช่ยัดทั้งหมดไว้ใน request เดียว
5. ระบบที่ต้องเปิดการเชื่อมต่อขาออกพร้อมกันจำนวนมาก
Workers เปิดการเชื่อมต่อขาออกพร้อมกันได้เพียง 6 ช่องต่อการเรียกหนึ่งครั้ง และเพดานนี้เท่ากันทั้งแพ็กเกจฟรีและเสียเงิน ถ้าโค้ดของคุณออกแบบมาให้ยิงคำขอขนานกัน 20 เส้นเพื่อความเร็ว คุณจะต้องออกแบบใหม่
นอกจากนี้ระบบ serverless แบบเดิมมักมีปัญหา connection pool กับฐานข้อมูล เพราะทุกการเรียกเปิด connection ใหม่ Cloudflare แก้ปัญหานี้ด้วย Hyperdrive ซึ่งทำ connection pooling และ caching ให้ ทำให้ต่อ PostgreSQL เดิมได้โดยไม่ต้องย้ายฐานข้อมูล
6. ฐานข้อมูลที่ใหญ่กว่า 10 GB บน D1
D1 คือ SQLite ที่รันบนเครือข่ายของ Cloudflare และมีเพดานชัดเจนที่ 10 GB ต่อหนึ่งฐานข้อมูล ขยายไม่ได้
นี่ไม่ใช่ข้อบกพร่อง แต่เป็นการออกแบบ Cloudflare ตั้งใจให้ D1 กระจายเป็นหลายฐานข้อมูลเล็ก ๆ เช่นแยกหนึ่งฐานข้อมูลต่อหนึ่ง tenant หรือต่อหนึ่งผู้ใช้ ซึ่งเหมาะกับ SaaS แบบ multi-tenant มาก
แต่ถ้าระบบของคุณต้องการฐานข้อมูลกลางขนาดใหญ่ที่ join ข้ามตารางหนัก ๆ D1 ไม่ใช่คำตอบ ให้ใช้ PostgreSQL ที่มีอยู่เดิมแล้วต่อผ่าน Hyperdrive แทน
7. งาน batch หรือ cron ที่ต้องรันนานเกิน 15 นาที
Cron Trigger, Queue Consumer และ Durable Object Alarm มีเพดานเวลาทำงานที่ 15 นาที งาน batch ที่ต้องรันข้ามคืนแบบยาว ๆ ในหนึ่งรอบจึงไม่เหมาะ
วิธีที่ถูกต้องคือแตกงานเป็นชิ้นเล็กแล้วให้ Queues ทยอยประมวลผล หรือใช้ Workflows ที่ออกแบบมาสำหรับงานหลายขั้นตอนที่กินเวลานานโดยเฉพาะ
แล้วควรใช้อะไรแทน
ข่าวดีคือเกือบทุกข้อจำกัดข้างต้น Cloudflare มีบริการรองรับอยู่แล้วในแพลตฟอร์มเดียวกัน คุณไม่จำเป็นต้องทิ้ง Cloudflare ทั้งระบบ
| ติดปัญหาเรื่อง | ให้ใช้แทน |
|---|---|
| หน่วยความจำเกิน 128 MB | Cloudflare Containers |
| ต้องเขียนไฟล์ หรือต้องใช้ binary | Cloudflare Containers |
| งานหลายขั้นตอน กินเวลานาน | Workflows |
| งาน batch ปริมาณมาก | Queues ร่วมกับ Workers |
| ต่อ PostgreSQL หรือ MySQL เดิม | Hyperdrive |
| ฐานข้อมูลใหญ่กว่า 10 GB | PostgreSQL ร่วมกับ Hyperdrive |
| เก็บไฟล์ขนาดใหญ่ | R2 (ไม่มีค่า egress) |
| สถานะที่ต้องประสานกันแบบ real-time | Durable Objects |
สถาปัตยกรรมที่ใช้งานได้จริงส่วนใหญ่จึงเป็นแบบผสม คือใช้ Workers เป็นชั้นหน้าสำหรับ routing และ logic ที่ตอบเร็ว แล้วส่งงานหนักไปให้ Containers, Workflows หรือ Queues จัดการต่อ
เมื่อไหร่ที่ Workers คือคำตอบที่ถูกต้อง
เพื่อความเป็นธรรม Workers เหมาะมากกับงานเหล่านี้ และมักจะดีกว่าทางเลือกอื่นอย่างชัดเจน
API ที่ต้องตอบเร็วและกระจายทั่วโลก เพราะโค้ดรันใกล้ผู้ใช้ ไม่ต้องวิ่งกลับ region เดียว และไม่มี cold start แบบที่ Lambda มี
งานที่รอ I/O เป็นหลัก เช่น API ที่เรียกบริการอื่นต่อ หรือ BFF ที่รวมข้อมูลจากหลายแหล่ง เพราะ Cloudflare คิดเงินตาม CPU time ไม่ใช่เวลารอ ระบบที่รอฐานข้อมูล 200 มิลลิวินาทีแต่ใช้ CPU จริงแค่ 5 มิลลิวินาที จะถูกคิดเงินตาม 5 มิลลิวินาที ขณะที่ Lambda คิดตาม 205 มิลลิวินาที ความต่างนี้สะสมเป็นตัวเลขที่มีนัยสำคัญเมื่อมีทราฟฟิกสูง
งานที่ต้องแทรกกลางระหว่างผู้ใช้กับระบบเดิม เช่น A/B testing, authentication gateway, image resizing, การเขียน header ใหม่ หรือการทำ edge caching ที่ซับซ้อนกว่าที่ CDN ทั่วไปทำได้
SaaS แบบ multi-tenant ที่แยกฐานข้อมูลต่อลูกค้าได้ ซึ่งเข้ากับโมเดล D1 พอดี
สรุป
Cloudflare Workers ไม่ใช่ Lambda ที่ราคาถูกกว่า แต่เป็นแพลตฟอร์มคนละแบบที่มีข้อแลกเปลี่ยนคนละชุด จุดแข็งคือความเร็ว การกระจายทั่วโลก และการคิดเงินตาม CPU time ซึ่งประหยัดกว่ามากในงานที่รอ I/O เป็นหลัก ส่วนจุดอ่อนคือเพดานหน่วยความจำ 128 MB การไม่มีระบบไฟล์ และเพดานการเชื่อมต่อ 6 ช่อง ซึ่งทั้งสามอย่างซื้อเพิ่มไม่ได้
คำถามที่ถูกต้องจึงไม่ใช่ว่า Workers ดีกว่า Lambda หรือไม่ แต่คือ งานชิ้นนี้ติดข้อจำกัดข้อไหนของ Workers บ้าง และ Cloudflare มีบริการอื่นรองรับหรือเปล่า ซึ่งส่วนใหญ่คำตอบคือมี
ที่ Cipher เราออกแบบและ implement ระบบบน Cloudflare Developer Platform ให้ธุรกิจไทย ตั้งแต่การประเมินว่างานไหนควรอยู่บน Workers และงานไหนควรย้ายไป Containers หรือ Workflows หากคุณกำลังพิจารณาย้ายระบบมา Cloudflare และอยากรู้ว่าติดข้อจำกัดตรงไหนบ้างก่อนลงมือ เราช่วยประเมินให้ได้
คำถามที่พบบ่อย
Cloudflare Workers มีหน่วยความจำเท่าไหร่
128 MB ต่อ isolate ทั้งแพ็กเกจ Free และ Paid ตัวเลขนี้ไม่สามารถซื้อเพิ่มได้ ต่างจาก AWS Lambda ที่ปรับได้ถึง 10,240 MB หากงานของคุณต้องโหลดข้อมูลก้อนใหญ่เข้าหน่วยความจำ Workers อาจไม่ใช่คำตอบ
Cloudflare Workers รันได้นานสุดกี่นาที
แพ็กเกจ Paid ให้ CPU time สูงสุด 5 นาทีต่อ request โดยค่าเริ่มต้นอยู่ที่ 30 วินาที ส่วนแพ็กเกจ Free ให้เพียง 10 มิลลิวินาที ทั้งนี้เป็นการนับ CPU time ไม่ใช่เวลารอ ดังนั้นโค้ดที่รอ API ตอบกลับนาน ๆ จะไม่ถูกนับเวลาระหว่างรอ
Cloudflare Workers เขียนไฟล์ลงดิสก์ได้ไหม
ไม่ได้ Workers ไม่รองรับการเข้าถึงระบบไฟล์เลย ไลบรารีที่ต้องเขียนไฟล์ชั่วคราว เช่น การประมวลผลภาพหรือวิดีโอบางตัว จะใช้งานบน Workers ไม่ได้ ต้องย้ายไปใช้ Cloudflare Containers แทน
D1 เก็บข้อมูลได้สูงสุดเท่าไหร่
ฐานข้อมูล D1 หนึ่งตัวเก็บได้สูงสุด 10 GB และขยายเพิ่มไม่ได้ D1 ถูกออกแบบให้กระจายเป็นหลายฐานข้อมูลเล็ก ๆ เช่น แยกต่อผู้ใช้หรือต่อ tenant หากระบบของคุณต้องการฐานข้อมูลเดียวขนาดใหญ่กว่านั้น ควรใช้ PostgreSQL ร่วมกับ Hyperdrive
ถ้า Workers ไม่เหมาะ ควรใช้บริการอะไรของ Cloudflare แทน
ขึ้นอยู่กับสาเหตุ หากติดเรื่องหน่วยความจำหรือระบบไฟล์ ให้ใช้ Cloudflare Containers หากเป็นงานหลายขั้นตอนที่ใช้เวลานาน ให้ใช้ Workflows หากเป็นงาน batch ให้ใช้ Queues และหากติดเรื่องการเชื่อมต่อฐานข้อมูลเดิม ให้ใช้ Hyperdrive
