PostgreSQL 14 หมดอายุ 12 พ.ย. 2026 อัปเกรดอย่างไร และขยายเวลาบนคลาวด์ได้ถึงเมื่อไร
PostgreSQL 14 หมดอายุ 12 พ.ย. 2026 หลังจากนั้นไม่มีแพตช์จากชุมชน คู่มือนี้รวมวันตัดซัพพอร์ตบน RDS, Aurora, Azure และ Cloud SQL พร้อมขั้นตอนอัปเกรด
โดย กองบรรณาธิการ THAI DATA อ่าน 8 นาที
สรุปประเด็นสำคัญ
- ตารางของ PostgreSQL ระบุว่ารุ่น 14 ได้รุ่นแก้ไขสุดท้ายวันที่ 12 พฤศจิกายน 2026 หลังจากนั้นชุมชนจะไม่ออกแพตช์ความปลอดภัยให้อีก
- Azure ตัด Standard Support ก่อนใครในวันที่ 31 มกราคม 2027 ส่วน Amazon RDS และ Aurora ตัดวันที่ 28 กุมภาพันธ์ 2027 และ Cloud SQL เริ่ม Extended Support วันที่ 1 กุมภาพันธ์ 2027
- Extended Support ซื้อเวลาได้ถึงปี 2029–2030 แต่มีค่าใช้จ่ายเพิ่ม โดย RDS เริ่มคิดตั้งแต่ 1 มีนาคม 2027 รวมถึงเครื่อง standby แบบ Multi-AZ
- ถ้าจะอัปเกรดตอนนี้ PostgreSQL 17 ซัพพอร์ตถึง 8 พฤศจิกายน 2029 และ PostgreSQL 18 ถึง 14 พฤศจิกายน 2030 ส่วนรุ่น 15 เหลือเวลาถึงปี 2027 เท่านั้น และการข้ามรุ่นต้องตรวจสิทธิ์ใน public schema กับรหัสผ่าน MD5
- รุ่นย่อยหมดก่อนรุ่นหลักได้ บน RDS รุ่น 14.18 และ 14.19 สิ้นสุด Standard Support วันที่ 31 ตุลาคม 2026 และบน Aurora รุ่น 14.17 สิ้นสุดวันที่ 30 พฤศจิกายน 2026
PostgreSQL 14 หมดอายุวันที่ 12 พฤศจิกายน 2026 หรืออีก 12 วันนับจากวันที่ 31 ตุลาคม 2026 วันนั้นรุ่น 14 จะได้รุ่นแก้ไขสุดท้าย แล้วชุมชนจะหยุดออกแพตช์ความปลอดภัย องค์กรที่ใช้บนคลาวด์มีเวลาเหลือมากกว่าเล็กน้อย แต่ถ้าเลยวันที่ผู้ให้บริการกำหนดอาจมีค่าใช้จ่ายเพิ่ม
PostgreSQL 14 หมดอายุเมื่อไรบนแต่ละแพลตฟอร์ม
คำถามแรกคือฐานข้อมูลของคุณรันที่ไหน เพราะแต่ละที่นับวันไม่เท่ากัน ตารางนี้รวมจากเอกสารทางการที่เราเปิดตรวจเมื่อ 31 ตุลาคม 2026
| แพลตฟอร์ม | ซัพพอร์ตปกติสิ้นสุด | Extended Support | สิ้นสุดทั้งหมด |
|---|---|---|---|
| ชุมชน PostgreSQL | 12 พ.ย. 2026 | ไม่มี | 12 พ.ย. 2026 |
| Azure Database for PostgreSQL | 31 ม.ค. 2027 | เริ่ม 1 ก.พ. 2027 | 11 พ.ย. 2029 |
| Google Cloud SQL | ก่อนวันเริ่ม Extended Support | เริ่ม 1 ก.พ. 2027 | 1 ก.พ. 2030 |
| Amazon RDS for PostgreSQL | 28 ก.พ. 2027 | เริ่ม 1 มี.ค. 2027 | 28 ก.พ. 2030 |
| Amazon Aurora PostgreSQL | 28 ก.พ. 2027 | เริ่ม 1 มี.ค. 2027 | 28 ก.พ. 2030 |
ถ้าติดตั้งเองบนเซิร์ฟเวอร์ ให้นับว่า PostgreSQL 14 หมดอายุตามวันของชุมชน ส่วนแพ็กเกจจากดิสโทรลินุกซ์อาจมีรอบซัพพอร์ตของตัวเอง จึงต้องตรวจกับผู้จำหน่ายแยกต่างหาก
รุ่นย่อยของ PostgreSQL 14 หมดอายุก่อนรุ่นหลักได้
จุดที่พลาดง่ายคือบนคลาวด์ รุ่นย่อยเก่ามีวันตัดซัพพอร์ตของตัวเอง ตารางของ RDS ระบุว่ารุ่น 14.18 และ 14.19 สิ้นสุด Standard Support วันที่ 31 ตุลาคม 2026 ซึ่งคือวันนี้ ส่วนตารางของ Aurora ระบุว่ารุ่น 14.17 สิ้นสุดวันที่ 30 พฤศจิกายน 2026 และรุ่น 14.18 สิ้นสุดวันที่ 31 ธันวาคม 2026 ทั้งหมดนี้เร็วกว่ารุ่นหลักหลายสัปดาห์
การอัปเดตรุ่นย่อยทำได้ง่ายกว่ารุ่นหลักมาก นโยบายของ PostgreSQL ระบุว่าไม่ต้อง dump และ restore เพียงหยุดเซิร์ฟเวอร์ ติดตั้งไฟล์รุ่นใหม่ แล้วเริ่มระบบใหม่ แม้บางรุ่นอาจมีขั้นตอนเพิ่มเติม จึงต้องอ่าน release notes ก่อนเสมอ
ดังนั้นแม้จะย้ายรุ่นหลักไม่ทัน ก่อน PostgreSQL 14 หมดอายุทุกองค์กรควรวางแผนลงรุ่นแก้ไขสุดท้ายที่มีกำหนดออกวันที่ 12 พฤศจิกายน 2026 เพื่อปิดปัญหาที่ชุมชนแก้เป็นรอบสุดท้าย
หลัง PostgreSQL 14 หมดอายุจะเกิดอะไรขึ้น
ฐานข้อมูลจะไม่ดับเองเมื่อ PostgreSQL 14 หมดอายุ แต่สถานะจะเปลี่ยน นโยบายของ PostgreSQL ระบุว่าแต่ละรุ่นหลักได้รับการสนับสนุน 5 ปี จากนั้นจะออกรุ่นแก้ไขสุดท้ายและไม่ซัพพอร์ตอีก
- ติดตั้งเอง ช่องโหว่ที่พบหลังวันนั้นจะไม่มีแพตช์จากชุมชนสำหรับรุ่น 14
- Amazon RDS เริ่มคิดค่า Extended Support วันถัดจากวันสิ้นสุด Standard Support คิดต่อ vCPU ต่อชั่วโมง รวมเครื่อง standby แบบ Multi-AZ ด้วย และหยุดคิดเมื่ออัปเกรดหรือลบฐานข้อมูล
- Cloud SQL ลงทะเบียนเข้า Extended Support ให้อัตโนมัติและคิดเงินเพิ่มจากค่าอินสแตนซ์ปกติ โดยไม่ได้ฟีเจอร์ใหม่ที่ออกหลังจากนั้น
- Azure ใส่ Extended Support ให้เซิร์ฟเวอร์ที่เข้าเกณฑ์อัตโนมัติ ผู้ใช้ปฏิเสธไม่ได้ และค่าบริการหยุดเมื่ออัปเกรดเสร็จ บริการนี้ให้แพตช์ความปลอดภัยและบั๊กสำคัญ ไม่รวมฟีเจอร์ใหม่หรือการจูนประสิทธิภาพ
ควรอัปเกรดจาก PostgreSQL 14 ไปรุ่นไหน
ข้อดีคืออัปเกรดข้ามรุ่นได้เลย เอกสารของ PostgreSQL ระบุว่าไม่ต้องผ่านรุ่นกลาง จึงไม่มีเหตุผลที่ต้องหยุดที่รุ่น 15 ถ้าระบบรองรับรุ่นใหม่กว่า
| รุ่นปลายทาง | รุ่นย่อยล่าสุด | ซัพพอร์ตถึง | เหมาะกับ |
|---|---|---|---|
| PostgreSQL 15 | 15.19 | 11 พ.ย. 2027 | ไม่แนะนำ เพราะต้องอัปเกรดอีกในปีหน้า |
| PostgreSQL 16 | 16.15 | 9 พ.ย. 2028 | ระบบที่ส่วนขยายยังไม่รองรับรุ่นใหม่กว่า |
| PostgreSQL 17 | 17.11 | 8 พ.ย. 2029 | ค่าเริ่มต้นที่ปลอดภัยสำหรับระบบหลัก |
| PostgreSQL 18 | 18.6 | 14 พ.ย. 2030 | ระบบที่ทดสอบแล้วและอยากได้เวลาซัพพอร์ตนานสุด |
PostgreSQL 19 มีแผนออกรุ่นจริงวันที่ 19 พฤศจิกายน 2026 ถ้าไม่มีการเลื่อน ระบบจริงควรรอให้ผ่านรุ่นแก้ไขแรก ๆ ก่อน และควรตรวจว่าผู้ให้บริการคลาวด์เปิดรุ่นนี้แล้วหรือยัง
วิธีอัปเกรดหลัง PostgreSQL 14 หมดอายุ
เอกสารของ PostgreSQL ระบุ 3 ทางหลัก คือ dump แล้ว restore, pg_upgrade และการย้ายด้วย logical replication ส่วนบนคลาวด์ให้ใช้เครื่องมืออัปเกรดของผู้ให้บริการก่อน
ขั้นตอนที่ 1: สำรวจทุกฐานข้อมูล
เมื่อรู้แล้วว่า PostgreSQL 14 หมดอายุเมื่อไร ให้รัน SELECT version(); ในทุกอินสแตนซ์ รวมฐานข้อมูลทดสอบ รายงาน และ standby จดว่าใครเป็นเจ้าของระบบ แอปใดเชื่อมต่อ และใช้ส่วนขยายอะไรบ้าง
ขั้นตอนที่ 2: เลือกรุ่นและตรวจส่วนขยาย
ตรวจว่าส่วนขยาย ไดรเวอร์ ORM เครื่องมือสำรองข้อมูล และระบบเฝ้าระวังรองรับรุ่นปลายทางแล้ว เพราะส่วนขยายมักเป็นตัวกำหนดว่าจะไปรุ่นไหนได้
ขั้นตอนที่ 3: อ่านส่วน Migration ของทุกรุ่นที่ข้าม
ไล่ release notes ของรุ่น 15 ถึงรุ่นปลายทาง แล้วเทียบกับแอปของคุณตามตารางในหัวข้อถัดไป
ขั้นตอนที่ 4: เลือกวิธีย้าย
| วิธี | เหมาะกับ | ข้อควรรู้ |
|---|---|---|
| pg_upgrade | ฐานข้อมูลใหญ่ที่หยุดระบบได้ช่วงสั้น | ใช้ --check ตรวจก่อนโดยไม่แก้ข้อมูล และมี --link ลดเวลาคัดลอก |
| pg_dump และ restore | ฐานข้อมูลขนาดเล็ก | ทำง่าย แต่ PostgreSQL ระบุว่าอาจช้า |
| Logical replication | งานที่ต้องการ downtime ต่ำ | ต้องซ้อมการสลับระบบและตรวจข้อมูลก่อน |
| เครื่องมือคลาวด์ | RDS, Aurora, Azure, Cloud SQL | ทำตามคู่มือของผู้ให้บริการและทดสอบบนสำเนาก่อน |
ขั้นตอนที่ 5: ซ้อมและวัดเวลาจริง
สำรองข้อมูลและทดลองกู้คืนก่อนเสมอ จากนั้นซ้อมอัปเกรดบนสำเนา จดเวลาที่ใช้ แล้วทดสอบแอปหลัก รายงาน และงานแบตช์กับรุ่นใหม่
ขั้นตอนที่ 6: อัปเกรดจริงและตรวจหลังย้าย
หลังย้าย ให้ตรวจ log ประสิทธิภาพคำสั่งสำคัญ และสถิติของ optimizer ตั้งแต่รุ่น 18 pg_upgrade ย้ายสถิติส่วนใหญ่ให้ แต่เอกสารยังแนะนำให้รัน vacuumdb เพื่อเก็บส่วนที่ขาด ซึ่งบางส่วนไม่ถูกย้าย เช่น สถิติจาก CREATE STATISTICS
สิ่งที่เปลี่ยนเมื่อข้ามจาก PostgreSQL 14
ตารางนี้คัดรายการที่มักกระทบงานจริงจาก release notes ไม่ใช่รายการครบถ้วน
เรื่อง public schema มีรายละเอียดสำคัญ release notes ของรุ่น 15 ระบุว่าการอัปเกรดคลัสเตอร์หรือการ restore จาก dump จะคงสิทธิ์เดิมไว้ แอปเดิมจึงไม่พังทันทีหลังอัปเกรด แต่ถ้าสร้างฐานข้อมูลใหม่จะได้ค่าใหม่ ทีมควรพิจารณายกเลิกสิทธิ์นี้กับฐานข้อมูลเดิมด้วย โดยเฉพาะฐานข้อมูลที่มีผู้ใช้หลายคน
| รุ่น | การเปลี่ยนแปลง | สิ่งที่ต้องตรวจ |
|---|---|---|
| 15 | ยกเลิกสิทธิ์ CREATE ของ PUBLIC ใน public schema สำหรับคลัสเตอร์และฐานข้อมูลที่สร้างใหม่ | ฐานข้อมูลใหม่ที่แอปสร้างตารางด้วยผู้ใช้ทั่วไป |
| 15 | ลบโหมด exclusive backup | สคริปต์สำรองข้อมูลแบบเก่า |
| 15 | ลบ plpython2u และ plpythonu | ฟังก์ชันที่ยังใช้ Python 2 |
| 16 | ลบ promote_trigger_file | ขั้นตอน failover ที่ใช้ไฟล์ trigger |
| 17 | งานบำรุงรักษาใช้ search_path แบบปลอดภัย | ดัชนีหรือมุมมองที่เรียกฟังก์ชันโดยไม่ระบุ schema |
| 17 | ลบ old_snapshot_threshold และ adminpack | ไฟล์ตั้งค่าและส่วนขยายเดิม |
| 18 | initdb เปิด data checksums เป็นค่าเริ่มต้น | ถ้าใช้ pg_upgrade ค่า checksum ต้องตรงกัน |
| 18 | ประกาศเลิกใช้รหัสผ่าน MD5 | บัญชีที่ยังไม่ย้ายไป SCRAM |
คำสั่งตรวจก่อน PostgreSQL 14 หมดอายุ
ก่อนถึงวันที่ PostgreSQL 14 หมดอายุ ให้เก็บข้อมูลพื้นฐานจากทุกอินสแตนซ์ คำสั่ง 3 ชุดนี้ใช้เวลาไม่นานและตอบได้ว่าระบบใดมีความเสี่ยงสูงกว่า
SELECT version();
SELECT extname, extversion FROM pg_extension;
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
คำสั่งแรกบอกรุ่นที่ใช้อยู่ คำสั่งที่สองแสดงส่วนขยายในฐานข้อมูลนั้น จึงต้องรันแยกทุกฐานข้อมูล ส่วนคำสั่งที่สามหาบัญชีที่ยังเก็บรหัสผ่านแบบ MD5 เอกสารของ PostgreSQL ระบุว่าค่า rolpassword แบบนี้ขึ้นต้นด้วย md5 แต่ตาราง pg_authid เป็นข้อมูลอ่อนไหว จึงต้องใช้สิทธิ์สูง และบริการคลาวด์บางรายอาจไม่เปิดให้อ่าน กรณีนั้นให้ดูเครื่องมือของผู้ให้บริการแทน
ถ้าติดตั้งเอง ให้รัน pg_upgrade --check กับคลัสเตอร์สำเนา ตัวเลือกนี้ตรวจความเข้ากันได้โดยไม่แก้ข้อมูล ทีมจะเห็นปัญหาก่อนกำหนดวันย้ายจริง และถ้าปลายทางเป็นรุ่น 18 ต้องดูเรื่อง data checksums ด้วย เพราะ pg_upgrade ต้องการค่าที่ตรงกันทั้งสองฝั่ง คลัสเตอร์เดิมที่ไม่เปิด checksum จึงอาจต้องสร้างปลายทางด้วยตัวเลือก --no-data-checksums
แผนเตรียมตัวก่อนและหลัง PostgreSQL 14 หมดอายุ
ถ้าเริ่มวันนี้ องค์กรส่วนใหญ่ยังย้ายไม่ทันวันที่ 12 พฤศจิกายน และไม่ควรเร่งจนข้ามการทดสอบ เป้าหมายที่สมจริงกว่าคือลงรุ่นแก้ไขสุดท้าย แล้วย้ายให้เสร็จก่อนผู้ให้บริการเริ่มคิดเงินเพิ่ม
| ช่วงเวลา | สิ่งที่ควรทำ |
|---|---|
| ถึง 12 พ.ย. 2026 | ทำบัญชีฐานข้อมูล ตรวจรุ่นย่อย และเตรียมรอบลงรุ่นแก้ไขสุดท้าย |
| ปลาย พ.ย. 2026 | ลงรุ่นแก้ไขสุดท้าย เลือกรุ่นปลายทาง และตรวจส่วนขยาย |
| ธ.ค. 2026 | ซ้อมอัปเกรดบนสำเนาและทดสอบแอปพลิเคชันหลัก |
| ม.ค. 2027 | ย้ายระบบจริงตามลำดับความสำคัญ ก่อน Azure ตัดซัพพอร์ตวันที่ 31 ม.ค. |
| ก.พ. 2027 | เก็บระบบที่เหลือบน RDS และ Aurora ก่อนสิ้นเดือน |
ระบบที่ซื้อจากผู้ผลิตซอฟต์แวร์ควรถามผู้ผลิตก่อน PostgreSQL 14 หมดอายุว่ารับรองรุ่นใด เพราะการอัปเกรดเองอาจทำให้เสียสิทธิ์การดูแล ส่วนระบบที่ปิดอยู่ในเครือข่ายภายในก็ยังควรมีแผน เพราะผู้โจมตีที่เข้ามาในเครือข่ายแล้วสามารถเล็งฐานข้อมูลที่ไม่มีแพตช์ได้เช่นกัน
ผลต่อองค์กรไทย
เมื่อ PostgreSQL 14 หมดอายุในช่วงปลายปี ความเสี่ยงคือเวลา หลายองค์กรงดเปลี่ยนแปลงระบบช่วงปิดงบหรือช่วงปีใหม่ เวลาที่ใช้ทำงานได้จริงจึงสั้นกว่าปฏิทิน โดยเฉพาะผู้ใช้ Azure ที่ตัด Standard Support เร็วที่สุด
- ตั้งเป้าก่อนสิ้นมกราคม 2027 ถ้าใช้หลายคลาวด์ ให้ยึดวันของ Azure เป็นเส้นตายร่วม
- ของบให้ชัด ถ้าจะใช้ Extended Support ให้คำนวณจากจำนวน vCPU รวม standby แล้วเทียบกับต้นทุนการอัปเกรด
- แจ้งผู้ตรวจสอบ ระบบที่ต้องผ่านการตรวจด้านความปลอดภัยควรบันทึกแผนอัปเกรดและวันที่เป้าหมายไว้
- ฝึกทีมกับเครื่องมือจริง การที่ PostgreSQL 14 หมดอายุเป็นโอกาสซ้อมขั้นตอนอัปเกรด เพราะรุ่น 15 จะหมดอายุในอีกหนึ่งปีถัดมา
ถ้าระบบของคุณยังไม่มีแผนก่อน PostgreSQL 14 หมดอายุ เริ่มจากตารางด้านบนได้เลย อ่านเรื่องฐานข้อมูลอื่นได้ที่หมวดข้อมูล ส่วนผู้ที่ใช้ Aurora ดูตารางเฉพาะได้จากปฏิทินของ AWS
ภาพบันทึก
คำถามที่พบบ่อย
PostgreSQL 14 หมดอายุวันไหน?
PostgreSQL 14 หมดอายุวันที่ 12 พฤศจิกายน 2026 ตามตารางเวอร์ชันของ PostgreSQL วันนั้นตรงกับรอบออกรุ่นแก้ไขของเดือนพฤศจิกายน และรุ่น 14 จะได้รุ่นแก้ไขสุดท้าย จากนั้นชุมชนจะไม่ออกแพตช์ให้อีก
PostgreSQL 14 หมดอายุแล้วฐานข้อมูลจะหยุดทำงานไหม?
ไม่หยุดทำงาน ฐานข้อมูลยังรันได้ตามเดิม แต่เมื่อ PostgreSQL 14 หมดอายุจะไม่มีแพตช์ความปลอดภัยจากชุมชนอีก ถ้าใช้บนคลาวด์ ผู้ให้บริการจะย้ายเข้า Extended Support ตามกำหนดของแต่ละราย โดยมีค่าบริการเพิ่ม
PostgreSQL 14 บน Amazon RDS ใช้ได้ถึงเมื่อไร?
Amazon RDS และ Aurora PostgreSQL ให้ Standard Support ของรุ่น 14 ถึง 28 กุมภาพันธ์ 2027 จากนั้นเข้า Extended Support ตั้งแต่ 1 มีนาคม 2027 ถึง 28 กุมภาพันธ์ 2030 โดยมีค่าบริการเพิ่มต่อ vCPU ต่อชั่วโมง
ควรอัปเกรดจาก PostgreSQL 14 ไปรุ่นไหน?
สำหรับงานหลักควรเลือก PostgreSQL 17 หรือ 18 เพราะซัพพอร์ตถึงปี 2029 และ 2030 ไม่ต้องอัปเกรดซ้ำเร็ว ส่วนรุ่น 19 มีแผนออกวันที่ 19 พฤศจิกายน 2026 จึงควรรอให้ผ่านรุ่นแก้ไขแรก ๆ ก่อนใช้กับระบบจริง
ต้องอัปเกรดไล่ทีละรุ่นหลัง PostgreSQL 14 หมดอายุหรือไม่?
ไม่ต้อง เอกสารของ PostgreSQL ระบุว่าอัปเกรดข้ามจากรุ่นหลักหนึ่งไปอีกรุ่นได้โดยไม่ต้องผ่านรุ่นกลาง แต่แนะนำให้อ่าน release notes ของทุกรุ่นที่ข้าม เพราะแต่ละรุ่นอาจมีการเปลี่ยนแปลงที่กระทบแอปพลิเคชัน
แหล่งอ้างอิง
- Versioning Policy — PostgreSQL Global Development Group
- Release calendars for Amazon RDS for PostgreSQL — Amazon Web Services
- Extended support for Azure Database for PostgreSQL — Microsoft Learn
- Cloud SQL database versions and version policies — Google Cloud
- pg_upgrade — PostgreSQL Global Development Group
- PostgreSQL 18.0 Release Notes — PostgreSQL Global Development Group
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Google Cloud71Microsoft170AWS86
- ประเทศและสถานที่
- อินเดีย115
- ผลิตภัณฑ์และเทคโนโลยี
- PostgreSQL20Amazon Aurora7Microsoft Azure67Cloud SQL6Amazon RDS5Python34
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ