Databricks เข้าซื้อกิจการ Neon ผู้เชี่ยวชาญด้าน Serverless Postgres

 (databricks.com)
7 คะแนน โดย GN⁺ 2025-05-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Databricks บรรลุข้อตกลงเพื่อเข้าซื้อ Neon ซึ่งให้บริการ Serverless Postgres ที่เน้นนักพัฒนาเป็นศูนย์กลาง
  • Neon มอบแพลตฟอร์มฐานข้อมูลแบบ serverless ที่เหมาะกับนักพัฒนาและระบบ AI ผ่าน สถาปัตยกรรมแยก storage และ compute
  • หลังการนำ Neon มาใช้ สัดส่วนฐานข้อมูลที่ AI agent สร้างขึ้นเติบโตอย่างรวดเร็วจาก 30% ไปเป็นมากกว่า 80%
  • Databricks และ Neon มี แนวคิดแบบโอเพนซอร์ส และ DNA ด้านนวัตกรรมโครงสร้างพื้นฐานร่วมกัน
  • หลังการเข้าซื้อ การสนับสนุนแพลตฟอร์ม Neon และโรดแมปที่มุ่งสู่อนาคตจะถูก เสริมความแข็งแกร่งด้วยทรัพยากรของ Databricks

การประกาศเข้าซื้อกิจการและความสำคัญ

  • Databricks บรรลุข้อตกลงเพื่อเข้าซื้อ Neon ซึ่งให้บริการ Serverless Postgres ที่เน้นนักพัฒนาเป็นศูนย์กลาง
  • ผู้ร่วมก่อตั้ง Neon เป็นหนึ่งในผู้เชี่ยวชาญไม่กี่คนของโลกที่สามารถออกแบบ Postgres ด้วยโครงสร้างแยก storage และ compute อย่างสมบูรณ์
  • ทีมนี้มุ่งเน้นการสร้าง แพลตฟอร์ม Serverless Postgres เพื่อรองรับนักพัฒนาจำนวนมากในยุค AI

ภารกิจนวัตกรรมบนพื้นฐาน Postgres

  • ผู้ร่วมก่อตั้ง Neon รวมตัวกันเมื่อราว 4 ปีก่อนเพื่อต้องการปฏิวัติโครงสร้างฐานข้อมูลแบบเดิมที่ล้าสมัย
  • เป้าหมายหลักมีดังนี้
    • มองเห็นว่า Postgres จะกลายเป็น มาตรฐานโดยพฤตินัย และวางวิสัยทัศน์ของ แพลตฟอร์ม serverless
    • ให้ความสำคัญกับความเร็ว เพื่อให้นักพัฒนาสามารถ สร้างอินสแตนซ์ใหม่ได้ภายในไม่กี่วินาที
    • มุ่งแก้ปัญหาความกังวลเรื่อง over/under provisioning ผ่าน การขยายอัตโนมัติ และการทำงานที่ง่ายขึ้นของฐานข้อมูล
    • รองรับ branch และ fork ได้ทันที เพื่อให้ทดสอบและทดลองฐานข้อมูลได้ง่ายขึ้น
  • ทีม Neon บรรลุเป้าหมายเหล่านี้ด้วยสถาปัตยกรรมที่ทำให้ storage และ compute ขยายแยกจากกันได้อย่างอิสระ
  • หลังเปิดตัว นักพัฒนาชื่นชมเรื่องความเร็ว ความเรียบง่าย และความสามารถด้าน branch/fork แบบ Git

ความเปลี่ยนแปลงในยุค AI agent

  • หลังจาก Neon เปิดให้ใช้งาน GA แล้ว AI agent คิดเป็น 30% ของการสร้าง DB ทั้งหมด และล่าสุดเพิ่มขึ้นเป็น มากกว่า 80%
  • AI agent มีความต้องการคล้ายกับนักพัฒนา
  • จุดแข็งของ Neon มีดังนี้
    • ระบบนิเวศโอเพนซอร์สของ Postgres: LLM รุ่นใหม่ถูกฝึกด้วยข้อมูลของ Postgres ทำให้ AI agent ใช้งาน Neon ได้อย่างเชี่ยวชาญ
    • ความรวดเร็ว: ต้องการความเร็วที่มากกว่ามนุษย์ จึงจำเป็นต้องมีการ provision อินสแตนซ์ที่รวดเร็วมาก
    • การขยายตัวและราคาที่ยืดหยุ่น: ด้วย โครงสร้าง serverless แบบแยกส่วน จึงมีต้นทุนต่ำมากและรองรับ AI agent จำนวนมากได้
    • branch และ fork: ทำให้ทดลองและตรวจสอบแนวทางที่เปลี่ยนแปลงตลอดเวลาของ AI agent ได้ง่ายขึ้น

DNA ร่วมกันของ Databricks และ Neon

  • ผู้ก่อตั้ง Nikita Shamgunov, Heikki Linnakangas และ Stas Kelvich เป็นผู้เชี่ยวชาญด้านเทคโนโลยีฐานข้อมูลที่มีชื่อเสียงในอุตสาหกรรม
  • แต่ละคนมีประสบการณ์เข้มข้นและความคิดสร้างสรรค์จาก SingleStore, การเป็น Postgres committer และบทบาทอื่น ๆ
  • ทั้ง Databricks และ Neon ต่างให้ความสำคัญกับ นวัตกรรมเทคโนโลยีขั้นสูงในชั้นโครงสร้างพื้นฐานและคุณค่าของโอเพนซอร์ส
  • ทั้ง Apache Spark และ Postgres ต่างก็เป็นโครงการโอเพนซอร์สที่เริ่มต้นจาก UC Berkeley เหมือนกัน

วิสัยทัศน์ในอนาคตและประโยชน์ต่อผู้ใช้

  • ตลาดฐานข้อมูล OLTP (มูลค่าราว 1 แสนล้านดอลลาร์) ปัจจุบันยังถูกครอบงำด้วยผลิตภัณฑ์จากหลายทศวรรษก่อน
  • ตอนนี้คือช่วงเวลาที่ นักพัฒนาและ AI agent จะเป็นผู้นำการเปลี่ยนแปลง
  • Databricks และ Neon ตั้งเป้าสร้าง แพลตฟอร์มฐานข้อมูลที่เป็นมิตรต่อนักพัฒนามากที่สุดและเหมาะกับ AI agent มากที่สุด
  • ลูกค้าและพาร์ตเนอร์ของ Neon เดิมยังคาดหวังได้ถึง การสนับสนุนและนวัตกรรมอย่างต่อเนื่อง รวมถึงการทำให้โรดแมปเกิดขึ้นจริง
  • ด้วยทรัพยากรของ Databricks จะช่วยรับประกัน การเสริมความแข็งแกร่งของแพลตฟอร์มและการเติบโตอย่างมั่นคง
  • จะมีการแบ่งปันวิสัยทัศน์ในอนาคตอย่างละเอียดในงาน Data + AI Summit (ซานฟรานซิสโก, 9-12 มิถุนายน)

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

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

 
GN⁺ 2025-05-16
ความเห็นจาก Hacker News
  • ผมคิดว่าคลังข้อมูลกำลังกลายเป็นของใช้ทั่วไปอย่างรวดเร็วเพราะโอเพนซอร์ส บริษัทที่ผมรู้จักแห่งหนึ่งเคยเก็บข้อมูลมากกว่า 2 เพตะไบต์ไว้ใน Cloudera แต่แทนที่จะย้ายขึ้นคลาวด์ (Databricks) ก็สร้างแพลตฟอร์มวิเคราะห์ของตัวเองด้วย Iceberg, Trino และ Superset แล้วประหยัดค่าใช้จ่ายได้ 5 เท่า ตอนนี้ k8s operator ระดับองค์กรดีพอแล้ว และ S3 แบบ on-premise ก็ยอดเยี่ยมด้วย ฮาร์ดแวร์และเครือข่ายดี ๆ อย่างเซิร์ฟเวอร์ที่มี CPU 128 ตัวและหน่วยความจำ 1TB ก็หาได้แล้ว ไม่ใช่แค่ Trino แต่ StarRocks และ Clickhouse ก็มี Helm chart/operator สำหรับ k8s ระดับองค์กรเช่นกัน มูลค่าบริษัท 60 พันล้านดอลลาร์ของ Databricks เป็นภาระของพวกเขาเอง พวกเขาต้องทำให้ราคานี้ดูสมเหตุสมผล และธุรกิจหลักของพวกเขาเองก็กำลังกลายเป็นของทั่วไปเช่นกัน Neon เข้ามาเติมช่องว่างในชุดผลิตภัณฑ์ที่ยังไม่มี DB เชิงปฏิบัติการ (แบบ row-oriented)
    • จากมุมมองขององค์กร มันไม่ได้กลายเป็นของทั่วไปเลย ที่ทำงานเก่าของผมไม่อนุญาตให้ใช้ซอฟต์แวร์โอเพนซอร์ส บริษัทที่อาจจะไม่อยู่แล้วในอีก 10 ปี หรือบริษัทที่เก็บข้อมูลไว้ที่อื่นนอกเหนือจาก tenant ของเราเอง กลับชอบนโยบายราคาแบบ “โทรสอบถาม” เสียด้วยซ้ำ และการนำ Databricks มาใช้ก็เป็นหนึ่งใน 3 ผลงานสำคัญของผม เพราะไม่ต้องกังวลเรื่องแพลตฟอร์มข้อมูลอีกต่อไป ความเสี่ยงในการนำแพลตฟอร์มใหม่เข้ามามันสูงเกินไปจนไว้ใจ (โครงการโอเพนซอร์สใด ๆ) ไม่ได้ ผมเคยนำโซลูชันของสตาร์ตอัปมาใช้ครั้งหนึ่ง แต่มันใช้ MongoDB และทีมปฏิบัติการของเรายังไม่เก่งพอ จึงไปทำสัญญาใช้บริการที่มีซัพพอร์ตครบอย่าง Atlas แทนการเรียนรู้เพิ่ม เราใช้แต่ไฟร์วอลล์ที่คุ้นเคยแทน Azure firewall ที่ไม่คุ้น และยังต้องจัดการสัญญาต่าง ๆ ด้วย ลดการจ้างคนลง มีช่องทางติดต่อเพียงจุดเดียว และได้ประสิทธิภาพการทำงานสูงขึ้น ใบอนุญาตของสตาร์ตอัปอยู่ที่ 5~10K ดอลลาร์ต่อปี แต่ค่าซัพพอร์ตกลับกินเงินมากกว่านั้นมาก เช่น 40K ดอลลาร์ สตาร์ตอัปกับองค์กรเป็นคนละโลกกันโดยสิ้นเชิง
    • ผมใช้ StarRocks แบบโอเพนซอร์สผ่าน k8s operator เพื่อวิเคราะห์ข้อมูลลูกค้าระดับเทราไบต์อยู่ และในสภาพแวดล้อมของผม Databricks แทบไม่จำเป็นเลย
    • ผมใช้ ClickHouse มาหลายปีแล้วโดยไม่มีปัญหาอะไร เป็นฐานข้อมูลที่เชื่อถือได้และมีฟีเจอร์กว้างมาก ฟีเจอร์ external dictionary ทำให้เชื่อมกับ datastore อื่นอย่าง Postgres และ Redis ได้ง่าย
    • ถ้ากำลังหาทางเลือกโอเพนซอร์สของ Cloudera ที่ใช้ Kubernetes operator เรากำลังพัฒนา stackable.tech มา 5 ปีแล้ว ส่วนฝั่ง S3 แบบโอเพนซอร์ส on-premise ยังมีปัญหา ผมไม่แนะนำ MinIO และนอกจากนั้นก็แทบไม่มีโซลูชันที่รองรับองค์กรจริง ๆ เลย
    • คลังข้อมูลกลายเป็นของทั่วไปมาตั้งแต่หลายสิบปีก่อนแล้ว มีประวัติของตัวชี้วัดด้านราคาและประสิทธิภาพยาวนาน แต่ผลิตภัณฑ์พวก SnowBricks ไม่ได้ตรงตามนั้น ต่างกันแค่ว่าจะขายแบบยัดเยียดหรือขายแบบนุ่มนวล
    • ผมไม่เข้าใจว่าทำไมต้องซื้อ DB เชิงปฏิบัติการจาก Databricks ด้วย มันดูเหมือน Databricks กำลังดิ้นรนเพื่อรักษามูลค่าตลาดของตัวเองเท่านั้น
    • ถ้า Databricks แค่ต้องการ row DB เฉย ๆ ก็น่าจะสร้าง Postgres ขึ้นมาเองแล้ว การยอมจ่ายเงินก้อนโตให้ Neon แบบนี้เป็นสัญญาณว่าพวกเขาต้องการอะไรบางอย่างที่พิเศษใน Neon เช่น “storage และ compute ที่ขยายแยกจากกันได้อย่างอิสระ”
    • อยากรู้ว่าใช้เครื่องมืออะไรสำหรับ ETL
  • สัปดาห์ที่แล้วผมสมัครงานที่ neon แล้วข่าวการเข้าซื้อกิจการก็ออกมา ก่อนจะได้รับอีเมลปฏิเสธตั้งแต่เช้าวันนี้ เป็นประสบการณ์โดนปฏิเสธที่มีความสุขที่สุดเท่าที่เคยเจอ รอบนี้นับเป็นครั้งที่สามติดแล้วที่ผมเกือบเข้าไปทำงานกับบริษัทที่ถูกซื้อกิจการ ตอนนี้ผมเลยแค่อยากได้ความมั่นคง ยินดีกับทีม neon ผมชอบและใช้งาน neon อยู่ และหวังว่าการเข้าซื้อนี้จะไม่เปลี่ยนมันมากเกินไป
    • ผมเคยเข้าทำงานที่ Kenna Security ก่อนการเข้าซื้อ แล้วหนึ่งเดือนต่อมาก็ถูก Cisco ซื้อไป มันเป็นประสบการณ์ที่เลวร้ายมาก และผมจะไม่กลับไปทำงานกับบริษัทที่มีผู้บริหารชุดจาก Kenna หรือกับ Cisco อีก
    • ผมกลับมีประสบการณ์ตรงกันข้าม ช่วงที่เข้าไปทำงานตอนมีการเข้าซื้อนี่แหละน่าสนใจที่สุด ในกรณีของผม ประสบการณ์ด้านการรวมกิจการหลังการเข้าซื้อทำให้มีคนมาทาบทามอยู่บ่อย ๆ
    • ตอนเป็นผู้จัดการวิศวกรรมปีแรก ผมอยู่ในกระบวนการเข้าซื้อกิจการ และต้องช่วยคัดเลือกคนที่จะถูกเก็บไว้ ช่วยปรับโครงสร้างทีม ขณะเดียวกันก็ต้องทนผ่านการปลดคนสองรอบ ขวัญกำลังใจตกต่ำมาก และวัฒนธรรมองค์กรก็ไม่เข้ากันเลย ผมหมดไฟหนักจนต้องพักไปหลายเดือน ตอนนี้กลับมาทำงานเป็น IC แล้วมีความสุขดี
    • ผมเดาว่าทีม neon น่าจะถูกรวมเข้าไปในเทคโนโลยี Online Tables ของ Databricks ซึ่งก็สมเหตุสมผลในเชิงผลิตภัณฑ์
    • ถ้าใครเข้าร่วม neon ตอนมูลค่าบริษัทในอดีตและหุ้น vesting เพิ่งครบพอดี ก็น่าจะได้รับเงินก้อนแบบไม่คาดคิด อยากรู้เหมือนกันว่ารู้สึกยังไง
  • Databricks เป็นซอฟต์แวร์ขยะที่น่าหงุดหงิดที่สุดเท่าที่ผมเคยใช้มา แปลกใจจริง ๆ ว่ามีใครเลือกใช้มันโดยสมัครใจ
    • Databricks เริ่มต้นในปี 2013 ตอนที่ Spark ยังไม่ค่อยดี และทำให้ Spark ดีขึ้นและเร็วขึ้น แม้ตัวผลิตภัณฑ์ยังคงเน้น Spark แต่ผมมองว่าชุด Iceberg + DuckDB เหมาะกับบริษัท 95% มากกว่า ถูกกว่า เร็วกว่า ใช้ง่ายกว่า และพวกเราที่ Definite ก็สร้างแพลตฟอร์มข้อมูลบนสมมติฐานนั้นเช่นกัน (รวม ETL, BI และ Data Lake ครบ)
    • Databricks คือ Jira ของโลกข้อมูล ไม่มีใครอยากใช้ มันก็ไม่ค่อยดี และฟีเจอร์ต่าง ๆ ที่พยายามจะตอบโจทย์ทุกคนกลับดูครึ่ง ๆ กลาง ๆ ไปหมด ตอนนี้มีทางเลือกที่ดีกว่ามากมายแล้ว ดังนั้นผมคงไม่เลือกใช้ Databricks เอง
    • ผมว่ามันยากมากที่จะเห็นด้วยจริง ๆ ในฐานะคนที่มาจากสาย Hadoop, Databricks คือยูโทเปีย มันเสถียร เร็ว และขยายไปสู่ชุดข้อมูลขนาดใหญ่ได้ยอดเยี่ยม เพียงแต่ข้อบ่นหลักคือมันแพงเกินไป
    • เมื่อก่อนผมเคยชอบแพลตฟอร์ม Databricks มาก ช่วงปี 2020~2021 ถ้าเทียบกับ AWS, Azure, Snowflake ก็แทบไม่มีทางเลือกที่สมเหตุสมผลนอกจาก Databricks แต่ตอนนี้มันดูสะเปะสะปะเพราะยัดฟีเจอร์เข้าไปเรื่อย ๆ เปลี่ยนบ่อย เข้าซื้อบริษัทต่าง ๆ และแม้แต่ชื่อฟีเจอร์ก็ยังเละเทะ
    • แปลว่ายังมีตลาดเหลืออยู่สำหรับซอฟต์แวร์สไตล์ IBM สินะ แบบ “ทุกคนใช้ เราก็เลยใช้”
    • พูดตรง ๆ Databricks เป็นผลิตภัณฑ์ที่น่าเบื่อมาก ถ้าย้อนกลับไปคิดถึงปลายยุค 2010, Spark-as-a-Service นั้นยอดเยี่ยม และเป็นยุคที่องค์กรต่าง ๆ ล้มเหลวในการรัน Spark เองให้เสถียร แม้แต่พวก hyperscaler ก็ยังมีบริการรุ่นแรกที่อ่อนมาก ตอนนั้น Databricks เองก็มีปัญหาอย่างเรื่องความเข้ากันได้ของ notebook format กับ Jupyter แต่เมื่อเทียบกับปัญหาคลัสเตอร์ on-prem ที่ไม่เสถียรแล้ว คนก็ยอมจ่ายพรีเมียม ตอนนั้น Databricks ก็เป็นธุรกิจระดับพันล้านดอลลาร์ที่ยอดเยี่ยมอยู่แล้ว แต่แค่ Spark-aaS อย่างเดียวทำให้เป็นยูนิคอร์นไม่ได้ AWS EMR ก็กำลังไล่ตามมาอย่างช้า ๆ ในฐานะคู่แข่ง สุดท้าย Databricks ก็ทุ่มหมดหน้าตักกับกลยุทธ์เติบโตแบบพองผลิตภัณฑ์ ใส่คำฮิตอย่าง data, lake, house กันเต็มไปหมด ในปี 2025 การถดถอยของ Databricks คืออีกด้านอันขมขื่นของ enshittification สักวันหนึ่ง Larry Ellison อาจเข้าซื้อและทำให้มันหายไปจากตลาดก็ได้ ผมไม่เข้าใจจริง ๆ ว่าทำไมทุกวันนี้ยังมีคนเลือก Databricks สำหรับโครงการใหม่ แต่ลูกค้าองค์กรที่ใช้มาเกิน 5 ปีคงออกไปยาก ต่อไปส่วนแบ่งตลาดคงลดลง แต่ก็ยังทำเงินได้อีกพักใหญ่ นี่แหละวงจรของอุตสาหกรรม และสุดท้าย entropy ก็ชนะ อยากจะไม่เกลียดมันเกินไปนัก เพราะมันก็เคยเป็นบริษัทที่สร้างประวัติศาสตร์ได้ดีพอสมควร
    • แม้จะชูเรื่อง Serverless มาก แต่ข้อจำกัดและกับดักที่ซ่อนอยู่มีเยอะมากจนใช้งานลำบากแทบบ้า
    • ผมสงสัยว่าแค่โฮสต์ Spark มันนับว่านวัตกรรมจริงหรือ แล้ว Spark เองก็ไม่ได้ซับซ้อนเกินไปสำหรับงานข้อมูลขององค์กรดั้งเดิม 90% หรอกหรือ ผมไม่เข้าใจเลยว่าทำไมบริษัทนี้ถึงมีมูลค่าสูงขนาดนี้
    • ถ้าปิดใช้งานคุกกี้แล้วเว็บไซต์ขึ้นไม่ได้เลย นี่ถือเป็นสัญญาณอันตรายร้ายแรง เว็บไซต์แค่อันเดียวยังทำไม่ได้ แล้วจะคาดหวังให้ทำผลิตภัณฑ์ดิจิทัลที่ดีได้ยังไง
  • Databricks แย่พอ ๆ กับ Oracle ผมมั่นใจว่ามันจะทำ Neon พังหรือไม่ก็ทำให้แพงขึ้น ในระยะกลางถึงยาวผมคงหาทางเลือกอื่นแทน Neon
    • กลยุทธ์ M&A ของ Databricks มีโครงสร้างแบบที่ทำให้บริษัทที่เข้าซื้อค่อย ๆ ขาดอากาศหายใจ พวกเขากำลังลำบากกับการเปลี่ยนแปลงครั้งใหญ่ของโอเพนซอร์สอย่าง Iceberg, DuckDB ฯลฯ จึงพยายามสร้างนวัตกรรมผ่านการเข้าซื้อกิจการ แต่ด้วยวัฒนธรรมองค์กร บริษัทที่ถูกซื้อเลยพังไป ผมมาจากสายบิ๊กดาต้า (เคยอยู่ Snowflake) เลยอาจมีอคติ แต่ก็เห็นชัดจริง ๆ ว่าโอเพนซอร์สกำลังมีอำนาจมากขึ้นเรื่อย ๆ ผมสนใจมากว่าการเปลี่ยนแปลงนี้จะลงเอยอย่างไร
  • อ้างคำพูดจากบทความต้นฉบับ: “ตอนที่ Neon เข้าสู่ GA เมื่อปีก่อน 30% ของฐานข้อมูลถูกสร้างโดย AI agent และพอมาดูอีกทีล่าสุด สัดส่วนนี้เกิน 80% ไปแล้ว แปลว่า AI สร้าง DB มากกว่ามนุษย์ 4 เท่า” นี่เป็นข้อมูลที่ทำให้สัญญาณเตือนหลายอย่างดังขึ้น ดูเหมือน Databricks กำลังพยายามแพ็กเกจ Postgres ให้เป็นโซลูชัน AI โลกทุกวันนี้ช่างน่าพิศวง
    • อยากรู้เหมือนกันว่าในนั้นมี DB ที่ถูกใช้งานจริงอยู่กี่ตัว
  • ยินดีกับทีม Neon ผมชอบสิ่งที่พวกเขาสร้างมาก แต่พูดตามตรงผมไม่ค่อยรู้สึกถึงความเกี่ยวข้องหรือซินเนอร์จีกับ Databricks และหวังว่า Neon จะยังคงอยู่เป็นผลิตภัณฑ์แยกต่างหาก ไม่อย่างนั้นตลาดก็จะเสียผู้ให้บริการ Postgres ที่ชัดเจนไปอีกราย
    • ด้วยความที่พึ่งพา Azure สูง ผมคิดว่ามันคงไม่หายไปทันที นี่คือการขยับของ Databricks เพื่อขยายจากฐานข้อมูลเชิงวิเคราะห์ไปสู่ฐานข้อมูลเชิงธุรกรรมด้วย
    • ใน FAQ บอกว่าจะดำเนินงานอย่างอิสระ แต่ในความเป็นจริงผมว่าตอนจบเดาได้อยู่แล้ว
  • ผมจำโพสต์แรกของทีม Neon บน HN ได้ ตอนนั้นผมก็คอมเมนต์ไว้ว่าเป็นไอเดียที่เจ๋งมาก แม้ตอนนั้นผมยังไม่มีความจำเป็นต้องใช้โดยตรง แต่คิดว่าสักวันคงได้ใช้ แต่พอเห็นข่าวการเข้าซื้อแบบนี้ก็เริ่มรู้สึกกังขา ตอนนี้ดูเหมือนพวกเขาน่าจะโฟกัสที่เจ้าของมากกว่าผู้ใช้ แม้ในทางหลักการทั้งสองฝั่งควรมีจุดยืนร่วมกัน แต่ในทางปฏิบัติมักไม่ค่อยเป็นแบบนั้น
    • ผมก็จำโพสต์แรกของ Neon ได้เหมือนกัน การแยก storage กับ compute ออกเป็นของสดใหม่มาก และตอนนั้นผมยังเคยถามเรื่อง Pageserver ด้วย หลังจากนั้นอีก 2 ปี ผมเองก็ได้ไปทำงานกับแนวทางแยก storage คล้ายกันที่ Turso database ขอแสดงความยินดีกับทีม Neon อีกครั้ง
    • ข่าวการเข้าซื้อทำให้ผมหยุดคิดเหมือนกัน ผมเชื่อได้ยากว่าการให้ความสำคัญกับผู้ใช้ AI ก่อน จะสอดคล้องกับผลประโยชน์ของนักพัฒนา และหวังว่าเทคโนโลยีที่เกี่ยวข้องกับแกนหลักของ PostgreSQL จะได้รับประโยชน์จากชุมชนโอเพนซอร์ส
  • ขอแสดงความยินดีกับทีม Neon ผลิตภัณฑ์ยอดเยี่ยมมาก แน่นอนว่าถ้าได้รับเงินจาก VC ผลลัพธ์แบบนี้ก็คงหลีกเลี่ยงไม่ได้ หวังว่า Nikita และคนอื่น ๆ จะไม่ถูก Databricks กลืนจนเสียตัวตน และจะยังคงแข็งแกร่ง
  • นี่เป็นพัฒนาการที่น่าสนใจมาก ผมคิดว่าวิธีที่ OLTP และ OLAP กำลังบรรจบกันเป็นทิศทางที่ถูกต้อง ผมเคยมีประสบการณ์สร้างระบบ HTAP ที่ SingleStore ร่วมกับ OP เราพยายามทำให้ OLTP และ OLAP อยู่ในฐานข้อมูลเดียวกัน (รองรับทั้งสองฝั่งด้วยการคัดลอกเพียงครั้งเดียว) แต่ HTAP ไปไม่รอด OLTP ควรอยู่บน Postgres, OLAP ควรอยู่บน data warehouse/lake แยกต่างหาก และการทำ replication ระหว่างกันต้องถูกออกแบบอย่างมีประสิทธิภาพ synchronous replication ทำได้ยากมาก และ columnar store ก็รับงานเขียนแบบ OLTP ได้ไม่ดี ผมคาดหวังว่า Databricks กับ Neon จะทำให้เกิดสถานการณ์แบบ “ใช้ตาราง Postgres ล่าสุดได้โดยตรงใน Unity Catalog” ได้จริงหรือไม่ (โดยไม่ต้องผ่าน Debezium, Kafka, Flink, Iceberg และให้ Spark ดูแลสถานะของ Iceberg เอง)
    • OP หมายถึง Nikita Shamgunov ผู้ก่อตั้ง Neon (อดีตผู้ก่อตั้ง MemSQL/SingleStore) ใช่ไหม
  • ยินดีกับทีม Neon พูดตามตรงก็แอบเสียดายนิดหน่อย ผมหวังว่า Neon จะมาเติมช่องว่างที่เกิดขึ้นหลัง CockroachDB เปลี่ยนไปใช้ business source แต่พอถูก Databricks ซื้อไป Neon ก็ดูน่าสนใจน้อยลง ผมไม่ค่อยเชื่อว่าบริษัทใหญ่จะรับผิดชอบอินฟราสตรักเจอร์สำคัญได้ดี ความต้องการ PostgreSQL แบบ “สมัยใหม่” มีมากพอ แต่ในบรรดาทางเลือกต่าง ๆ ไม่มีตัวไหนที่ไม่ค่อยหลุดจากรากเดิมเลย ไม่ว่าจะเรื่องราคา ความเข้ากันได้ หรือการเปิดเผยซอร์ส ตอนมองหาทางเลือกของ Postgres ผมเทียบสิ่งเหล่านี้ไว้
    (1) AWS RDS เราใช้อยู่แล้ว แต่แพงและมีปัญหาทั้งด้านการขยายตัวและการปฏิบัติการ
    (2) AWS Aurora ช่วยแก้ปัญหาด้านปฏิบัติการบางส่วน แต่ก็มาพร้อมข้อเสียอื่น และมีข้อจำกัดคล้ายกับทางเลือก Postgres ที่ wire-compatible อื่น ๆ
    (3) CockroachDB น่าสนใจมาก แต่มีปัญหาเรื่องความเข้ากันได้กับ toolchain และความเข้ากันได้เชิงลึก ตอนนั้นยังเป็นโอเพนซอร์สอยู่
    (4) Neon ดูยังไม่สุกงอมพอจึงยังไม่ได้ใช้ แต่ก็น่าสนใจและดูเหมือนจะแก้ปัญหาได้หลายอย่าง
    (5) Yugabyte ก็เป็นเทคโนโลยีที่น่าสนใจเช่นกัน แต่ก็มีปัญหาความเข้ากันได้หลายด้าน
    ผมยังเคยคิดจะโฮสต์ Postgres เองด้วย แต่ภาระในการดูแล Kubernetes กับ postgres ด้วยตัวเองหนักมาก ฟังก์ชัน replication หรือความสามารถด้านปฏิบัติการที่ทำเองก็ยังไม่สุกงอมพอ และเวลาอัปเกรดต้อง unload/reload ข้อมูลทั้งหมดซึ่งยุ่งยากมาก การขยายระบบหรือทำ automation ก็ไม่ง่าย
    • สำหรับการเอา Yugabyte มาเปรียบเพราะ query engine ของมันดูเหมือนจะอิง Postgres ขอเตือนว่า Neon เองก็คือ Postgres
    • ขอแชร์ประสบการณ์ระยะสั้นของตัวเองว่า “ทางเลือก modern Postgres ที่ดีที่สุดคือ Postgres เอง (ในอีก 5 ปีข้างหน้า)”
    • อยากฟังเพิ่มว่าข้อเสีย “เหมือนกัน” ของทางเลือก PostgreSQL แบบ wire-compatible อื่น ๆ มีอะไรบ้าง