Real-time data replication to Supabase from your operational databases

• Application teams building on Supabase who need the data of the systems of record in public or in their own schemas, ready for the Supabase client libraries, APIs, and dashboards
• Platform leads who want one Core Hub for every source feeding Supabase instead of one sync script per database, backed by best-in-class enterprise support, rated 4.9/5 by customers
• Architects who need ingestion that works with the project as Supabase runs it: the standard postgres role, TLS only, row level security on the tables, and extension types such as vector and PostGIS
• Engineers replacing scheduled extracts, Debezium with a JDBC sink, or custom loaders that exist only to fill Supabase, who want every source delivered by one product with snapshots and monitoring built in

The PostgreSQL write path, with Supabase's connection defaults

Supabase is PostgreSQL, so the Supabase agent is the PostgreSQL target with Supabase's defaults: it connects through the bundled PostgreSQL JDBC driver to database postgres as user postgres, with TLS on. It is a target agent: it applies the change stream from any Gluesync source agent in real time, in commit order per entity, after a snapshot seeds each table.

• Same type mapping: values are written with the PostgreSQL target's type mapping, including enum types, arrays, and extension types.
• Optimized batches, never row by row: changes are grouped into JDBC batches, and a connection pool is on by default so several pipelines share the project's connections.
• Native bulk load: rows can go through PostgreSQL's COPY, for snapshots and for CDC, as described below.
• Database connection only: Gluesync calls neither the Supabase REST API nor the management API. Supabase agent overview ↗

COPY bulk loads for snapshots and CDC

With bulk load on, the agent stages rows with COPY in a table of the GLUESYNC schema and merges them into the target table, for the snapshot and for the change stream. Rows never go through single-row SQL.

In each CDC cycle with bulk operations on, an update is applied as a DELETE of the existing row plus an INSERT of the new version, in one pass from the staging table. Entities whose target table has an identity column apply their updates as UPDATE statements.

• Seed, then stream: each entity loads its full table, then follows the source agent's change mechanism.
• TRUNCATE before snapshot: the option for a clean reload is supported on the target tables.
• Scheduled reloads: the Chronos scheduler runs a snapshot, or a snapshot followed by CDC, on a cadence for tables you refresh on a timetable. See schedules and events.

Tables, schemas, and Supabase features

Target tables live in public or in the schemas you created. When a table does not exist, Core Hub generates a CREATE TABLE from the source definition, and the agent writes any table in the project that the connection user owns or can write to, including tables you created in a Supabase migration.

• Managed schemas stay out of the way: the schemas Supabase manages for itself, such as auth, storage, realtime, vault, extensions, and graphql, are system schemas for discovery in Core Hub, so auth.users and its password hashes are never read. Your own tables are discovered as usual.
• Row level security: tables with row level security enabled are written. The postgres role bypasses it on Supabase, so a table needs no policy for Gluesync, also with forced row level security.
• Extension types: vector from pgvector, geometry, geography, and raster from PostGIS, and hstore are written on snapshot and CDC.

Data types

The type coverage is the PostgreSQL target's, written as column values and as primary keys through snapshots and CDC, with binary and text COPY and with batch statements.

• Numbers and booleans: smallint, integer, bigint, the serial types, boolean, numeric and decimal with and without precision, money, real, and double precision, with NaN and infinity.
• Dates and times: date, time, timetz, timestamp, timestamptz, and interval, with dates before 1582 keeping their value.
• Text and documents: varchar, char, text, json, jsonb, xml, uuid, enum types, tsvector, and tsquery.
• Binary, network, geometric, and ranges: bytea and bit strings, inet, cidr, and macaddr, the geometric types, and the range and multirange types.
• Arrays of all of the above, such as integer[], text[], uuid[], and jsonb[].

Setup in your Supabase project

The agent needs the database connection details from the Connect page of the Supabase dashboard and the password of the database user. The postgres role is enough: the agent creates its GLUESYNC schema and staging tables as that role. Full settings are in the Supabase target setup guide ↗.

1. Choose the connection: the direct connection, db.<project-ref>.supabase.co on port 5432 with user postgres, or the session pooler, aws-0-<region>.pooler.supabase.com on port 5432 with user postgres.<project-ref>. Use the session pooler when Core Hub has IPv4 connectivity only.
2. In Core Hub, enter the host, port 5432, database postgres, and the user and password of the project.
3. Keep TLS on, which is the default and matches Supabase's enforced SSL. To verify the server certificate, turn off Trust server certificate and provide a trust store with the project's CA certificate from the Supabase dashboard.
4. Map each entity to a table, or let Core Hub create the tables from the source definition. Gluesync starts with a snapshot and then follows the changes.

Architecture around Core Hub

Source agents sit close to each database, and Core Hub orchestrates them through its web UI and REST APIs. A pipeline groups a source agent with the Supabase agent and the tables it replicates. The agent keeps no local state: writes go straight to your Supabase Postgres tables, and pipeline state lives in Core Hub metadata. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes. See CDC streaming for the wider pattern.

Explore the general CDC streaming architecture →

Any Gluesync source agent can feed Supabase, each with its own native capture technique. Open the integrations finder with Supabase pre-selected to see every source that pairs with it.

One Core Hub runs Oracle to Supabase, SQL Server to Supabase, and MongoDB to Supabase pipelines side by side, with the same snapshot, monitoring, and write settings for each. Gluesync keeps pace with your change volume at any scale, and MOLO17 Professional Services can help with schema design and the choice of write path for each table.

• Oracle to Supabase from the redo logs through LogMiner or XStream: see Oracle CDC
• SQL Server to Supabase through Change Data Capture or Change Tracking: see SQL Server CDC
• MySQL to Supabase from the binary log: see MySQL CDC
• PostgreSQL to Supabase from the write-ahead log: see PostgreSQL CDC
• MongoDB to Supabase from change streams: see MongoDB CDC