PgDog ปิดการระดมทุนและกำลังมุ่งหน้ามาสู่ฐานข้อมูลใกล้ตัวคุณ

 (pgdog.dev)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • PgDog เป็นพร็อกซีที่วางไว้หน้า PostgreSQL เพื่อขยาย Postgres ในแนวนอนได้ผ่านการทำ connection pooling, load balancing และ sharding โดยไม่ต้องเขียนแอปใหม่
  • มองว่าเหตุผลที่ยังมีฐานข้อมูลอย่าง Mongo หรือ Dynamo อยู่ เป็นเพราะ ปัญหาการขยายระบบของ Postgres และเชื่อว่าหากรองรับตารางขนาดเกิน 100TB และคำสั่งคิวรี 1 ล้านครั้งต่อวินาทีได้ ก็ไม่จำเป็นต้องใช้ฐานข้อมูลอื่น
  • PgDog ประมวลผลคิวรีมากกว่า 2 ล้านครั้งต่อวินาทีในโปรดักชัน, ทำ sharding เกิน 20TB ในขอบเขตที่ตรวจสอบแล้ว และมียอด GitHub Docker pull เกิน 1.4 ล้านครั้ง
  • ทีมขนาด 3 คนอาศัยประสบการณ์จากการสร้างแอปพลิเคชันขนาดใหญ่บน Postgres และการรองรับการขยายตัว 5 เท่าของ Instacart ในเดือนเมษายน 2020 เพื่อจัดการปัญหา Postgres sharding บน RDS, Aurora และ EC2
  • ระดมทุนได้ 5.5 ล้านดอลลาร์ จาก Basis Set, YC, Pioneer Fund และนักลงทุนรายอื่น พร้อมเดินหน้าสร้าง PgDog ให้เป็นผลิตภัณฑ์โอเพนซอร์สที่ทำให้ Postgres ใช้งานได้ในทุกขนาด

การระดมทุนและทิศทางของผลิตภัณฑ์

  • การพัฒนา Postgres ของ PgDog เริ่มต้นจากมุมมองที่ว่าเป็นฐานข้อมูลเดียวที่จำเป็นต้องมี
  • มองว่าเหตุผลที่ยังมีฐานข้อมูลอย่าง Mongo หรือ Dynamo อยู่ เป็นเพราะ ปัญหาการขยายระบบ ของ Postgres
  • เชื่อว่าหาก Postgres รองรับตารางขนาดเกิน 100TB และคำสั่งคิวรี 1 ล้านครั้งต่อวินาทีได้อย่างเหมาะสม ก็จะไม่ต้องใช้ฐานข้อมูลอื่น
  • PgDog ทำให้ การขยายในแนวนอน เป็นไปได้ด้วยการวางพร็อกซีไว้หน้า Postgres เดิม
  • PgDog สามารถดีพลอยได้ทุกที่ ทั้ง on-premises และในบัญชีคลาวด์ของผู้ใช้
  • เพียงดึง Docker image และเปลี่ยน DATABASE_URL แล้ว PgDog จะรับช่วงการทำงานต่อ

สถานะปัจจุบันและที่มาของการลงมือทำ

  • สถานะปัจจุบัน

    • PgDog กำลังประมวลผลคิวรีมากกว่า 2 ล้านครั้งต่อวินาทีในโปรดักชันหลายสิบสภาพแวดล้อม
    • ในขอบเขตที่ตรวจสอบแล้ว PgDog ทำ sharding ได้เกิน 20TB
    • PgDog เป็นโอเพนซอร์สและใครก็สามารถดีพลอยได้
    • มียอด Docker pull บน GitHub เกิน 1.4 ล้านครั้ง
    • เวอร์ชันใหม่ออกทุกวันพฤหัสบดี
    • คอมมูนิตี้ Discord กำลังเติบโต และมีการตอบคำถามกับให้การสนับสนุนทุกวัน

  • ทีมและเหตุผลที่น่าเชื่อถือ

    • PgDog เป็นสตาร์ตอัปขนาดเล็กที่มีทีมเพียง 3 คน
    • ทีมประกอบด้วยวิศวกรโครงสร้างพื้นฐาน, วิศวกรแอปพลิเคชัน และ generalist
    • ทีมได้สร้างและทำให้แอปพลิเคชันบน Postgres ทำงานในสเกลใหญ่ได้ตั้งแต่ก่อนที่ Postgres จะได้รับความสนใจอย่างกว้างขวาง
    • ที่ Instacart ทีมได้สั่งสมประสบการณ์การดูแล Postgres ระหว่างช่วงที่บริษัทขยายตัว 5 เท่าในเดือนเมษายน 2020
    • ตอนนั้นปัญหาใหญ่ที่สุดคือการทำให้ Postgres รองรับคำสั่งซื้อส่งของชำหลายแสนรายการต่อนาที
    • ทีมทำ Postgres sharding บน RDS, Aurora และ EC2 และแก้ปัญหาจริงด้วยหลักการพื้นฐานและโค้ดจำนวนมาก
    • เทคโนโลยีเดียวกันนี้ถูกนำมาให้ใช้งานในรูปแบบผลิตภัณฑ์โอเพนซอร์สแล้วในปัจจุบัน

  • วิธีการดีพลอยและเงินทุน

    • การพัฒนา PgDog ไม่ใช่การ pivot และเป้าหมายเดียวมาตลอดคือการขยาย Postgres
    • PgDog ถูกสร้างมาให้รันได้ทั้งบนคลาวด์ของผู้ใช้, colocation rack, on-premises และโน้ตบุ๊ก
    • PgDog ทำงานได้ในที่ที่ต้องการโดยไม่มี dependency หรือค่าใช้จ่าย serverless แฝง
    • หากมี CPU ให้ใช้งาน โค้ดแบบ multithread ของ PgDog จะใช้ CPU ทั้งหมด
    • มองว่าการนำ Postgres ไปใช้งานจะยังคงเพิ่มขึ้นต่อเนื่อง
    • ระดมทุนได้ 5.5 ล้านดอลลาร์จาก Basis Set, YC, Pioneer Fund และนักลงทุนรายอื่น ทำให้มี runway สำหรับหลายปี
    • เป้าหมายคือทำให้ Postgres ทำงานได้อย่างเหมาะสมสำหรับทุกคนและทุกขนาด

  • Enterprise edition

    • Enterprise edition ของ PgDog กำลังอยู่ระหว่างการพัฒนาเพื่อให้รันบน AWS ได้ง่ายขึ้น
    • Enterprise edition มาพร้อมการสนับสนุนจากทีมภายใต้ SLA

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • แม้จะมีคนบอกว่าเหตุผลที่มีฐานข้อมูลอย่าง Mongo หรือ Dynamo ก็เพราะปัญหาการสเกลของ Postgres แต่จากที่เคยใช้ Postgres ในหลายที่ ปัญหาอันดับหนึ่งกลับเป็นเรื่อง ความพร้อมใช้งานสูง มากกว่าการสเกลเสมอ
    คลัสเตอร์ Postgres เดียวจัดการธุรกรรม 100,000 รายการต่อนาทีได้สบาย แต่ถ้าโหนดหลักตาย ก็ต้องถูกเรียกมาจัดการ สลับไปใช้โหนดสำรองแบบแมนนวล แล้วก็ต้องเปลี่ยนโหนดสำรองด้วยมืออีก
    เครื่องมือแบบแมนนวลนั้นจุกจิกมาก แต่ก็ยังพอใช้งานได้ ส่วนทางแก้อัตโนมัตินั้นยังห่างไกลจากคำว่าใช้ได้จริง
    เพราะยังไม่มีเรื่องราวด้าน HA ที่ดีพอ จึงพยายามหลีกเลี่ยงการรัน Postgres แบบดูแลเองถ้าเป็นไปได้

    • เราก็รองรับ HA เช่นกัน: https://docs.pgdog.dev/features/load-balancer/
      มี load balancer ที่ทำงานเป็นค่าเริ่มต้นพร้อม health check และ failover และตอนนี้ก็ผ่านการใช้งานจริงมาพอสมควรแล้ว น่าลองดู
    • Patroni 1.0 ออกมาตั้งแต่ปี 2016 ก็เกือบ 10 ปีแล้ว
      https://github.com/patroni/patroni
    • สงสัยว่าเคยลอง cnpg ไหม
      สำหรับงานของฉัน มันทำงานได้ดีมากจริง ๆ
    • ตอนนี้ Patroni จัดการปัญหาในด้านนี้ได้ค่อนข้างดี
    • สงสัยว่าได้ลองดูอะไรอย่าง CloudNativePG หรือยัง: https://cloudnative-pg.io/

  • ถ้าใน “Why Us” เขียนว่า “เราเคยดูแล Postgres ที่ Instacart และตอนบริษัทโตขึ้น 5 เท่าในเดือนเมษายน 2020 ปัญหาใหญ่ที่สุดคือทำให้ Postgres รองรับออเดอร์ส่งของชำหลายแสนรายการต่อนาทีได้” ก็คงไม่มีคำตอบสำหรับคำถาม ทำไมต้องเรา ที่ดีกว่านี้แล้ว

    • ออเดอร์ 100,000 รายการต่อนาทีถือว่าเยอะมากไหม?
      ดูเหมือนว่า Postgres อินสแตนซ์เดียวก็น่าจะรับไหว
    • สงสัยว่าทำไมถึงเปลี่ยนเกณฑ์เป็น ต่อนาที
      SSD ระดับองค์กรคุณภาพสูงสมัยใหม่สามารถจัดการ fsync จริงได้ราว 35,000 ครั้งต่อวินาที
    • ฉันรู้สึกว่า Instacart ช้ามากและมี latency สูงอยู่เสมอ
      แน่นอนว่าไม่รู้ว่านั่นเป็นเพราะ Postgres หรือเพราะข้อบกพร่องด้านการออกแบบอย่างอื่น

  • โดยพื้นฐานแล้วอยากทำความเข้าใจ ตอนนี้มี DB ขนาด 4TB อยู่บนเซิร์ฟเวอร์ใหญ่เครื่องเดียว
    ถ้าใช้เครื่องมือพร็อกซีอย่าง PGDog โครงสร้างจะกลายเป็นการรันเซิร์ฟเวอร์เล็ก 8 เครื่องที่แต่ละเครื่องรับผิดชอบประมาณ 500GB และมีเซิร์ฟเวอร์ระดับกลางอีก 1 เครื่องสำหรับพร็อกซีใช่ไหม
    โปรเจ็กต์ปัจจุบันมีทราฟฟิกเขียนจากหลายบริการสูงมาก และเว็บแอปก็อ่านจากตรงนี้
    ตอนนี้เริ่มเข้าใกล้จุดที่ไม่ว่าทำ indexing, query optimization, caching หรืออัปเกรดเซิร์ฟเวอร์แค่ไหนก็แทบไม่ช่วยแล้ว
    ก็กำลังดูทางเลือกย้ายข้อมูล static ส่วนใหญ่ไป ClickHouse เพื่อลดขนาด DB อยู่เหมือนกัน แต่อยากฟังว่าการทำ sharding ด้วย PgDog หรืออย่างอื่นจะมีประโยชน์กับเคสแบบนี้ไหม

    • “เซิร์ฟเวอร์เล็ก 8 เครื่องที่แต่ละเครื่องรับผิดชอบราว 500GB และมีเซิร์ฟเวอร์ระดับกลาง 1 เครื่องสำหรับพร็อกซี” นั่นคือโครงสร้างนั้นเป๊ะ
      ติดต่อมาได้เลย (lev@pgdog.dev)
      เราอาจช่วยได้ หรืออย่างน้อยก็บอกได้ว่าตอนนี้อะไรเวิร์ก อะไรไม่เวิร์ก เพื่อให้เห็นตัวเลือกที่มี
    • นั่นคือแนวคิดของ sharding
      ถ้าอ่านเอกสารของ pgdog จะเห็นว่าคุณต้องบอกมันว่าจะ route คำขอไปยัง shard server ไหน มันไม่ได้ทำงานได้เองแบบเวทมนตร์
      ถึงอย่างนั้นมันก็มีคุณค่าเพราะช่วย reuse การเชื่อมต่อที่มีต้นทุนสูงเป็นพิเศษใน Postgres
      เพราะมันไม่ใช่เวทมนตร์ คุณจึงต้องเข้าใจว่าเกิดอะไรขึ้นข้างใน และตัวอย่างเช่น ไม่มีธุรกรรมข้าม shard
      การทำ sharding นั้นยากถ้าคุณต้องใส่ใจเรื่องความสอดคล้องของข้อมูล ดังนั้นฉันจะดูก่อนว่าแอปพลิเคชันจะได้ประโยชน์จาก read replica ไหม
      แต่ละ replica จะมีสำเนาข้อมูลทั้งหมด และรับการเขียนที่ master เท่านั้น ส่วนธุรกรรมที่สามารถไปรันบน replica ซึ่งอาจช้ากว่าเกือบเรียลไทม์เล็กน้อยนั้น คุณต้องเป็นคนตัดสินเอง
      ตัวอย่างเช่น การอ่านเพื่อสร้างหน้าเว็บมักจะปลอดภัยที่จะทำบน replica แต่การอ่าน-แก้ไข-เขียนจะไม่ปลอดภัย

  • สงสัยว่าสิ่งนี้จะช่วยกับ การอัปเกรดเมเจอร์เวอร์ชัน ซึ่งเป็นสาเหตุของ downtime ที่ใหญ่ที่สุดใน Postgres ได้อย่างไร
    pooler นั้นยอดเยี่ยมสำหรับ failover และ load balancing แต่เพราะการอัปเกรดจึงยังต้องมี downtime ราว 10~20 นาทีอย่างสม่ำเสมอปีละหนึ่งหรือสองครั้ง
    logical replication จากเวอร์ชันเก่าไปเวอร์ชันใหม่อาจช่วยได้ แต่ก็ดูเหมือนว่ายังต้องมีขั้นตอนย้ายทุกอย่างไปยังคลัสเตอร์ใหม่โดยไม่มี partial write หรือสถานะแปลก ๆ อยู่ดี
    อยากรู้ว่ามีใครมีประสบการณ์กับเรื่องนี้ไหม

    • พวกเราใช้ logical replication กับการ pause/switchover ของ pgbouncer ทำให้การเขียนไม่ล้มเหลวและหยุดไปประมาณ 5 วินาที
      ขนาด DB อยู่ที่ราว 1~1.5TB แต่ปริมาณการเปลี่ยนแปลงหรือจำนวนคิวรีต่อวินาทีไม่ได้สูงมาก
      โดยพื้นฐานแล้วคือวิธีที่อธิบายไว้ที่นี่: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • ปกติแล้วจัดการด้วย logical replication
      ถ้ามีการตั้งค่า infrastructure as code ก็สร้างคลัสเตอร์ใหม่ที่เหมือนเดิมทุกอย่างยกเว้นเมเจอร์เวอร์ชัน จากนั้นนำเข้า schema เริ่มคัดลอกข้อมูลจาก read replica ของเวอร์ชันเก่า หยุดรับการเขียนบนเวอร์ชันเก่า (เริ่ม downtime) ซิงก์หมายเลข sequence แล้วชี้บริการไปยังคลัสเตอร์ใหม่ (จบ downtime)
      ถ้าใช้ของอย่าง CloudNativePG มันจะช่วยทำบางส่วนของกระบวนการนี้ให้อัตโนมัติผ่าน CLI tools และไวยากรณ์เชิงประกาศ
      ไม่อย่างนั้นก็ต้องใช้เวลาทำความเข้าใจเอง
      ฟังดูอาจซับซ้อน แต่ถ้าซ้อมบน staging DB แล้วได้ผล ก็ทำขั้นตอนเดียวกันใน production ได้
      เพิ่มเติมคือดูเหมือนว่า Postgres 19 จะมีแพตช์สำหรับ one-time logical replication ของ sequence: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • logical replication แก้เรื่องนี้ได้
      ถ้าหมุนคลัสเตอร์ตามลำดับ downtime จะน้อยมาก อาจประมาณ 60 วินาที
    • แปลกที่ PostgreSQL ยังไม่มี implementation แบบ multi-master ทั่วไปที่เป็นโอเพนซอร์สและใช้งานได้จริงเสียที
      ถึงตอนนี้แล้วก็ยังสงสัยว่าชาตินี้จะได้เห็นไหม
    • ถ้ามาจาก MySQL นี่ถือเป็นการถอยหลังครั้งใหญ่ และทำให้ Postgres ดูเหมือนของยุค 80
      ผมยังสงสัยอยู่เลยว่าทำไมเรื่องนี้ถึงไม่ถูกมองว่าเป็นสิ่งสำคัญสูงสุดแบบเด็ดขาด

  • ยินดีด้วยกับการระดมทุน, Lev
    ที่นี่เราใช้ PgDog อย่างพอใจมาก
    ผมชอบความสามารถของพร็อกซีที่จัดการการตั้งค่าการเชื่อมต่อที่ต่างกันในแต่ละ connection เช่น statement_timeout
    ตอนก่อนหน้านี้ที่ผมลองดู RDS Proxy มันยังไม่รองรับ และ pgbouncer ก็ดูเหมือนจะเหมือนกัน เลยต้องแก้แอปเยอะมาก
    แต่ใน PgDog มันทำงานได้แบบโปร่งใสเลย

  • สงสัยว่ามันเทียบกับ multigres ของ Supabase ที่เพิ่งประกาศได้ไหม

  • เห็นว่ามี Enterprise Edition เลยอยากรู้ว่าส่วนไหนบ้างที่ไม่ใช่โอเพนซอร์สให้ชัดเจน
    และอยากรู้ด้วยว่าคาดไหมว่าฟีเจอร์ใหม่ ๆ ที่จะเพิ่มเข้ามาจะเป็น ไลเซนส์ EE เพื่อสร้างผลตอบแทนให้ VC นักลงทุน

    • มีฟีเจอร์ใหญ่สองอย่าง
      อย่างแรกคือ control plane ที่ใช้จัดการการ deploy แบบหลายโหนด ทำให้ deploy และใช้งาน PgDog ได้ง่ายขึ้น พร้อมประสบการณ์แบบ “ใช้ได้ทันที”
      อย่างที่สองคือ quality of service (QoS) ที่จะบล็อกคิวรีแย่ ๆ โดยอัตโนมัติไม่ให้ทำฐานข้อมูลล่ม
      สุดท้ายคือสามารถรับการสนับสนุนที่มี SLA รับประกันไปถึงระดับ P0 ได้
      ฟีเจอร์ใหม่จะแบ่งเป็นสองหมวด
      sharding และการรัน Postgres ขนาดใหญ่จะเป็นโอเพนซอร์สเสมอ ส่วนการจัดการโครงสร้างพื้นฐานและฟีเจอร์ที่ทำให้รัน PgDog ในสเกลใหญ่ได้ง่ายจะเป็นฝั่ง enterprise

  • ดีที่ได้เห็น PgDog, Neki, multigres ออกมา
    ก็ถูกแล้วที่นี่คือปัญหาหลักของ Postgres และการไม่มี index hints ก็เป็นอีกปัญหาหนึ่ง เลยตั้งตารอ Postgres 19

    • อย่าลืม PgBouncer ต้นตำรับด้วย
      การตั้งค่ายาก แต่ทุกวันนี้มี AI ช่วยเลยทำคอนฟิกได้ง่ายขึ้น
    • ส่วนขยาย pg_hint_plan แม้จะไม่ได้อยู่ใน core แต่ก็เก่งพอตัวเวลาต้อง override planner

  • ข้อความที่ว่า “เราทำ sharding ไปมากกว่า 20TB เท่าที่เรารู้” น่าจะเป็นการพิมพ์ผิด
    20TB ไม่ได้ใหญ่ขนาดนั้น
    ผมคิดว่าน่าจะทำ sharding มากกว่านั้นเยอะ

    • ถ้าคุณคิดว่า 20TB “ไม่ได้ใหญ่ขนาดนั้น” ผมก็อยากรู้ว่าคุณดูแล DB ขนาดไหนอยู่
    • ถ้า working set คือ 20TB นั่นก็ถือว่าใหญ่มาก
      แต่ละฐานข้อมูลมีสัดส่วนของข้อมูลร้อนกับข้อมูลเย็นต่างกัน เลยเทียบกันไม่ได้ถ้าไม่มีข้อมูลเพิ่ม
      ตัวชี้วัดที่ดีกว่าอาจเป็น IOPS
      บน RDS ถ้าไม่ยอมจ่ายเพิ่มมากสำหรับ provisioned IOPS หรือไม่ใช้ Aurora ค่า IOPS สูงสุดจะค่อนข้างต่ำ
    • ใช่เลย
      เอาไว้เทียบกัน เมื่อเกือบ 10 ปีก่อนที่ Segment เราเคยรัน Aurora PostgreSQL instance เดี่ยวที่มีข้อมูลราว 50TB และใช้มันทำดัชนีข้อมูลตัวระบุที่อาจระบุตัวบุคคลได้ภายในคลังไฟล์ที่ใหญ่กว่ามากซึ่งเก็บไว้บน S3
    • สำหรับ use case ส่วนใหญ่ 20TB ถือว่าใหญ่มากแน่นอน

  • PgDog ดีมาก
    เอาตรง ๆ คือไม่ได้จำเป็นสำหรับผมหรอก แต่ตอนเดินป่าในป่าดันไม่มีอะไรฟัง เลยบังเอิญเปิดพอดแคสต์ Postgres FM แล้วรู้สึกสนใจ จึงเอามาใช้บน Kubernetes แบบ on-premises ของตัวเอง
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb