PostgreSQL 14 หมดอายุ พ.ย. 2569

เส้นตายของแต่ละเวอร์ชัน และใครได้รับผลกระทบ

PostgreSQL ปล่อย Major Release ปีละหนึ่งเวอร์ชัน และสนับสนุนแต่ละเวอร์ชันเป็นเวลา 5 ปี โดยวันหมดอายุตกอยู่กลางเดือนพฤศจิกายนเสมอ จึงวางแผนล่วงหน้าได้แม่นยำ PostgreSQL 13 หมดอายุไปแล้วเมื่อ 13 พฤศจิกายน 2568 และ PostgreSQL 14 จะหมดอายุ 12 พฤศจิกายน 2569 — สองเวอร์ชันนี้คือกลุ่มที่ต้องตัดสินใจก่อน

เวอร์ชัน	วันที่ออก	End of Life	สถานะ
PostgreSQL 18	25 ก.ย. 2568	พ.ย. 2573	รองรับเต็มที่
PostgreSQL 17	2567	พ.ย. 2572	รองรับ
PostgreSQL 16	2566	พ.ย. 2571	รองรับ
PostgreSQL 15	2565	พ.ย. 2570	รองรับ
PostgreSQL 14	2564	พ.ย. 2569	เหลือเวลาไม่นาน
PostgreSQL 13	2563	13 พ.ย. 2568	หมดอายุแล้ว

ย้ายไป 17 หรือ 18 ดี

เมื่อต้องย้ายอยู่แล้ว คำถามถัดมาคือย้ายไปเวอร์ชันไหน การข้ามไปเวอร์ชันล่าสุดไม่ได้ถูกเสมอ และการเลือกเวอร์ชันรองสุดท้ายก็ไม่ได้ปลอดภัยเสมอเช่นกัน

เลือก	เหมาะกับ	อายุการสนับสนุนที่เหลือ
PostgreSQL 17	องค์กรที่เน้นความนิ่ง มี Extension หรือเครื่องมือรอบข้างที่ยังไม่รับรอง 18 และไม่อยากเป็นผู้ใช้กลุ่มแรก	ถึง พ.ย. 2572 (ราว 6 ปี)
PostgreSQL 18	องค์กรที่ต้องการอายุการสนับสนุนยาวที่สุดต่อการอัปเกรดหนึ่งครั้ง และได้ประโยชน์จาก Async I/O, OAuth 2.0 หรือ UUIDv7 โดยตรง	ถึง พ.ย. 2573 (ราว 7 ปี)

PostgreSQL 18 ให้อะไรเพิ่มจากที่ใช้อยู่

ถ้าเลือกย้ายไป 18 ต่อไปนี้คือสิ่งที่ได้เพิ่มขึ้นจริง จัดกลุ่มตามผลกระทบต่องาน Production

กลุ่มที่ 1 — Async I/O และการปรับปรุงประสิทธิภาพ

นี่คือกลุ่มที่ส่งผลกระทบกับ Production มากที่สุด เพราะกระทบ ทุก query ที่อ่านข้อมูลจากดิสก์ โดยตรง โดยไม่ต้องแก้ Application Code:

1. Asynchronous I/O Subsystem (AIO)

PostgreSQL 18 มี I/O subsystem ใหม่ ที่ทำงานแบบ Asynchronous — Storage Read สามารถเร็วขึ้นได้ สูงสุด 3 เท่า สำหรับ Sequential Scan, Bitmap Heap Scan และ Vacuum ปรับค่าได้ผ่านพารามิเตอร์ io_method ที่รองรับสามแบบ: worker (ค่า default), io_uring (เฉพาะ Linux เคอร์เนลใหม่) และ sync (พฤติกรรมเดิม)

2. Skip Scan สำหรับ B-tree Multicolumn Index

เดิมถ้ามี Index บน (a, b) แล้ว Query ค้นด้วย WHERE b = ? โดยไม่ระบุ a — Planner ต้องทำ Sequential Scan เพราะใช้ Index ไม่ได้ เวอร์ชัน 18 รองรับ Skip Scan ที่กระโดดข้ามค่าของคอลัมน์แรกอัตโนมัติ — ลดเวลา Query ลงได้มากในกรณีที่ Selectivity ของคอลัมน์แรกต่ำ

3. Parallel GIN Index Build

การสร้าง GIN Index (ใช้บ่อยใน Full-Text Search และ JSONB) สามารถทำแบบ Parallel ได้ — ลดเวลา Reindex ลงตามจำนวน Worker — สำคัญสำหรับองค์กรที่มีตาราง JSON ขนาดใหญ่

4. Planner Statistics ติดมากับการ Upgrade

เดิมหลัง pg_upgrade Major Version จะต้องรอ ANALYZE ใหม่ทั้งหมด — ช่วงนั้น Query Plan อาจช้าผิดปกติ เวอร์ชัน 18 เก็บสถิติเดิมไว้ หลัง Upgrade ทำให้ Performance หลัง Upgrade เสถียรตั้งแต่นาทีแรก

กลุ่มที่ 2 — Authentication และ Security

ฟีเจอร์กลุ่มนี้สำคัญมากสำหรับองค์กรที่ต้องการเชื่อม PostgreSQL กับระบบ Single Sign-On (SSO) ขององค์กร และยกระดับ Authentication และความปลอดภัย ของ Database:

1. OAuth 2.0 Authentication ในตัว

PostgreSQL 18 รองรับ OAuth 2.0 ผ่าน Auth Method ใหม่ชื่อ oauth ใน pg_hba.conf — เปลี่ยนเกมสำหรับองค์กรที่ใช้ Azure AD, Google Workspace, Keycloak หรือ Identity Provider อื่นๆ — เพราะ ไม่ต้องเก็บ Password ใน Database และไม่ต้อง Sync User Account ระหว่างระบบ

2. SCRAM Passthrough ใน postgres_fdw และ dblink

การเชื่อมต่อแบบ Federated Query ผ่าน postgres_fdw และ dblink รองรับการส่งต่อ SCRAM Credentials โดยไม่ต้องเก็บรหัสผ่านในไฟล์ Configuration — ลดความเสี่ยงเรื่อง Credential Leak

3. md5 Authentication ถูก Deprecated

4. FIPS Mode Validation และ TLS 1.3 Cipher Config

เพิ่มการตรวจสอบ FIPS-compliance สำหรับองค์กรที่ต้องผ่านมาตรฐานความปลอดภัยภาครัฐ และเพิ่มพารามิเตอร์ ssl_tls13_ciphers ให้กำหนด TLS 1.3 Cipher Suite ได้เอง

5. SHA-2 ใน pgcrypto Extension

ฟังก์ชันใน Extension pgcrypto รองรับ SHA-2 สำหรับการเก็บ Password Hash ในตาราง — แทนที่ MD5 ที่ถือว่าไม่ปลอดภัยตามมาตรฐานสมัยใหม่

กลุ่มที่ 3 — Developer Features ที่เปลี่ยนวิธีออกแบบ Schema

1. UUIDv7() — แก้ปัญหา Cache ของ UUIDv4

UUIDv4 (สุ่มล้วน) เป็น Primary Key ที่นิยมใช้กันมานาน แต่มีข้อเสียคือ กระจาย Cache ของ B-tree Index เพราะ ID ใหม่ที่ Insert ไม่เรียงตามเวลา — Database ต้องอ่าน Index Block ที่กระจัดกระจาย ทำให้ช้าลงเรื่อยๆ เมื่อข้อมูลใหญ่ขึ้น

PostgreSQL 18 เพิ่มฟังก์ชัน uuidv7() ที่ เรียง UUID ตาม Timestamp — ทำให้ Insert เรียงต่อกันเหมือน Sequence Number แต่ยังเป็น UUID ที่ Globally Unique และยังเพิ่ม Alias uuidv4() สำหรับ gen_random_uuid() เพื่อความสม่ำเสมอ

2. Virtual Generated Columns เป็น Default

Generated Columns ใน PostgreSQL ก่อนเวอร์ชัน 18 ต้องเป็น STORED เท่านั้น — คอมพิวเตอร์คำนวณค่าและเก็บลงในดิสก์จริง เปลือง Storage และ Update ช้า เวอร์ชัน 18 รองรับ VIRTUAL เป็น Default — คำนวณค่าเฉพาะตอน Query โดยไม่เปลือง Storage

ประเภท	STORED (เดิม)	VIRTUAL (ใหม่)
Storage	เปลืองพื้นที่ดิสก์	ไม่เปลือง
Update Performance	ช้า (เขียนดิสก์ใหม่)	เร็ว (ไม่เขียน)
Query Performance	เร็ว (อ่านตรงๆ)	ช้ากว่าเล็กน้อย (คำนวณตอน Query)
เหมาะกับ	คอลัมน์ที่อ่านบ่อย Update น้อย	คอลัมน์ Derived ทั่วไป (เช่น Full Name)

3. Temporal Constraints — WITHOUT OVERLAPS และ PERIOD

เป็นฟีเจอร์ที่นักพัฒนาระบบ ERP รอมานาน เวอร์ชัน 18 รองรับการประกาศ WITHOUT OVERLAPS ใน PRIMARY KEY และ UNIQUE Constraint และ PERIOD ใน FOREIGN KEY — สำหรับตารางที่เก็บข้อมูลแบบช่วงเวลา เช่น:

• อัตราภาษี VAT ที่มีผลแต่ละช่วง — ไม่ให้สร้าง Rate ที่ทับซ้อนเวลากันได้
• ราคาสินค้าตามช่วงโปรโมชั่น — บังคับให้ช่วงเวลาไม่ทับกันในระดับ Database
• เงินเดือนพนักงานในแต่ละช่วง — ป้องกัน Data Inconsistency โดยไม่ต้องเขียน Trigger เอง

เดิมต้องเขียน Trigger หรือใช้ btree_gist Extension ซึ่งยุ่งยาก เวอร์ชัน 18 ทำได้ในระดับ Standard SQL Syntax

4. RETURNING รองรับ OLD และ NEW

คำสั่ง INSERT, UPDATE, DELETE, MERGE รองรับ RETURNING OLD.* และ NEW.* — ดึงทั้งค่าก่อนและหลังเปลี่ยนแปลงในคำสั่งเดียว — ช่วยลด Round-trip กับ Database สำหรับ Audit Trail Logic

กลุ่มที่ 4 — Replication และ High Availability

• Parallel Streaming เป็น default สำหรับ CREATE SUBSCRIPTION — Replication Lag ลดลงในระบบที่มี Transaction ขนาดใหญ่
• pg_createsubscriber --all สร้าง Logical Replica ของทุก Database ได้ในคำสั่งเดียว
• Idle Replication Slot Cleanup อัตโนมัติ ผ่าน idle_replication_slot_timeout — แก้ปัญหาคลาสสิกของ Replication Slot ที่ลืมลบทิ้งจน WAL กิน Disk จนเต็ม
• Logical Replication Conflict Logging — บันทึก Write Conflict ลง pg_stat_subscription_stats สำหรับ วาง Disaster Recovery Strategy ที่แม่นยำขึ้น

กลุ่มที่ 5 — Observability และการ Monitor

• EXPLAIN ANALYZE แสดง Buffer Access อัตโนมัติโดยไม่ต้องใส่ option BUFFERS เอง
• Index Lookup Count โผล่ใน Plan — เห็นได้ทันทีว่า Query ไป Probe Index กี่ครั้ง
• EXPLAIN ANALYZE VERBOSE แสดง CPU, WAL และ Average Read Stats — Tuning Query ละเอียดขึ้น
• pg_stat_all_tables เก็บเวลา Vacuum และ Maintenance Operations แต่ละครั้ง
• I/O และ WAL Utilization ต่อ Connection — ระบุได้ว่า Session ไหนใช้ I/O หรือ WAL หนัก

ผลกระทบสำหรับองค์กรที่ใช้ระบบ ERP

สำหรับองค์กรที่ใช้ PostgreSQL เป็น Backend ของระบบ ERP มีจุดที่ต้องประเมินก่อนตัดสินใจ Upgrade:

โมดูล ERP	ฟีเจอร์ที่ได้ประโยชน์	ระดับผลกระทบ
บัญชี (GL, AR, AP)	Async I/O + Temporal Constraints สำหรับ VAT/อัตราแลกเปลี่ยน	สูง
ปิดงบ / รายงาน	Skip Scan + Parallel GIN + Planner Stats Preservation	สูง
HR / Payroll	Temporal Constraints สำหรับเงินเดือนตามช่วง + UUIDv7	สูง
คลังสินค้า	Async I/O สำหรับ Sequential Scan ตารางใหญ่	ปานกลาง
Authentication	OAuth 2.0 สำหรับองค์กรที่มี SSO	ปานกลาง

ก่อน Upgrade — สิ่งที่ต้องเตรียม

1. ตรวจสอบเวอร์ชันปัจจุบัน — รัน SELECT version(); ทุก Server ทั้ง Primary และ Standby
2. เปลี่ยน md5 → SCRAM-SHA-256 ก่อน — ใน pg_hba.conf และ password_encryption เพื่อเตรียมความพร้อมสำหรับเวอร์ชันถัดไปที่จะลบ md5 ออก
3. ทดสอบ Application กับ PostgreSQL 18 ใน Staging — โดยเฉพาะถ้าใช้ Trigger หรือ Stored Procedure ที่ซับซ้อน
4. สำรองข้อมูลก่อน Upgrade ทุกครั้ง — pg_basebackup + WAL Archive — ดู แผน Disaster Recovery ก่อนเริ่ม
5. วางแผน Page Checksum — PostgreSQL 18 เปิด Page Checksum เป็น default สำหรับ Database ใหม่ — ถ้าทำ pg_upgrade จาก Cluster เดิมที่ไม่มี Checksum ต้องวางแผนการ Migrate
6. ตรวจสอบ Extension — ทุก Extension ที่ใช้ (pg_trgm, postgis, timescaledb ฯลฯ) ต้องมีเวอร์ชันที่รองรับ PostgreSQL 18

ทำไมเรื่องนี้สำคัญกับองค์กรที่ใช้ Saeree ERP

Saeree ERP ใช้ PostgreSQL เป็นฐานข้อมูลหลักมากว่า 20 ปี — เลือกตั้งแต่ยังเป็นเวอร์ชัน 7.x จนถึงปัจจุบัน ผ่าน Major Release มาแล้วกว่า 10 ครั้ง การออกของเวอร์ชัน 18 มี Implication กับลูกค้าโดยตรง ได้แก่:

• การ Upgrade ตามรอบ — ทีม Saeree ทดสอบ Compatibility กับ PostgreSQL 18 ผ่าน Staging Environment ก่อนแนะนำลูกค้า production ให้ Upgrade ตามรอบที่เหมาะสม ไม่บังคับให้ Upgrade ทันทีในวันที่เวอร์ชันออก
• Temporal Constraints กับ Master Data — ใน Saeree ERP, admin สามารถเพิ่ม / inactive / กำหนด valid from-to ของอัตรา VAT, อัตราแลกเปลี่ยน, ราคาสินค้า ได้เองโดยไม่ต้อง patch Logic นี้ทำงานในระดับ Application อยู่แล้ว PostgreSQL 18 Temporal Constraint จะทำให้การ Enforce ทำได้ในระดับ Database ด้วย — ลดความผิดพลาดของข้อมูลในระยะยาว
• OAuth + SSO — สำหรับลูกค้าที่ใช้ระบบ SSO อยู่แล้ว (Azure AD, Keycloak ฯลฯ) — สามารถวางแผนรวม Authentication ของ Database เข้ากับระบบกลางได้ในอนาคต
• EOL ของ PostgreSQL 13 — Saeree ตรวจสอบ Cluster ของลูกค้าทุกรายที่อยู่บนเวอร์ชันต่ำกว่า 14 และวางแผน Upgrade Roadmap ให้

เหมาะ / ไม่เหมาะที่จะย้ายไป 18

เหมาะ Upgrade ทันที	ควรรอประเมินก่อน
ยังอยู่บน PostgreSQL 13 หรือต่ำกว่า (EOL แล้ว)	เพิ่ง Upgrade เป็น PostgreSQL 17 ภายใน 6 เดือน
มี Workload Read-heavy ที่ใช้ Sequential Scan / Vacuum	ระบบเล็ก ใช้ Storage SSD ที่เร็วอยู่แล้ว
วางแผน Implement SSO กับ Database	ยังใช้ Auth แบบ Local Password ทั้งระบบ
เริ่มโปรเจกต์ใหม่ — เลือก PostgreSQL 18 ตั้งแต่แรก	Extension หลักยังไม่ Compatible (PostGIS, TimescaleDB เฉพาะรุ่นเก่า)
ต้องการ UUIDv7 สำหรับ Primary Key ใหม่	ใช้ Trigger เก่าที่พึ่ง md5 auth

PostgreSQL 18 ไม่ใช่ Upgrade ตามรอบธรรมดา — เป็นการเปลี่ยน I/O Subsystem ที่ส่งผลกับทุก Query ที่อ่านดิสก์ บวกกับเครื่องมือใหม่อย่าง OAuth, UUIDv7 และ Temporal Constraints ที่จะลดงาน Custom Code ของทีม Developer ลงอย่างมาก

- ทีมงาน Saeree ERP

สรุป

1. ถ้ายังใช้ PostgreSQL 13 หรือต่ำกว่า — วางแผน Upgrade ทันที เพราะไม่มี Patch ความปลอดภัยอีกแล้ว
2. เปลี่ยน md5 → SCRAM-SHA-256 ในระบบที่ยังใช้อยู่ — เตรียมรับการลบ md5 ในเวอร์ชันถัดไป
3. ทดสอบ Application กับ PostgreSQL 18 ใน Staging ก่อน Upgrade Production
4. ใช้เวอร์ชัน Minor ล่าสุด (ตอนนี้คือ 18.4) ไม่ใช่ 18.0
5. สำหรับโปรเจกต์ใหม่ — เริ่มที่ PostgreSQL 18 และใช้ UUIDv7 + Temporal Constraints ตั้งแต่ออกแบบ Schema

หากองค์กรของคุณใช้ Saeree ERP หรือกำลังวางแผนใช้ระบบ ERP บน PostgreSQL และต้องการประเมินความพร้อมในการ Upgrade — ทีม Saeree พร้อมให้คำปรึกษาเรื่อง การเลือกฐานข้อมูล, การวางแผน Upgrade, และ Disaster Recovery สามารถติดต่อทีมที่ปรึกษาได้โดยตรง

แหล่งอ้างอิง

• PostgreSQL 18 Released! — postgresql.org (25 ก.ย. 2568)
• PostgreSQL Versioning Policy — postgresql.org
• Celebrating PostgreSQL 18 Release — EnterpriseDB
• PostgreSQL 18 Release Notes — postgresql.org