ฐานข้อมูลที่โฮสต์เองต้องการ RAM เท่าไร?

สำหรับแอปเดียว — instance Postgres หรือ Redis บวก backend ของมัน — 1.7-2 GB คือ working set ที่เป็นจริง ดังนั้น Small ($8) พอดี หลายแอป หรือฐานข้อมูลโปรดักชันที่มี concurrency จริง ดันคุณไป Medium ($12) และหากเครื่องอื่นต้องเข้าถึง แพ็กเกจ dedicated-IP กำหนดขนาดตาม working set และจำนวนการเชื่อมต่อ ไม่ใช่ตามความหวัง

ทำไมโฮสต์เองแทนฐานข้อมูลที่จัดการให้?

การควบคุม คุณได้ postgresql.conf ทั้งหมด, superuser และ extension ใดก็ตามที่คุณต้องการ — pgvector, PostGIS, TimescaleDB, pg_cron — สิ่งที่ระดับที่จัดการให้มักล็อกหรือคิดค่าเพิ่ม การแลกเปลี่ยนคือการสำรอง การปรับจูน และการอัปเกรดเป็นของคุณให้รัน หากคุณอยากเป็นเจ้าของเครื่อง นี่คือจุดประสงค์

VPS ที่ใช้ร่วมกันโอเคสำหรับฐานข้อมูลโปรดักชันไหม?

สำหรับแอปเล็กถึงปานกลาง ใช่ สำหรับ OLTP หนัก — หลายร้อยธุรกรรมต่อวินาที การเขียนที่วิกฤตความหน่วง — เครื่อง shared-vCPU เป็นเครื่องมือผิด และเราจะพูดอย่างนั้นแทนที่จะขายให้คุณ Disk I/O และคล็อกรับประกันสำคัญที่นั่น และแพ็กเกจที่ใช้ร่วมกันไม่สัญญาทั้งสอง

ฉันให้เซิร์ฟเวอร์อื่นเชื่อมต่อฐานข้อมูลอย่างไร?

ผูก Postgres กับอินเทอร์เฟซที่ถูกต้อง เปิดพอร์ตเฉพาะกับ IP ที่ต้องการ และใช้แพ็กเกจที่มี IPv4 แบบเฉพาะเพื่อให้ที่อยู่เสถียรและเข้าถึงได้ อย่าเปิด 5432 ต่ออินเทอร์เน็ตทั้งหมด — firewall มันเฉพาะเซิร์ฟเวอร์แอปของคุณและกำหนดให้ใช้ TLS

ฉันต้องให้ ID ไหม?

ไม่ อีเมลเพื่อสมัคร USDC หรือ USDT เพื่อจ่าย ไม่มีเอกสาร root ในเวลาประมาณหนึ่งนาที

VPS สำหรับฐานข้อมูล

โฮสต์ PostgreSQL หรือ Redis เองบน VPS พร้อม root เต็มรูปแบบ — postgresql.conf ทั้งหมด, extension ที่บริการที่จัดการให้ไม่ยอมให้ติดตั้ง และขีดจำกัดที่ตรงไปตรงมาว่าเครื่องที่ใช้ร่วมกันรับได้และรับไม่ได้อะไร เริ่มต้น $8/เดือน

มีช่วงเวลาเฉพาะที่ฐานข้อมูลที่จัดการให้หยุดเป็นความสะดวกและเริ่มเป็นกำแพง คุณต้องการ extension ที่ระดับนั้นไม่มี คุณต้องการเห็น query plan จริงและปรับจูน work_mem คุณต้องการ superuser บริการที่จัดการให้เป็นค่าเริ่มต้นที่ดีจนถึงตอนที่คุณต้องเป็นเจ้าของสิ่งนั้น — และตอนนั้น VPS พร้อม root เต็มรูปแบบคือคำตอบที่ตรงไปตรงมา

หน้านี้เกี่ยวกับการรัน PostgreSQL หรือ Redis ของคุณเองอย่างถูกต้อง และการชัดเจนว่าที่ที่เครื่องที่ใช้ร่วมกันเป็นทางเลือกที่ถูกต้องและที่ที่ไม่ใช่

ฐานข้อมูลต้องการอะไรจริง ๆ

ฐานข้อมูลสนใจสองสิ่งที่เซิร์ฟเวอร์เกมไม่สนใจ: หน่วยความจำสำหรับ working set และ disk I/O รูปร่างคร่าว ๆ:

แอปเดียว — instance Postgres (หรือ Redis) บวกบริการ backend working set มักคือ 1.7-2 GB Small ($8) จัดการมันได้โดยไม่ดราม่า
สองสามแอป หรือ concurrency โปรดักชันจริง — การเชื่อมต่อมากขึ้น แคชใหญ่ขึ้น งานพื้นหลัง Medium ($12) ให้พื้นที่เหลือ
เครื่องอื่นต้องเข้าถึง — คุณต้องการที่อยู่ที่เสถียรและ routable ดังนั้น แพ็กเกจ dedicated-IPv4 (Small-IP $16 ขึ้นไป) เพิ่มเติมด้านล่าง

Redis เบากว่าอีก — มันผูกหน่วยความจำ ดังนั้นกำหนดขนาดแพ็กเกจตาม dataset บวก overhead แล้วเสร็จ Postgres คือตัวที่ตอบแทนการปรับจูนเล็กน้อย

เหตุผลจริงในการโฮสต์เอง: การควบคุม

นี่คือที่ที่ VPS ได้ที่ยืน บนเครื่องของคุณเองคุณได้:

postgresql.conf ทั้งหมด — shared_buffers, work_mem, max_connections, การตั้ง WAL ทั้งหมด ปรับจูนตามงานของคุณแทนค่าเริ่มต้นของผู้จำหน่าย
extension ใดก็ได้ pgvector สำหรับ embeddings และการค้นหาเชิงความหมาย, PostGIS สำหรับ geospatial, TimescaleDB สำหรับ time series, pg_cron, pg_stat_statements — ติดตั้งสิ่งที่คุณต้องการ ระดับที่จัดการให้มักจำกัดรายการ extension หรือกันไว้หลังแพ็กเกจสูงกว่า
superuser และ OS ข้างใต้มัน คุณย้าย data directory, ปรับจูน kernel, รัน pg_dump ตามกำหนดของคุณเอง และตั้ง streaming replication ไปยังอีกเครื่องได้หากต้องการ

หากไม่มีอะไรในนั้นสำคัญกับคุณ ฐานข้อมูลที่จัดการให้ก็โอเคจริง ๆ และคุณควรใช้มัน หน้านี้สำหรับกรณีที่มันสำคัญ

ที่ที่เครื่องที่ใช้ร่วมกันเป็นเครื่องมือผิด

พูดตรง ๆ: VPS แบบ shared-vCPU ไม่ได้สร้างมาสำหรับ OLTP หนัก — หลายร้อยธุรกรรมต่อวินาทีพร้อมการเขียนที่วิกฤตความหน่วง งานนั้นอยู่รอดหรือตายที่ disk I/O รับประกันและคล็อกคงที่ และแพ็กเกจที่ใช้ร่วมกันไม่สัญญาทั้งสอง หากนั่นคือคุณ คุณต้องการฮาร์ดแวร์เฉพาะ และเราขอบอกตอนนี้ดีกว่าดู latency p99 ของคุณทำให้เราทั้งคู่ขายหน้า

สำหรับกรณีที่พบมากกว่ามาก — ฐานข้อมูลหลังแอปเดียว เครื่องมือภายใน คลังวิเคราะห์ แคช — แพ็กเกจที่ใช้ร่วมกันถูกต้องพอดี

การสำรองไม่ใช่ทางเลือก

การโฮสต์เองหมายถึงการสำรองเป็นงานของคุณ และกฎหนึ่งคือ: ทำมันก่อนที่คุณต้องการ สำหรับ Postgres pg_dump บน cron สำหรับการสำรองเชิงตรรกะ หรือ WAL archiving สำหรับการกู้คืน point-in-time บนอะไรที่คุณใส่ใจจริง ส่ง dump ออกจากเครื่อง — ไปยัง object storage หรืออีกเซิร์ฟเวอร์ — เพื่อให้ดิสก์เสียไม่พาการสำรองไปด้วย ทดสอบการกู้คืนอย่างน้อยครั้งหนึ่ง การสำรองที่คุณไม่เคยกู้คืนคือความหวัง ไม่ใช่การสำรอง

ให้เซิร์ฟเวอร์อื่นเชื่อมต่อ

หากฐานข้อมูลให้บริการเฉพาะแอปบนเครื่องเดียวกัน ผูกมันกับ localhost แล้วเสร็จ — ไม่มีอะไรให้เปิด ทันทีที่เครื่องอื่นต้องเข้า สองสิ่งเปลี่ยน:

คุณต้องการที่อยู่ที่เสถียรและ routable — นั่นคือ แพ็กเกจ dedicated-IPv4 (Small-IP $16, Medium-IP $20) แพ็กเกจ NAT ใช้ที่อยู่ร่วมกัน ซึ่งโอเคสำหรับขาออกแต่ไม่ใช่การเป็นฐานข้อมูลที่เซิร์ฟเวอร์อื่นโทรเข้า
คุณ firewall มันหนัก เปิด 5432 (หรือ 6379) เฉพาะกับ IP เจาะจงที่ต้องการ ไม่เคยกับ 0.0.0.0/0 และกำหนดให้ใช้ TLS พอร์ต Postgres ที่เปิดบนอินเทอร์เน็ตสาธารณะถูกพบในไม่กี่นาที

เลือกแพ็กเกจ

การตั้งค่า	แพ็กเกจ
DB หลังแอปเดียว, localhost เท่านั้น	Small ($8)
สองสามแอป / concurrency โปรดักชัน	Medium ($12)
เซิร์ฟเวอร์อื่นต้องเชื่อมต่อเข้า	Small-IP ($16) / Medium-IP ($20)
OLTP หนัก หลายร้อย TPS	ฮาร์ดแวร์เฉพาะ ไม่ใช่ VPS ที่ใช้ร่วมกัน

ฐานข้อมูลที่โฮสต์เองส่วนใหญ่เริ่มบน Small และโตเป็น Medium หรือแพ็กเกจ dedicated-IP เมื่อรับแอปหรือ client ภายนอกมากขึ้น

ทำไมที่นี่

root เต็มรูปแบบหมายถึงมันคือฐานข้อมูลของคุณจนสุด — ทุกบรรทัดคอนฟิก ทุก extension กำหนดการสำรองของคุณเอง ไม่มีระดับตัดสินว่าคุณติดตั้งอะไรได้ การชำระเป็นคริปโต (USDC หรือ USDT บน Base, Ethereum หรือ Polygon) ไม่ต้อง KYC ไม่มีเอกสาร root ในเวลาประมาณ 60 วินาทีหลังจ่าย และคุณให้ Postgres รับการเชื่อมต่อได้สองสามนาทีถัดมา

สรุปที่ตรงไปตรงมา: โฮสต์เองเมื่อคุณต้องการการควบคุม — extension, การปรับจูน, superuser — และเมื่องานของคุณปานกลาง สำหรับฐานข้อมูลของแอปเล็กถึงกลาง แพ็กเกจที่ใช้ร่วมกันคือเครื่องมือที่ถูกต้อง สำหรับ OLTP วิกฤตความหน่วงหลายร้อย TPS มันไม่ใช่ และเราจะพูดอย่างนั้น พร้อมไหม? เลือกแพ็กเกจ