What happens when two coding agents use the same local Supabase database? Test data created by one can get mixed into the other's work. To reduce this problem, Supabase is experimenting with Docker-free local runs and multiple isolated stacks. It doesn't, however, automatically separate agents that run from the same repository and branch.
Supabase Compute, for agents and services that run for long periods, has also been announced, but it is currently in private alpha. OrioleDB, a Postgres storage engine, has entered public beta. The up-to-1.8x throughput mentioned in the announcement comes from a specific server and a TPC-C-derived test. You can't assume your own workload will see the same difference.
What changes when you run locally without Docker?
The new runtime runs Supabase services as native processes on your computer rather than in containers. That is welcome news for teams that want to start local development without installing or managing Docker. It is still an alpha feature, and the setting is off by default. You need Supabase CLI 2.119.0 or later, and you should also check that your operating system and architecture are supported. Because it is alpha, settings and behavior may change. You can find the details in the Supabase announcement and the local projects guide.
Multiple instances are separated by project path, Git branch, and, if you need it, a --stack name you specify. Each stack uses its own ports and data directory. If you create a worktree for each agent or specify different stack names, you can set up independent local environments.
There is an easy-to-miss point here. Running in parallel from the same checkout and branch doesn't isolate automatically, and the Supabase config directory can be shared. If you need to run several instances at once, the Docker or Podman approach is recommended. When you use the native runtime, separate your workspaces first and check the support conditions. For an agent-centered development flow, see GitHub Spec Kit's step-by-step development approach, and for an example of handling several agents in one environment, the Spotify Xirp case.
Compute for keeping agents running in the cloud
After you finish local development, you may want to keep running agents or background services close to the database. Supabase Compute targets that use. It lets you deploy HTTP services, background jobs, and isolated execution environments on Linux in the language you want, and choose CPU and memory. It was introduced as letting you check runtime status, calls, and logs in the dashboard and use an agent skill for Compute to help with monitoring and debugging.
It isn't a generally available service anyone can use right away, though. For now it is a private alpha that takes a waitlist. Deployment and management are described through the CLI and the Management API. You should keep the dashboard's and skill's observation and debugging features separate from MCP management features. Check the current access stage on the Supabase Compute page.
Connecting an MCP server to your own app is a separate flow. It is implemented with an authenticated Edge Function and gives access to data according to the signed-in user's permissions and RLS. It is different from MCP for project management and from Compute monitoring. If you're curious about an example of an MCP server for an app, see also ChatGPT Sites' MCP extension.
OrioleDB beta: can you turn it on for an existing project?
OrioleDB is a storage engine that replaces Heap, Postgres's default storage method. You have to choose it when you create a new Supabase project, and you can't add or remove it on an existing project later. It has entered public beta, but production use is not recommended and no SLA is offered.
You should also check recovery and compatibility conditions first. It doesn't support PITR (point-in-time recovery), and restoring a backup into a new project isn't offered either. Indexes other than B-tree are limited, and some extensions are missing from the provided image. It is also not yet included in the full self-hosted Supabase stack. Before adopting it, check the supported scope in the public beta changelog and the OrioleDB docs.
What test did "up to 1.8x" come from?
Supabase compared the throughput of OrioleDB and the default Postgres Heap. The test used an 8XL compute instance (32 vCPUs, 128 GiB of memory) and a dataset larger than memory, connecting directly to PostgreSQL 17 over TLS. It ran a TPC-C-derived workload with no think time on the platform's default settings and compared transactions per minute (tpmC), and OrioleDB recorded about 1.8x.
It is hard to apply this figure as is to every environment. The test is derived from TPC-C but doesn't follow the full official specification, so it can't be compared directly with an official TPC-C score. If the server specs, data, or queries change, so will the result. If you are considering adoption, measuring with your own workload separately is more accurate. You can see the detailed conditions and charts in the Supabase OrioleDB docs.
Check first whether the feature fits your work
Docker-free native runs and multiple stacks are still alpha and experimental features. You have to split paths, branches, and stack names explicitly for each agent to keep data from mixing. Compute is a private alpha at the waitlist stage, and OrioleDB is a public beta, but you can't expect production guarantees or conversion of an existing project.
First, try separating your local agents' workspaces. For OrioleDB, check the recovery method and extension compatibility, then measure performance in a test project. Your own service's data and queries are a more direct basis for judgment than the numbers in the announcement.