Snowflake Postgres, Lakebase và HorizonDB: Khi nào nên chọn nền tảng dữ liệu chuyên biệt?

Trong vòng 12 tháng qua, ba trong số các công ty nền tảng dữ liệu lớn nhất đã tung ra các database mang hương vị Postgres với lớp lưu trữ tùy chỉnh và kiến trúc "mở rộng tính toán (scale-out compute), lưu trữ chia sẻ (shared storage)". Cụ thể, Snowflake Postgres đã chính thức GA (General Availability), được xây dựng dựa trên đội ngũ của Crunchy Data với hook lakehouse là pg_lake. Databricks Lakebase đã GA trên AWS và bản preview trên Azure, được xây dựng trên engine Neon plus công việc tích hợp Mooncake. Azure HorizonDB hiện đang ở giai đoạn preview mời và là nền tảng táo bạo nhất về mặt kiến trúc — Microsoft tự xây dựng engine của riêng mình, tuyên bố hỗ trợ lên tới 3.072 vCores và database 128 TB, với hiệu năng gấp 3 lần Postgres tiêu chuẩn trên khối lượng công việc OLTP.

Minh họa kiến trúc database hiện đại

Tất cả ba nền tảng này đều tương thích về giao thức (wire-compatible) với Postgres. Tuy nhiên, không cái nào thực sự là Postgres theo cách mà bạn quan tâm. Vấn đề không phải là cái nào tốt nhất — chúng nhắm đến các khối lượng công việc chồng chéo nhưng riêng biệt, và câu trả lời ý nghĩa phụ thuộc vào môi trường của chính bạn, không phải của họ.

Câu hỏi quyết định thực sự

Câu hỏi trung thực đầu tiên cần đặt ra là: Bạn đang chuẩn hóa trên nền tảng dữ liệu nào? Nếu kho lưu trữ phân tích (analytics warehouse) của bạn là Snowflake, câu trả lời là Snowflake Postgres hoặc không dùng managed cloud-native PG nào cả. Nếu nền tảng phân tích của bạn là Databricks, câu trả lời là Lakebase. Nếu bạn là một cửa hàng Azure đang chạy trên VM và bắt đầu mệt mỏi vì nó, câu trả lời là HorizonDB hoặc một trong các lựa chọn khác qua private link với một vài điều kiện kèm theo.

Các tài liệu marketing sẽ nói với bạn rằng mỗi nền tảng là tương lai của sự hội tụ vận hành và phân tích. Họ đúng theo nghĩa là bất kỳ cái nào cũng sẽ đạt được sự hội tụ đó — trong nền tảng mà bạn đã trả tiền. Câu chuyện đa nền tảng (cross-platform) của cả ba đều giống hệt nhau: đó là hóa đơn truyền dữ liệu xuyên đám mây (cross-cloud egress) với thêm một vài bước trung gian.

Đó là khung tham chiếu. Phần còn lại là các chi tiết kỹ thuật bạn cần để đưa ra quyết định.

Phân tích chi tiết từng nền tảng

Snowflake Postgres là nền tảng "giống Postgres" nhất trong cả ba. Engine nhận diện rõ là PG, câu chuyện về các tiện ích mở rộng (extension) hợp lý, và tích hợp lakehouse thông qua pg_lake được thiết kế thực sự tốt. pg_lake là mã nguồn mở và hoạt động với bất kỳ Postgres nào, điều này có nghĩa là phiên bản trong Snowflake không phải là một tính năng bị giam cầm — bạn có thể tạo mẫu (prototype) trên PG tiêu chuẩn và di chuyển. Lời chào mời là "dữ liệu vận hành của bạn sống cạnh dữ liệu phân tích của bạn, và phía vận hành là một Postgres thực sự". Lời chào mời này đứng vững. Chi phí là bạn hiện đang mua Postgres từ Snowflake, và định giá của Snowflake luôn là định giá của Snowflake.

Lakebase là nền tảng thú vị nhất trong cả ba đối với các nhà phát triển. Mô hình phân nhánh (branching) xuất phát từ Neon là một tính năng thực sự: các nhánh database tức thì cho CI/CD, khôi phục thời điểm (point-in-time recovery) như một hoạt động bình thường thay vì quy trình thảm họa, tách biệt tính toán khỏi lưu trữ theo cách làm cho việc scale-to-zero trở nên rẻ. Lời chào mời là "Postgres cho kỷ nguyên AI", đó là cách marketing nói cho "Postgres nằm cạnh không gian làm việc Databricks của bạn". Đó là một sản phẩm tốt nếu bạn sống trong Databricks. Nó là một sản phẩm kỳ lạ nếu bạn không.

Azure HorizonDB là nền tảng tham vọng nhất về mặt kiến trúc. Microsoft không mua một công ty Postgres; họ xây dựng một engine lưu trữ từ đầu nói giao thức wire và bề mặt SQL của Postgres. Các con số hiệu năng, nếu giữ vững dưới thử nghiệm độc lập, là đáng tin cậy — các kiến trúc shared-storage / scale-out-compute thực sự đánh bại Postgres single-primary ở quy mô lớn nhất. Chi phí là "tương thích giao thức" và "thực sự là Postgres" là hai chuyện khác nhau, và khoảng cách giữa chúng quan trọng tương ứng với mức độ bạn phụ thuộc vào bề mặt tiện ích mở rộng và công cụ.

Những gì bạn thực sự đánh đổi

Đây là phần bị lờ đi trong tài liệu của nhà cung cấp. Với mỗi nền tảng này, bạn đánh mất một sự kết hợp của:

• Tiện ích mở rộng (Extensions): Mỗi fork hỗ trợ một tập con. Hỗ trợ PostGIS thường tốt. Các extension ít phổ biến hơn là ngẫu nhiên. Bất cứ thứ gì vận hành worker nền riêng của nó đều là ngẫu nhiên với tỷ lệ nghiêng về phía rủi ro.
• Sao chép logic (Logical replication): Cả ba đều xử lý việc này khác nhau. Snowflake Postgres gần với hành vi tiêu chuẩn nhất; mô hình phân nhánh của Lakebase và kiến trúc shared-storage của HorizonDB đều có những hàm ý cho logical decoding chưa được tài liệu hóa đầy đủ. Nếu bạn đang chạy logical replication hiện nay, đó là thứ đầu tiên cần kiểm tra.
• Công cụ vận hành: pg_basebackup không áp dụng. pgBackRest không áp dụng. Patroni không áp dụng. Kinh nghiệm vận hành hiện có của bạn có thể chuyển đổi phần lớn cho các truy vấn nhưng phần lớn vô dụng cho mọi thứ khác.
• Đường nâng cấp có thể dự đoán: Mỗi nhà cung cấp kiểm soát khi nào bạn chuyển phiên bản PG. Bạn không được kiểm tra PG 19 theo lịch trình của mình.

Những gì bạn thực sự đạt được

Bạn đạt được quy mô vận hành mà bạn sẽ không có nếu tự chạy Postgres. Không có tuyên bố nào trong số này là nhỏ. Multi-zone commit ở độ trễ mà Microsoft đưa ra cho HorizonDB thực sự khó sao chép. Tính năng phân nhánh của Lakebase thực sự hữu ích. Tích hợp lakehouse-OLTP của Snowflake thực sự chặt chẽ hơn so với phương án thay thế là "ETL giữa Postgres và Snowflake".

Bạn cũng đạt được một mối quan hệ với nhà cung cấp, với tất cả những gì điều đó hàm ý theo cả hai hướng.

Lời khuyên

Hãy chọn nền tảng có nền tảng dữ liệu liền kề mà bạn đã sử dụng, và đừng giả vờ rằng bạn có một sự lựa chọn mà bạn không có. Nếu bạn không có nền tảng dữ liệu liền kề, hãy chạy Postgres thực sự trên các instance thực sự hoặc sử dụng một trong các dịch vụ được quản lý thông thường (Aurora, Cloud SQL, Azure Database for PostgreSQL, Crunchy Bridge, EDB, pgEdge). Câu chuyện scale-out đám mây gốc là có thật, nhưng đó là câu chuyện có thật cho một phần nhỏ khối lượng công việc. Hầu hết Postgres sản xuất vẫn vừa vặn thoải mái trên một primary mạnh mẽ với một vài bản sao, và "Tôi có thể cần 3.000 vCores vào một ngày nào đó" không phải là lý do để mua một database ngày hôm nay.

Sự phát triển thú vị không phải là có ba nền tảng này. Đó là cả ba đều diễn ra trong cùng mười tám tháng. Kiến trúc shared-storage scale-out cho Postgres đã hội tụ thành một danh mục thực sự. Hãy xem cách nó lắng xuống. Đừng là người đầu tiên đặt cược chồng vận hành của bạn vào bản preview.