Your lake#

Everything Supernova syncs lands in one place: your organization's lake. It's a
single queryable surface over every connected source — Stripe next to HubSpot next
to your production Postgres — stored in an open columnar format, so a query that
joins across three SaaS tools is no different from a query over one table. This
page explains the small set of rules the lake lives by. They're worth ten minutes:
every other page assumes them.

Tables and names#

Each source syncs into its own schema, named after the source. The full name of
any table is titan.<schema>.<table>:

select * from titan.stripe.charges
select * from titan.hubspot.deals
select * from titan.postgres.orders

Sources with fixed schemas (Stripe, Zendesk, Shopify) always produce the same
tables. Sources with discovered schemas (Postgres, Salesforce, Airtable) produce
whatever your account contains — Airtable, for instance, syncs each base into its
own schema named airtable_<base>. Column names are lowercase snake_case
everywhere, whatever the source API calls them.

The system columns#

Every synced table carries two columns maintained by Supernova:

_deleted is the one to internalize. When a charge is deleted in Stripe or a deal
is merged away in HubSpot, the lake doesn't remove the row — it marks it. Your
history stays intact, and queries opt out explicitly:

select count(*) from titan.hubspot.deals where not _deleted

Filter not _deleted in anything that counts, sums, or joins current state. Skip
the filter when you're deliberately looking at history — that's the point of
keeping it.

How rows change#

Syncs are incremental: each run fetches what changed since the last one and merges
it in by primary key, keeping the latest version of each row. Two consequences:

• A sync interrupted halfway is harmless. The next run picks up from the last
  checkpoint. You never get duplicate rows, because the merge is by key.

• Delete detection varies by source. Some APIs report deletions incrementally;
  others only reveal them in a complete pull, so those connectors periodically
  re-read everything to find what vanished. Each connector page states which
  strategy its source forces.

Snapshots#

Every sync commits atomically. A query always reads one consistent snapshot of a
table — never a half-written sync, even if the sync is running while your query
is. New data becomes visible all at once, when its sync commits.

The lake retains recent snapshots (30 days by default) rather than only the
present, which is what makes the atomicity cheap and interrupted work safe to
abandon.

What this buys you#

• Joins across sources with no pipelines to build: revenue by deal stage is
  one join between titan.stripe.charges and titan.hubspot.deals.

• Schema changes surface, they don't break. When a source grows a column, it
  appears in the lake; the Schema changes feed shows you what changed and when.

• An open format. Your data is stored as standard columnar files with standard
  table metadata — not a proprietary blob keyed to us.

Next: writing models turns queries over these tables
into tables of your own.