เอาตรงๆ ครับ blog ที่คุณกำลังอ่านอยู่นี้ — ไม่มี database เลย#

ย้อนไป 8 ตอนที่ผ่านมา เราคุยกันเรื่อง database จนหมดทุกซอกทุกมุมแล้ว — ยุคของมัน schema index transaction ฟังเยอะขนาดนั้นแล้วผมขอ flip มุมหน่อย

หน้าเว็บนี้ — ที่คุณกำลังเลื่อนอ่านอยู่ตอนนี้ — เบื้องหลังไม่มี MySQL ไม่มี PostgreSQL ไม่มี MongoDB ไม่มี SQLite ไม่มีแม้แต่ไฟล์ database สักไฟล์เดียว ทุกตัวอักษรที่คุณเห็นถูกเตรียมไว้ก่อนหน้านี้แล้ว เก็บไว้เป็นไฟล์ HTML ธรรมดาที่กระจายอยู่ตาม edge ของ Cloudflare ทั่วโลก พอคุณกดเข้ามา server ใกล้ๆ คุณก็โยนไฟล์ใส่ browser ของคุณภายในเสี้ยววินาที

เปรียบกับร้านอาหารก็คือ — ร้านนี้ไม่มีครัวครับ ทำอาหารเสร็จก่อน วางไว้บนชั้น พอลูกค้าเข้ามา หยิบจานเสิร์ฟ จบ. ไม่มีเชฟ ไม่มีเตา ไม่มีตู้เย็นวัตถุดิบ ไม่มีคนล้างจาน

ฟังแล้วอาจเอ๊ะ — “งั้นเรื่องที่คุยมา 8 ตอนคืออะไรล่ะ?” ใจเย็นๆ ครับ database ยังจำเป็นอยู่เต็มที่สำหรับธุรกิจที่ต้องเก็บคำสั่งซื้อ ลูกค้า สต็อก แต่เว็บประเภท “content” — blog, portfolio, documentation, landing page — ปี 2026 ไม่จำเป็นต้องมีอีกแล้ว blog ของผมเองพิสูจน์ตรงนี้

(เคสเต็ม ผมเขียนไว้ในโพสต์ ย้ายจาก WordPress + Cloudways มา Cloudflare ล้วนๆ — อันนั้นเป็น migration story EP.09 จะเป็นมุม “ทำไมมันใช้ได้ และใช้ได้ถึงไหน”)

โลกเก่า — ทำไม blog ของผมเคยจ่าย $14 ทุกเดือนเพื่อรัน MySQL#

ก่อนหน้านี้ blog เดียวกันนี้รันบน WordPress + MySQL บน Cloudways สแตกเดียวกับเว็บเกือบครึ่งโลก เปิดบิลทุกเดือน $14 รวมหลายเว็บแล้วเดือนละหลายพันบาท

WordPress เป็น CMS ที่ครองตลาดอยู่ประมาณ 40% ของเว็บทั้งโลก สูตรการทำงานของมันคือ: ทุกครั้งที่มีคนเปิดหน้า blog หนึ่งหน้า PHP จะรัน → ถาม MySQL ว่า “บทความ ID 42 มีเนื้อหาอะไร” → MySQL ส่งกลับมา → PHP ประกอบเป็น HTML → ส่งกลับให้ browser

แปลเป็นภาษาคน คือ: ทุกผู้เข้าชม 1 คน = 1 รอบ “ปรุงสด” ในครัวหลังบ้าน บทความเดียวกัน คนอ่านพันคน ครัวก็ปรุงพันรอบ ทั้งที่เนื้อหาไม่ได้เปลี่ยนเลย

ปัญหาที่ตามมามี 4 ชั้น:

1. ค่าใช้จ่ายต่อเนื่อง — ต้องมี server เปิด 24/7 รอเสิร์ฟ ต่อให้ blog มีคนอ่านเดือนละไม่กี่ร้อยคน ก็จ่ายเท่าเดิม เหมือนเปิดร้านอาหารทั้งวันรอลูกค้าวันละ 3 คน

2. Plugin compatibility — WordPress จะใช้งานได้จริง ต้องติดตั้ง plugin ครบ — SEO, cache, security, form, image optimizer สิบกว่าตัว แต่ละตัวอัปเดตแยก บางทีอัปเดตแล้วชนกันเอง เว็บพังกลางดึก ตื่นมาเจอลูกค้าโทรมาบ่น

3. Security patches — WordPress = เป้าโจมตีอันดับหนึ่งของโลก เพราะใช้กันเยอะ hacker เลยเขียนเครื่องมือสแกนช่องโหว่อัตโนมัติยิงรัวๆ ทุกวันมีบอทพยายาม brute-force หน้า /wp-admin ผมเป็นพันครั้ง ต้องลง security plugin มาบล็อก แล้วก็ต้องอัปเดต security plugin อีกที

4. Slow without cache plugin — ปรุงสดทุกครั้ง “ช้าโดยธรรมชาติ” เลยต้องลง cache plugin มาเก็บผลที่ปรุงแล้ว — แต่ cache plugin ก็มีบั๊กของมัน บางทีอัปเดตเนื้อหาแล้ว cache ไม่ล้าง ลูกค้าเห็นของเก่า

ที่ตลกร้ายคือ — WordPress เกิดปี 2003 ตอนนั้น “blog แบบมี database” คือมาตรฐาน เพราะมันคือทางเดียวที่ทำได้จริง จะให้ผู้เขียนล็อกอินเข้ามากดปุ่ม “Publish” แล้วเนื้อหาขึ้นเว็บทันที ก็ต้องมี admin panel ต้องมี form ต้องมี database เก็บว่าคำไหนอยู่ ID เท่าไร

แต่ปี 2026 เครื่องมือเปลี่ยนไปเยอะแล้ว — เราไม่จำเป็นต้องลากครัวทั้งครัวมาด้วยอีกต่อไป

โลกใหม่ — Static-first architecture: ปรุงเสร็จก่อน เสิร์ฟทันที#

แนวคิดของ static-first คือ “ไหนๆ บทความก็เขียนเสร็จแล้ว ทำไมต้องปรุงใหม่ทุกครั้งที่มีคนเข้า” ปรุงครั้งเดียวตอนเขียนเสร็จ แล้วเก็บเป็น HTML สำเร็จรูปไว้บนชั้น พอคนเข้ามาก็หยิบจานเสิร์ฟ

มันมี 4 ชิ้นส่วนที่ประกอบกันเป็น stack ปี 2026:

1. Markdown files เก็บใน Git — บทความทุกบทความเขียนเป็นไฟล์ .md ธรรมดา (ภาษาเขียนที่อ่านออกเลย ไม่ต้องมี editor พิเศษ) เก็บใน Git repo (GitHub/GitLab) Git คือ “source of truth” ของเว็บทั้งเว็บ ใครเปลี่ยนคำไหน ตอนไหน เพราะอะไร ดูได้หมดผ่าน git log ไม่ต้องมี admin panel ไม่ต้องมีหน้าล็อกอิน — การ “publish” คือการ git push

2. Static Site Generator (SSG) — โปรแกรมที่อ่าน markdown ทั้งโฟลเดอร์ แล้ว generate ออกมาเป็น HTML สำเร็จรูปทุกหน้า ที่นิยมก็ Astro, Next.js, Hugo, Eleventy, Jekyll blog ของผมใช้ Astro เพราะมัน framework-agnostic เขียน component ได้หลายภาษา และ build เร็ว

3. Edge hosting — เอา HTML ที่ generate เสร็จ ไป host บน edge network ทั่วโลก เช่น Cloudflare Pages, Vercel, Netlify “Edge” แปลว่า server กระจายอยู่หลายร้อยเมือง คนไทยเข้าก็ได้จาก server ที่สิงคโปร์/กรุงเทพ คนยุโรปเข้าก็ได้จาก server ที่แฟรงก์เฟิร์ต/ลอนดอน ความเร็วเลย “ใกล้ลูกค้า” เสมอ

4. Object storage สำหรับรูป — รูปภาพไม่เก็บใน Git (มันใหญ่) แต่เก็บแยกใน object storage ราคาถูกๆ เช่น Cloudflare R2, AWS S3, Bunny CDN blog นี้ใช้ R2 — ราคาถูกกว่า S3 และไม่มี egress fee (ค่าโยนข้อมูลออก) ซึ่ง S3 คิดแพงมาก

flow ทั้งหมดมันสั้นๆ แค่นี้:

1
เขียน Markdown → git push → SSG build อัตโนมัติ
2
              → deploy ขึ้น edge → CDN เสิร์ฟทั่วโลก

ไม่มี database ตรงไหนเลย ไม่มี server ที่รันรอ ไม่มีฟอร์มล็อกอิน ไม่มีอะไรต้องเฝ้า

ที่สำคัญ — pattern นี้ไม่ได้ผมคิดเองนะ ใน IT Foundation EP.04 — Architectures เคยคุยเรื่อง Jamstack ไปแล้วในมุมหลังบ้าน EP.09 ก็มาขยายต่อในมุม “แล้วทำไมเลิก database ได้จริงๆ”

3 เหตุผลที่ static-first ชนะสำหรับเว็บ content#

เมื่อไหร่ “database กลับมา” แม้ในเว็บ static#

อ่านมาถึงตรงนี้อาจคิดว่า — “เออ แต่ blog มันต้องมี search สิ มี comment สิ ต้องมีอะไรที่เป็น dynamic บ้างสิ ถ้าไม่มี database จะทำได้ยังไง”

คำตอบคือ — มี แต่เป็น “database แบบเล็ก เฉพาะกิจ” ไม่ใช่ database server กลางที่ต้องรันตลอด แต่ละฟีเจอร์ใช้คนละเครื่องมือ:

Search → Pagefind — Pagefind เป็น static search engine มัน build index ของบทความทั้งหมดตอน build site แล้วเก็บเป็นไฟล์ JSON ขนาดเล็ก ตอนผู้ใช้พิมพ์ค้นหา JavaScript ใน browser โหลดไฟล์ index มาค้นใน browser เอง — ไม่มี database server ในวงจรเลย

Comments → Giscus / utterances — แทนที่จะเก็บ comment ใน database ของเราเอง ใช้ GitHub Issues เป็น storage แต่ละบทความ map ไปที่ 1 issue ผู้อ่านล็อกอินด้วย GitHub แล้ว comment เป็น reply ของ issue ภาระเรื่อง spam, account, moderation = GitHub จัดการให้

Forms → Cloudflare Workers + KV — ฟอร์ม contact ส่งข้อมูลไปที่ Worker (function เล็กๆ ที่รันบน edge เฉพาะตอนถูกเรียก ไม่ได้รันตลอด) Worker เก็บข้อมูลใน KV (key-value storage เล็กๆ) หรือส่งต่อเข้าอีเมล/LINE Notify

Newsletter → ConvertKit / Buttondown / Beehiiv — งานจัดการ subscriber list, ส่งอีเมล, ติดตาม open rate มันยุ่งพอที่จะให้ SaaS ภายนอกทำดีกว่า เราแค่ฝัง form ของเขาในเว็บ

Analytics → Cloudflare Analytics / Plausible — แทนที่จะเก็บ pageview log ใน database ของเรา ใช้บริการ analytics ที่ privacy-friendly (ไม่ใช้ cookie, ไม่ track ข้าม site) เห็นตัวเลขที่ต้องการโดยไม่ต้องมี database ของเราเอง

ที่น่าสังเกตคือ — ทุกข้อข้างบน “database” ก็ยังอยู่ในระบบนั่นแหละ แค่มันไม่ใช่ database ของเรา ไม่ใช่ database ที่เราต้องดูแล ไม่ใช่ database ที่ต้องเปิดตลอด 24 ชม. แต่ละชิ้นเป็นบริการจ่ายตามใช้ หรือฟรีในระดับการใช้งานปกติ

ใครยังไม่ค่อยเก็ตเรื่อง serverless / edge / Workers แนะนำย้อนไป IT Foundation EP.04 — Architectures ก่อน จะเห็นภาพ Jamstack กับ Serverless ที่ผมพูดตรงนี้ชัดขึ้น

Pattern นี้ใช้ได้ถึงไหน — ไม่ใช่แค่ blog#

อย่าเพิ่งคิดว่า “pattern นี้เหมาะกับ blog เล็กๆ ของเด็กเขียนเล่น” — มันใช้กับเว็บที่ใหญ่กว่า blog ผมเป็นพันเท่าได้สบาย:

เว็บที่ใช้ได้ดี (content-first):

• Blog (เคสนี้)
• Portfolio ของ designer / photographer / freelancer
• Documentation site — Stripe docs, Tailwind docs, Cloudflare docs ทั้งหมดเป็น static site ที่สร้างจาก markdown
• Marketing landing page — เว็บโปรโมตสินค้าหน้าเดียว
• Corporate website — about us / สินค้า / ข่าว / ติดต่อ
• Small e-commerce — Snipcart + static / Shopify Hydrogen หรือ Astro + Stripe checkout (แค่ติดปุ่มซื้อ ไม่ต้องมี backend ของตัวเอง)

เว็บที่ “ไม่เหมาะ” — ยังต้องมี database จริงจัง:

• Dashboard / admin panel ที่ข้อมูลเปลี่ยนทุกวินาที
• Social network ที่มี user-generated content จำนวนมาก
• Real-time app เช่น chat, live stream
• Banking / fintech ที่ต้องมี transaction integrity (ลองย้อนไปดู EP.08 — Transaction + Concurrency)
• Marketplace ที่ต้อง match buyer/seller สดๆ

เส้นแบ่งง่ายๆ คือ — “เนื้อหาเปลี่ยนรายวัน/รายสัปดาห์ตามที่คนเขียน publish ใหม่” → static ดี. “เนื้อหาเปลี่ยนรายวินาทีตาม user ทำอะไร” → ต้องมี database

เคสจริงที่ใหญ่กว่า blog ผมหลายเท่า#

เพื่อยืนยันว่า pattern นี้ scale ได้จริง ลองดูเว็บใหญ่ๆ ที่ทุกคนรู้จัก:

Vercel.com เอง — เว็บของบริษัทที่ host เว็บเป็นล้านๆ เว็บ ใช้ Next.js + edge ของตัวเอง ไม่มี traditional database สำหรับ content

Stripe Documentation — Stripe เป็นบริษัท fintech ที่ประมวลผลเงินเป็นแสนล้านเหรียญต่อปี แต่ documentation ของเขา (stripe.com/docs) เป็น markdown + custom SSG เก็บใน Git สิทธิ์การแก้แต่ละหน้ากำหนดผ่าน GitHub permission

Cloudflare Workers Documentation — เหมือนกัน developers.cloudflare.com เป็น static site เนื้อหาเป็น markdown ใน public GitHub repo ใครเห็นที่ผิด pull request แก้ได้

Tailwind CSS docs / React docs / TypeScript handbook — รายชื่อยาวจนหมดแถบ ทั้งหมด pattern เดียวกัน

ถ้า documentation ของบริษัทระดับ Stripe / Cloudflare ที่ traffic เป็นพันเท่าของ blog ทั่วไป ยังใช้ static-first — เว็บบริษัทขนาดกลางในไทยจะมีเหตุผลอะไรที่ต้องเช่า server WordPress รันตลอดวัน?

มุมผู้บริหาร — เว็บคุณควรย้ายออกจาก WordPress ตอนไหน#

ถ้ากำลังจ่ายค่า hosting WordPress อยู่เดือนละหลายพัน ลอง check 3 signal นี้:

1. เนื้อหาเปลี่ยนไม่บ่อย — เว็บบริษัท เว็บโปรเจกต์ portfolio ที่ update เดือนละ 1-2 ครั้ง ถ้าเข้าข่ายนี้ ปรุงสดทุก request = เปลือง

2. ไม่มี user login / e-commerce / dynamic data — ไม่มีระบบสมาชิก ไม่มีตะกร้าสินค้า ไม่มีฟอร์มที่ซับซ้อนกว่า contact form ถ้าใช่ คุณไม่ต้องการ database

3. ค่า hosting + ค่าดูแล plugin + ค่าจ้าง dev แก้ปัญหารายเดือน รวมแล้วเกินค่ากาแฟ — ถ้าใช่ static-first คืนเงินส่วนนี้ให้เกือบหมด

WordPress ไม่ได้ “แย่” นะ มันเหมาะกับเว็บที่ทีมไม่ใช่สาย tech ต้อง publish เนื้อหาผ่านหน้าจอ admin (ตอนนี้มี git-based CMS อย่าง Decap, Tina, Sanity ที่ทำหน้า admin สวยๆ ให้คนไม่ใช่ dev ใช้ได้บนเว็บ static แล้ว แต่ก็ยังมี learning curve)

แต่สำหรับเว็บ content ส่วนใหญ่ของบริษัทขนาดเล็ก-กลาง ที่ทีมพอเขียน markdown ได้ (หรือมี AI ช่วย) — WordPress = technical debt ของยุค 2010s ที่ลากมาถึงยุคนี้

การย้ายไม่ต้องใหญ่ครับ ไม่ต้อง migrate ทั้งหมดทีเดียว เริ่มจาก blog ก่อน หรือ landing page ตัวต่อไปลอง deploy บน Cloudflare Pages ดู ใช้แค่เดือนสองเดือนก็เห็นเอง

ปิดท้าย — แล้ว database จริงๆ มันอยู่ที่ไหนกัน#

EP.09 เราคุยเรื่อง “เว็บที่ไม่มี database” — content static เสิร์ฟจาก edge

แต่นี่คือมุมเล็กที่สุดของ spectrum เท่านั้น พอเป็นเว็บ ไม่ต้องเก็บ state ของผู้ใช้ ทุกอย่างเลยง่าย

EP.10 จะ flip มุมตรงข้าม — แทนที่ database จะ “หายไป” เราจะย้ายมันมาอยู่บนเครื่องของผู้ใช้แต่ละคนแทน — SQLite + Local-first architecture เคสคือพวก Notion offline, Apple Notes, Obsidian, Linear ที่ data อยู่ในเครื่องคุณก่อน แล้วค่อย sync ขึ้น cloud ทีหลัง

จาก “ไม่มี database เลย” → “database อยู่ในกระเป๋าคุณตลอดเวลา” 2 pattern นี้ดูเหมือนตรงข้ามกัน แต่จริงๆ มาจากความคิดเดียวกัน — เลิกพึ่ง database server กลาง

→ EP.10 — มุม Personal Data: SQLite + Local-first