Databricks mua lại Neon, công ty chuyên về Postgres serverless

• Databricks đã đồng ý mua lại Neon, đơn vị cung cấp Postgres serverless lấy nhà phát triển làm trung tâm
• Neon cung cấp nền tảng cơ sở dữ liệu serverless được tối ưu cho nhà phát triển và các hệ thống AI nhờ kiến trúc tách biệt storage và compute
• Sau khi Neon được áp dụng, tỷ trọng cơ sở dữ liệu do các AI agent tạo ra đã tăng vọt từ 30% lên hơn 80%
• Databricks và Neon có chung triết lý mã nguồn mở và DNA đổi mới hạ tầng
• Ngay cả sau thương vụ, việc hỗ trợ nền tảng Neon và lộ trình hướng tới tương lai sẽ tiếp tục được tăng cường bằng nguồn lực của Databricks

---

Thông báo mua lại và ý nghĩa

• Databricks đã đồng ý mua lại Neon, đơn vị cung cấp Postgres serverless lấy nhà phát triển làm trung tâm
• Các đồng sáng lập Neon là một trong số rất ít chuyên gia hàng đầu thế giới có thể thiết kế Postgres với cấu trúc tách biệt hoàn toàn giữa storage và compute
• Đội ngũ này đã tập trung xây dựng nền tảng Postgres serverless để hỗ trợ quy mô lớn cho nhà phát triển trong kỷ nguyên AI

Sứ mệnh đổi mới dựa trên Postgres

• Khoảng 4 năm trước, các đồng sáng lập Neon đã cùng chung mục tiêu đổi mới cấu trúc cơ sở dữ liệu lỗi thời
• Mục tiêu cốt lõi như sau
  • Dự đoán Postgres sẽ trở thành tiêu chuẩn thực tế, và xây dựng tầm nhìn về một nền tảng serverless
  • Tập trung vào tốc độ để nhà phát triển có thể tạo instance mới chỉ trong vài giây
  • Hướng tới giải quyết nỗi lo over/under provisioning thông qua tự động mở rộng cơ sở dữ liệu và đơn giản hóa vận hành
  • Hỗ trợ branching và forking tức thì để việc kiểm thử và thử nghiệm cơ sở dữ liệu trở nên dễ dàng hơn
• Đội ngũ Neon đã đạt được các mục tiêu trên bằng cách xây dựng kiến trúc cho phép storage và compute mở rộng độc lập
• Sau khi ra mắt, các nhà phát triển đánh giá cao tốc độ, sự đơn giản và tính năng branch/fork theo kiểu Git

Thay đổi trong kỷ nguyên AI agent

• Sau GA của Neon, AI agent chiếm 30% tổng số cơ sở dữ liệu được tạo, và gần đây con số này đã tăng lên hơn 80%
• AI agent bắt đầu có những yêu cầu tương tự nhà phát triển
• Thế mạnh của Neon gồm
  • Hệ sinh thái mã nguồn mở Postgres: các LLM mới nhất được huấn luyện trên dữ liệu Postgres, nên AI agent rất thành thạo khi sử dụng Neon
  • Tốc độ cao: vì yêu cầu nhanh hơn con người, việc provisioning instance siêu nhanh là điều thiết yếu
  • Mở rộng linh hoạt và chi phí: nhờ kiến trúc serverless tách biệt, chi phí cực thấp và có thể hỗ trợ số lượng lớn AI agent
  • Branching và forking: giúp AI agent dễ dàng thử nghiệm/xác minh trong các tình huống thay đổi liên tục

DNA chung của Databricks và Neon

• Các nhà sáng lập Nikita Shamgunov, Heikki Linnakangas, Stas Kelvich là những chuyên gia công nghệ cơ sở dữ liệu nổi tiếng trong ngành
• Họ có kinh nghiệm phong phú và sự sáng tạo riêng biệt từ SingleStore, vai trò Postgres committer và nhiều lĩnh vực khác
• Cả Databricks và Neon đều coi trọng đổi mới công nghệ tiên tiến ở tầng hạ tầng và các giá trị mã nguồn mở
• Apache Spark và Postgres đều có mối liên hệ ở chỗ là các dự án mã nguồn mở khởi nguồn từ UC Berkeley

Tầm nhìn tương lai và lợi ích cho người dùng

• Thị trường cơ sở dữ liệu OLTP (quy mô khoảng 100 tỷ USD) hiện vẫn chủ yếu dựa trên các sản phẩm từ nhiều thập kỷ trước
• Giờ là lúc nhà phát triển và AI agent dẫn dắt đổi mới
• Databricks và Neon hướng tới nền tảng DB thân thiện nhất với nhà phát triển và AI agent
• Khách hàng và đối tác Neon hiện tại có thể kỳ vọng vào sự hỗ trợ và đổi mới liên tục cũng như việc hiện thực hóa lộ trình sản phẩm
• Với nguồn lực của Databricks, việc tăng cường nền tảng và tăng trưởng ổn định sẽ được đảm bảo
• Tại Data + AI Summit (San Francisco, ngày 9–12 tháng 6), hai bên sẽ chia sẻ chi tiết hơn về tầm nhìn tương lai

[GN⁺]

Ý kiến trên Hacker News

• Tôi nghĩ kho dữ liệu đang nhanh chóng bị phổ thông hóa nhờ mã nguồn mở. Có công ty tôi biết từng lưu hơn 2 petabyte dữ liệu trên Cloudera, nhưng thay vì chuyển lên đám mây (Databricks), họ tự xây nền tảng phân tích bằng Iceberg, Trino và Superset, nhờ đó tiết kiệm chi phí gấp 5 lần. Các operator k8s cấp doanh nghiệp giờ đã đủ tốt, còn S3 on-premise cũng rất ổn. Phần cứng và mạng cũng có thể rất mạnh, như máy chủ với 128 CPU và 1TB bộ nhớ. Không chỉ Trino, mà StarRocks và ClickHouse cũng cung cấp Helm chart/operator k8s cấp doanh nghiệp. Mức định giá 60 tỷ USD của Databricks là gánh nặng của chính họ. Họ phải biện minh cho mức giá đó, trong khi bản thân mảng kinh doanh cốt lõi của họ cũng đang bị phổ thông hóa. Neon lấp vào chỗ trống trong danh mục sản phẩm của họ, nơi trước đây thiếu một DB vận hành (hướng hàng)
  • Từ góc nhìn doanh nghiệp thì đó không phải là sự phổ thông hóa. Chỗ làm trước đây của tôi không cho phép phần mềm mã nguồn mở, hay công ty có thể không còn tồn tại sau 10 năm, hoặc doanh nghiệp lưu dữ liệu ở nơi khác ngoài tenant của chúng tôi. Họ thậm chí còn thích mô hình giá “liên hệ để được báo giá”, và việc triển khai Databricks là một trong 3 thành tựu lớn nhất của tôi vì từ đó không còn phải bận tâm đến nền tảng dữ liệu nữa. Rủi ro khi đưa vào một nền tảng mới quá lớn nên không thể tin bất kỳ dự án mã nguồn mở nào. Có lần chúng tôi dùng giải pháp của startup, họ dùng MongoDB, nhưng đội vận hành không đủ năng lực nên thay vì tự học thì ký luôn dịch vụ hỗ trợ đầy đủ kiểu Atlas. Chúng tôi cũng chỉ dùng loại firewall quen thuộc thay vì Azure firewall còn lạ lẫm, rồi làm đủ loại hợp đồng. Giảm nhu cầu tuyển người, chỉ còn một đầu mối liên hệ, đạt hiệu quả vận hành. License của startup chỉ khoảng 5~10 nghìn USD/năm, nhưng phần hỗ trợ lại tốn nhiều hơn rất nhiều, như 40 nghìn USD. Startup và doanh nghiệp là hai thế giới hoàn toàn khác nhau
  • Tôi đang dùng StarRocks mã nguồn mở với operator k8s để phân tích khách hàng ở quy mô terabyte, và trong môi trường của tôi thì gần như không cần Databricks
  • Tôi đã dùng ClickHouse rất ổn trong vài năm qua mà không gặp vấn đề gì. Tính năng đa dạng, phạm vi rộng và là một cơ sở dữ liệu tạo cảm giác đáng tin cậy. Nhờ tính năng external dictionary mà việc tích hợp với các kho dữ liệu khác như Postgres hay Redis rất dễ
  • Nếu đang tìm một lựa chọn thay thế Cloudera mã nguồn mở dựa trên Kubernetes operator, thì chúng tôi đã phát triển stackable.tech được 5 năm rồi. Phía S3 mã nguồn mở on-premise mới là vấn đề. Tôi không khuyến nghị MinIO, còn ngoài ra thì gần như không có giải pháp nào đủ khả năng phục vụ doanh nghiệp
  • Kho dữ liệu đã bị phổ thông hóa từ hàng chục năm trước rồi. Lịch sử các thước đo giá và hiệu năng ở đây rất dài, và các sản phẩm kiểu SnowBricks không đáp ứng được điều đó. Chỉ khác nhau ở chỗ là ép mua hay bán mềm mà thôi
  • Tôi không hiểu tại sao phải mua DB vận hành từ Databricks. Nó chỉ giống như Databricks đang vật lộn để giữ giá trị thị trường
  • Nếu Databricks chỉ đơn giản cần một row DB thì họ đã tự xây trên Postgres rồi. Việc bỏ ra nhiều tiền như vậy cho Neon cho thấy họ muốn một thứ gì đó đặc biệt ở Neon, như “storage và compute có thể mở rộng độc lập”
  • Tôi tò mò mọi người dùng gì cho ETL
• Tôi đã ứng tuyển vào neon tuần trước, rồi tin bị mua lại nổ ra, và sáng nay tôi nhận luôn thông báo trượt. Đây là lần trượt vui nhất từ trước đến nay. Đây đã là lần thứ ba liên tiếp tôi suýt vào một công ty rồi lại bị mua lại, nên giờ tôi chỉ muốn sự ổn định thôi. Chúc mừng đội neon. Tôi thích neon và đang dùng nó, chỉ mong sau thương vụ này nó đừng thay đổi quá nhiều
  • Tôi vào Kenna Security trước khi bị mua lại, rồi một tháng sau công ty bị Cisco thâu tóm. Đó là trải nghiệm thực sự tệ hại, và tôi sẽ không bao giờ làm việc nữa ở công ty có lãnh đạo từ Kenna hay ở Cisco
  • Tôi thì có trải nghiệm ngược lại. Gia nhập vào đúng giai đoạn bị mua lại lại là lúc thú vị nhất. Trong trường hợp của tôi, kinh nghiệm tích hợp sau M&A còn khiến tôi thường xuyên được săn đón
  • Tôi từng ở trong quá trình bị mua lại khi đang là quản lý kỹ thuật năm đầu tiên, phải trải qua hai đợt sa thải, chọn người được giữ lại, hỗ trợ tái cơ cấu đội ngũ. Tinh thần xuống rất nặng, văn hóa tổ chức thì hoàn toàn không khớp. Tôi bị burnout nặng đến mức phải nghỉ vài tháng, giờ quay lại làm IC và đang rất hài lòng
  • Theo tôi đoán thì đội neon sẽ được đưa vào mảng công nghệ Online Tables của Databricks. Xét về sản phẩm thì cũng hợp lý
  • Nếu ai đó gia nhập neon từ thời định giá cũ và vừa vesting xong thì chắc hẳn bất ngờ nhận được một khoản tiền lớn, tôi cũng tò mò cảm giác đó thế nào
• Databricks là thứ phần mềm rác gây khó chịu nhất mà tôi từng dùng. Tôi ngạc nhiên là có ai tự nguyện dùng nó
  • Databricks bắt đầu từ năm 2013 khi Spark còn chưa ra gì, và họ đã làm Spark tốt hơn, nhanh hơn. Sản phẩm vẫn lấy Spark làm trung tâm, nhưng tôi nghĩ tổ hợp Iceberg + DuckDB phù hợp hơn với 95% công ty. Rẻ hơn, nhanh hơn và dễ xử lý hơn, và ở Definite chúng tôi cũng đang xây nền tảng dữ liệu theo giả định đó (gồm cả ETL, BI, Data Lake)
  • Databricks giống như Jira cho dữ liệu. Không ai muốn dùng, bản thân nó cũng chẳng hay ho, và vì cố phục vụ mọi loại người dùng nên mọi tính năng chắp vá đều nửa vời. Giờ đã có nhiều lựa chọn tốt hơn hẳn nên tôi sẽ không bao giờ chủ động chọn Databricks
  • Tôi thật sự rất khó đồng ý. Với người xuất thân từ Hadoop như tôi thì Databricks là thiên đường. Ổn định, nhanh và mở rộng cực tốt với tập dữ liệu lớn. Chỉ có điều giá quá đắt là điểm tôi phàn nàn nhiều nhất
  • Trước đây tôi từng thích nền tảng Databricks. Vào giai đoạn 2020~2021, so với AWS, Azure và Snowflake thì gần như chỉ Databricks là lựa chọn hợp lý. Còn hiện giờ thì tính năng bị nhồi nhét, thay đổi liên tục, mua bán sáp nhập đủ kiểu, và tên tính năng cũng rất lộn xộn
  • Hóa ra phần mềm kiểu IBM (ai cũng dùng nên mình cũng dùng) vẫn còn đất sống trên thị trường
  • Thành thật mà nói Databricks là một sản phẩm cực kỳ nhạt nhẽo. Nhìn lại cuối thập niên 2010, Spark-as-a-Service từng rất xuất sắc, thời điểm mà các doanh nghiệp liên tục thất bại trong việc tự vận hành Spark một cách ổn định. Các hyperscaler khi đó cũng có dịch vụ lớp đầu còn nghèo nàn, Databricks thì có các vấn đề như khả năng tương thích Jupyter của định dạng notebook riêng, nhưng cụm on-premise bất ổn còn đau đầu hơn nhiều nên chúng tôi sẵn sàng trả premium. Khi đó Databricks đã là một doanh nghiệp tỷ đô rất tốt. Nhưng chỉ với Spark-aaS thì không thể thành unicorn. AWS EMR đang chậm rãi đuổi theo như một đối thủ, và rồi Databricks cũng lao vào chiến lược tăng trưởng bằng cách bơm phồng sản phẩm, tung ra đủ thứ buzzword như data, lake, house. Tính đến năm 2025, đà đi xuống của Databricks là một ví dụ cay đắng của enshittification. Có ngày Larry Ellison sẽ mua lại nó và nó sẽ biến mất khỏi thị trường. Tôi không hiểu vì sao giờ còn ai chọn Databricks cho dự án mới, nhưng các doanh nghiệp đã dùng hơn 5 năm thì khó mà rời đi. Thị phần của họ có lẽ sẽ giảm, nhưng tiền vẫn còn đổ về một thời gian nữa. Đó là vòng tuần hoàn của ngành, và cuối cùng entropy luôn thắng. Tôi cũng không ghét họ đến thế. Họ từng là một công ty tạo ra lịch sử khá ổn
  • Họ quảng bá Serverless quá nhiều, nhưng nó có quá nhiều giới hạn và bẫy ẩn, đến mức thực sự rất mệt mỏi
  • Tôi vẫn nghi ngờ liệu việc host Spark có thực sự là bước đột phá không. Và tôi luôn thấy Spark bản thân nó đã quá phức tạp cho 90% nhu cầu xử lý dữ liệu của các doanh nghiệp truyền thống. Không hiểu sao công ty này lại được định giá cao đến vậy
  • Nếu tắt cookie thì website của họ hoàn toàn không tải được, đây là một red flag nghiêm trọng. Một nơi còn không làm nổi một website tử tế thì khó mà tin họ sẽ làm được sản phẩm số tốt
• Databricks dở chẳng kém gì Oracle. Tôi gần như chắc chắn họ sẽ phá hỏng Neon hoặc biến nó thành thứ đắt đỏ. Về trung và dài hạn tôi sẽ tìm phương án thay thế Neon
  • Chiến lược M&A của Databricks là bóp nghẹt các công ty mà họ mua lại. Họ đang chật vật trước làn sóng biến động lớn từ mã nguồn mở như Iceberg, DuckDB. Họ cố đổi mới thông qua thâu tóm, nhưng văn hóa doanh nghiệp khiến các công ty được mua về sụp đổ. Tôi xuất thân từ ngành big data (từng ở Snowflake) nên có thể hơi thiên vị, nhưng rõ ràng xu hướng mã nguồn mở đang ngày càng mạnh. Tôi rất tò mò xem sự thay đổi này sẽ đi đến đâu
• Trích bài gốc: “Năm ngoái khi Neon chuyển sang GA, 30% cơ sở dữ liệu được tạo ra là do AI agent tạo, nhưng gần đây xem lại thì tỷ lệ này đã vượt 80%. Nghĩa là AI đã tạo ra số DB nhiều gấp 4 lần con người.” Đây là loại dữ liệu làm hàng loạt chuông báo động reo lên. Có vẻ Databricks đang cố đóng gói Postgres thành một giải pháp AI. Đúng là thời buổi lạ lùng
  • Tôi tò mò trong số đó có bao nhiêu DB thực sự đang được dùng tích cực
• Chúc mừng đội Neon. Tôi rất thích thứ họ đã xây dựng. Nhưng thành thật mà nói tôi không thấy mối liên hệ hay hiệp lực rõ ràng nào với Databricks, và mong Neon sẽ tiếp tục tồn tại như một sản phẩm riêng. Nếu không thì thị trường sẽ mất đi một nhà cung cấp Postgres đáng tin cậy
  • Vì Neon phụ thuộc vào Azure khá nhiều nên chắc sẽ không biến mất ngay đâu. Có vẻ Databricks đang muốn mở rộng từ DB phân tích sang cả mảng DB giao dịch
  • FAQ nói là sẽ tiếp tục vận hành độc lập, nhưng tôi nghĩ kết cục thực tế thì ai cũng đoán được
• Tôi nhớ bài đăng đầu tiên của đội Neon trên HN. Khi đó tôi cũng đã bình luận rằng đây là một ý tưởng rất hay, dù lúc đó chưa có nhu cầu dùng ngay nhưng nghĩ rằng rồi sẽ có ngày cần đến. Nhưng mỗi lần thấy tin mua lại kiểu này tôi lại thấy hoài nghi. Có vẻ giờ họ sẽ tập trung vào góc nhìn của chủ sở hữu hơn là người dùng. Về nguyên tắc thì hai bên nên đồng nhất lợi ích, nhưng thực tế hiếm khi đúng như vậy
  • Tôi cũng nhớ bài đăng đầu tiên của Neon. Việc tách storage và compute khi đó rất mới mẻ, và tôi còn hỏi về Pageserver. Hai năm sau, chính tôi cũng đang làm phần storage tách biệt tương tự tại Turso database. Xin chúc mừng đội Neon một lần nữa
  • Tin mua lại này cũng khiến tôi chững lại. Tôi khó mà tin việc ưu tiên người dùng AI lại đồng nghĩa với lợi ích của nhà phát triển. Tôi hy vọng những công nghệ liên quan đến lõi PostgreSQL sẽ nhận được sự hỗ trợ từ cộng đồng mã nguồn mở
• Xin chúc mừng đội Neon. Một sản phẩm tuyệt vời. Tất nhiên, khi nhận vốn VC thì kết cục như thế này có lẽ là không tránh khỏi. Tôi mong Nikita và những người khác đủ cứng cáp để không bị Databricks đồng hóa
• Đây thực sự là một diễn biến thú vị. Tôi nghĩ cách OLTP và OLAP hội tụ như thế này là hướng đi đúng. Tôi từng cùng OP xây hệ thống HTAP tại SingleStore. Chúng tôi cố gắng làm OLTP và OLAP trong một cơ sở dữ liệu duy nhất (hỗ trợ cả hai chỉ với một lần sao chép), nhưng HTAP đã không thành công. OLTP nên dùng Postgres, còn OLAP nên đi với data warehouse/lake riêng, và phần sao chép ở giữa cần được thiết kế hiệu quả. Sao chép đồng bộ rất khó. Kho lưu trữ dạng cột không tiếp nhận ghi OLTP tốt. Tôi rất mong xem Databricks và Neon có thể hiện thực hóa kịch bản “dùng trực tiếp các bảng Postgres mới nhất trong Unity Catalog” hay không (không cần qua Debezium, Kafka, Flink, Iceberg, còn Spark giữ trạng thái Iceberg)
  • OP ở đây có phải là Nikita Shamgunov, nhà sáng lập Neon (trước đây là nhà sáng lập MemSQL/SingleStore), đúng không
• Chúc mừng đội Neon. Thành thật mà nói tôi hơi thất vọng. Tôi từng hy vọng Neon sẽ lấp vào khoảng trống mà CockroachDB để lại sau khi chuyển sang business source. Việc bị Databricks mua lại khiến Neon kém hấp dẫn hơn trong mắt tôi. Tôi khó mà tin một tập đoàn lớn sẽ chăm lo tốt cho hạ tầng quan trọng. Nhu cầu với một PostgreSQL “hiện đại” là có thật, nhưng trong số các lựa chọn thay thế trực tiếp thì chẳng cái nào còn bám sát gốc rễ nữa (xét về giá, mức độ tương thích, việc có mở mã nguồn hay không). Khi tìm phương án thay thế Postgres, tôi đã so sánh các lựa chọn dưới đây
  (1) AWS RDS thì chúng tôi đã dùng rồi, nhưng đắt và có vấn đề về mở rộng cũng như vận hành
  (2) AWS Aurora giải quyết được một phần vấn đề vận hành nhưng kéo theo nhược điểm khác, và cũng có những giới hạn tương tự các lựa chọn Postgres tương thích wire khác
  (3) CockroachDB rất thú vị, nhưng có vấn đề về tương thích với toolchain và mức độ tương thích sâu; vào thời điểm đó nó vẫn là mã nguồn mở
  (4) Neon khi đó còn có vẻ non, nên tôi chưa triển khai, nhưng nó rất đáng chú ý và có vẻ có thể giải quyết được nhiều vấn đề
  (5) Yugabyte cũng là công nghệ thú vị, nhưng cũng có nhiều vấn đề tương thích khác nhau
  Tôi cũng từng cân nhắc tự host Postgres, nhưng gánh nặng tự vận hành Kubernetes và Postgres là quá lớn. Các tính năng tự sao chép và tự vận hành khi đó vẫn còn chưa chín muồi, còn việc unload/reload toàn bộ dữ liệu khi nâng cấp thì cực kỳ phiền phức. Mở rộng hay tự động hóa đều không hề dễ
  • Về việc so sánh với Yugabyte vì engine truy vấn của nó có vẻ dựa trên Postgres, xin nhắc lại rằng bản thân Neon chính là Postgres
  • Tôi xin chia sẻ kinh nghiệm ngắn hạn của mình rằng “lựa chọn thay thế Postgres hiện đại tốt nhất là chính Postgres (của 5 năm sau)”
  • Tôi muốn nghe thêm về việc những lựa chọn PostgreSQL tương thích wire khác có “cùng những nhược điểm” gì