Census

Census defined reverse ETL alongside Hightouch: read from the warehouse, diff against the last run, and push changed rows into the APIs of CRMs, email platforms, and ad networks. Following the 2025 Fivetran acquisition the product has been folded in fully — getcensus.com and docs.getcensus.com now redirect to fivetran.com, where it is sold and documented as “Activations.” The engine is the same; the packaging, pricing, and docs live under Fivetran.

Data modeling is flexible about where truth lives: a dataset can be raw SQL, an existing warehouse table, a dbt model referenced straight from a GitHub- or GitLab-hosted project, or a Looker Explore or Sigma element — so teams that already govern definitions in dbt or a BI layer do not redefine them. Audience Hub layers visual, no-SQL segment building on top for marketers. Supported sources include Snowflake, BigQuery, Redshift, PostgreSQL, and Databricks.

Every sync is incremental: only rows that are new or changed since the previous run are sent, and you pick the write behavior per sync — upsert (“update or create”), update only, create only, append only, mirror (which also removes destination records that left the source), or delete. Mirror diffs against what was previously sent, not the destination’s current state, so out-of-band edits in the destination are not reconciled. Syncs run on cron schedules, on API/orchestration triggers, or chained to dbt Cloud job completion.

Two implementation notes matter. First, you choose a sync engine per source: the basic engine keeps diff state in Fivetran’s infrastructure with read-only warehouse access, while the advanced engine stores state inside your warehouse — faster, but it needs read/write permissions and a slightly more involved setup. Second, it runs background metadata and health-check queries that show up in your warehouse usage bills, which surprises teams on per-query pricing. Observability is a strength: run history distinguishes invalid records (caught before send — null identifiers, duplicates) from records the destination rejected, with samples and reasons for each, plus alerting and a REST API.

Like all reverse ETL, it owns no data and resolves no identities; it is a sync engine over whatever your warehouse already knows, so upstream modeling discipline — usually dbt — is the real prerequisite.

Use it when you already run ELT into a warehouse (especially Fivetran) and want the return path into operational tools handled by the same vendor and bill. Look past it when you want a standalone vendor independent of the Fivetran ecosystem, need event collection or identity stitching, or your activation needs are simple enough for native warehouse connectors in the destination tools.