Supabase Select 2026: Turso, Multigres, OrioleDB and the deadlines to handle before November 10

In early October 2026, Supabase held its Select 2026 event and announced a wave of changes: the acquisition of Turso, new fault-tolerant Postgres infrastructure, schema management as code, new operations tools and safer access control.

At the same time, the Supabase changelog lists several technical deadlines that teams using Supabase need to handle, the earliest on November 10, 2026. This article summarizes the changes announced through October 15, 2026, says which items are generally available and which are still alpha or beta, and lists what to do.

Key points

• Supabase announced the acquisition of Turso on October 2, 2026. The announcement gives no financial terms or closing date, and says existing users are not affected.
• Multigres (multi-node Postgres with automatic failover) is in private alpha, by invitation only. OrioleDB (a new storage engine) is in public beta.
• Declarative Schemas 2.0 uses pg-delta to generate migrations from schema files. pg-delta is still in alpha.
• New operations tools: Health Check Advisors, Database Connections, Explorer and Notebooks. Pipelines streams Postgres data to analytics warehouses and is in public alpha.
• On access control, scoped personal access tokens and Enterprise-Managed Auth for MCP are generally available.
• Act early: from November 10, 2026, older TLS 1.2 ciphers will be disabled on project APIs.

1. Supabase is acquiring Turso

On October 2, 2026, Supabase announced it is acquiring Turso, the company building databases on SQLite, to build database infrastructure for agentic AI applications.

The stated reason: agents are creating very large numbers of databases and demand will exceed current capacity. Supabase wants databases that are cheap, available on demand and have a route to production. It positions SQLite for small workloads and Postgres for applications that need to scale.

Turso's architecture lets one server manage millions of databases, loading them when needed and suspending them when idle.

What the announcement says, and does not say:

• Turso will continue operating, will keep working on SQLite, and has a path into the broader Supabase ecosystem as workloads grow.
• Nothing changes for existing users. Supabase keeps building around Postgres.
• Glauber Costa, Pekka Enberg and the Turso team are joining Supabase. Glauber Costa will lead the agentic infrastructure effort.
• No financial terms, no closing date, and the post does not mention libSQL or Limbo.

For businesses, nothing needs to change today. What is worth watching is whether Supabase ships a "database per agent" product in the coming months.

2. Scaling: Multigres, OrioleDB and dbarena

Multigres is an open source system for Postgres built by the team behind Vitess. It has built-in connection pooling (no separate pooler to run) and automated multi-node failover.

It runs 3 Postgres nodes across availability zones in one region, uses a consensus protocol on top of Postgres synchronous replication so committed transactions survive failover, and promotes a replica within seconds when a node fails, with no application code changes.

On Supabase, Multigres is in private alpha, by invitation, intended for testing and not production workloads. The announcement states no performance numbers. The changelog adds that the alpha is limited to selected Pro, Team and Enterprise organizations.

OrioleDB is an open source storage engine that replaces the default Postgres heap. It uses an undo log instead of leaving dead tuples behind, so there is no table bloat and no need for VACUUM. It uses 64-bit transaction IDs by default, which avoids transaction ID wraparound, and lock-free page reads help under high concurrency.

According to Supabase, OrioleDB reaches up to 1.8x the throughput of the Postgres heap in public, TPC-C-derived benchmarks published on dbarena.com. OrioleDB is in public beta: choose it under advanced configuration when creating a project, and within one project you can choose per table with USING orioledb or USING heap.

New OrioleDB projects are available on all plans, with paid plans and paid features planned.

dbarena is a public site for open, reproducible database benchmarks that compares managed Postgres providers.

At launch it covers Supabase, Amazon RDS and Google Cloud SQL. It publishes the benchmark code, methodology and downloadable raw data, and metrics such as transactions per dollar, monthly cost, transactions per minute and p95 latency. Note that these benchmarks come from Supabase, so measure on your own workload before deciding.

3. Building: schema as code, local without Docker, Compute

Declarative Schemas 2.0 with pg-delta. You keep your schema as SQL files in supabase/schemas/, and the CLI generates migrations from changes to those files. The diff engine is pg-delta, open source, replacing migra.

Compared with the first version, pg-delta can alter RLS policies (not only create and drop them), preserves security_invoker on views, diffs column privileges, roles and grants, and covers domains, comments, partitions, foreign tables and extension-owned objects.

File order comes from a dependency graph built from the catalog, no longer alphabetical.

How it works: the CLI starts 2 temporary Postgres databases. One loads your schema files and the other replays your migration history. pg-delta compares them through the system catalog, without parsing SQL text, and writes the difference as a SQL file in supabase/migrations/.

Limits to remember:

• It handles schema changes only and does not write table data (except a few extension configuration rows such as cron.job).
• Storage buckets (rows in storage.buckets) are not diffed. Storage RLS policies are.
• Renaming a table or column is generated as a drop and an add, which can lose data. Review the flagged statements before applying.
• It needs Supabase CLI 2.119 or later and supports Postgres 14 through 18. pg-delta is in alpha and may change before a stable release. New projects created with supabase init already use pg-delta, and existing projects enable it with [experimental.pgdelta] enabled = true in config.toml.

Local without Docker (alpha, off by default). Local Supabase runs as native processes, useful on machines without Docker such as CI runners and agent sandboxes. Each directory or git worktree can run its own instance so an agent can test 2 changes side by side. It needs a recent CLI.

Supabase Compute (private alpha, waitlist). Run long-lived web services or agents in any language right next to your database, with no limit on runtime and a full Linux environment per service. Services are defined in config.toml and deployed with the CLI or the Management API. They can be public (with an HTTP URL and load balancing) or private for background jobs.

An MCP server for your own app. It lets your users connect their agents to your app, acting as the signed-in user. You add an authenticated MCP server with one shadcn command, it installs as an Edge Function you own, and your RLS policies still decide which rows each person can see.

It requires asymmetric signing keys and the Supabase Auth OAuth server. This is a separate product from the official Supabase MCP server, which helps you build apps. It is built on @supabase/server and Supabase Middleware, and @supabase/middleware 1.0.0 has been stable since September 30.

4. Operations: see problems earlier

• Health Check Advisors: Advisors now check more than security and performance. They flag elevated error rates for the Data API, Auth, Storage and Edge Functions. Checks run on demand from the dashboard or the Management API, and results appear in the Health tab on the Advisors page.
• Database Connections: shows sessions holding connections, long-running queries, idle-in-transaction sessions, blocked queries and lock holders. You can cancel a query or terminate a connection. It is on by default for every project, including self-hosted.
• Explorer and Notebooks: Explorer is the next version of the SQL editor and queries logs and databases in one workspace. Notebooks save an investigation as a file in the supabase folder that teammates can rerun. Explorer is rolling out to all projects through October 12, and you turn it on in Feature Previews.
• query_logs and agent prompts: a new MCP tool lets agents query logs with SQL, plus prebuilt prompts with suggested schedules for 4 checks: health, security, performance and resources. They run in Claude, Codex or Cursor over a read-only MCP connection.
• Pipelines (public alpha, Pro, Team and Enterprise plans): streams Postgres data in near real time to BigQuery, ClickHouse, DuckLake or Snowflake so analytics do not run on the production database. The initial sync starts on creation, and schema changes are detected and applied automatically. The feature was previously called Database Replication and was renamed on September 21.
• Logs usage-based pricing (Sep 25): Supabase says over 90% of projects stay within the included limits, and a grace period runs into early 2027.

5. Access control: less risk when you delegate to agents

• Scoped personal access tokens (generally available, Oct 6): limit a token to specific organizations, projects and permissions for the Management API, MCP server and CLI. This is the default for new dashboard tokens, and Supabase recommends starting with read-only tokens.
• Enterprise-Managed Auth for MCP (generally available): companies control MCP server access through their identity provider, starting with Okta. Tokens are short-lived and tied to the signed-in member. It requires a Team or Enterprise plan with SSO configured.
• MCP Elicitations: the MCP server asks for confirmation before an agent creates a paid project or branch, or runs SQL that could delete data. Supabase says clearly that this reduces risk and is not a guarantee, and the agent client must support it.
• "No access" role for invites (Oct 5): Team and Enterprise admins can default new members to no project access, instead of read-only access to all projects.

6. Technical deadlines to handle

• PostgreSQL 15.19 and 17.11 (Sep 25): the minor release fixes 44 CVEs. ltree and btree_gist indexes may need reindexing, and pgcrypto data encrypted with legacy ciphers needs re-encryption.
• November 10, 2026, older TLS 1.2 ciphers disabled: legacy CBC ciphers are disabled on project APIs including Auth, Data APIs, Storage, Realtime and Edge Functions. Clients without modern TLS support will fail to connect. Supabase estimates under 0.0001% of traffic is affected.
• December 1, 2026, adapters in @supabase/server removed: the Hono, H3, Elysia and NestJS adapters are removed, so move to the framework bridges.
• January 31, 2027: supabase-js requires TypeScript 5.0 or later and drops support for 4.7 through 4.9.
• Already in effect: the Management API logs.all endpoint was removed on September 23, so use the logs endpoint, which accepts only ClickHouse SQL. Since August 5, explicit extension versions in CREATE or ALTER EXTENSION are ignored and the default version is installed.
• Self-hosted projects: Envoy replaced Kong as the default API gateway from the week of August 9, a breaking change if you use Kong's HTTPS listener or a custom kong.yml file.

7. Other updates

The .NET SDK is officially supported (Oct 9), with a dependency injection package for ASP.NET Core (Oct 12) and OpenTelemetry export (Oct 14). The Go SDK is in public alpha (Oct 5). The status page moved to incident.io (Oct 8): email subscribers carried over, while SMS, Slack and webhook subscribers must resubscribe.

Realtime Postgres Changes gained AND filters, new operators and column selection (Aug 5). Sign in with ChatGPT is in beta (Jul 29). Unified Logs opened in beta (Jul 16).

8. What to do if your team uses Supabase

1. Before November 10: check every client that calls the Supabase APIs, including devices, older apps and older HTTP libraries, for modern TLS support.
2. After the Postgres patch: check ltree and btree_gist indexes and pgcrypto data as described in the changelog.
3. Review tokens: replace old personal tokens with scoped tokens, and give agents and automation read-only access. On Team or Enterprise, set new members to "No access" by default.
4. Try Declarative Schemas on a test project, not directly in production. Read the drop statements carefully when you rename tables or columns.
5. Turn on Health Check Advisors and open Database Connections so you know how to read an incident before one happens.
6. Do not use alpha features in production: Multigres, Supabase Compute, Pipelines and local without Docker are not yet stable or not open to everyone.
7. If you use @supabase/server or supabase-js: move adapters before December 1 and upgrade TypeScript to 5.0 before January 31, 2027.
8. If you log heavily: watch your Logs usage before the grace period ends.