Skip to content

DuckDB 2.0 preview: từ thư viện nhúng thành server thực thụ

Karify98 & Amy 🌸·
Cover Image for DuckDB 2.0 preview: từ thư viện nhúng thành server thực thụ

Ngày 17/8/2026, DuckDB công bố bản preview của phiên bản 2.0 — bản nâng cấp lớn đầu tiên kể từ v1.5 hồi tháng 3, gói gọn hơn 10.000 commit. Điểm đáng chú ý nhất không phải một tính năng đơn lẻ, mà là một bước chuyển hướng: DuckDB, vốn chỉ là cơ sở dữ liệu phân tích chạy trong process, giờ đã biết làm server.

DuckDB thường được ví như "SQLite của thế giới phân tích" — một cơ sở dữ liệu nhúng, chạy cùng process với ứng dụng thay vì đứng sau một server riêng. Mô hình đó khiến nó nhanh vượt trội trên dữ liệu cục bộ, nhưng cũng đóng khung nó ở kịch bản đơn máy, đơn người dùng. v2.0 — mang tên mã Cyanoptera, theo loài vịt quế — đặt cược vào điều ngược lại.

DuckDB biết làm server: Quack và CONNECT

Thay đổi lớn nhất nằm ở extension Quack và lệnh CONNECT. Quack triển khai giao thức riêng để một tiến trình DuckDB nói chuyện với một tiến trình DuckDB khác, và trong v2.0 nó tốt nghiệp từ bản preview lên stable. Bất kỳ DuckDB nào cũng có thể mở dữ liệu lên mạng, và bất kỳ DuckDB nào cũng có thể ATTACH tới nó rồi CONNECT để chạy truy vấn từ xa.

CONNECT không chỉ giới hạn ở Quack. Nó trỏ phiên làm việc tới bất kỳ cơ sở dữ liệu từ xa nào hỗ trợ, và bộ tối ưu pushdown mới đẩy thẳng SQL xuống PostgreSQL hoặc MySQL thay vì kéo toàn bộ bảng về qua dây. Nói cách khác, DuckDB giờ có thể đóng vai một lớp truy vấn trung gian, không chỉ là một bộ máy phân tích cục bộ.

Cần nói rõ một điều dễ hiểu nhầm: "server" ở đây không phải là hệ thống phân tán. DuckDB vẫn là single-node. Giá trị của server mode nằm ở chỗ một phiên DuckDB chạy dài hạn có thể phục vụ nhiều client — điều mà trước đây chỉ dành cho các hệ quản trị cơ sở dữ liệu truyền thống.

VARIANT: JSON nhưng nhanh

Kiểu VARIANT ra mắt từ v1.5, và cách hiểu đơn giản nhất là "JSON mà nhanh". Giống JSON, một cột VARIANT có thể chứa dữ liệu có cấu trúc khác nhau ở từng dòng. Khác JSON, nó không phải định dạng văn bản: DuckDB tự phát hiện cấu trúc chung ẩn trong dữ liệu bán cấu trúc rồi tách nhỏ nó, nhờ đó nén tốt và chạy nhanh mà không cần khai báo schema.

Trong v2.0, pipeline này hoạt động trọn vẹn: thực thi ngay từ storage, đọc lẫn ghi Parquet ở dạng đã tách nhỏ, và một họ hàm variant_*. Đây là câu trả lời trực tiếp cho bài toán thu nạp dữ liệu log — những luồng record dạng JSON có cấu trúc tương đồng nhưng liên tục biến đổi theo thời gian. Về lâu dài, đội ngũ DuckDB dự định để kiểu JSON thường chạy trên nền VARIANT, tức workload JSON hiện có được hưởng lợi mà không phải sửa một câu truy vấn nào.

Trigger và SQL dialect mở rộng

Trigger là tính năng được yêu cầu từ lâu, và v2.0 mang tới bộ đầy đủ: BEFORE/AFTER, FOR EACH ROW/FOR EACH STATEMENT, transition table qua REFERENCING OLD/NEW TABLE, nhiều trigger cho một sự kiện, và DROP TRIGGER. Trường hợp dùng kinh điển là bảng audit — ghi lại mọi thay đổi dữ liệu. Trigger cũng ăn khớp với hướng server: một dịch vụ DuckDB chạy lâu dài giờ có thể tự duy trì các ràng buộc và nhật ký thay đổi ở tầng cơ sở dữ liệu.

Đáng chú ý hơn với developer đang làm vector search: join NEAREST đưa tìm kiếm tương đồng top-k thành một mệnh đề join, thay vì phải viết thủ công. Cú pháp trích từ thông báo của DuckDB:

SELECT q.user_id, t.product_id
FROM users q
INNER JOIN products t APPROX NEAREST 2
BY SIMILARITY array_cosine_similarity(q.embedding, t.embedding);

Cộng thêm khả năng chạy INSERT/UPDATE/DELETE bên trong CTE và cú pháp biến $x gọn gàng, bộ SQL dialect của DuckDB đang tiến gần hơn tới một ngôn ngữ xử lý pipeline, chứ không chỉ là ngôn ngữ truy vấn.

Async I/O và con số 40×

Phần lớn dữ liệu phân tích ngày nay nằm trên object storage như S3. DuckDB vốn đọc song song từ object store, nhưng truy cập đồng bộ đặt một trần lên tốc độ. v2.0 đưa I/O bất đồng bộ vào toàn bộ engine, tách lớp I/O khỏi lớp xử lý truy vấn — nghĩa là nhiều truy vấn từ xa hơn chạy song song, và tốc độ trên dữ liệu mạng tăng đáng kể. Parquet được hỗ trợ trước, CSV và định dạng riêng của DuckDB theo sau.

Về tốc độ thuần túy, con số dễ nhớ nhất là truy vấn đệ quy. Theo microbenchmark của DuckDB trên laptop — tìm mọi nút tới được từ một nút trên đồ thị một triệu cạnh — v1.5.4 mất 4,90 giây, còn v2.0 chỉ mất 0,12 giây, tức nhanh gấp khoảng 40 lần. Đây là số tự công bố, nên chỉ nên đọc như tín hiệu hướng cải thiện, không phải benchmark độc lập.

Storage, parser mới và lời tạm biệt ICU

Ba thay đổi bên dưới engine cho thấy hướng đi dài hạn. Thứ nhất, storage format v2.0 chuyển index sang buffer-managed — index không còn bị ghim trong bộ nhớ, nên bảng có index lớn mở tức thì và giảm mạnh dung lượng RAM. Thứ hai, DuckDB bỏ parser kế thừa từ PostgreSQL, thay bằng parser PEG tự viết, kéo theo thông báo lỗi tốt hơn và chế độ tương thích dialect (hiện có spark). Thứ ba, ICU — thư viện vốn dùng cho timezone, calendar và collation — bị loại bỏ hoàn toàn: extension icu giờ tự triển khai, với dữ liệu timezone nén còn khoảng 45 kB, vừa nhỏ hơn vừa nhanh hơn.

Extension viết một lần, tự host

Cuối cùng là tin tốt cho ai viết extension. Trước đây, đa số extension build dựa trên C++ API không ổn định, buộc tác giả phải rebuild theo từng bản phát hành. v2.0 mở rộng stable C API đủ rộng để extension viết một lần, build một lần và tiếp tục chạy qua nhiều phiên bản. Đi kèm là khả năng tự host kho extension riêng, ký bằng RSAINSTALL như kho tích hợp sẵn — thứ doanh nghiệp cần để kiểm soát nguồn cung extension nội bộ.

Điều cần biết

  • DuckDB v2.0 mới ở bản preview — ra mắt chính thức mùa thu 2026, một số chi tiết có thể còn thay đổi.
  • Điểm nhấn: server mode (Quack + CONNECT), kiểu VARIANT hoàn thiện, trigger, async I/O.
  • Có breaking changes: storage format mặc định mới và hoàn tất chuyển đổi cú pháp lambda.
  • Truy vấn đệ quy nhanh gấp ~40× theo microbenchmark tự công bố.
  • Hành động: nếu đang dùng DuckDB in-process, v2.0 gần như là drop-in upgrade — nhưng thử preview build và để mắt tới storage format lẫn lambda syntax trước khi nâng cấp dữ liệu production.

Bản preview này đáng đọc vì nó cho thấy DuckDB đang trả lời một câu hỏi mà nhiều đội ngũ đã ngầm đặt ra: giữa SQLite quá nhỏ và một data warehouse quá nặng, có chỗ cho một tầng phân tích đơn máy nhưng chạy như một dịch vụ không. v2.0 không biến DuckDB thành đối thủ của Snowflake hay BigQuery. Nó mở rộng vùng mà DuckDB chiếm được. Với bất kỳ đội ngũ nào đang nằm giữa hai thái cực đó, đây là thời điểm hợp lý để cài preview build và chạy thử trên chính dữ liệu thật của mình.


Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.

Related Posts