Reference · built on requestConnectorDatabases & warehouses

Supabase

Hosted Postgres tables through Supabase's REST and GraphQL APIs, Realtime change streams, Database Webhooks, and the Management API.

Request accessPricing ↗

About

Supabase hosts a Postgres database per project and generates its APIs from the schema. PostgREST serves tables, views, and functions at https://<project_ref>.supabase.co/rest/v1/; pg_graphql serves the same schema at /graphql/v1; both enforce Postgres Row Level Security. Realtime streams INSERT, UPDATE, and DELETE events for tables added to the supabase_realtime publication. Database Webhooks wrap triggers with pg_net to POST a JSON payload to an HTTP endpoint or Edge Function after a row changes. Direct Postgres access runs on port 5432, with a shared pooler in session mode on 5432 and transaction mode on 6543.

An operator on Fibric reads through Supabase's REST API or a webhook and proposes row writes for your approval, each with a receipt and undo.

This is a reference listing. It documents what Fibric would read from Supabase and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Rows from tables and views through /rest/v1/, including nested relationships between tables
  • Realtime Postgres Changes for INSERT, UPDATE, DELETE, or *, per table in the supabase_realtime publication
  • Old row values on UPDATE and DELETE when the table has replica identity full
  • Database Webhook payloads with type, table, schema, record, and old_record, delivered after the row changes
  • GraphQL queries against the schema at /graphql/v1 through pg_graphql
  • Project, database, function, and secret records from the Management API at https://api.supabase.com

Proposed actions

  • Target capability: propose a row insert or update through /rest/v1/, sent with the secret key only after approval
  • Target capability: propose adding a table to the supabase_realtime publication or setting replica identity full
  • Target capability: propose creating a Database Webhook on a table for INSERT, UPDATE, or DELETE

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • React to a new order row within seconds

    Point a Database Webhook at the operator's endpoint for INSERT on the orders table and process the record field from each payload.

    With Order Risk, Webhook Replay

  • Answer a question from the app's own tables

    Query /rest/v1/ with the reviewer's role so Row Level Security limits what the operator can see, and show the rows behind the answer.

    With Operations Analyst

  • Check that the change stream is healthy

    Compare webhook call history in the net schema with expected volume and flag a table whose trigger has gone quiet.

    With Integration Health, Data Freshness

Requirements

  • A Supabase project with the tables exposed to the Data API and Row Level Security policies that permit the connector's role
  • A secret key kept on the server side; the service_role JWT bypasses Row Level Security and must never reach a client
  • Tables added to the supabase_realtime publication, and replica identity full where old records or DELETE filters are needed
  • For direct Postgres connections, IPv6 reach or the IPv4 add-on, or the shared pooler host
Authentication
A project publishable key (sb_publishable_...) or secret key (sb_secret_...) in the apikey header, or the legacy anon and service_role JWTs; the Management API takes a personal access token or OAuth2 token as Authorization: Bearer.

Limits

  • Realtime handles Postgres Changes on a single thread to preserve order; larger compute does not raise throughput, and every event is authorized per subscriber
  • Row Level Security is not applied to DELETE events, and DELETE events can only be filtered when replica identity is full
  • Legacy anon and service_role keys are deprecated, with removal planned by the end of 2026
  • The Management API allows 120 requests per minute per user; some endpoints are capped lower

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Supabase ↗

Questions and answers

Which key should a server-side connector use?
A secret key, sb_secret_..., sent in the apikey header; it is not a JWT, so Authorization: Bearer verification fails on it. The legacy service_role JWT still works but bypasses Row Level Security and is deprecated. Publishable keys are for client code.
Why does a DELETE event arrive without the old row?
Realtime only sends previous values when the table's replica identity is full: alter table <name> replica identity full. Without it, Postgres has no old record to include, and delete events cannot be filtered. Row Level Security is also not applied to DELETE.
How do Database Webhooks differ from Realtime?
Webhooks are triggers wrapped around pg_net: after INSERT, UPDATE, or DELETE they POST a JSON payload to an HTTP endpoint or Edge Function and log the call in the net schema. Realtime is a subscription that authorizes every event against each subscriber before delivery.
Ask about Supabase

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Supabase through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy