ในความเคลื่อนไหวที่น่าประหลาดใจที่กำลังสร้างความตื่นตัวอย่างมากในชุมชนฐานข้อมูล Snowflake ได้เปิดตัว pg_lake เป็นโอเพนซอร์ส ซึ่งเป็นส่วนขยายของ PostgreSQL ที่นำความสามารถของ Apache Iceberg และ data lake เข้ามาสู่โลกของฐานข้อมูลโอเพนซอร์สยอดนิยมโดยตรง การเปิดตัวครั้งนี้แสดงถึงการเปลี่ยนแปลงครั้งสำคัญในวิธีที่องค์กรต่างๆ สามารถจัดการโครงสร้างข้อมูลของพวกเขา โดยมีศักยภาพที่จะลดทอนไปซึ่งกระบวนการ ETL ที่ซับซ้อน ในขณะที่ยังคงความสม่ำเสมอของการทำธุรกรรมทั่วทั้ง workloads ด้านปฏิบัติการและด้านการวิเคราะห์
เวลาของการเปิดตัวครั้งนี้มีความน่าสนใจเป็นพิเศษ – เนื่องจากเกิดขึ้นเพียงไม่กี่เดือนหลังจากการเข้าซื้อกิจการ Crunchy Data ของ Snowflake ในเดือนมิถุนายน 2025 และตามหลังการเข้าซื้อทีมงาน pg_mooncake ซึ่งเป็นคู่แข่งโดย Databricks ภูมิทัศน์ของฐานข้อมูลกำลังร้อนระอุอย่างชัดเจน โดยผู้ให้บริการรายใหญ่กำลังลงเดิมพันครั้งใหญ่กับอนาคตของ PostgreSQL ในพื้นที่ data lake
การเชื่อมโยง Workloads ด้านปฏิบัติการและการวิเคราะห์
นวัตกรรมหลักของ pg_lake อยู่ที่ความสามารถในการทำให้ PostgreSQL ทำงานเป็นทั้งฐานข้อมูลปฏิบัติการแบบดั้งเดิมและระบบ lakehouse พร้อมกันได้ นักพัฒนาสามารถสร้างและปรับเปลี่ยนตาราง Iceberg โดยตรงจาก PostgreSQL ด้วยการรับประกันการทำธุรกรรมแบบ ACID แบบเต็มรูปแบบ จากนั้นจึง query ตารางเดียวกันนั้นจากเอ็นจิ้นอื่นๆ เช่น Spark สิ่งนี้ขจัดความยุ่งยากแบบดั้งเดิมระหว่างระบบปฏิบัติการและการประมวลผลเชิงวิเคราะห์
สิ่งที่ทำให้สิ่งนี้มีประสิทธิภาพเป็นพิเศษคือโมเดลการดำเนินการแบบไฮบริด ขณะที่ผู้ใช้เชื่อมต่อและโต้ตอบกับ PostgreSQL มาตรฐาน ระบบจะมอบหมายคำถามเชิงวิเคราะห์ที่ใช้การคำนวณอย่างเข้มข้นให้กับเอ็นจิ้นการดำเนินการของ DuckDB ซึ่งทำงานแบบขนานสูงและเป็นคอลัมน์ ผ่านกระบวนการ pgduck_server ที่แยกต่างหาก สถาปัตยกรรมนี้ช่วยหลีกเลี่ยงข้อจำกัดด้านเธรดและความปลอดภัยของหน่วยความจำที่อาจเกิดขึ้นจากการฝัง DuckDB โดยตรงในการออกแบบแบบแยกกระบวนการของ PostgreSQL
ธุรกรรมไม่ได้มาฟรีๆ การฝังเอ็นจิ้นไว้ในแคตตาล็อก แทนที่จะฝังแคตตาล็อกไว้ในเอ็นจิ้น ทำให้สามารถทำธุรกรรมข้ามตารางเชิงวิเคราะห์และตารางปฏิบัติการได้
การเปรียบเทียบสถาปัตยกรรม:
- pg_lake: ส่วนหน้า PostgreSQL + แบ็กเอนด์ DuckDB
- DuckLake: ส่วนหน้า DuckDB + แคตตาล็อก PostgreSQL
- pg_mooncake: PostgreSQL ที่มีแนวทางสถาปัตยกรรมที่แตกต่างกัน (ถูกซื้อกิจการโดย Databricks)
การประยุกต์ใช้จริงและความตื่นเต้นของนักพัฒนา
การตอบรับจากชุมชนเป็นไปในทางบวกอย่างท่วมท้น โดยนักพัฒนาต่างตระหนักถึงการประยุกต์ใช้จริงได้ในทันที ซึ่งสามารถลดความซับซ้อนของสแต็กข้อมูลของเราได้อย่างมากสำหรับบริษัท saas แบบ b2b ตามที่ผู้แสดงความคิดเห็นหนึ่งระบุ ความสามารถในการใช้เครื่องมือและไวยากรณ์ของ PostgreSQL ที่คุ้นเคยสำหรับการดำเนินการกับ data lake แสดงถึงการลดความซับซ้อนลงอย่างมีนัยสำคัญสำหรับหลายองค์กร
คุณสมบัติหลักหลายประการโดดเด่นในฐานะที่มีคุณค่าอย่างยิ่ง: การสนับสนุนคำสั่ง COPY สำหรับการส่งออกผลลัพธ์ของ query ไปยัง S3 โดยตรงในรูปแบบ Parquet, CSV หรือ JSON; การอนุมาน schema อัตโนมัติจากแหล่งข้อมูลภายนอก; และความสามารถในการรวมตาราง heap แบบดั้งเดิม ตาราง Iceberg และไฟล์ภายนอกไว้ใน query เดียวกัน นักพัฒนาคนหนึ่งแสดงความตื่นเต้นเกี่ยวกับความสามารถในการถ่ายโอนข้อมูลจาก Postgres ไปยังข้อมูลที่ถูกแบ่งพาร์ติชันใน lake house เป็นระยะๆ ด้วย query เดียว – ซึ่งเป็นงานที่ก่อนหน้านี้ต้องใช้ยูทิลิตี้ที่สร้างขึ้นเอง
รูปแบบไฟล์ที่รองรับ:
- อินพุต: Parquet, CSV, JSON, Iceberg, GeoJSON, Shapefiles
- เอาต์พุต: Parquet, CSV, JSON
- การบีบอัด: รองรับ gzip, zstd แบบโปร่งใส
- พื้นที่จัดเก็บ: S3 และ object stores ที่เข้ากันได้
ภูมิทัศน์การแข่งขันและความหมายเชิงกลยุทธ์
การเปิดตัว pg_lake เป็นโอเพนซอร์สวางตำแหน่งมันให้แข่งขันโดยตรงกับโซลูชันเกิดใหม่อื่นๆ เช่น DuckLake และ pg_mooncake ซึ่งแต่ละตัวใช้แนวทางทางสถาปัตยกรรมที่แตกต่างกันเล็กน้อย ในขณะที่ DuckLake ใช้ DuckDB เป็นเอ็นจิ้น query หลักโดยมี PostgreSQL เป็นแคตตาล็อก pg_lake กลับกันโมเดลนี้ – โดยใช้ PostgreSQL เป็นส่วนติดต่อหน้าบ้าน (frontend) และใช้ DuckDB เป็นแบ็กเอนด์สำหรับการคำนวณ
การเปิดตัวครั้งนี้ทำให้เกิดคำถามที่น่าสนใจเกี่ยวกับกลยุทธ์ของ Snowflake เนื่องจาก pg_lake มีศักยภาพที่จะมาแทนที่ผลิตภัณฑ์หลักของพวกเขา อย่างไรก็ตาม ดังที่ผู้สังเกตการณ์หนึ่งระบุไว้ Snowflake ได้แสดงให้เห็นถึงความมุ่งมั่นที่แท้จริงในการแทนที่ตัวเองด้วยการเป็นผู้สนับสนุน awal ของ Iceberg แม้จะมีศักยภาพในการสร้างการเปลี่ยนแปลง การเคลื่อนไหวครั้งนี้ดูเหมือนจะเป็นส่วนหนึ่งของแนวโน้มที่กว้างขึ้น โดยผู้ให้บริการแพลตฟอร์มข้อมูลรายใหญ่กำลังยอมรับรูปแบบตารางแบบเปิด (open table formats) ในขณะที่แข่งขันในเลเยอร์การคำนวณ (compute layer)
ความพร้อมสำหรับการใช้งานจริงและทิศทางในอนาคต
สิ่งที่ทำให้ pg_lake แตกต่างจากโซลูชันคู่แข่งบางตัวคือความ成熟ของมัน เทคโนโลยีนี้ได้รับการทดสอบในการใช้งานจริงมาแล้วในฐานะ Crunchy Data Warehouse ก่อนการเข้าซื้อกิจการ และทีมงาน behind it มีประสบการณ์อย่างกว้างขวางในการสร้างส่วนขยาย PostgreSQL ระดับ production-grade อย่างเช่น Citus และ pg_cron ประสบการณ์นี้แสดงให้เห็นในชุดคุณลักษณะที่ครอบคลุม ซึ่งรวมถึงการสนับสนุน SQL แบบเต็ม การจัดการธุรกรรม และความสามารถในการ push down ส่วนที่เหมาะสมของ query ไปยัง DuckDB
สถาปัตยกรรมแบบโมดูลาร์ – ซึ่งประกอบด้วยส่วนขยายหลายตัวที่ทำงานร่วมกันได้ แทนที่จะเป็น codebase เดียวขนาดใหญ่ – บ่งบอกถึงแนวทางที่รอบคอบต่อการบำรุงรักษาในระยะยาว ข้อจำกัดในปัจจุบันเกี่ยวกับการสนับสนุนตาราง Iceberg ภายนอกและการควบคุมการเข้าถึงแบบละเอียด (fine-grained access control) ได้รับการยอมรับ โดยล่าสุดมีการรวมการสนับสนุน REST catalog แล้ว และมีแนวโน้มว่าจะมีคุณสมบัติเพิ่มเติมตามมาเมื่อพิจารณาจากการพัฒนาของโปรเจกต์ที่ยังคงดำเนินการอย่างต่อเนื่อง
คอมโพเนนต์หลักของ pg_lake:
- pg_lake.iceberg: ใช้งานข้อกำหนด Iceberg สำหรับ PostgreSQL
- pg_lake.table: Foreign data wrapper สำหรับการ query ไฟล์ใน object storage
- pg_lake.copy: ใช้งานฟังก์ชัน COPY to/from data lake
- pg_lake.engine: โมดูลทั่วไปสำหรับ extension ของ pg_lake
- pgduck_server: โปรเซสแยกต่างหากที่รัน DuckDB ด้วย PostgreSQL wire protocol
- duckdb_pglake: DuckDB extension ที่เพิ่มฟังก์ชันที่เข้ากันได้กับ PostgreSQL
ยุคใหม่ของ PostgreSQL
การเปิดตัว pg_lake เป็นอีกหนึ่ง веха ในสิ่งที่หลายคนเรียกขานว่ายุคทองของ PostgreSQL ในขณะที่องค์กรต่างๆ มองหาการรวมโครงสร้างพื้นฐานข้อมูลและลดความซับซ้อนมากขึ้นเรื่อยๆ โซลูชันที่ขยายขีดความสามารถของ PostgreSQL สู่โดเมนใหม่ๆ กำลังได้รับความนิยมอย่างมีนัยสำคัญ ความสามารถในการจัดการทั้ง workloads ธุรกรรมปริมาณสูงและคำถามเชิงวิเคราะห์ภายในระบบเดียวกันที่คุ้นเคย เป็นสิ่งที่น่าสนใจเป็นพิเศษสำหรับองค์กรขนาดกลางที่การใช้ Snowflake อาจจะเกินความจำเป็น แต่การใช้ PostgreSQL ธรรมดาก็ไม่เพียงพอ
สำหรับนักพัฒนาและวิศวกรข้อมูล pg_lake เสนอทางเลือกที่น่าสนใจเพื่อลดความซับซ้อนของสถาปัตยกรรมข้อมูลโดยไม่เสียสละความสามารถ ในขณะที่ ecosystem ยังคงพัฒนาต่อไป เส้นแบ่งระหว่างฐานข้อมูลปฏิบัติการ คลังข้อมูล (data warehouses) และ data lakes กำลังเบลอมากขึ้นเรื่อยๆ – และดูเหมือนว่า PostgreSQL จะพร้อมที่จะเล่นบทบาทสำคัญในการบรรจบกันครั้งนี้