How to Use Supabase with Unified.to

January 6, 2026

Supabase is a strong choice when you want Unified's normalized objects available in Postgres for querying, analytics, and joins with your own data.

Unified.to supports Supabase in two complementary ways:

Schema-first (DDL): create Postgres tables that match Unified's data models
Data delivery: stream normalized updates into those tables via database sync or your own ingestion layer

This guide explains both approaches, when to use each, and how Supabase fits into Unified's real-time, no-storage architecture.

When Supabase is the right tool

Use Supabase with Unified.to when you want:

A local, queryable mirror of normalized SaaS data
SQL for analytics, reporting, or BI
Joins between Unified objects and your own application tables
Eventual consistency with predictable schemas

Supabase is not a replacement for Unified's API or webhooks. It's a storage and query layer you control.

High-level architecture

SaaS providers (CRM, HRIS, Calendar, etc.)
            ↓
         Unified.to
   (real-time normalization)
            ↓
   ┌───────────────┐
   │  Your backend │  ← API calls / webhooks (real-time)
   └───────────────┘
            ↓
         Supabase
     (Postgres mirror)

Unified remains the integration layer and source of truth
Supabase is a mirror/cache for querying and analytics
Your backend decides when to read from Supabase vs call Unified directly

Step 1: Create tables using Unified's Supabase DDL

Unified provides Supabase-compatible SQL DDL files for each integration category (CRM, Calendar, HRIS, etc.), as well as an all-in-one option.

The DDL creates Postgres tables that match Unified's normalized data models so incoming data can be written consistently. These tables are designed to receive data delivered by Unified's database webhook pipeline.

Supabase SQL DDL: Unified API's DDL

You can use our SQL DDL to create databases in Supabase matching our data-model schemas. You can download one DDL SQL for all of our Unified APIs, or you can download a DDL SQL for each API, which will contain just the data models for that API category.
supabase_ddl_accounting.sql
supabase_ddl_ats.sql
supabase_ddl_calendar.sql
supabase_ddl_commerce.sql
supabase_ddl_crm.sql
supabase_ddl_enrichment.sql
supabase_ddl_hris.sql
supabase_ddl_kms.sql
supabase_ddl_lms.sql
supabase_ddl_martech.sql
supabase_ddl_messaging.sql
supabase_ddl_payment.sql
supabase_ddl_repo.sql
supabase_ddl_scim.sql
supabase_ddl_storage.sql
supabase_ddl_task.sql
supabase_ddl_ticketing.sql
supabase_ddl_uc.sql
supabase_ddl_verification.sql

What the DDL gives you

Tables in the default schema (typically public)
Consistent naming (unified_<category>_<object>)
Columns that match Unified's normalized fields
Read-only mappings (no primary keys, indexes, or constraints enforced)

Apply the DDL

Open Supabase Dashboard → SQL Editor
Paste the DDL (for a single category or all categories)
Run the query

Recommendation: start with a single category DDL (e.g., CRM) unless you know you need multiple domains.

Step 2: Understand the schema guarantees (and limits)

Unified's Supabase DDL is intentionally minimal.

What you should not change

Do not add or remove columns on the foreign tables
Do not add primary keys or constraints to the foreign tables
Do not rely on foreign tables as a transactional store

Altering the foreign tables can break the mapping to Unified's API.

What you can safely extend

Create local tables or materialized views
Add indexes and constraints to those local tables
Join Unified foreign tables into your own schema

This pattern keeps the Unified mapping intact while giving you full Postgres control.

Step 3: How data is delivered into Supabase

Unified delivers data into Supabase using the same database webhook mechanism it uses for other Postgres-compatible databases.

Supabase is treated as a database destination, not a special integration. Data flows one-way from Unified into your Supabase tables using Unified's normalized data model.

How delivery works

Unified listens for changes from connected SaaS platforms (via native APIs and webhooks)
Those changes are normalized into Unified's standard object schemas
Unified delivers inserts and updates into your Supabase database via its database webhook pipeline
Records are written using upserts keyed by id and connection_id

This mechanism ensures that data written into Supabase matches the schemas created by the Supabase DDL.

Important characteristics

One-way delivery: data flows from Unified to Supabase only
Changes made directly in Supabase do not propagate back to Unified or to upstream SaaS platforms.
Upserts, not hard deletes: if a record is removed in the source system, it is not hard-deleted from Supabase. Rows remain unless you explicitly prune them.
Eventual consistency: delivery is asynchronous. Updates typically arrive seconds to minutes after upstream changes.
Same delivery model as other databases: Supabase does not use a custom or separate sync engine.

When to rely on this delivery path

Use database delivery into Supabase when you want:

A local, queryable mirror of Unified's normalized data
SQL access for analytics, reporting, or joins
A storage layer you control for downstream use cases

For real-time application logic, user-initiated actions, or write operations, continue to use Unified's API or webhooks directly.

Step 4: Data freshness and consistency

Supabase should be treated as eventually consistent.

What to expect

Updates arrive seconds to minutes after upstream changes
Ordering is preserved per object and connection
Supabase mirrors the latest known state, not a live view

What not to assume

Supabase is not strongly consistent
Supabase is not guaranteed real-time
Supabase is not a system of record

For user-facing or transactional workflows, call Unified's API directly or rely on webhooks.

Step 5: Failure modes and reliability

Unified's data delivery is asynchronous and resilient, but not transactional.

Retries

Transient failures (network, database downtime) are retried automatically
Backoff is applied until the destination is healthy again

Error visibility

Destination errors surface in the Unified dashboard
Failed writes are logged with timestamps and messages
Partial failures do not stop the entire stream

Backfill and replay

There is no selective 'replay' button
To backfill:
- Re-enable the destination, or
- Re-pull data via API and upsert manually

Deletes

Source deletes are not hard-deleted in Supabase
Rows remain unless you prune them yourself

How Supabase fits Unified's no-storage model

Unified does not store your customers' data.

Supabase support does not change that:

Unified normalizes and forwards data
Supabase is your database
Credentials are stored securely and scoped per environment
Unified never reads from your database or syncs data back upstream

This preserves vendor neutrality and avoids lock-in.

When to use Supabase vs API vs webhooks

Use case	Best option
Analytics / BI	Supabase
Reporting / dashboards	Supabase
Real-time UI reads	Unified API
Event-driven workflows	Unified webhooks
Writes / mutations	Unified API
Auditing / joins	Supabase

Most production systems use both: API/webhooks for real-time paths, Supabase for analytics and queries.

Summary

Using Supabase with Unified.to is about mirroring, not replacing, the integration layer.

Use Unified to integrate and normalize data in real time
Use Supabase to query, analyze, and join that data
Keep writes, auth, and real-time logic at the API/webhook layer

This separation keeps your system flexible, scalable, and vendor-neutral.

Resources

All articles