Supabase Release Notes

OrioleDB is now in Public Beta. You can create OrioleDB projects on the Pro, Team, and Enterprise plans, not only Free. These projects get the same paid features as other Supabase projects, with the exceptions listed below. OrioleDB projects are billed the same as standard Postgres projects.

Public Beta is for testing. We don't recommend OrioleDB for production workloads yet, and it has no SLA.

What's new

You can create OrioleDB projects in organizations on paid plans, and upgrade an organization that has OrioleDB projects to a paid plan.

OrioleDB projects support compute and disk resizing, pause and restore, Postgres version upgrades, read replicas, and scheduled backups.

New OrioleDB projects run OrioleDB beta18 on Postgres 17.11.

The dashboard labels OrioleDB as Public Beta.

The Supabase CLI no longer requires --experimental to start a local project with OrioleDB.

How to use it

You choose OrioleDB when you create a project. You can't add OrioleDB to an existing project or remove it later.

Create a new Supabase project.

Expand Advanced Configuration.

Under Postgres Type, select Postgres with OrioleDB.

Finish creating the project.

For local development, run:

supabase init --use-orioledb

Limitations in Public Beta

Point-in-Time Recovery (PITR) isn't available for OrioleDB projects.

Restoring a backup to a new project isn't available for OrioleDB projects.

Native B-tree indexes give the best performance. Other index types, including pgvector HNSW indexes, run through an experimental bridge.

The OrioleDB image doesn't include plv8, plls, plcoffee, or timescaledb-apache.

Read the full list of OrioleDB limitations before you choose it for a project.

Existing OrioleDB alpha projects

We don't move existing alpha projects to the Public Beta. They keep running as they are.

Local development (CLI) and standalone OrioleDB images

These changes come from the supabase/postgres image 17.11.0.001-orioledb and later. They apply to:

• Local projects created with supabase init --use-orioledb on Supabase CLI v2.119.0 or later. The CLI sets db.orioledb_version in supabase/config.toml (previously experimental.orioledb_version, now deprecated).
• Anyone running the standalone supabase/postgres OrioleDB image directly.

OrioleDB isn't part of the self-hosted Supabase stack yet.

What changed in the image:

• Postgres moves from 17.9 to 17.11 (OrioleDB patch set 20 to 22).
• The OrioleDB extension moves from beta16 to beta18. beta18 bumps the extension SQL version to 1.10 and the WAL format from version 19 to 20. Read the beta18 release notes.
• The image sets output_plugin_libraries = 'pgoutput, test_decoding, wal2json'. The Postgres 17.11 build for OrioleDB only loads logical decoding output plugins on this list. Add the same line if you maintain your own postgresql.conf.

Why we built this

OrioleDB is an alternative storage engine for Postgres. It replaces the default heap storage through the Table Access Method interface. Old row versions go to an undo log instead of staying in the table, so Postgres reclaims dead rows without VACUUM. OrioleDB also uses 64-bit transaction IDs, which removes transaction ID wraparound.

Your project is still Postgres. You keep the same SQL, the same connection string, and the same Auth, Row Level Security, and client libraries.

In a benchmark derived from TPC-C on an 8XL compute instance (32 vCPU, 128 GiB RAM), with a data set larger than memory, OrioleDB completed about 1.8x more transactions per minute than heap storage. See the comparison. Clients connect directly over TLS on Postgres 17 with platform defaults and no think time. Results depend on the workload, so benchmark your own. Read the full methodology.

This workload is derived from the TPC-C Benchmark and is not comparable to published TPC-C Benchmark results, as this implementation does not comply with all requirements of the TPC-C Benchmark.

Original source

What's new

@supabase/middleware 1.0.0 is on npm and JSR under the latest tag. From 1.0 the package follows semantic versioning: breaking changes ship only in a new major.

It is a small, MIT-licensed engine for per-request logic on Web Fetch handlers:

• defineMiddleware writes one piece of per-request logic. It contributes one typed key to a shared ctx.
• pipeline([...], handler) runs several in order and returns the fetch handler. Middleware also nest directly, so pipeline is optional.
• The handler sees every upstream key, correctly typed. Duplicate keys fail to compile, and so does a middleware placed before its prerequisite.
• Any middleware can return a Response and stop the chain, or read and change the response on the way out.
• Two middleware ship with the engine: withCors and withFeatureFlag. Everything else is yours, or comes from a package.

The engine runs wherever fetch runs: Supabase Edge Functions, Vercel Functions, Cloudflare Workers, Deno, Bun, and Node 22 or newer. Inside Hono, H3, Elysia, NestJS, or TanStack Start, the same middleware runs through a short, typechecked bridge you copy into your app. No adapter package, no new dependency. See the frameworks guide.

@supabase/server is built on the engine and ships the Supabase middleware. withSupabase(config) with no handler is a pipeline entry; withSupabase(config, handler) wraps a single handler. Entries before it in the array run ahead of the auth gate, and entries after it receive the Supabase context. The @supabase/server/middleware/* subpaths export the pieces on their own: withClaims, withRequiredClaims, withSupabaseClient, withSupabaseAdminClient, withPostgresClient, and withPostgresAdminClient. withOAuthProtectedResource answers OAuth discovery for MCP clients. All of them are stable as of @supabase/server 1.9.0.

How to use it

1 npm install @supabase/middleware

On Edge Functions, import it directly. This example answers OAuth discovery for MCP clients, verifies the caller's token, and hands the handler a Supabase client scoped to that user. The Bring your own MCP guide builds a full MCP server on the same two entries:

import { pipeline } from 'npm:@supabase/middleware@1'
import { withOAuthProtectedResource, withSupabase } from 'npm:@supabase/server@1'

Deno. serve(
  pipeline(
    // 1. OAuth discovery for MCP clients, 2. verify the user's token and scope a client to them
    [
      withOAuthProtectedResource(),
      withSupabase({ auth: 'user' }),
    ],
    async (req, { supabase }) => {
      // RLS scopes this query to the signed-in user
      const { data } = await supabase.from('tasks').select('id, title')
      return Response.json(data)
    },
  )
)

Writing your own is one call:

import { defineMiddleware } from '@supabase/middleware'

const withRequestId = defineMiddleware<'requestId', void, Record<never, never>, string>({
  key: 'requestId',
  run: () => async (req) => ({
    requestId: req.headers.get('x-request-id') ?? crypto.randomUUID(),
  }),
})

The authoring guide covers prerequisites, the response seam, bundling several middleware into one, and publishing to npm and JSR.

Why we built this

Per-request logic is stuck where you wrote it. Move to a different runtime and you write it again. Adopt a framework and you rewrite it as that framework's middleware, which cannot leave that framework. Start a second project and you copy the file across. This is the code least worth rewriting: verifying a caller, scoping a database connection to them, handling CORS, checking a flag. It is fiddly, security-sensitive, and easy to get subtly wrong the second time.

@supabase/server has run on this engine since 1.5.1, released on August 31, 2026. withSupabase is a composite of single-key parts: the auth gate, claims, CORS, the Supabase client, the admin client. withOAuthProtectedResource handles the whole OAuth protected-resource flow an MCP client expects, and it is one entry in the pipeline. None of it uses a private API. What you get is the same primitive we use.

Original source

What changed

We are rolling out the PostgreSQL 15.19 / 17.11 minor release (from 15.14 / 17.6). It bundles five upstream security cycles and closes 44 CVEs. Four changes may require action, depending on how you use your database:

• ltree indexes may need reindexing — a case-folding fix on multibyte/ICU databases, plus an integer-overflow fix for very deep ltree values (any encoding).
• pgcrypto stops decrypting legacy-cipher PGP data (CVE-2026-14663) — data encrypted with cipher-algo=bf / blowfish / cast5 was effectively stored unencrypted and fails to decrypt by default after the upgrade.
• btree_gist indexes on float columns that may contain NaN need reindexing.
• Custom operators with non-built-in selectivity estimators (CVE-2026-2004) — recreating them (dump/restore, branching) now requires superuser.

If none of the detection queries below return rows for your project, no action is needed.

Why we made this change

This is an upstream PostgreSQL minor release. Staying current closes 44 CVEs (including several rated High) and picks up correctness fixes in the ltree and btree_gist extensions.

Who is affected

1. ltree indexes

Case-folding (multibyte/ICU)

After upgrading, indexes on ltree columns built under the previous version can silently return incomplete results on databases using a multibyte encoding (such as UTF-8) or a non-libc collation provider (ICU or builtin). Check whether your database is affected:

[SQL query to detect]

If reindex_required is true, find the affected indexes:

[SQL query to find indexes]

Integer overflow (any encoding)

This release also fixes an integer overflow in ltree comparisons: values with more than about 14,653 labels could compare incorrectly, which can corrupt B-tree indexes built over them, regardless of your database encoding. This query lists only the B-tree indexes that actually contain such values (an empty result means no action is needed):

[SQL query to detect]

2. pgcrypto legacy ciphers (CVE-2026-14663)

If you call pgp_sym_encrypt / pgp_pub_encrypt (or their _bytea variants) with cipher-algo=bf, cipher-algo=blowfish, or cipher-algo=cast5, that data was effectively stored unencrypted — decryption succeeds even with the wrong key. The default cipher (AES) and 3des are not affected. If you never passed a cipher-algo option, no action is needed.

To find affected rows, scan each stored value with a deliberately wrong passphrase: properly encrypted values raise an error, while affected values decrypt successfully even with the wrong key. Run the helper and the scan in the same session (pg_temp functions are session-scoped):

[SQL function and scan queries]

Any rows returned hold affected values. The scan covers symmetric (pgp_sym_*) messages. The wrong-key probe does not apply to public-key (pgp_pub_*) messages. If pgp_pub_encrypt was used with an affected cipher-algo, treat those values as affected and re-encrypt them the same way using pgp_pub_decrypt and pgp_pub_encrypt with the key pair.

3. btree_gist indexes on float columns

Indexes built under the previous version can return wrong results for rows containing NaN until reindexed. Find btree_gist indexes on float columns:

[SQL query to find indexes]

You are affected only if indexes are returned and those columns may contain NaN values.

4. Custom operators (CVE-2026-2004)

Only superusers may now attach a non-built-in selectivity estimator to an operator. Existing operators keep working. Only re-creation (dump/restore, branching, major-version upgrade) fails.

Operators installed by extensions (PostGIS, intarray, etc.) are not affected. Check for affected operators:

[SQL query to find operators]

What happens if you take no action

ltree / btree_gist: affected index searches may silently return wrong or incomplete results - no error is raised.

pgcrypto: decryption of affected messages fails by default after the upgrade (recoverable with the ignore-cipher-failure=1 decrypt option). The underlying data remains effectively unencrypted at rest until re-encrypted.

Custom operators: a future dump/restore, branch, or major-version upgrade fails to recreate the operator.

Migration steps

Run the detection queries above for each database.

After upgrading, reindex each affected ltree/btree_gist index using its schema-qualified name — REINDEX INDEX CONCURRENTLY .; runs online with no downtime, but cannot run inside a transaction block.

For pgcrypto: re-encrypt affected values with a modern cipher (for example cipher-algo=aes256), before the upgrade or after it using ignore-cipher-failure=1, and consider rotating secrets stored this way.

For custom operators: recreate without the RESTRICT / JOIN clause (or with a built-in estimator), or contact support and we'll assist.

Rollout timeline

Date Milestone User action
2026-09-25 Release announce (this entry) Run detection queries
2026-09-28 New projects created on 15.19 / 17.11 —
2026-09-28 Upgrade available in dashboard for existing projects Upgrade, then reindex if affected

Original source

When you run a backend on Supabase, we instrument it for you — logs come out of the box so you can monitor your services and debug issues without standing up separate infrastructure. We're continuing to invest in them. We're also announcing usage-based pricing early, because we'd rather give impacted projects time to adjust than hand anyone an unexpected bill. More than 90% of projects are within the included limits and won't be affected; for those that are, the grace period through early 2027 gives you time to understand and tune your usage before enforcement begins.

Background

We've been working for years to bring meaningful observability to Supabase developers — shipping Unified Logs, client trace integration, Log Drains, Observability Auto-Pilot, and Health Check Advisors, among other things. We'll keep going — more ways to surface logs meaningfully, more tools to help you monitor and debug, with or without an agent in the loop.

But as we've scaled to millions of projects, the infrastructure behind logs has scaled with us. Usage-based pricing is how we make sure we can keep building, in a way that's fair for everyone.

Usage-based pricing

That said, there are workloads where logs will scale with usage — and at platform scale, that needs to be priced fairly. We're introducing usage-based pricing for logs ingest (the volume of log data generated by your services) and a quota that scales with ingest for log query (the volume scanned when reading logs).

This is a soft launch: usage is now metered and visible in your project's usage dashboard, but limits are not yet enforced. A grace period runs through early 2027, giving you time to understand your usage before billing begins. More than 90% of projects are within the included limits and won't be impacted.

What we've done to control log volume

A significant part of this work has been changing default logging behavior across the Supabase stack, and giving you more control over your own:

• We've shipped fleet-wide changes to reduce noisy defaults — for example, disabling connection logging (log_connections) across most plans, which alone cut tens of millions of log rows per hour fleet-wide.
• Postgres log settings are configurable and often the biggest lever for teams running heavy query workloads. Settings like log_statement, log_min_duration_statement, and log_min_messages can dramatically reduce volume when tuned. See Postgres log settings and the log field reference to understand what each source captures.
• We've published guides to help you understand your usage and take action: Manage Logs Ingest and Manage Logs Query.

We'll keep adding controls. The goal is that the defaults are right for most projects, and that teams who need to go further have the tools to do it.

What's coming to Studio

Starting soon, your project's usage dashboard will show log ingest and query meters with an "Upcoming" label. If you approach your limits during the grace period, you'll see a warning in Supabase Studio — these are informational only, not enforcement actions.

Why we built this

Supabase has a healthy free tier, and we're committed to keeping it that way. Usage-based pricing makes that possible: when infrastructure costs reflect actual use, high-volume projects pay their share rather than that cost being spread across the fleet. It also lets us keep finding more meaningful ways to surface logs — better tools to understand, access, and act on what they're telling you, with or without an agent in the loop — in a way that's sustainable and fair for everyone, whether you're a hobbyist, a growing startup, or a large enterprise.

Share your feedback

This is a soft launch and we're actively seeking input. If you're notified about your usage during the grace period — or you have thoughts on pricing, limits, or the tooling — we'd love to hear from you. Visit our GitHub Discussion to share feedback directly with the team.

Original source

Pipelines destinations now live at Database > Pipelines in the Supabase Dashboard. This makes the page's purpose clearer now that read replicas are managed in Project Settings > Infrastructure.

What changes:

• Open Pipelines at Database > Pipelines
• Existing bookmarks and pipeline detail URLs under Database > Replication redirect to the matching Pipelines page

What stays the same:

• Pipelines destinations, configuration, and behavior
• Management API and database APIs
• Replication logs and Postgres replication terminology

See the Pipelines guide for setup and monitoring instructions.

Original source

Supabase Advisors already surface security misconfigurations and performance issues. They now also monitor service health, starting with error rates — the broadest early-warning signal across your stack.

What's in v1

Service error rate checks — read from log data, one per service:

• log_data_api_error_rate_high — PostgREST 5xx rate is elevated
• log_auth_error_rate_high — Auth service error rate is elevated
• log_storage_error_rate_high — Storage service error rate is elevated
• log_edge_function_error_rate_high — Edge Functions error rate is elevated

Error rate checks are designed to be a broad net. A single elevated result tells you where to look; from there you can drill into logs, query connection stats, or trigger your own deeper checks. This makes them particularly useful as a signal source for agents — an elevated rate check is a reliable catalyst for automated investigation flows.

An empty result means all checks ran and found nothing.

advisor_check_unavailable means a check could not run — so you can distinguish between healthy and unchecked.

Where to access them

Studio — a Health tab appears in the Advisors section of your project, above Security in the navigation. Each check result links directly to the relevant logs, connection stats, or infrastructure view.

Management API — POST /v2/projects/{ref}/advisors/run returns health check results alongside security and performance advisors. Results are cached to avoid repeated probing.

Get started

Open your project in Supabase Studio and go to Advisors → Health.

To query programmatically:

curl -X POST https://api.supabase.com/v2/projects/{ref}/advisors/run \
-H "Authorization: Bearer {token}"

What's next

v1 ships service error rate checks. Database connectivity probes and instance health checks are next on the roadmap.

If there are health signals you wish Supabase surfaced — specific error conditions, resource thresholds, connection patterns — reply in the GitHub Discussion linked below.

Original source

Hire an agent

Most attempts to use agents for monitoring fail for the same reason: the brief is too vague. "Monitor and fix" is not a job description. An expert needs a defined scope, the right data sources, and a clear format for what they report back.

We shipped a few things to make this even more powerful with Supabase's AI tooling.

The guide defines four roles, each with a prepared prompt and setup instructions for Claude Routines, Codex scheduled tasks, or Cursor Automations:

• Health — API and Auth error rates, connection pressure, instance state
• Security — Security Advisor findings, RLS gaps, Auth 4xx patterns
• Performance — slow queries, lock waits, long-running sessions, Performance Advisor
• Capacity — request, error, storage, and connection growth against baselines

Each prompt scopes the agent to a specific job, runs across a fresh context, and routes findings through your existing integrations — Linear, Slack, wherever your team tracks work. Copy the prompt as-is or adapt it. It runs in any environment that supports MCP, not just the ones listed.

The Supabase plugin

The MCP server already covers a broad range of Supabase tooling — database management, debugging, Edge Functions, branching, and more. A new query_logs tool extends that with structured access to logs across all services: API, Auth, Storage, Edge Functions, and Postgres. Everything you'd debug with a SQL query against your instance, your agent can now reach through MCP.

The agent skills pair with that data: they teach agents how to use Supabase correctly, pulling from a docs structure rebuilt so agents find the right material reliably. More knowledge on what the data means and where to look.

Both are part of the Supabase plugin — the MCP server and skills bundled for a single install.

Get started

Read the Hire an agent guide, pick a role, and copy the prepared prompt into your environment of choice. To use the full Supabase toolset, install the plugin from the AI tools page.

Original source

Read replica management now lives on Project Settings → Infrastructure, next to compute and disk. Database → Replication is for Pipelines destinations only.

What stays the same:

• Creating, dropping, and managing replicas
• The Management API
• Read replica docs (updated for the new location)

What changes in the Dashboard:

• Open Project Settings → Infrastructure to list replicas, open the topology, and add a replica
• Old replica detail URLs redirect to Infrastructure
• Bookmarks that used ?destinationType=Read+Replica on Replication open the Infrastructure add-replica flow
• Replication shows a short note pointing to Infrastructure for anyone who still opens that page looking for replicas

See the getting started guide for the updated create path.

Original source

The job that schedules daily backups checks which projects are due on a strict time budget. Under database replica lag, that check could exceed its budget, and with no retry in place the whole 10-minute scheduling window was silently dropped fleet-wide — any project due in that window missed its backup for the day.

Backup scheduling now retries on failure, anchored to its original scheduled window so a retry can't skip or re-scan the wrong projects, reads eligibility from the primary database instead of a replica to avoid the lag that triggered the timeout, and no longer lets a project in an unroutable region crash the whole scheduling run. A companion fix (supabase/platform#36499) addresses the underlying slow query.

Original source

A WAL-G physical restore restores the whole PGDATA directory, including pg_authid, so credentials from the backup snapshot overwrote any password rotated after that backup was taken.

Credential reapplication was previously only queued when a restore was part of an in-progress clone, so a plain restore to the same project, or an unpause (which shares the same completion path), skipped it entirely and could leave db_user with a stale password. Logical restores are unaffected:

pg_dumpall runs with --no-role-passwords, so a logical backup never carries password hashes to begin with.

Supabase now reapplies current credentials after every physical restore completes, regardless of whether it is part of a clone.

A related fix also closes a data-loss path in cloning status tracking: reapplying credentials for a non-clone restore could, on retry exhaustion, flip an unrelated and already-completed clone's status back to failed, which could let a later stray clone request overwrite that project's data. Status transitions are now scoped to clones that are actually in progress.

Original source

The logs.all Management API endpoint is being removed on 23rd September 2026 (Wednesday), two months from this announcement. Log querying moves to a new ClickHouse-backed logs endpoint. The new endpoint accepts ClickHouse SQL only. It returns every source through a single unified logs table instead of a separate table per source.

How Do I Know if This Impacts Me?

You are impacted only if you query the logs.all Management API endpoint (.../analytics/endpoints/logs.all). This includes any scripts, integrations, or tooling that call it directly.

If you do not call this endpoint, no action is needed. Using logs through the dashboard Logs Explorer is not affected.

What Should I Do?

• Update the endpoint path from analytics/endpoints/logs.all to analytics/endpoints/logs.
• Convert your SQL to the ClickHouse dialect. The endpoint only accepts ClickHouse SQL.
• Filter by source_name instead of selecting a source table. All sources now live in one logs table. Filter to a specific source in the WHERE clause.

Before (query a source table directly):

SELECT timestamp, event_message
FROM edge_logs
ORDER BY timestamp DESC
LIMIT 100

After (filter the unified stream by source_name):

SELECT timestamp, event_message
FROM logs
WHERE source_name = 'edge_logs'
ORDER BY timestamp DESC
LIMIT 100

Any query that previously targeted a specific table must now add a source_name filter in its WHERE clause.

Accessing Nested Fields

Nested fields move from the metadata array to a flat log_attributes map. Before, you added one CROSS JOIN unnest() per level of nesting to reach a field. Now you read the field directly from log_attributes with map key access. The joins go away.

Before (unnest each level of metadata):

SELECT timestamp, request.method, header.x_real_ip
FROM edge_logs
CROSS JOIN unnest(metadata) AS m
CROSS JOIN unnest(m.request) AS request
CROSS JOIN unnest(request.headers) AS header

After (read from the log_attributes map):

SELECT
  timestamp,
  log_attributes['request.method'] AS method,
  log_attributes['request.headers.x_real_ip'] AS x_real_ip
FROM logs
WHERE source_name = 'edge_logs'

Timeline

Date Change 23 July 2026 Changelog published 23 September 2026 logs.all endpoint removed for all projects

Learn More

• Management API reference: the logs endpoint and its parameters
• Logs & querying documentation: available sources and ClickHouse SQL query examples

Original source

Starting 2026-08-05, specifying an explicit version when creating or updating a Postgres extension on Supabase is deprecated. Statements like:

1 create extension pgvector version '0.7.0';
2 alter extension pg_graphql update to '1.5.9';

will still succeed, but the requested version is now ignored: the extension is installed at (or updated to) its current default version on your project's Postgres instance, and the statement emits a warning:

WARNING: only superusers can specify extension versions, ignoring version "0.7.0" and installing the default version

In a future release, announced separately in advance, these statements will be rejected with an error instead.

Why we're making this change

Supabase instances ship multiple versions of some extensions side by side. Allowing any role to install or downgrade to an older version means projects can end up running extension versions with known security issues — including reintroducing vulnerabilities that were already patched in the default version. Pinning versions is now reserved for platform operations.

What's not affected

• Extensions you've already installed — nothing changes on running databases.
• create extension / alter extension ... update without a version clause.
• Database backups and restores (pg_dump output never includes version clauses).
• Installing extensions from the dashboard.

Original source

Stream Postgres changes to BigQuery in near real time with Supabase Pipelines, a managed CDC service configured right in the Dashboard. Now in public alpha on all paid plans.

What's new

Supabase Pipelines is a managed change-data-capture service, powered by the open-source Supabase ETL engine, that streams changes from your Supabase Postgres database to external destinations in near real time. You pick a destination in the Dashboard, and Supabase runs and monitors the pipeline that keeps it in sync, reading directly from the Postgres write-ahead log.

What you can do

• Near real-time streaming — a complete initial copy of your selected tables, then near real-time replication of inserts, updates, deletes, and truncates, with at-least-once delivery.
• Granular control over what's replicated — publish specific tables, a whole schema, or all tables. Narrow to column subsets, filter rows with a WHERE clause, and handle partitioned tables.
• Automatic schema change support — supported changes (adding, removing, and renaming columns, and changing nullability and defaults) are detected and applied to the destination automatically.
• Full Dashboard management — create, start, stop, and restart pipelines, add or remove tables without restarting replication from scratch, and tune advanced settings like batch wait time, sync workers, and slot recovery.
• Monitoring — track pipeline status, metrics, and logs from the Dashboard.
• Reliable recovery — replication resumes from the last acknowledged position after a restart, detecting and recovering from many transient failures automatically while surfacing issues that require intervention.
• Workload isolation — replicate to an analytical destination so heavy queries run there, not on your production database.

Destinations: BigQuery is the first destination available to everyone in public alpha. ClickHouse, Snowflake, and DuckLake are available on request through the early access form.

Pricing during the public alpha: $0.053 per hour per active pipeline, $0.60/GB for the initial table copy, and $3/GB for replicated data after that.

How to use it

• Open the Dashboard and choose the tables to replicate.
• Pick a destination — BigQuery, at launch (or request ClickHouse, Snowflake, or DuckLake through the early access form).
• Pipelines runs an initial copy of the selected tables, parallelized across and within tables for faster loading.
• After the copy completes, the pipeline switches to streaming mode. New changes are read from the replication slot, batched, and written to the destination.
• Supported schema changes are detected and applied to the destination automatically.

Data is replicated as-is, without transformation.

Why we built this

Postgres is excellent for transactional workloads: reading a user profile, inserting an order, updating a subscription, or serving your application.

Analytics workloads are different. They often scan large amounts of data, aggregate across many rows, and power dashboards, reports, notebooks, and downstream systems. Running those queries directly on your production database can add load to the same system your application depends on.

Supabase Pipelines gives you a reliable way to move production data into systems built for analytics, while keeping your application workload on Postgres.

Affected products: ETL

Authored by @jhydra12

Original source