Supabase OrioleDB public beta (October 28, 2026): how to enable it, what is not supported yet, and whether RLS and grants change

By Ohad Krispin, founder of VibeRaven · LinkedIn

On October 28, 2026, Supabase put OrioleDB in public beta on every plan, billed the same as standard Postgres: a Postgres storage engine that writes the old version of an updated or deleted row to an undo log instead of leaving a dead tuple, so update-heavy tables do not bloat and need no VACUUM in most cases. You choose it only when you create a project (Create a new project > Advanced Configuration > Postgres Type > Postgres with OrioleDB), an existing project cannot be switched to it or back, and Supabase says the beta has no SLA and is not for production. Supabase says connection strings, Auth, Row Level Security policies and client libraries stay the same; the beta has no Point-in-Time Recovery, CLUSTER and VACUUM FULL do not work on OrioleDB tables, the image leaves out plv8, plls, plcoffee and timescaledb-apache, and pgvector HNSW indexes run through an experimental bridge. Checked against Supabase's announcement and OrioleDB docs on 2026-10-28.

What OrioleDB changes in how Postgres stores rows

Postgres's default storage, the heap, writes a new row version on every update and leaves the old one behind as a dead tuple, and the new version usually needs an entry in every index on the table. Autovacuum cleans up later and can fall behind on tables with many updates or deletes, so tables and indexes grow larger than the data they hold. OrioleDB replaces the heap through the table access method, Postgres's plug-in interface for storage engines.

Supabase lists four changes. Old row versions go to an undo log that is reclaimed automatically. OrioleDB tables use 64-bit transaction IDs, so they do not wrap around; system catalogs and any heap tables still use 32-bit IDs. Rows are stored inside the primary key index, and a table without a primary key gets a hidden one. Secondary indexes point to the primary key, so an update writes only to the indexes whose columns changed. The beta ships OrioleDB beta19 on Postgres 17.11.

Supabase says it helps most on tables that are updated or deleted often, such as order status, inventory counts, job queues and session data, on data sets larger than memory, and on primary key lookups. On its DBArena benchmark, with data four times larger than memory, an 8XL instance ran about 1.8x the transactions per minute of heap storage (113,850). With data that fits in memory the gap was smaller, and at the Small size heap came out ahead. Supabase recommends benchmarking your own workload.

How to enable OrioleDB on Supabase

In the Dashboard: Create a new project, expand Advanced Configuration, and under Postgres Type select Postgres with OrioleDB. In that project, new tables use OrioleDB by default, with a plain create table and no special syntax. For local development, initialize the project with Supabase CLI v2.119.0 or later:

supabase init --use-orioledb

Which tables use OrioleDB

Each table records its storage engine in pg_class.relam. OrioleDB's own docs create a table with USING orioledb, so an OrioleDB table shows orioledb in this list and a heap table shows heap. We ran it on plain Postgres 17 on 2026-10-28, where a table showed heap; we did not run it on an OrioleDB project.

select c.relname as table_name, am.amname as storage
from pg_class c
join pg_am am on am.oid = c.relam
where c.relnamespace = 'public'::regnamespace and c.relkind = 'r'
order by 1;

Do RLS policies and grants work the same?

Supabase's announcement says Row Level Security policies, Auth, connection strings and client libraries stay the same. Neither the announcement nor the OrioleDB docs mention GRANT. The table access method interface covers how rows are stored, scanned and written; privilege checks and row security policies are not part of it. We have not tested an OrioleDB project, so after your migrations run, compare the grants and the row level security flag with the same query on your current project (we ran it on plain Postgres 17 on 2026-10-28):

An OrioleDB project is a new project, so also check Integrations > Data API > Settings in it before your migrations run: whether new tables are exposed to the Data API is a project setting. See the October 30 Data API change.

select c.relname as table_name,
       c.relrowsecurity as rls_enabled,
       has_table_privilege('anon', c.oid, 'select') as anon_select,
       has_table_privilege('authenticated', c.oid, 'select') as authenticated_select
from pg_class c
where c.relnamespace = 'public'::regnamespace and c.relkind = 'r'
order by 1;

What is not supported in the public beta

From Supabase's list of things to know, and the current limitations in OrioleDB's own docs:

Not for production        no SLA during the public beta
Project creation only     cannot add OrioleDB to an existing project or remove it later
Backups                   no Point-in-Time Recovery, no restore to a new project
Indexes                   native B-tree is the fast path; other types (pgvector HNSW) use an experimental bridge
Commands                  CLUSTER, VACUUM FULL and a few others do not work on OrioleDB tables
Extensions                plv8, plls, plcoffee and timescaledb-apache are not in the image
SERIALIZABLE              locks each table it touches by default (orioledb.serializable = table_lock)
Multigres                 a project uses OrioleDB or Multigres, not both
Self-hosting              not in the self-hosted Supabase stack yet
Alpha projects            not migrated to the public beta; they keep running as they are
OrioleDB docs also list   no prepared transactions, no sample scans, sequences stay on heap

Trying it with an existing app

Because OrioleDB is chosen at project creation, trying it means a new project with your schema applied from your migrations. Anything you changed in the dashboard and never wrote to a migration, such as a policy or a grant, will be missing there; see whether your migrations match production. The announcement does not describe moving data from a heap project, and restoring a backup to a new project is not available in the beta.

supabase link --project-ref <orioledb-project-ref>
supabase db push

Checklist

Before you try OrioleDB

01Pick the tables that are updated or deleted most (status columns, counters, queues, sessions); those are where heap storage bloats.
02Check that the app does not depend on plv8, plls, plcoffee, timescaledb-apache, CLUSTER, VACUUM FULL or Point-in-Time Recovery.
03Create a new project with Postgres with OrioleDB, check its Data API settings, then apply your migrations with supabase db push.
04Run the two queries above: every table should show orioledb, and the RLS flag and grants should match your current project.
05Benchmark your own workload against a heap project of the same compute size before you decide.

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Can I switch my existing Supabase project to OrioleDB?

No. OrioleDB is chosen when you create a project; you cannot add it to an existing project or remove it later.

Does OrioleDB cost more on Supabase?

No. Supabase says it is billed the same as standard Postgres and is available on every plan.

Does pgvector work on OrioleDB?

pgvector HNSW indexes run through an experimental Index Access Method bridge, and Supabase says workloads that depend on them may not see gains yet.