Supabase Select 2026: Turso, Multigres, OrioleDB và các mốc cần xử lý trước 10/11

Đầu tháng 10/2026, Supabase tổ chức sự kiện Select 2026 và công bố hàng loạt thay đổi: mua lại Turso, hạ tầng Postgres chịu lỗi mới, cách quản lý schema bằng mã, công cụ vận hành và quyền truy cập an toàn hơn. Song song, changelog của Supabase có nhiều mốc kỹ thuật mà đội đang dùng Supabase cần xử lý, sớm nhất là 10/11/2026.

Bài này tóm tắt các thay đổi đã được công bố đến 15/10/2026, nói rõ mục nào đã chính thức, mục nào còn alpha hoặc beta, và việc nên làm.

Điểm chính

• Supabase công bố mua lại Turso ngày 2/10/2026. Bài công bố không nêu điều khoản tài chính hay thời điểm hoàn tất, và cho biết người dùng hiện tại không bị thay đổi.
• Multigres (Postgres nhiều node, tự chuyển đổi dự phòng) đang ở alpha riêng, chỉ theo lời mời. OrioleDB (storage engine mới) đã ở beta công khai.
• Declarative Schemas 2.0 dùng pg-delta để tạo migration từ các file schema. pg-delta vẫn ở bản alpha.
• Công cụ vận hành mới: Health Check Advisors, Database Connections, Explorer và Notebooks. Pipelines đẩy dữ liệu Postgres sang kho phân tích, đang ở alpha công khai.
• Về quyền truy cập, Scoped personal access token và Enterprise-Managed Auth cho MCP đã ra chính thức.
• Việc cần làm sớm: từ 10/11/2026, các cipher TLS 1.2 cũ sẽ bị tắt trên API của dự án.

1. Supabase mua lại Turso

Ngày 2/10/2026, Supabase công bố sẽ mua lại Turso, công ty làm cơ sở dữ liệu trên nền SQLite, để xây hạ tầng database cho các ứng dụng AI dạng agent.

Lý do được nêu: agent đang tạo ra số lượng database rất lớn và nhu cầu sẽ vượt khả năng hiện có. Supabase muốn có database rẻ, tạo ngay khi cần và có đường lên môi trường chạy thật. Họ xếp SQLite cho các tải nhỏ và Postgres cho ứng dụng cần mở rộng. Kiến trúc của Turso cho phép một máy chủ quản lý hàng triệu database, nạp khi cần và tạm dừng khi nhàn rỗi.

Những điều bài công bố nói rõ và không nói:

• Turso tiếp tục hoạt động, tiếp tục làm việc với SQLite, và có đường đi vào hệ sinh thái Supabase khi tải tăng lên.
• Người dùng hiện tại không bị thay đổi. Supabase vẫn xây quanh Postgres.
• Glauber Costa, Pekka Enberg và đội ngũ Turso gia nhập Supabase. Glauber Costa sẽ dẫn dắt mảng hạ tầng cho agent.
• Không có điều khoản tài chính, không có mốc hoàn tất, và bài không nhắc đến libSQL hay Limbo.

Với doanh nghiệp, hiện chưa có gì phải đổi. Điều đáng theo dõi là liệu Supabase có ra sản phẩm "database cho từng agent" trong các tháng tới hay không.

2. Mở rộng quy mô: Multigres, OrioleDB và dbarena

Multigres là hệ thống mã nguồn mở cho Postgres do nhóm đứng sau Vitess xây dựng. Nó có sẵn connection pooling (không cần chạy thêm bộ pooler riêng) và tự chuyển đổi dự phòng nhiều node.

Hệ thống chạy 3 node Postgres trên nhiều vùng khả dụng trong cùng một khu vực, dùng giao thức đồng thuận trên nền sao chép đồng bộ của Postgres để các giao dịch đã commit không mất khi chuyển đổi, và promote một replica trong vài giây khi một node lỗi, không cần sửa mã ứng dụng.

Trên Supabase, Multigres ở alpha riêng, chỉ theo lời mời, dành cho thử nghiệm chứ chưa phải tải production. Bài công bố không nêu số liệu hiệu năng. Changelog ghi thêm rằng alpha giới hạn cho một số tổ chức Pro, Team và Enterprise được chọn.

OrioleDB là storage engine mã nguồn mở thay cho heap mặc định của Postgres. Nó dùng undo log thay vì để lại các dòng chết, nên không bị phình bảng và không cần VACUUM. Nó dùng mã giao dịch 64 bit mặc định để tránh hiện tượng tràn mã giao dịch, và đọc trang không khóa để hưởng lợi khi nhiều truy cập đồng thời.

Theo Supabase, OrioleDB đạt thông lượng cao hơn heap của Postgres tới 1,8 lần trên các benchmark công khai dựa trên TPC-C đăng ở dbarena.com. OrioleDB ở beta công khai: chọn khi tạo dự án trong phần cấu hình nâng cao, và trong cùng một dự án có thể chọn từng bảng bằng USING orioledb hoặc USING heap.

Dự án OrioleDB mới có trên mọi gói, kèm kế hoạch về gói và tính năng trả phí.

dbarena là trang công khai về benchmark database có thể tái lập, so sánh các nhà cung cấp Postgres được quản lý. Lúc ra mắt có Supabase, Amazon RDS và Google Cloud SQL. Trang công bố mã benchmark, phương pháp, dữ liệu thô tải về được, và các chỉ số như số giao dịch trên mỗi đô la, chi phí hằng tháng, giao dịch mỗi phút, độ trễ p95.

Lưu ý rằng đây là benchmark do Supabase đưa ra, nên hãy tự đo trên khối lượng công việc của mình trước khi quyết định.

3. Xây dựng: schema bằng mã, local không cần Docker, Compute

Declarative Schemas 2.0 với pg-delta. Bạn giữ schema dưới dạng các file SQL trong supabase/schemas/, CLI tạo migration từ thay đổi của các file đó. Engine so sánh là pg-delta, mã nguồn mở, thay cho migra.

So với phiên bản đầu, pg-delta sửa được cả RLS policy (không chỉ tạo và xóa), giữ security_invoker của view, so sánh quyền cột, role và grant, hỗ trợ domain, comment, partition, foreign table và đối tượng thuộc extension. Thứ tự file được tính từ đồ thị phụ thuộc lấy trong catalog, không còn theo thứ tự chữ cái.

Cách hoạt động: CLI dựng 2 database Postgres tạm. Một cái nạp các file schema, cái còn lại chạy lại lịch sử migration. pg-delta so sánh 2 cái qua system catalog, không đọc chữ SQL, rồi ghi phần khác biệt thành một file SQL trong supabase/migrations/.

Những giới hạn cần nhớ:

• Chỉ xử lý thay đổi schema, không ghi dữ liệu trong bảng (trừ vài dòng cấu hình của extension như cron.job).
• Bucket Storage (dòng trong storage.buckets) không được so sánh. RLS policy của Storage thì có.
• Đổi tên bảng hoặc cột được tạo thành xóa rồi thêm, có thể mất dữ liệu. Phải đọc kỹ các câu lệnh bị đánh dấu trước khi áp dụng.
• Cần Supabase CLI 2.119 trở lên, hỗ trợ Postgres 14 đến 18. pg-delta đang ở alpha và có thể đổi trước bản ổn định. Dự án mới tạo bằng supabase init đã dùng pg-delta, dự án cũ bật bằng [experimental.pgdelta] enabled = true trong config.toml.

Local không cần Docker (alpha, mặc định tắt). Supabase local chạy như các tiến trình gốc, hữu ích trên máy không có Docker như máy chạy CI hay sandbox của agent. Mỗi thư mục hoặc git worktree có thể chạy một bản riêng, để agent thử 2 thay đổi song song. Cần CLI bản mới.

Supabase Compute (alpha riêng, đăng ký chờ). Chạy dịch vụ web hoặc agent dài hạn bằng bất kỳ ngôn ngữ nào, ngay cạnh database, không giới hạn thời gian chạy, mỗi dịch vụ có môi trường Linux đầy đủ. Dịch vụ khai báo trong config.toml và triển khai bằng CLI hoặc Management API. Có thể để công khai (có URL HTTP và cân bằng tải) hoặc riêng tư cho tác vụ nền.

MCP server cho chính ứng dụng của bạn. Cho phép người dùng của bạn kết nối agent của họ vào ứng dụng, hoạt động đúng với tư cách người đã đăng nhập. Bạn thêm một MCP server có xác thực bằng một lệnh shadcn, nó được cài như một Edge Function thuộc về bạn, và RLS policy vẫn quyết định mỗi người thấy dòng dữ liệu nào.

Tính năng cần khóa ký bất đối xứng và máy chủ OAuth của Supabase Auth. Đây là sản phẩm riêng, khác với MCP server chính thức của Supabase vốn giúp bạn xây ứng dụng. Nền tảng của nó là @supabase/server và Supabase Middleware, bản @supabase/middleware 1.0.0 đã ổn định từ 30/9.

4. Vận hành: nhìn thấy sự cố sớm hơn

• Health Check Advisors: Advisor không chỉ kiểm bảo mật và hiệu năng mà còn cảnh báo khi tỷ lệ lỗi của Data API, Auth, Storage và Edge Functions vượt mức bình thường. Chạy theo yêu cầu từ dashboard hoặc Management API, kết quả ở tab Health trên trang Advisors.
• Database Connections: cho thấy các phiên đang giữ kết nối, truy vấn chạy lâu, phiên nằm im trong giao dịch, truy vấn bị chặn và bên đang giữ khóa. Bạn có thể hủy truy vấn hoặc ngắt kết nối. Bật mặc định cho mọi dự án, kể cả tự host.
• Explorer và Notebooks: Explorer là phiên bản kế tiếp của SQL editor, truy vấn cả log lẫn database trong một không gian. Notebooks lưu một phiên điều tra thành file trong thư mục supabase, đồng đội chạy lại được. Explorer triển khai dần tới mọi dự án đến hết 12/10, bật trong Feature Previews.
• query_logs và prompt cho agent: công cụ MCP mới cho agent truy vấn log bằng SQL, cùng các prompt dựng sẵn kèm lịch gợi ý cho 4 nhóm kiểm tra là sức khỏe, bảo mật, hiệu năng và tài nguyên. Chạy trong Claude, Codex hoặc Cursor qua kết nối MCP chỉ đọc.
• Pipelines (alpha công khai, gói Pro, Team, Enterprise): đẩy dữ liệu Postgres gần như theo thời gian thực sang BigQuery, ClickHouse, DuckLake hoặc Snowflake để phân tích không chạy trên database production. Đồng bộ ban đầu bắt đầu ngay khi tạo, thay đổi schema được phát hiện và áp dụng tự động. Tính năng trước đây tên Database Replication, đổi tên từ 21/9.
• Logs tính phí theo mức dùng (25/9): Supabase cho biết hơn 90% dự án nằm trong hạn mức đã gồm, và có giai đoạn ân hạn kéo đến đầu 2027.

5. Quyền truy cập: bớt rủi ro khi giao việc cho agent

• Scoped personal access token (chính thức, 6/10): giới hạn token theo tổ chức, dự án và quyền cụ thể cho Management API, MCP server và CLI. Đây là mặc định cho token mới tạo ở dashboard, và Supabase khuyên bắt đầu bằng token chỉ đọc.
• Enterprise-Managed Auth cho MCP (chính thức): doanh nghiệp kiểm soát quyền dùng MCP server qua nhà cung cấp danh tính, bắt đầu với Okta. Token ngắn hạn và gắn với người đã đăng nhập. Cần gói Team hoặc Enterprise có cấu hình SSO.
• MCP Elicitations: MCP server hỏi xác nhận trước khi agent tạo dự án hoặc branch tính phí, hay chạy SQL có thể xóa dữ liệu. Supabase nói rõ đây giảm rủi ro chứ không bảo đảm tuyệt đối, và phần mềm agent phải hỗ trợ tính năng này.
• Vai trò "No access" khi mời thành viên (5/10): quản trị viên Team và Enterprise có thể đặt thành viên mới mặc định không có quyền vào dự án, thay vì quyền chỉ đọc trên mọi dự án.

6. Các mốc kỹ thuật cần xử lý

• PostgreSQL 15.19 và 17.11 (25/9): bản cập nhật phụ vá 44 lỗ hổng. Chỉ mục ltree và btree_gist có thể cần reindex, và dữ liệu pgcrypto mã hóa bằng cipher cũ cần mã hóa lại.
• 10/11/2026, tắt cipher TLS 1.2 cũ: các cipher CBC cũ bị tắt trên API của dự án gồm Auth, Data APIs, Storage, Realtime và Edge Functions. Client không hỗ trợ chuẩn TLS hiện đại sẽ không kết nối được. Supabase ước tính dưới 0,0001% lưu lượng bị ảnh hưởng.
• 1/12/2026, gỡ adapter trong @supabase/server: các adapter Hono, H3, Elysia và NestJS bị gỡ, cần chuyển sang framework bridge.
• 31/1/2027: supabase-js yêu cầu TypeScript 5.0 trở lên, không còn hỗ trợ 4.7 đến 4.9.
• Đã có hiệu lực: endpoint Management API logs.all bị gỡ từ 23/9, phải dùng endpoint logs chỉ nhận SQL của ClickHouse. Từ 5/8, phiên bản extension ghi rõ trong CREATE hoặc ALTER EXTENSION bị bỏ qua và luôn cài phiên bản mặc định.
• Dự án tự host: Envoy thay Kong làm API gateway mặc định từ tuần 9/8, một thay đổi gây lỗi nếu bạn dùng listener HTTPS của Kong hoặc file kong.yml tùy chỉnh.

7. Một số cập nhật khác

SDK .NET được hỗ trợ chính thức (9/10), có gói dependency injection cho ASP.NET Core (12/10) và xuất OpenTelemetry (14/10). SDK Go ở alpha công khai (5/10). Trang trạng thái chuyển sang incident.io (8/10): người đăng ký email được giữ nguyên, người đăng ký SMS, Slack hoặc webhook phải đăng ký lại.

Postgres Changes của Realtime thêm bộ lọc AND, toán tử mới và chọn cột (5/8). Đăng nhập bằng ChatGPT đang beta (29/7). Unified Logs mở beta (16/7).

8. Việc nên làm cho đội đang dùng Supabase

1. Trước 10/11: kiểm tra mọi client gọi API Supabase, gồm thiết bị, ứng dụng cũ và thư viện HTTP cũ, xem có hỗ trợ TLS hiện đại không.
2. Sau bản vá Postgres: kiểm tra chỉ mục ltree, btree_gist và dữ liệu pgcrypto như hướng dẫn trong changelog.
3. Rà soát token: đổi token cá nhân cũ sang scoped token, cấp quyền chỉ đọc cho agent và công cụ tự động. Với Team hoặc Enterprise, đặt thành viên mới mặc định "No access".
4. Thử Declarative Schemas trên dự án thử, chưa áp dụng thẳng vào production. Đọc kỹ các lệnh xóa khi đổi tên bảng hoặc cột.
5. Bật Health Check Advisors và mở Database Connections để quen với cách nhìn sự cố trước khi sự cố xảy ra.
6. Không dùng alpha cho production: Multigres, Supabase Compute, Pipelines và local không cần Docker đều chưa ổn định hoặc chưa mở rộng cho mọi người.
7. Nếu dùng @supabase/server hoặc supabase-js: chuyển adapter trước 1/12 và nâng TypeScript lên 5.0 trước 31/1/2027.
8. Nếu log nhiều: theo dõi mức dùng Logs trước khi hết giai đoạn ân hạn.