PocketBase Cloud เพิ่มโควตา API แผน Free เป็น 5,000 ครั้งต่อชั่วโมง

PocketBase Cloud ประกาศเมื่อวันที่ 11 ตุลาคม 2026 ว่า instance บนแผน Free เรียก API ได้ 5,000 ครั้งต่อชั่วโมง จากเดิม 500 ครั้งต่อชั่วโมง การเพิ่มเพดานสิบเท่านี้มีผลกับคนทำต้นแบบ แอปขนาดเล็ก และบริการที่มีผู้ใช้จริงจำนวนน้อย เพราะช่วยลดโอกาสที่การใช้งานปกติจะชน rate limit ระหว่างการทดสอบ แต่ยังต้องวางแผนรับสถานะ 429 และติดตามปริมาณคำขอเมื่อเปิดให้คนภายนอกใช้

อะไรเปลี่ยนและอะไรยังเหมือนเดิม

ตาม changelog ของผู้ให้บริการ ตัวนับคิดเฉพาะคำขอที่เข้าพาธ /api เท่านั้น การเปิดหน้า admin และการดึงไฟล์ static ไม่ถูกนับรวม เมื่อการใช้ถึง 80% ของโควตารายชั่วโมง ระบบส่งอีเมลแจ้งเตือน หากใช้เกิน 5,000 ครั้ง API จะตอบ HTTP 429 จนถึงต้นชั่วโมงถัดไป ข้อมูลใน instance ไม่ถูกลบเพราะชนเพดาน ส่วนแผน Starter และ Pro ยังไม่จำกัดจำนวนคำขอตามเงื่อนไขนี้ ดังนั้นข่าวนี้ไม่ใช่การยกเลิก rate limit ของ Free แต่เป็นการขยับขอบเขตให้กว้างขึ้น

ต้องแยกชื่อให้ชัดด้วยว่า PocketBase Cloud เป็นบริการโฮสต์ของบุคคลที่สาม ไม่ใช่ประกาศจากโครงการ PocketBase โอเพนซอร์สโดยตรง และการเปลี่ยนโควตานี้ไม่ได้หมายความว่า PocketBase ที่ติดตั้งเองเปลี่ยนข้อกำหนดเดียวกัน ผู้ดูแลระบบที่ใช้ PocketBase บนเซิร์ฟเวอร์ของตัวเองต้องดูนโยบายของ reverse proxy และ infrastructure ที่ตนกำหนดไว้

ทำไม 5,000 ครั้งต่อชั่วโมงยังต้องคิดเรื่องโหลด

ตัวเลข 5,000 เมื่อหารเฉลี่ยเท่ากับประมาณ 83 คำขอต่อนาที แต่การใช้งานเว็บจริงมักมาเป็นช่วง ไม่ได้กระจายเท่ากันตลอดชั่วโมง หน้าเดียวอาจโหลดรายการหลายชุด เรียกข้อมูลผู้ใช้ และส่งคำขอจาก component หลายตัว หากสิบคนเปิดหน้าเดียวกันพร้อมกัน ปริมาณคำขออาจพุ่งเร็วกว่าที่คาด การ polling ทุกห้าวินาทีจาก browser ที่เปิดค้างไว้ก็สะสมจำนวนมากในหนึ่งชั่วโมง แม้จำนวนผู้ใช้งานจะดูน้อย

ทีมที่กำลังประเมินแผน Free ควรนับคำขอจาก network log ของหน้าใช้งานหลักก่อน แล้วทดสอบกรณีคนเปิดพร้อมกัน แยกการอ่านข้อมูลที่จำเป็นออกจากการเรียกซ้ำโดยไม่ตั้งใจ ตรวจ cache และ debounce ฝั่ง client สำหรับช่องค้นหา รวมถึงหยุด polling เมื่อแท็บไม่ได้ใช้งาน หากมีงาน background หรือ webhook เรียก API ให้รวมภาระเหล่านั้นในการประมาณด้วย เพราะเป็นโควตาเดียวกันของ instance

ออกแบบเมื่อได้รับ HTTP 429

อย่าให้ client retry ทุกคำขอพร้อมกันทันทีเมื่อพบ 429 เพราะจะสร้างคลื่นคำขอซ้ำและทำให้ผู้ใช้เห็นหน้าเว็บช้าลง ควรแสดงข้อความที่เข้าใจได้ เก็บข้อมูลที่ผู้ใช้กรอกไว้ และกำหนด retry แบบมีช่วงรอพร้อม jitter สำหรับงานที่ retry ได้ สำหรับคำขอเขียนข้อมูลต้องระวังการส่งซ้ำหลัง timeout โดยเฉพาะหากไม่รู้ว่าคำขอแรกสำเร็จหรือไม่ ให้ตรวจผลลัพธ์หรือใช้วิธีป้องกันรายการซ้ำในแอป

ฝั่งผู้ดูแลระบบควรดูทั้งอัตราคำขอต่อชั่วโมงและอัตรา 429 ไม่ใช่ดูเฉพาะค่าเฉลี่ยรายวัน ถ้าปกติใช้ใกล้ 80% เป็นประจำ อีเมลเตือนควรนำไปสู่การตรวจ endpoint ที่ถูกเรียกมากที่สุดและการตัดสินใจเรื่องแผนบริการ ไม่ควรรอจนผู้ใช้รายงานว่า API ใช้งานไม่ได้ ในช่วงทดสอบสามารถจำลอง 429 ที่ client เพื่อดูว่าหน้าแสดงข้อผิดพลาดอย่างไร โดยไม่จำเป็นต้องยิงคำขอจริงจนเต็มโควตา

เช็กลิสต์ก่อนพึ่งพาแผน Free

เริ่มจากระบุว่าหน้าใดเรียก /api กี่ครั้งต่อการใช้งานหนึ่งรอบ จากนั้นวัด peak hour ด้วยข้อมูลจริง ตรวจการแจ้งเตือนทางอีเมลว่าไปถึงคนรับผิดชอบ และกำหนดขั้นตอนรับมือเมื่อบริการตอบ 429 ให้ชัด หากแอปมีข้อกำหนดความพร้อมใช้งานสูงหรือมีการเติบโตของทราฟฟิก ให้ประเมินแผนที่เหมาะสมก่อนเปิดตัว การเพิ่มโควตาครั้งนี้ช่วยให้ทดลองได้สะดวกขึ้น แต่ไม่ได้แทนการวัดพฤติกรรมของแอปจริง

ประกาศต้นทาง: PocketBase Cloud Changelog — 11 ตุลาคม 2026