เปรียบเทียบทางเลือก DigitalOcean สำหรับนักพัฒนาปี 2026

สิ่งที่ทางเลือกอื่นของ DigitalOcean เปลี่ยนแปลงจริง

ทางเลือกอื่นของ DigitalOcean ส่วนใหญ่เปลี่ยนแค่ยอดเงินในใบแจ้งหนี้ ไม่ใช่ตัวเครื่อง คุณยังคงได้รับ Linux virtual machine ที่มี public IP, virtio disk และสิทธิ์ root เหมือนเดิม และ kernel ของคุณก็ไม่ได้สนใจว่าโลโก้บน control panel เป็นของใคร ความแตกต่างที่ใช้ตัดสินใจเลือกคือราคาต่อ GB ของ RAM, ปริมาณ transfer allowance ที่รวมมาให้และค่าใช้จ่ายต่อ byte ที่เกินกำหนด, ประเภทของ disk ที่ใช้จริง และระดับของ stack เหนือระบบปฏิบัติการที่ผู้ให้บริการจะดูแลให้คุณ

คู่มือนี้เปรียบเทียบตามเกณฑ์ดังกล่าว เนื่องจากนักพัฒนาสามารถตรวจสอบทุกหัวข้อได้จาก terminal หรือจากรายการราคาที่ประกาศไว้ นอกจากนี้ยังระบุถึงกรณีที่ DigitalOcean เป็นคำตอบที่เหมาะสมที่สุด เพราะการเปรียบเทียบที่ไม่มีการยอมรับข้อดีของคู่แข่งถือเป็นเพียงโฆษณาเท่านั้น

ราคาด้านล่างทั้งหมดเป็นราคาตามรายการที่ประกาศไว้ ณ วันที่ 5 สิงหาคม 2026 ราคามีการเปลี่ยนแปลงอยู่เสมอ และมีผู้ให้บริการมากกว่าหนึ่งรายในที่นี้ที่ปรับราคาในช่วงปี 2026 อย่างไรก็ตาม โครงสร้าง ราคาเปลี่ยนแปลงช้ากว่ามาก ดังนั้นให้อ่านสัดส่วนและรูปแบบการเรียกเก็บเงินก่อน แล้วจึงตรวจสอบตัวเลขปัจจุบันบนหน้าเว็บไซต์ของผู้ให้บริการอีกครั้งก่อนตัดสินใจใช้งาน

ราคาต่อ GB ของ RAM คือตัวเลขที่ควรนำมาเปรียบเทียบ

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

ภายในผู้ให้บริการรายเดียวกัน ราคาต่อ GB ของ RAM แทบไม่มีการเปลี่ยนแปลง DigitalOcean คิดราคาที่ $6.00 ต่อ GB สำหรับแผน 1 GB และคิดราคาเท่ากันที่ $6.00 ต่อ GB สำหรับแผน 4 GB ซึ่งมีราคาอยู่ที่ $24.00 ต่อเดือน การเลือกแผนที่ใหญ่ขึ้นกับผู้ให้บริการรายเดิมไม่ได้ส่วนลด ดังนั้นขนาดของแผนจึงไม่ใช่ปัจจัยในการตัดสินใจ แต่เป็นตัวผู้ให้บริการเองต่างหาก

Akamai ซึ่งปัจจุบันขายบริการที่เคยเป็นของ Linode ตั้งราคาแผน shared 2 GB และ 4 GB ไว้ที่ $12 และ $24 ซึ่งเท่ากับ DigitalOcean แบบดอลลาร์ต่อดอลลาร์ แผนเริ่มต้นของพวกเขามีราคาถูกกว่าที่ $5.00 การที่สองบริษัทตั้งราคาตรงกันเป๊ะเป็นสัญญาณที่น่าสนใจว่า ราคาระดับนั้นถูกกำหนดโดยอิงจากคู่แข่ง ไม่ใช่ต้นทุนฮาร์ดแวร์ และราคาจะยังคงไล่เลี่ยกับคู่แข่งรายนั้นต่อไป

ช่องว่างของราคาจะปรากฏชัดเมื่อเทียบกับผู้ให้บริการที่มีศูนย์ข้อมูลเป็นของตนเองและขายในสกุลเงินยูโร Hetzner รุ่น CX23 ให้ RAM คุณมา 4 GB ในราคาประมาณ $6.49 ต่อเดือน ซึ่งคิดเป็น $1.62 ต่อ GB หรือเกือบหนึ่งในสี่ของอัตราค่าบริการจาก DigitalOcean ตัวเลขดอลลาร์นี้เป็นการแปลงมาจากราคาที่ประกาศเป็นยูโร จึงมีความผันผวนตามอัตราแลกเปลี่ยน นอกจากนี้ Hetzner ยังได้ปรับขึ้นราคา cloud ในช่วงปี 2026 ดังนั้นบทความเปรียบเทียบเก่าๆ จึงอ้างอิงตัวเลขที่ไม่มีอยู่จริงแล้ว

ราคาต่อ GB ของ RAM ไม่ได้บอกอะไรเกี่ยวกับ CPU ที่คุณได้รับ vCPU แบบ shared หมายความว่า hypervisor จะจัดสรรคอร์ของคุณไปใช้ร่วมกับผู้เช่ารายอื่น และการตรวจสอบที่แท้จริงต้องทำบนเครื่องที่คุณเช่าใช้งานจริง:

vmstat 1 10

ให้อ่านคอลัมน์ st ซึ่งนับเปอร์เซ็นต์ของเวลาที่ vCPU ของคุณพร้อมทำงาน แต่ hypervisor กลับส่งคอร์ทางกายภาพไปให้ผู้อื่นใช้งานแทน ค่าที่ต่ำเพียงไม่กี่เปอร์เซ็นต์ในขณะที่มีโหลดถือเป็นเรื่องปกติ แต่ถ้าตัวเลขเป็นเลขสองหลักอย่างต่อเนื่อง แสดงว่าโฮสต์นั้นมีการใช้งานเกินขีดจำกัด (oversubscribed) และไม่มีราคาต่อ GB ใดที่คุ้มค่ากับคอร์ที่คุณใช้งานไม่ได้ ให้รันการตรวจสอบในช่วงเวลาที่มีการใช้งานสูง เพราะ steal time เป็นปัญหาที่เกิดจากเพื่อนบ้าน และเพื่อนบ้านแต่ละรายก็มีตารางเวลาการใช้งานที่ต่างกัน สำหรับภาพรวมของค่าใช้จ่ายในการโฮสต์ต่อเดือนเมื่อรวมค่าพื้นที่จัดเก็บและปริมาณการรับส่งข้อมูลแล้ว โปรดอ่าน ค่าใช้จ่าย VPS รายเดือน

ต้นทุนที่แท้จริงของโควตาการรับส่งข้อมูลที่รวมมาให้

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean รวมโควตาการรับส่งข้อมูลขาออกไว้ 1 TB สำหรับแผนเริ่มต้น และคิดค่าบริการส่วนเกินเป็นราย GiB ซึ่งคำนวณแล้วอยู่ที่ประมาณ $10.00 ต่อ TB ที่เกินมา Akamai ให้โควตา TB เท่ากันแต่คิดค่าบริการส่วนเกินถูกกว่าประมาณครึ่งหนึ่ง คืออยู่ที่ประมาณ $5.00 ต่อ TB ส่วน Vultr ให้โควตา 2 TB โดยมีอัตราค่าบริการส่วนเกินใกล้เคียงกัน ในขณะที่ Hetzner ให้โควตา 20 TB และคิดค่าบริการประมาณ $1.20 ต่อ TB หลังจากนั้น ซึ่งถือว่าถูกกว่าเจ้าอื่นถึงหนึ่งลำดับขั้น

รายละเอียดเชิงโครงสร้าง 3 ประการมีความสำคัญมากกว่าตัวเลขที่ระบุไว้ในโฆษณา ประการแรก การรับส่งข้อมูลขาเข้า (inbound) ของทั้ง 4 ผู้ให้บริการนั้นฟรี ดังนั้นจะนับเฉพาะข้อมูลที่คุณส่งออกไปเท่านั้น ประการที่สอง DigitalOcean และ Vultr จะนำโควตาของเซิร์ฟเวอร์ทุกเครื่องในบัญชีมารวมกัน (pool) ดังนั้นหากมีเครื่องหนึ่งใช้งานหนักก็จะดึงโควตาของเครื่องอื่นไปใช้ และเซิร์ฟเวอร์ขนาดเล็กหลายเครื่องจะใช้โควตาร่วมกันในกองกลาง ประการที่สาม การรับส่งข้อมูลระหว่างเซิร์ฟเวอร์ผ่านเครือข่ายส่วนตัวหรือ VPC มักจะไม่ถูกนำมาคำนวณเลย นี่คือเหตุผลว่าทำไมการตั้งค่าฐานข้อมูลให้สื่อสารผ่านอินเทอร์เฟซส่วนตัวจึงเป็นการตัดสินใจทั้งในแง่ของค่าใช้จ่ายและความปลอดภัย

ข้อมูลเหล่านี้ไม่มีความหมายหากคุณใช้งานไม่ถึงขีดจำกัด บล็อก, API ที่ตอบกลับเป็น JSON หรือ SaaS ขนาดเล็กจะไม่ใช้งานถึง 1 TB ต่อเดือน แต่สำหรับวิดีโอ, แกลเลอรีรูปภาพ, เซิร์ฟเวอร์เกม, แพ็กเกจมิเรอร์ และเป้าหมายการสำรองข้อมูลนอกสถานที่นั้นอาจถึงขีดจำกัดได้ ควรวัดผลก่อนที่จะคาดเดา:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m จะแสดงปริมาณการรับส่งข้อมูลรายเดือน โดยแยกเป็นข้อมูลที่ได้รับและข้อมูลที่ส่งออก เฉพาะคอลัมน์ข้อมูลที่ส่งออกเท่านั้นที่จะถูกนำมาคิดค่าบริการ ฐานข้อมูลจะว่างเปล่าในตอนเริ่มต้น ดังนั้นค่าที่อ่านได้จริงครั้งแรกจะปรากฏหลังจากติดตั้งไปแล้ว 1 วัน และข้อมูลรายเดือนที่สมบูรณ์จะปรากฏหลังจากผ่านไป 1 เดือน จนกว่าจะถึงตอนนั้น กราฟแบนด์วิดท์ของผู้ให้บริการจะเป็นบันทึกเดียวที่คุณมี

ควรตั้งคำถามอีกหนึ่งข้อที่ไม่มีในรายการราคา คือเมื่อคุณใช้งานเกินโควตา ผู้ให้บริการจะเรียกเก็บเงินเพิ่มหรือจำกัดความเร็วพอร์ต (throttle) การเรียกเก็บเงินเพิ่มทำให้เสียค่าใช้จ่าย แต่การจำกัดความเร็วพอร์ตทำให้เสียผู้ใช้งาน ในช่วงเวลาที่คุณมีผู้ใช้งานมากที่สุดพอดี คุณควรทราบว่าเมื่อเกิด traffic spike ขึ้น ผลลัพธ์จะเป็นอย่างไร

NVMe หรือ SATA และวิธีการตรวจสอบสิ่งที่คุณได้รับจริง

แผงควบคุมระบุว่าเป็น NVMe นั่นเป็นเพียงการกล่าวอ้างเกี่ยวกับดิสก์ในโฮสต์ ซึ่งเครื่องเสมือนของคุณอาจไม่ได้อยู่บนดิสก์เหล่านั้น พื้นที่จัดเก็บข้อมูลแบบ Local จะวางดิสก์เสมือนของคุณไว้บนไดรฟ์ภายในเครื่องเดียวกัน ส่วนพื้นที่จัดเก็บข้อมูลแบบ Network จะวางไว้บนคลัสเตอร์จัดเก็บข้อมูลแยกต่างหากที่เข้าถึงผ่านเครือข่ายของศูนย์ข้อมูล ซึ่งเป็นสิ่งที่ทำให้การปรับขนาดทันที การย้ายข้อมูลแบบ live migration และการทำ snapshot-in-place เป็นไปได้

ภายใน Guest ทั้งสองแบบจะดูเหมือนกันทุกประการ:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA และ rotational จะรายงานค่า 0 สำหรับทุกสิ่งที่โฮสต์ประกาศว่าเป็น non-rotational ดังนั้น network volume ที่มีพื้นฐานมาจาก NVMe จึงรายงานค่าเดียวกับ NVMe แบบ local ค่านี้บอกเพียงว่าดิสก์ไม่ใช่จานหมุน แต่ไม่สามารถบอกคุณได้ว่าดิสก์นั้นอยู่ที่ไหน การยืนยันดิสก์ NVMe บน Linux จะอธิบายถึงชื่ออุปกรณ์และความหมายของแต่ละชื่อ

การทดสอบที่แยกความแตกต่างระหว่างสองสิ่งนี้คือค่า latency ที่ queue depth 1 เนื่องจากการอ่านขนาดเล็กเพียงรายการเดียวไม่มีสิ่งใดให้ซ่อนอยู่ NVMe แบบ local จะตอบสนองจากแชสซีเดียวกัน ส่วน network volume จะเพิ่มการเดินทางไป-กลับผ่านเครือข่ายของศูนย์ข้อมูลในการอ่านทุกครั้ง ดังนั้นค่า latency ต่ำสุดจึงสูงกว่า แม้ว่า throughput ที่ queue depth ลึกๆ จะดูใกล้เคียงกันก็ตาม

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

การรันครั้งแรกจะแสดงบล็อก clat ซึ่งเป็นค่า completion latency ให้ดูที่บรรทัด 99th percentile แทนค่าเฉลี่ย เพราะค่าเฉลี่ยจะซ่อนอาการสะดุดที่ผู้ใช้งานรู้สึกได้ การรันครั้งที่สองจะแสดง IOPS= ในบรรทัดสรุป ให้รันทั้งสองคำสั่งบนผู้ให้บริการที่คุณใช้งานอยู่และบน instance ทดลองของผู้ให้บริการที่คุณกำลังพิจารณา ในวันเดียวกัน แล้วเปรียบเทียบตัวเลขทั้งสองชุดของคุณ ตัวเลขที่เผยแพร่จากผู้ให้บริการรายใดก็ตามถูกวัดบนเครื่องที่คุณไม่สามารถตรวจสอบได้ ให้รันการทดสอบสามครั้งในช่วงเวลาที่ต่างกันด้วย เพราะโฮสต์ที่ว่างงานและโฮสต์ที่งานยุ่งจะให้ผลลัพธ์ที่ต่างกันแม้จะเป็นแผนบริการเดียวกัน การทำ Benchmarking VPS อย่างถูกต้อง ครอบคลุมถึงวิธีการ และ ความหมายที่แท้จริงของ SSD VPS ครอบคลุมถึงคำศัพท์ทางการตลาดที่อยู่เบื้องหลัง

ภูมิภาค: วัดค่าความหน่วง อย่าดูแค่แผนที่

รายการภูมิภาคเป็นเพียงการตลาดจนกว่าคุณจะวัดค่าจริง สิ่งที่ผู้ใช้สัมผัสคือระยะเวลาไป-กลับ (round trip) จากเครือข่ายของพวกเขาไปยังเซิร์ฟเวอร์ของคุณ ซึ่งขึ้นอยู่กับเส้นทางที่แพ็กเก็ตวิ่งผ่าน ไม่ใช่ระยะทางบนแผนที่ เซิร์ฟเวอร์ที่อยู่ห่างออกไป 300 กม. แต่อยู่หลังลิงก์เชื่อมต่อที่มีความหนาแน่นสูง ย่อมทำงานได้แย่กว่าเซิร์ฟเวอร์ที่อยู่ห่างออกไป 1,500 กม. บนเส้นทางที่โล่งกว่า

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr จะแสดงทุกจุดเชื่อมต่อ (hop) พร้อมค่าการสูญเสียข้อมูลและความหน่วงของแต่ละจุด ดังนั้นการกระโดดของเวลา 60 ms ระหว่างสองจุดเชื่อมต่อจะระบุได้ว่าลิงก์ใดที่เป็นปัญหา แทนที่จะโทษปลายทาง ให้รันคำสั่งนี้จากเครื่องที่อยู่ในเครือข่ายเดียวกับผู้ใช้ของคุณ เส้นทางระหว่างศูนย์ข้อมูลต่อศูนย์ข้อมูลเป็นเส้นทางที่ดีที่สุดบนอินเทอร์เน็ต และเป็นเส้นทางที่ทำให้ผู้ให้บริการทุกรายดูดีเท่าเทียมกัน

ประเด็นเชิงโครงสร้างประเด็นหนึ่งที่ยังคงสำคัญไม่ว่าราคาจะเปลี่ยนไปอย่างไร คือการที่ผู้ให้บริการมีภูมิภาคเดียวในทวีปของคุณ หมายความว่าแผนการกู้คืนระบบจากภัยพิบัติ (disaster recovery plan) ของคุณคือการย้ายข้ามทวีป ซึ่งจะมาพร้อมกับค่าความหน่วงที่เพิ่มขึ้นตามมา ให้คุณนับจำนวนภูมิภาคที่คุณสามารถย้ายระบบไปทำงานแทนได้จริง ไม่ใช่จำนวนภูมิภาคที่ระบุไว้บนหน้าเว็บไซต์

Snapshots และ backups คือค่าใช้จ่ายแยกต่างหาก

ส่วนเสริมด้านพื้นที่จัดเก็บข้อมูลคือจุดที่ทำให้แผนราคาประหยัดกลายเป็นราคาแพง DigitalOcean คิดค่าบริการ snapshots ที่ $0.06 ต่อ GiB ต่อเดือน และคิดราคา automatic backups เป็นสัดส่วนของเซิร์ฟเวอร์แทน โดยอยู่ที่ 20% ของราคาแผนสำหรับรายสัปดาห์ และ 30% สำหรับรายวัน หรือเลือกแบบคิดตามการใช้งานจริงต่อ GiB ทั้งสองรูปแบบมีเหตุผลรองรับในตัวเองแต่มีข้อเสียต่างกัน รูปแบบคิดเป็นเปอร์เซ็นต์จะแปรผันตามขนาดของเซิร์ฟเวอร์ ดังนั้นเซิร์ฟเวอร์ขนาดใหญ่ที่เก็บข้อมูลเพียงเล็กน้อยจะเสียค่าใช้จ่ายเกินความจำเป็น ส่วนรูปแบบคิดตาม GiB จะแปรผันตามปริมาณข้อมูลของคุณ ดังนั้นเซิร์ฟเวอร์ขนาดเล็กที่เชื่อมต่อกับ volume ขนาดใหญ่จะเสียค่าใช้จ่ายเกินความจำเป็น

จงสอบถามว่าการกู้คืนข้อมูลมีค่าใช้จ่ายเท่าใดและใช้เวลานานแค่ไหน เพราะราคาในการเก็บรักษา backup เป็นเพียงครึ่งหนึ่งของคำถามที่น่าเบื่อเท่านั้น และจงตรวจสอบว่าการลบเซิร์ฟเวอร์จะทำให้ snapshots ถูกลบไปด้วยหรือไม่

จากนั้นให้เก็บสำเนาข้อมูลที่ผู้ให้บริการไม่สามารถควบคุมได้ไว้ด้วย เนื่องจาก snapshots ของผู้ให้บริการจะอยู่ในบัญชีของผู้ให้บริการเอง ดังนั้นหากบัญชีถูกระงับ, การชำระเงินล้มเหลว หรือเข้าสู่ระบบไม่ได้ ข้อมูลทั้งเซิร์ฟเวอร์และ backups จะสูญหายไปพร้อมกัน การทำ restic backups ไปยังพื้นที่จัดเก็บที่คุณเป็นเจ้าของ มีค่าใช้จ่ายเพียงไม่กี่ดอลลาร์สำหรับ object storage ซึ่งสามารถกู้คืนไปยังผู้ให้บริการรายใดก็ได้ และเป็นสิ่งที่ทำให้การย้ายระบบสามารถย้อนกลับได้แทนที่จะเป็นการตัดสินใจที่แก้ไขไม่ได้

คุณต้องการจัดการ stack มากน้อยเพียงใด

ผู้ให้บริการแต่ละรายมีจุดยืนที่แตกต่างกัน บนสุดขั้วหนึ่ง คุณเช่าเครื่องและจัดการทุกอย่างด้วยตนเอง บนอีกสุดขั้วหนึ่ง คุณเพียงแค่ push git branch โดยไม่ต้องสนใจเซิร์ฟเวอร์เลย การเปรียบเทียบราคาต่อ GB ของ RAM จะใช้ได้เฉพาะกับฝั่งแรกเท่านั้น เพราะในฝั่งที่สอง คุณกำลังซื้อแรงงานแทนที่จะเป็นหน่วยความจำ และแรงงานไม่มีราคาต่อ GB

จงซื่อสัตย์กับตัวเองว่าคุณอยู่ฝั่งไหนก่อนที่จะเริ่มเปรียบเทียบสิ่งใดก็ตาม Managed database ราคา $15.15 ต่อเดือนอาจดูแพงเมื่อเทียบกับเซิร์ฟเวอร์ราคา $6 จนกว่าคุณจะคำนวณมูลค่าของชั่วโมงการทำงานที่อยู่เบื้องหลัง เช่น การทำ replication, failover, point in time restore, การอัปเกรด minor version และการแจ้งเตือนที่ปลุกใครบางคนขึ้นมาตอน 03:00 หากงานเหล่านั้นเป็นหน้าที่ของคุณ ก็จงจัดการเองและเก็บส่วนต่างนั้นไว้ แต่หากงานของคุณคือการพัฒนาแอปพลิเคชัน การซื้อบริการเหล่านี้ถือว่าคุ้มค่า ความแตกต่างระหว่างบริการแบบ managed และ unmanaged จะเป็นตัวกำหนดว่าคุณควรพิจารณาตารางราคาในคอลัมน์ใด หากคำตอบที่แท้จริงคือคุณต้องการครอบครองทั้งเครื่องและดิสก์ด้วยตนเอง นั่นเป็นคำถามเรื่อง VPS เทียบกับ dedicated server ไม่ใช่คำถามเรื่องผู้ให้บริการ คำถามในลักษณะเดียวกันนี้ยังปรากฏอยู่ในค่าใช้จ่ายรายเดือนส่วนอื่นของนักพัฒนา เช่น การเปรียบเทียบแผนบริการของ Claude และ ChatGPT ซึ่งขึ้นอยู่กับว่าคุณต้องการส่งต่องานให้ผู้อื่นมากน้อยเพียงใด มากกว่าที่จะดูเพียงราคาที่ประกาศไว้หน้าเว็บ

กรณีที่ DigitalOcean เป็นคำตอบที่เหมาะสม

DigitalOcean มีความได้เปรียบเมื่อคุณต้องการซื้อแพลตฟอร์มมากกว่าแค่เครื่องเสมือน (virtual machine)

• Managed databases: บริการ Managed PostgreSQL และ MySQL เริ่มต้นที่ $15.15 ต่อเดือน สำหรับ RAM ขนาด 1 GiB และพื้นที่จัดเก็บ 10 GiB โดยพื้นที่จัดเก็บเพิ่มเติมจะคิดค่าบริการเป็นราย GiB และ standby node จะคิดราคาต่อ node การสร้างความน่าเชื่อถือระดับเดียวกันด้วยตนเองหมายถึงการต้องใช้ Patroni หรือ repmgr, ระบบ consensus store, connection proxy และการซ้อมแผน failover ที่คุณต้องทำจริง ทีมงานขนาดสองคนไม่สามารถดูแลระบบเหล่านี้ไปพร้อมกับพัฒนาฟีเจอร์ใหม่ได้
• App Platform: เพียง push branch ระบบจะทำการ build, ออก certificate และรัน service ให้โดยที่คุณไม่ต้องคอย patch ระบบปฏิบัติการ การทำสิ่งนี้ด้วยตัวเองบน VPS ราคาถูกคือการที่คุณต้องมานั่งทำเองในวันเสาร์
• Object storage และ load balancers ที่รองรับโดย Terraform provider ที่สมบูรณ์: กลุ่มทรัพยากรที่คุณสามารถทำลายและสร้างใหม่จากโค้ดได้นั้นมีค่ามากกว่าราคาต่อหน่วยที่ถูกกว่า
• องค์กรที่อยู่เบื้องหลังผลิตภัณฑ์: มีระดับการสนับสนุนที่เผยแพร่ชัดเจน, หน้าสถานะระบบที่มีประวัติย้อนหลัง และองค์กรที่สามารถตอบแบบสอบถามด้านความปลอดภัยของลูกค้าได้ หากคุณทำธุรกิจขายต่อบริการโฮสติ้ง สิ่งเหล่านี้มีค่ามากกว่าส่วนต่างราคาเพียงไม่กี่ดอลลาร์ต่อ GB

จุดที่ DigitalOcean มีราคาสูงคือเมื่อใช้งานเครื่องเสมือนทั่วไปในปริมาณมากที่มีการรับส่งข้อมูลขาออก (outbound traffic) จริง ซึ่งเป็นกรณีที่ผู้ให้บริการรายอื่นเข้ามาแก้ไขได้ และเป็นสิ่งที่นักพัฒนาที่ทำ self-hosting ส่วนใหญ่เลือกซื้อ

การย้ายไปยังผู้ให้บริการรายใหม่โดยไม่เกิด Downtime

Downtime ระหว่างการย้ายระบบเกิดจากสาเหตุเดียว คือการที่ traffic ยังคงวิ่งไปยัง IP เก่าหลังจากที่ข้อมูลถูกย้ายไปยังเซิร์ฟเวอร์ใหม่แล้ว ขั้นตอนทั้งหมดด้านล่างนี้มีไว้เพื่อให้ช่วงเวลาดังกล่าวสั้นลงและคาดการณ์ได้

เริ่มต้นที่ DNS ล่วงหน้าอย่างน้อย 48 ชั่วโมงก่อนการย้าย ระบบ Resolver จะแคช A record ของคุณไว้ตามระยะเวลา TTL (time to live) ดังนั้น record ที่มี TTL 24 ชั่วโมงจะยังคงส่งผู้ใช้งานไปยังเซิร์ฟเวอร์เก่าต่อไปอีกสูงสุดหนึ่งวันหลังจากที่คุณเปลี่ยนค่า การลด TTL ในขณะที่ทำการย้ายนั้นไม่ได้ผล เพราะ Resolver ถือค่าเก่าพร้อมวันหมดอายุเดิมไว้แล้ว ให้ลดค่า TTL ลงก่อน รอให้ค่าเดิมหมดอายุ แล้วจึงค่อยทำการย้าย

dig +noall +answer example.com A
dig +noall +authority example.com SOA

คำสั่งแรกจะแสดงค่า TTL ปัจจุบันในคอลัมน์ที่สองของผลลัพธ์ ให้ตั้งค่าเป็น 300 ที่ผู้ให้บริการ DNS ของคุณ จากนั้นรอเป็นเวลาที่นานกว่าค่าที่คุณเพิ่งเปลี่ยนไป

จากนั้นให้ดำเนินการตามลำดับนี้

1. จัดเตรียมเซิร์ฟเวอร์ใหม่และทำ hardening ก่อนที่จะนำสิ่งใดไปวางบนนั้น สิบนาทีแรกบน VPS ใหม่ ครอบคลุมส่วนที่ผู้คนมักข้ามไปเมื่อรีบร้อน
2. ติดตั้ง application stack และรันการคัดลอกข้อมูลรอบแรกด้วย rsync ในขณะที่เซิร์ฟเวอร์เก่ายังคงให้บริการตามปกติ
3. ออก TLS certificate บนโฮสต์ใหม่ทันที โดยใช้ DNS-01 challenge เนื่องจาก HTTP-01 challenge จะตรวจสอบกับ IP ที่ DNS ชี้ไปในปัจจุบัน ซึ่งก็คือเซิร์ฟเวอร์เก่านั่นเอง DNS-01 challenge จะช่วยขจัดปัญหาเรื่องลำดับขั้นตอนนี้ไปได้ทั้งหมด
4. ทดสอบโฮสต์ใหม่ก่อนการเปลี่ยนแปลงใดๆ ต่อสาธารณะโดยการ override DNS บนแล็ปท็อปของคุณเอง เพิ่ม 203.0.113.20 example.com ไปยัง /etc/hosts แล้วเข้าใช้งานเว็บไซต์จริง จากนั้นจึงลบรายการดังกล่าวออก การทดสอบนี้จะไม่ส่งผลกระทบต่อผู้ใช้งาน
5. จัดการกับคำถามเรื่องขนาดของฐานข้อมูล หากมีขนาดไม่กี่ GB การ dump และ restore จะทำเสร็จได้ภายในช่วงที่หยุดการเขียนข้อมูล หากขนาดใหญ่กว่านั้น ให้ตั้งค่า replication จากฐานข้อมูลเก่าไปยังฐานข้อมูลใหม่ล่วงหน้าหลายวันและปล่อยให้ข้อมูลซิงค์กัน เพื่อให้ช่วงเวลาที่ต้องหยุดเขียนข้อมูลครอบคลุมเฉพาะการเลื่อนสถานะ (promotion) เท่านั้น
6. หยุดการเขียนข้อมูล นำแอปพลิเคชันเข้าสู่โหมดบำรุงรักษาหรือโหมดอ่านอย่างเดียว นี่เป็นส่วนเดียวที่ผู้ใช้งานจะเห็น และควรใช้เวลาเพียงไม่กี่นาที
7. รันการซิงค์ส่วนต่างครั้งสุดท้าย: รัน rsync ตัวเดิมอีกครั้ง ตามด้วยการซิงค์ฐานข้อมูลครั้งสุดท้าย
8. เปลี่ยน A และ AAAA records ไปยัง IP ใหม่ ด้วย TTL 300 วินาที Resolver ส่วนใหญ่จะปรับตามภายในเวลาประมาณห้านาที
9. ปล่อยให้เซิร์ฟเวอร์เก่าทำงานและเข้าถึงได้ต่อไปอีกอย่างน้อยหนึ่งวัน เนื่องจาก Resolver บางตัวเพิกเฉยต่อค่า TTL ที่สั้น หากแอปพลิเคชันเก่ายังคงเขียนข้อมูลได้ ผู้ใช้งานที่มาถึงช้าจะเขียนข้อมูลลงในฐานข้อมูลที่ผิด ดังนั้นให้ชี้โฮสต์เก่าไปยังฐานข้อมูลใหม่หรือแสดงหน้าบำรุงรักษาจากโฮสต์นั้นแทน
10. เฝ้าระวังอัตราข้อผิดพลาดของเซิร์ฟเวอร์ใหม่เป็นเวลาหนึ่งวัน ปรับค่า TTL กลับเป็นค่าปกติ และทำลายเซิร์ฟเวอร์เก่าทิ้งหลังจากผ่านไปหนึ่งสัปดาห์ แทนที่จะทำในเย็นวันเดียวกัน

การคัดลอกข้อมูลประกอบด้วยสองคำสั่ง โดยแต่ละคำสั่งรันสองรอบ สำหรับการซิงค์ไฟล์:

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a จะคงความเป็นเจ้าของ สิทธิ์ และ timestamp ไว้, -H จะคง hard links ไว้, -AX จะคง ACLs และ extended attributes ไว้ และ --numeric-ids จะป้องกันไม่ให้ rsync ทำการ remapping user ID ผ่านชื่อที่แตกต่างกันระหว่างสองเครื่อง ให้รันคำสั่งนี้ล่วงหน้าหลายวัน แล้วรันอีกครั้งระหว่างช่วงที่หยุดการเขียนข้อมูล ซึ่งจะโอนย้ายเฉพาะส่วนที่มีการเปลี่ยนแปลงเท่านั้น

สำหรับ PostgreSQL ที่มีขนาดเล็กพอที่จะ dump ได้:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

สำหรับ MySQL หรือ MariaDB:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction จะทำการ dump ภายใน transaction เดียวบนตาราง InnoDB ดังนั้นผลลัพธ์ที่ได้จะมีความสอดคล้องกันและแอปพลิเคชันยังคงเขียนข้อมูลได้ในขณะที่รันคำสั่ง หากไม่มี flag นี้ mysqldump จะล็อกตาราง ซึ่งหมายความว่าช่วงเวลาที่คุณหยุดเขียนข้อมูลจะเริ่มเร็วกว่าที่คุณวางแผนไว้และคุณไม่ได้เป็นผู้กำหนดเวลาเอง

มีสองสิ่งที่อาจเกิดปัญหาภายนอกเซิร์ฟเวอร์ของคุณ: IP address ใหม่ไม่มีชื่อเสียงด้านอีเมล ดังนั้นอีเมลที่ส่งตรงจากเครื่องใหม่จะถูกกรองเป็นสแปม ให้ส่งผ่าน relay ที่มีชื่อเสียงอยู่แล้ว และคู่ค้าใดก็ตามที่ทำ allowlist IP ขาออกของคุณ เช่น payment gateway หรือ firewall ของลูกค้า จะต้องได้รับการอัปเดตก่อนการย้ายระบบ มิฉะนั้นการเรียกใช้งานเหล่านั้นจะเริ่มล้มเหลวทันทีที่ traffic ย้ายไปที่ใหม่

สิ่งที่ควรตรวจสอบก่อนตัดสินใจเลือกใช้บริการ

• ตรวจสอบว่าราคาที่เห็นเป็นราคาโปรโมชันหรือไม่ และราคาเมื่อต่ออายุจะเป็นเท่าใด ส่วนลดสำหรับรอบบิลแรกที่เพิ่มขึ้นเป็นสองเท่าเมื่อต่ออายุถือเป็นต้นทุนจริงที่ถูกเลื่อนเวลาออกไปเท่านั้น
• ตรวจสอบว่าเป็นการชำระเงินล่วงหน้าหรือไม่ แผนการชำระเงินล่วงหน้าแบบหลายปี ซึ่งเป็นรูปแบบที่ SSD Nodes ใช้ จะช่วยให้ได้ราคาต่อ GB ของ RAM ที่ถูกลงมากโดยแลกกับการจ่ายเงินก้อนล่วงหน้า ข้อแลกเปลี่ยนคือคุณไม่สามารถยกเลิกบริการในเดือนถัดไปได้ ดังนั้นควรเลือกเงื่อนไขเวลาให้สอดคล้องกับความมั่นใจของคุณ
• ตรวจสอบค่าใช้จ่ายรายเดือนสำหรับ snapshot และค่าใช้จ่ายในการกู้คืนข้อมูลทั้งในแง่ของตัวเงินและระยะเวลาที่ใช้
• ตรวจสอบว่าการใช้งานเกินโควตาจะถูกเรียกเก็บเงินเพิ่มหรือถูกจำกัดความเร็ว
• ตรวจสอบว่า IPv6 มีการ routing อย่างถูกต้อง หรือเป็นเพียงแค่การเพิ่มหมายเลข IP เข้ามาเฉยๆ
• ตรวจสอบว่ามี API พร้อมกับ Terraform provider ที่ได้รับการดูแลรักษาหรือไม่ หากคุณต้องการสร้างโครงสร้างพื้นฐานใหม่จากโค้ดแทนการตั้งค่าด้วยตนเอง
• ตรวจสอบช่องทางการติดต่อฝ่ายสนับสนุน และเป้าหมายเวลาในการตอบกลับที่ประกาศไว้สำหรับกรณีเซิร์ฟเวอร์ล่ม ไม่ใช่สำหรับคำถามด้านการขาย

ให้เลือกพิจารณาจากปัจจัยที่เป็นต้นทุนหลักในบิลของคุณ หากปัจจัยนั้นคือหน่วยความจำ ราคาต่อ GB ของ RAM จะเป็นตัวตัดสิน หากเป็นปริมาณการรับส่งข้อมูลขาออก ปริมาณ transfer ที่รวมมาให้จะเป็นตัวตัดสิน หากเป็นเวลาของคุณเอง แพลตฟอร์มแบบ managed จะเป็นตัวตัดสิน ซึ่งของ DigitalOcean ถือว่าโดดเด่นที่สุดในบรรดาสี่ผู้ให้บริการที่เปรียบเทียบในที่นี้

FAQ

Hetzner ราคาถูกกว่า DigitalOcean เสมอไปหรือไม่

สำหรับ virtual machine แบบทั่วไป Hetzner มีราคาต่อ GB ของ RAM ที่ถูกกว่ามาก โดยอยู่ที่ประมาณ $1.62 เทียบกับ $6.00 ในแผนเริ่มต้นแบบ shared ณ วันที่ 5 สิงหาคม 2026 อย่างไรก็ตาม การเปรียบเทียบจะเปลี่ยนไปเมื่อพิจารณาบริการแบบ managed เนื่องจาก Hetzner ขายเฉพาะเซิร์ฟเวอร์และระบบเครือข่าย ดังนั้นหากต้องการ managed database หรือแพลตฟอร์มแบบ push-to-deploy คุณจะต้องติดตั้งเองหรือใช้บริการจากบุคคลที่สาม ซึ่งมีต้นทุนด้านเวลาและค่าใช้จ่ายแฝง นอกจากนี้ Hetzner ได้ปรับขึ้นราคา cloud ในช่วงปี 2026 ดังนั้นควรตรวจสอบราคาปัจจุบันในหน่วยยูโรแทนการอ้างอิงจากบทความเก่า

หากต้องการ managed database ควรเลือกใช้บริการใดแทน DigitalOcean

Vultr และ Akamai มีบริการ managed database ซึ่งเป็นตัวเลือกที่ใกล้เคียงที่สุดหากคุณใช้ DigitalOcean เพราะบริการนี้โดยเฉพาะ ผู้ให้บริการราคาประหยัดในยุโรปส่วนใหญ่ไม่มีบริการนี้ ซึ่งหมายความว่าคุณต้องดูแล PostgreSQL หรือ MySQL ด้วยตนเอง รวมถึงการทำ replication และการทดสอบ failover ซึ่งเป็นงานที่ต้องใช้ทักษะสูง ควรเปรียบเทียบต้นทุนนี้กับค่าบริการ $15.15 ต่อเดือนสำหรับ managed instance ขนาด 1 GiB ก่อนตัดสินใจว่าการเลือกเซิร์ฟเวอร์ที่ถูกกว่านั้นคุ้มค่าจริงหรือไม่

จะย้ายเว็บไซต์ที่ใช้งานจริงไปยังผู้ให้บริการรายใหม่โดยไม่ให้เกิด downtime ได้อย่างไร

ให้ลดค่า DNS TTL ลงเหลือ 300 วินาทีอย่างน้อย 48 ชั่วโมงก่อนการย้าย เนื่องจาก resolver จะยังคงส่งค่า IP เดิมตามค่า TTL ก่อนหน้า ให้สร้างและทดสอบโฮสต์ใหม่ในขณะที่โฮสต์เดิมยังคงให้บริการอยู่ โดยใช้ /etc/hosts override บนเครื่องของคุณเองเพื่อให้คุณเห็นผลลัพธ์เพียงคนเดียว จากนั้นให้หยุดการเขียนข้อมูลชั่วคราวสักครู่ ทำการ rsync ข้อมูลส่วนต่างครั้งสุดท้ายและ sync ฐานข้อมูลให้เรียบร้อย แล้วจึงเปลี่ยนค่า A และ AAAA record จากนั้นให้เปิดเซิร์ฟเวอร์เดิมทิ้งไว้อีกหนึ่งสัปดาห์เผื่อกรณีที่ resolver บางแห่งเพิกเฉยต่อค่า TTL ที่สั้นลง

VPS ที่ราคาถูกกว่าหมายถึงดิสก์ที่ช้ากว่าหรือไม่

ไม่เสมอไป สิ่งที่สำคัญคือดิสก์เสมือนของคุณเป็นแบบ local ที่อยู่บนโฮสต์หรือเป็นแบบ network storage cluster ซึ่งแผงควบคุมมักไม่ได้ระบุไว้ lsblk -o NAME,ROTA จะรายงาน 0 ให้ทั้งสองกรณีเนื่องจากเป็นแบบ non-rotational ทั้งคู่ ให้วัดผลด้วยการรัน fio พร้อม --iodepth=1 --bs=4k --direct=1 แล้วอ่านค่า 99th percentile completion latency แทน เพราะ network volume จะเพิ่มเวลา round trip ของเครือข่ายในศูนย์ข้อมูลเข้าไปในทุกการอ่าน ทำให้ค่า latency ต่ำสุดสูงกว่า local NVMe แม้ว่าค่า throughput ในคิวลึกจะดูใกล้เคียงกันก็ตาม

อีเมลจะยังคงถูกส่งจากเซิร์ฟเวอร์ใหม่ได้หรือไม่

มักจะไม่สามารถส่งได้ในทันที IP address ใหม่ไม่มีประวัติการส่งอีเมล ผู้รับจึงมองว่าอีเมลจาก IP นี้มีความน่าสงสัยและอาจถูกส่งไปยังโฟลเดอร์สแปมหรือถูกปฏิเสธทันที นอกจากนี้ SPF และ DKIM record จะยังคงชี้ไปยังโฮสต์เดิมจนกว่าคุณจะอัปเดตข้อมูล ควรส่งอีเมลจากแอปพลิเคชันผ่าน relay หรือบริการอีเมลที่มีความน่าเชื่อถืออยู่แล้ว และควรอัปเดต DNS record สำหรับอีเมลก่อนการย้ายระบบแทนที่จะทำหลังจากนั้น