Canonical: https://molo17.com/solutions/replicate-to-supabase/ Markdown mirror: https://molo17.com/solutions/replicate-to-supabase/index.md Title: Replicate to Supabase in real time with Gluesync | MOLO17 Description: Real-time replication into Supabase Postgres from Oracle, SQL Server, MySQL, MongoDB, and PostgreSQL, with TLS by default and COPY bulk loads. Start a trial. [Solutions](/solutions/) Replicate to Supabase SOLUTION · REPLICATE TO SUPABASE # Real-time data replication to Supabase from your operational databases **Committed changes from your systems of record land in Supabase Postgres continuously, over TLS and through the same batch and COPY write path as PostgreSQL, instead of waiting for the next sync job.** Gluesync by MOLO17 captures changes from Oracle, SQL Server, MySQL, MongoDB, PostgreSQL, and other [heterogeneous sources](/integrations/?target=Supabase#integration-finder) with a dedicated agent per database, then writes them into the tables of your Supabase project. The Supabase agent speaks the PostgreSQL wire protocol and needs only a database connection, so it works with projects hosted on supabase.com and with self-hosted Supabase. Core Hub, the Gluesync control plane, runs snapshots and CDC for every pipeline from one web UI and REST API. [Start a Gluesync trial](/get-gluesync/) [Talk to us](/contacts/) WHO THIS IS FOR ## Teams that want Supabase to hold current operational data, not last night's extract - 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](/support/#customer-ratings) - 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](/integrations/?target=Supabase#integration-finder) delivered by one product with snapshots and monitoring built in THE PROBLEM ## A Supabase project fed by scheduled loads is always behind the source Most Supabase projects that mirror an operational database are filled by a script: a job queries the source on a timer, writes files or staging tables, and merges them in. Apps and dashboards then show the last run, each run adds read load to production, and every new source adds a job and the credentials to reach it. Teams looking for real-time Supabase ingestion or a CDC feed into Supabase Postgres usually weigh managed ELT from Fivetran or Airbyte, a Debezium and Kafka Connect chain with a JDBC sink, or scripts they maintain themselves. Gluesync addresses that with **per-agent CDC into Supabase**. A source agent reads each database's native change log or change stream, Core Hub routes the changes, and the Supabase agent applies them to your tables with JDBC batches or COPY bulk loads. Oracle to Supabase, SQL Server to Supabase, and MongoDB to Supabase pipelines share the same model, the same snapshot, and the same operations. HOW IT WORKS ## How Gluesync writes to Supabase ### 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 ↗](https://docs.molo17.com/gluesync/latest/agents/supabase-intro.html) ### 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](/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 ↗](https://docs.molo17.com/gluesync/latest/agents/supabase-target.html). 1. Choose the connection: the direct connection, `db..supabase.co` on port 5432 with user `postgres`, or the session pooler, `aws-0-.pooler.supabase.com` on port 5432 with user `postgres.`. 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](/solutions/cdc-streaming/) for the wider pattern. [Explore the general CDC streaming architecture →](/solutions/cdc-streaming/) WRITE OPTIONS ## The Supabase target agent: one agent, the PostgreSQL write path Supabase has one Gluesync target agent. It writes snapshots and CDC changes into Supabase Postgres tables over the PostgreSQL wire protocol, with JDBC batches and COPY bulk loads. | Agent | Write technique | Versions | Best for | | --- | --- | --- | --- | | [Supabase agent ↗](https://docs.molo17.com/gluesync/latest/agents/supabase-intro.html) | Bundled PostgreSQL JDBC driver over the PostgreSQL wire protocol, with TLS on by default; optimized batches, and `COPY` bulk load through a staging table for snapshots and CDC | Supabase Postgres 15 and later, hosted or self-hosted; tested on Supabase Postgres 17.6 | Teams feeding a Supabase project from Oracle, SQL Server, MySQL, MongoDB, or PostgreSQL, over the direct connection or the session pooler, with TLS, row level security, and extension types supported. | SOURCES AND TOPOLOGIES ## Feed Supabase from the systems of record you already run Any Gluesync source agent can feed Supabase, each with its own native capture technique. Open the [integrations finder with Supabase pre-selected](/integrations/?target=Supabase#integration-finder) 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](/solutions/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](/solutions/oracle-cdc/) - SQL Server to Supabase through Change Data Capture or Change Tracking: see [SQL Server CDC](/solutions/sql-server-cdc/) - MySQL to Supabase from the binary log: see [MySQL CDC](/solutions/mysql-cdc/) - PostgreSQL to Supabase from the write-ahead log: see [PostgreSQL CDC](/solutions/postgresql-cdc/) - MongoDB to Supabase from change streams: see [MongoDB CDC](/solutions/mongodb-cdc/) FAIR, HIGH-LEVEL COMPARISON ## Where Gluesync fits among Supabase ingestion approaches | Approach | What buyers usually get | Where Gluesync fits | | --- | --- | --- | | Fivetran, Airbyte, and other ELT tools | Managed or open-source connectors with Postgres destinations that load on a sync schedule; change capture varies by source connector | Log-based capture with a commercial agent per source and MOLO17 enterprise support, writing continuously rather than on a sync schedule | | Debezium with Kafka Connect and a JDBC sink | Open-source capture into Kafka topics, then a JDBC sink that writes rows into Postgres; you run Connect, offsets, and schema changes, and usually a merge step into current-state tables | Changes applied to Supabase tables by key, with no Kafka cluster in the path. Read the [Debezium alternative](/solutions/debezium-alternative/) comparison | | AWS DMS, Qlik Replicate, and Striim | Commercial replication services with Postgres among their targets; capture and load options differ by product and version | Agents deployed next to each source, native capture per engine, and COPY bulk cycles into Supabase, all run from one Core Hub | | Scheduled scripts and custom loaders | Full control; your team owns the extract queries, staging files, merge logic, retries, and the load each run puts on the source database | Log-based capture with no polling queries against production, staged bulk cycles, and snapshot restarts handled by the agent; see [migrating to Gluesync](/migrate-to-gluesync/) | RELATED CONTENT ## Supabase replication research and implementation detail - [Batch ETL vs real-time data replication: how to choose](/blog/batch-etl-vs-real-time-data-replication/) - [Log-based CDC: how real-time replication works](/blog/real-time-replication-log-based-cdc/) - [CDC streaming without source overhead](/solutions/cdc-streaming/) - [Debezium alternative: managed CDC versus Kafka + Debezium](/solutions/debezium-alternative/) - [Replicate to PostgreSQL](/solutions/replicate-to-postgresql/) - [Supabase agent overview ↗](https://docs.molo17.com/gluesync/latest/agents/supabase-intro.html) - [Supabase target setup guide ↗](https://docs.molo17.com/gluesync/latest/agents/supabase-target.html) - [Supabase agent changelog ↗](https://docs.molo17.com/gluesync/latest/agents/supabase-agent-changelog.html) - [Bulk load: staging, COPY, and apply phases ↗](https://docs.molo17.com/gluesync/latest/core-hub/bulk-load.html) FAQ ## Supabase replication questions What does replicating to Supabase with Gluesync involve? A Gluesync source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and the Supabase agent writes them into Supabase Postgres tables. Each table is seeded with a snapshot first and then follows the change stream. How does Gluesync write data into Supabase? Through the bundled PostgreSQL JDBC driver over the PostgreSQL wire protocol, with the PostgreSQL target's type mapping. Changes go in optimized batches, and COPY bulk load into a staging table is available for snapshots and for CDC. Does Gluesync use the Supabase API? No. The agent needs only a database connection, so it works with projects hosted on supabase.com and with self-hosted Supabase. It calls neither the Supabase REST API nor the management API. Which Supabase connection should I use? The direct connection on port 5432 with user postgres, or the session pooler on port 5432 with user postgres.. The direct connection is the recommended one, and the session pooler suits a Core Hub that has IPv4 connectivity only. Is the connection encrypted? Yes. TLS is on by default, matching Supabase's enforced SSL. Turn off Trust server certificate and provide a trust store with the project's CA certificate to verify the server certificate. Which Supabase versions are supported? Supabase Postgres 15 and later, hosted or self-hosted. MOLO17 tests the agent against Supabase Postgres 17.6. Does the agent work with row level security and extension types? Yes. Tables with row level security are written, because the postgres role bypasses it on Supabase. Columns of type vector, geometry, geography, raster, and hstore are written on snapshot and CDC. Will Gluesync read the auth schema or other Supabase-managed schemas? No. The schemas Supabase manages for itself, such as auth, storage, realtime, vault, extensions, and graphql, are treated as system schemas for discovery in Core Hub, so auth.users and its password hashes are never read. Your own tables are discovered as usual. Does Gluesync create the tables in Supabase? Yes. When a target table is missing, Core Hub generates a CREATE TABLE from the source definition. Tables you created yourself, for example in a Supabase migration, are written as they are. Which sources can replicate to Supabase? Any Gluesync source agent. Oracle, SQL Server, MySQL, PostgreSQL, and MongoDB can all feed Supabase, and each one uses its own native capture technique. REPLICATE TO A TARGET ## Other targets Gluesync delivers to - [Replicate to Aerospike](/solutions/replicate-to-aerospike/) - [Replicate to DynamoDB](/solutions/replicate-to-dynamodb/) - [Replicate to Redshift](/solutions/replicate-to-redshift/) - [Replicate to Amazon S3 & S3-compatible](/solutions/replicate-to-amazon-s3/) - [Replicate to Cassandra](/solutions/replicate-to-cassandra/) - [Replicate to Kafka](/solutions/replicate-to-kafka/) - [Replicate to Cosmos DB](/solutions/replicate-to-cosmos-db/) - [Replicate to Azure Data Lake](/solutions/replicate-to-azure-data-lake/) - [Replicate to ClickHouse](/solutions/replicate-to-clickhouse/) - [Replicate to CockroachDB](/solutions/replicate-to-cockroachdb/) - [Replicate to Couchbase](/solutions/replicate-to-couchbase/) - [Replicate to Databricks](/solutions/replicate-to-databricks/) - [Replicate to Elasticsearch and OpenSearch](/solutions/replicate-to-elasticsearch/) - [Replicate to file stores](/solutions/replicate-to-file-stores/) - [Replicate to BigQuery](/solutions/replicate-to-bigquery/) - [Replicate to Google Cloud Storage](/solutions/replicate-to-google-cloud-storage/) - [Replicate to Google Pub/Sub](/solutions/replicate-to-google-pubsub/) - [Replicate to GridGain](/solutions/replicate-to-gridgain/) - [Replicate to Db2](/solutions/replicate-to-db2/) - [Replicate to Informix](/solutions/replicate-to-informix/) - [Replicate to MariaDB](/solutions/replicate-to-mariadb/) - [Replicate to Microsoft Fabric](/solutions/replicate-to-microsoft-fabric/) - [Replicate to SQL Server](/solutions/replicate-to-sql-server/) - [Replicate to MongoDB](/solutions/replicate-to-mongodb/) - [Replicate to MySQL](/solutions/replicate-to-mysql/) - [Replicate to Oracle](/solutions/replicate-to-oracle/) - [Replicate to PostgreSQL](/solutions/replicate-to-postgresql/) - [Replicate to RavenDB](/solutions/replicate-to-ravendb/) - [Replicate to Redis](/solutions/replicate-to-redis/) - [Replicate to Redis Streams](/solutions/replicate-to-redis-streams/) - [Replicate to SAP ASE](/solutions/replicate-to-sap-ase/) - [Replicate to SAP HANA](/solutions/replicate-to-sap-hana/) - [Replicate to ScyllaDB](/solutions/replicate-to-scylladb/) - [Replicate to SingleStore](/solutions/replicate-to-singlestore/) - [Replicate to Snowflake](/solutions/replicate-to-snowflake/) - [Replicate to Solace PubSub+](/solutions/replicate-to-solace/) - [Replicate to Vertica](/solutions/replicate-to-vertica/) - [Replicate to YugabyteDB](/solutions/replicate-to-yugabytedb/) ## Evaluate Gluesync with your Supabase project Start a trial against your Supabase project, or talk to MOLO17 about your sources, table design, and the write path for each table. [Start a Gluesync trial](/get-gluesync/) [Talk to MOLO17](/contacts/)