
Railway หรือ Render: เซิร์ฟเวอร์ว่างอาจถูกกว่า แต่โหลดทั้งวันกลับแพงกว่า

Railway อาจถูกกว่าสำหรับแบ็กเอนด์ที่ใช้ CPU น้อย แม้จะเปิดบริการไว้ทั้งเดือน ส่วน Render อาจถูกกว่าเมื่อใช้ CPU ต่อเนื่อง เพราะ อัตราของ Railway คิด CPU และ RAM ตามปริมาณที่ใช้ ขณะที่ ราคา web service ของ Render กำหนดตามขนาด instance ที่เลือก โดยขนาด 512 MB ราคา 7 ดอลลาร์ต่อเดือน และขนาด 2 GB ราคา 25 ดอลลาร์ต่อเดือน
คำตอบจึงขึ้นกับ CPU เฉลี่ย RAM ที่กระบวนการถือไว้ และข้อมูลขาออก ไม่ใช่ราคาเริ่มต้นเพียงอย่างเดียว บริการที่รอคำขออาจใช้ CPU น้อยแต่ยังมีค่า RAM บน Railway ส่วน instance แบบจ่ายเงินของ Render ยังมีค่า compute ตราบใดที่เปิดอยู่ แม้แทบไม่มีคำขอ ตารางด้านล่างเทียบบริการเดียวก่อน แล้วจึงรวมผลของ workspace และ staging ที่ว่างบ่อย
คิดต้นทุนจากการใช้ CPU และ RAM คนละส่วน
อัตรา Railway สำหรับบริการทั่วไปคือ 0.00000772 ดอลลาร์ต่อ vCPU ต่อวินาที และ 0.00000386 ดอลลาร์ต่อ RAM 1 GB ต่อวินาที หากสมมติเดือนยาว 730 ชั่วโมง จะคิดเป็นประมาณ 20.29 ดอลลาร์ต่อ vCPU ที่ใช้งานเต็มเดือน และ 10.14 ดอลลาร์ต่อ RAM 1 GB ที่ถือไว้เต็มเดือน ดังนั้น CPU เฉลี่ย 0.1 vCPU มีต้นทุน CPU ราว 2.03 ดอลลาร์ ไม่ใช่ต้นทุนของ 1 vCPU เต็มเดือน
RAM เปลี่ยนผลเปรียบเทียบได้มากกว่าที่ราคาเริ่มต้นบอก หากบริการถือ RAM 512 MB ตลอดเดือน ต้นทุนส่วนนั้นอยู่ที่ประมาณ 5.07 ดอลลาร์ แม้ CPU จะว่างเกือบตลอดเวลา เมื่อรวม CPU เฉลี่ย 0.05 vCPU ต้นทุนก่อน egress อยู่ราว 6.09 ดอลลาร์ และขยับเป็น 7.10 ดอลลาร์ที่ CPU เฉลี่ย 0.1 vCPU การมีคำขอน้อยจึงไม่ได้ทำให้ค่า RAM หายไป ตราบใดที่กระบวนการยังทำงานและถือหน่วยความจำนั้น
Render คิดอีกแบบหนึ่ง: ค่า instance จ่ายตามเวลาที่เปิดและขนาดที่เลือก จึงต้องเลือกขนาดให้รับช่วงโหลดสูงสุดที่สำคัญต่อบริการด้วย ขนาด 512 MB มี 0.5 CPU ส่วนขนาด 2 GB มี 1 CPU หากบริการใช้ CPU เฉลี่ยต่ำแต่มีช่วงพุ่งเกินขนาดเล็ก การเทียบกับราคา 7 ดอลลาร์อาจไม่ตรงกับ configuration ที่ใช้งานได้จริง ตัวเลข CPU ในตารางเป็นสมมติฐานต้นทุน ไม่ใช่ผลทดสอบว่าโค้ดเดียวกันทำงานเร็วเท่ากันบนทั้งสองแพลตฟอร์ม
สี่ระดับโหลดทำให้ผู้ที่ถูกกว่าสลับกัน

ตัวอย่างสมมตินี้ให้แบ็กเอนด์หนึ่งบริการทำงานครบ 730 ชั่วโมงต่อเดือน ส่งข้อมูลออก 5 GB และใช้ Railway Hobby เทียบกับ Render Hobby workspace ซึ่งไม่มีค่าสมาชิกรายเดือน ค่า egress ของ Railway เท่ากับ 0.25 ดอลลาร์ ส่วนข้อมูลออก 5 GB ยังอยู่ในโควตาของ Render ตัวเลข Railway รวมขั้นต่ำของ Hobby แล้วและปัดเป็นเซนต์ โดยยังไม่รวมฐานข้อมูล ดิสก์ และบริการอื่น
- CPU เฉลี่ย 0.05 vCPU, RAM 512 MB: Railway ประมาณ 6.34 ดอลลาร์ เทียบกับ Render ขนาด 512 MB ที่ 7 ดอลลาร์ Railway ถูกกว่าประมาณ 0.66 ดอลลาร์
- CPU เฉลี่ย 0.1 vCPU, RAM 512 MB: Railway ประมาณ 7.35 ดอลลาร์ เทียบกับ Render ขนาดเดิมที่ 7 ดอลลาร์ Render ถูกกว่าประมาณ 0.35 ดอลลาร์
- CPU เฉลี่ย 0.25 vCPU, RAM 2 GB: Railway ประมาณ 25.61 ดอลลาร์ เทียบกับ Render ขนาด 1 CPU และ RAM 2 GB ที่ 25 ดอลลาร์ Render ถูกกว่าประมาณ 0.61 ดอลลาร์
- CPU เฉลี่ย 1 vCPU, RAM 1 GB: Railway ประมาณ 30.68 ดอลลาร์ เทียบกับ Render ขนาด 1 CPU และ RAM 2 GB ที่ 25 ดอลลาร์ Render ถูกกว่าประมาณ 5.68 ดอลลาร์ ภายใต้สมมติฐานว่า instance นั้นรองรับโหลดที่ต้องการได้
ที่ RAM 512 MB และไม่มี egress ต้นทุน Railway จะเท่ากับ Render ราคา 7 ดอลลาร์เมื่อ CPU เฉลี่ยประมาณ 0.095 vCPU หรือใกล้หนึ่งในสิบ vCPU เมื่อเพิ่ม egress เป็น 5 GB ตามตัวอย่าง จุดตัดลดลงเป็นราว 0.083 vCPU เพราะ Render ยังไม่คิดส่วนเกิน bandwidth บริการที่ CPU เฉลี่ยอยู่ใกล้จุดนี้จึงเปลี่ยนผู้ที่ถูกกว่าได้จากทราฟฟิกเพียงส่วนหนึ่งของบิล
กรณี RAM 2 GB มีจุดตัดกับ Render ราคา 25 ดอลลาร์ที่ CPU เฉลี่ยราว 0.23 vCPU หากไม่คิด egress และราว 0.22 vCPU เมื่อรวม egress 5 GB ส่วนบริการที่ถือ RAM เพียง 1 GB มีจุดตัดสูงกว่า เพราะ Railway คิดหน่วยความจำตามที่ใช้ ขณะที่ Render ขนาด 25 ดอลลาร์จัดสรร RAM มา 2 GB อยู่แล้ว นี่เป็นเหตุผลที่การเทียบ CPU เฉลี่ยโดยไม่ระบุ RAM อาจให้คำตอบผิด
Egress เปลี่ยนผลของบริการที่โหลดสูง

Railway คิด egress ของบริการ 0.05 ดอลลาร์ต่อ GB ส่วน เกณฑ์ outbound bandwidth ของ Render ให้ Hobby workspace รวม 5 GB ต่อเดือน และคิดข้อมูลที่ส่งผ่านอินเทอร์เน็ตเกินโควตา 0.15 ดอลลาร์ต่อ GB โควตา Render ใช้ร่วมกันทั้ง workspace ไม่ได้เริ่มใหม่สำหรับทุก instance หากมี production, staging และ worker ส่งข้อมูลออกพร้อมกัน ต้องรวมปริมาณของทั้งหมดก่อนหาส่วนเกิน
ลองเปลี่ยนเฉพาะ egress ในแถว CPU เฉลี่ย 1 vCPU และ RAM 1 GB จาก 5 เป็น 100 GB ต่อเดือน Railway จะมีต้นทุนประมาณ 35.43 ดอลลาร์ ส่วน Render Hobby จะอยู่ที่ 39.25 ดอลลาร์ ซึ่งมาจากค่า instance 25 ดอลลาร์กับข้อมูลเกินโควตา 95 GB ในตัวอย่างนี้ Railway กลับมาถูกกว่า แม้จะแพ้เมื่อ egress อยู่ที่ 5 GB ผลดังกล่าวเป็นการคำนวณจากอัตรา ไม่ใช่ผลทดสอบประสิทธิภาพหรือใบเรียกเก็บเงินจริง
เส้นทางของข้อมูลก็มีผลต่อจำนวน GB ที่ถูกคิด คำตอบ API ที่ส่งให้ผู้ใช้และการเชื่อมต่อบริการภายนอกผ่านอินเทอร์เน็ตนับเป็นข้อมูลออกของ Render ขณะที่ทราฟฟิกระหว่างบริการภายในเครือข่ายส่วนตัวของ Render ไม่ถูกนับในเกณฑ์นี้ สำหรับ Railway การใช้เครือข่ายส่วนตัวระหว่างบริการช่วยหลีกเลี่ยง egress สาธารณะได้เช่นกัน การประเมิน backend ที่คุยกับฐานข้อมูลหรือบริการอื่นจึงควรแยกทราฟฟิกภายในออกจากทราฟฟิกที่ออกสู่อินเทอร์เน็ต
ค่า workspace ทำให้ราคา instance ไม่ใช่ยอดทั้งทีม
Railway Hobby มีขั้นต่ำ 5 ดอลลาร์ต่อเดือนและรวมเครดิตการใช้งานจำนวนเท่ากัน หากใช้ทรัพยากรต่ำกว่า 5 ดอลลาร์ก็ยังจ่าย 5 ดอลลาร์ แต่หากใช้ 8 ดอลลาร์ ยอดรวมเป็น 8 ดอลลาร์ ไม่ใช่ 13 ดอลลาร์ Railway Pro ใช้หลักเดียวกันกับขั้นต่ำและเครดิต 20 ดอลลาร์ต่อเดือน โดยเพิ่มความสามารถสำหรับการทำงานเป็นทีม ดังนั้นบริการที่ใช้ทรัพยากร 30.43 ดอลลาร์ก่อน egress จะยังมีต้นทุนตามการใช้งานนั้นเมื่ออยู่บน Pro เพราะเกินขั้นต่ำแล้ว
ฝั่ง Render มีองค์ประกอบต่างกัน: รายละเอียดค่าโฮสต์ของ Render ระบุว่า Hobby workspace ราคา 0 ดอลลาร์ต่อเดือนพร้อม bandwidth 5 GB ส่วน Pro workspace ราคา 25 ดอลลาร์ต่อเดือนพร้อม bandwidth 25 GB และค่า compute คิดแยกตามบริการ ดังนั้น web service ขนาด 25 ดอลลาร์บน Pro workspace เริ่มที่ 50 ดอลลาร์ก่อนส่วนเกินอื่น การเทียบ Railway 30.43 ดอลลาร์กับ Render 25 ดอลลาร์จึงใช้ได้กับสมมติฐาน Render Hobby เท่านั้น
เมื่อมี production กับ staging อย่างละบริการ Render คิดค่า instance ที่เปิดอยู่แต่ละตัว ส่วน Railway รวมการใช้ CPU, RAM และ egress ของบริการในแผนเข้ากับเครดิตรายเดือน หาก staging ว่างแต่ยังทำงานทั้งเดือน ค่า RAM บน Railway และค่า instance บน Render ยังอยู่ในบิล ขณะที่ค่า workspace แบบจ่ายเงินเพิ่มยอดของ Render อีกชั้นหนึ่ง การแยกต้นทุนต่อบริการออกจากยอดทั้ง workspace ทำให้เห็นผลของ environment ที่เพิ่มขึ้นชัดกว่าเทียบราคา instance เดี่ยว
Staging ว่างบ่อย: CPU ว่างต่างจากบริการหลับ

Railway มี Serverless สำหรับพักบริการเมื่อไม่มีกิจกรรม โดย คำอธิบาย Serverless ของ Railway ระบุว่าระบบดูแพ็กเก็ตขาออกและโดยทั่วไปจะพักหลังไม่มีแพ็กเก็ตประมาณ 5–10 นาที การเชื่อมต่อฐานข้อมูลที่ยังทำงานหรือ telemetry อาจทำให้บริการไม่พัก เมื่อพักแล้วบริการหยุดสะสมค่า compute แต่คำขอแรกหลังปลุกอาจตอบช้า และบางกรณีอาจได้รับข้อผิดพลาด 502
สมมติ staging ใช้ CPU เฉลี่ย 0.1 vCPU และ RAM 512 MB เฉพาะช่วงที่ทำงานรวม 176 ชั่วโมงในเดือน 730 ชั่วโมง พร้อม egress 1 GB ค่าใช้ทรัพยากร Railway จะอยู่ราว 1.76 ดอลลาร์ แต่หากเป็นบริการเดียวใน Hobby ยอดจ่ายยังติดขั้นต่ำ 5 ดอลลาร์ หากบริการไม่พักและทำงานครบเดือน ต้นทุน CPU กับ RAM ตามสมมติฐานเดิมจะขึ้นเป็นประมาณ 7.10 ดอลลาร์ก่อน egress ส่วนต่างนี้เกิดจากชั่วโมงที่กระบวนการทำงานจริง ไม่ใช่การลดจำนวนคำขอเพียงอย่างเดียว
Render มีเงื่อนไขอีกแบบสำหรับ staging: paid instance ไม่พักอัตโนมัติเมื่อไม่มีทราฟฟิก แต่คิดค่า compute ตามเวลาที่เปิดใช้งาน หาก suspend instance ขนาด 7 ดอลลาร์และให้ทำงานเพียง 176 ชั่วโมงในเดือนสมมติ 730 ชั่วโมง ค่า compute ตามสัดส่วนจะราว 1.69 ดอลลาร์ โดยบริการไม่พร้อมรับคำขอระหว่าง suspend ส่วน Free web service พักหลังไม่มีคำขอเข้า 15 นาทีและต้องใช้เวลาปลุกกลับมา ตัวเลือก Free จึงเปลี่ยนทั้งค่าใช้จ่ายและพฤติกรรมการตอบคำขอ ไม่ใช่เพียงลดราคาของ paid instance
จุดตัดใช้ได้เมื่อขนาดบริการรับโหลดจริง
ตารางแสดงต้นทุนภายใต้ CPU เฉลี่ยและ RAM ที่กำหนด แต่ค่าเฉลี่ยไม่ได้บอกว่าโหลดพุ่งสูงเพียงใดหรืออยู่นานเท่าไร บริการที่เฉลี่ย 0.1 vCPU อาจต้องการมากกว่า 0.5 CPU ในบางช่วง; หากเป็นเช่นนั้น Render ขนาด 7 ดอลลาร์อาจไม่ใช่ตัวเลือกที่เทียบได้ ขณะเดียวกันแถว 1 vCPU เฉลี่ยทั้งเดือนใช้ขนาด 1 CPU ของ Render เต็มตามสมมติฐาน จึงควรพิจารณาความสามารถในการรับโหลดและพื้นที่เผื่อควบคู่กับส่วนต่างราคา
สำหรับ backend ที่เปิดตลอดเวลาและมี egress ต่ำ ต้นทุนจะค่อย ๆ เอนเข้าหา Render เมื่อ CPU เฉลี่ยหรือ RAM สูงขึ้น ส่วน staging ที่พักได้จริงลดชั่วโมงคิด compute บน Railway อย่างเห็นได้ชัด แต่ยังมีขั้นต่ำของแผน การเลือกจึงอยู่ที่รูปแบบโหลดของทุกบริการใน workspace รวมถึงเวลาที่ต้องพร้อมรับคำขอ: บริการซึ่งยอมให้ตื่นช้าหรือ suspend เป็นช่วง ๆ ได้มีสมมติฐานค่าใช้จ่ายต่างจากบริการ production ที่ต้องเปิดรอตลอดเดือน
อ่านเพิ่มเติม:
บทความที่เกี่ยวข้อง


Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว

Postman หรือ Insomnia: ทีมใหญ่แลก RAM กับระบบกำกับ API

Supabase หรือ Neon: ฐานข้อมูลที่หลับได้อาจถูกกว่า จนทราฟฟิกทำงานทั้งวัน

AWS Lambda หรือ Cloudflare Workers: งานรอ I/O คิดเงินคนละนาฬิกา

Supabase หรือ Firebase: งานอ่านกับงานเขียนให้คำตอบคนละแบบ
สมัครรับจดหมายข่าวของเรา
รับข่าวสารล่าสุดเกี่ยวกับ Web3, AI และคริปโตส่งตรงถึงกล่องจดหมายของคุณ