TL;DR
- Reverse ETL sends modelled warehouse data into operating tools. Decide which fields the warehouse owns before enabling CRM updates.
- Hightouch is a strong starting point for managed activation with row-level troubleshooting. Fivetran Activations, formerly Census, merits evaluation in an existing Fivetran estate.
- RudderStack fits a warehouse-centred customer-data programme. Polytomic deserves attention when activation is part of broader operational data movement.
- A source row disappearing must have an explicit destination policy. It should not automatically delete a CRM account or clear a seller-owned field.
- For 500,000 rows and four destinations, price initial load, daily deltas, sync definitions and warehouse compute separately. Destination API limits still apply.
Activate a model, not a raw table
The warehouse holds product usage, billing and account segmentation. Sellers need a current expansion flag in the CRM; marketing needs an eligible audience; customer success needs a usage milestone. Reverse ETL moves those modelled attributes into the tools where people act.
The output model is the real product. It should contain stable destination keys, approved fields, freshness and eligibility. A raw join that duplicates accounts can make a technically successful sync overwrite the same record repeatedly.
This guide concerns warehouse activation of business models. It does not replace transactional activity sync. Our product-led sales guide covers how product signals support selling, while CRM cleaning tools addresses destination hygiene. The email suppression guide owns the final contact restriction layer that activation must respect.
Use the RevOps CRM setup playbook to assign field ownership. A warehouse-derived score can coexist with seller-owned account status; it should not silently replace it.
Four platforms and their billing models
| Platform | First evaluation when | Billing scope to inspect | Main non-fit |
|---|---|---|---|
| Hightouch | Managed warehouse activation needs detailed sync visibility | Active-sync self-service model or scoped offer | Treating four destinations as automatically four syncs |
| Fivetran Activations | Existing Fivetran estate wants activation | Current consumption rules and destination relationships | Reusing a historical Census contract calculation |
| RudderStack | Customer-data pipelines and warehouse activation share ownership | Selected Reverse ETL and broader product scope | Buying an entire data programme for one trivial field export |
| Polytomic | Activation sits among databases, apps and operational data movement | Starts at $500/month; exact package quote | Assuming entry price includes every enterprise requirement |
Documentation and pricing were checked on 6 October 2026. No throughput, connector-reliability or cost benchmark was run.
Where each option fits
Hightouch: activation with row-level evidence
Hightouch's Reverse ETL product describes warehouse activation and a row-level debugger. Its sync documentation exposes requests and destination responses alongside processed rows. That is useful when RevOps needs to explain why one account updated and another failed.
Its change-data-capture guide describes difference-based detection and the importance of reliable primary keys. Stable uniqueness is a prerequisite, not a feature the destination connector can infer from an ambiguous company name.
The self-service pricing documentation bases that offer on active syncs and distinguishes it from other commercial scope. Confirm current entitlement and rates for the required models and destinations. One destination can contain several separately configured syncs, so count definitions rather than integration logos.
Choose Hightouch first when managed activation and inspectable failures are central. Avoid assuming its broader audience, identity or real-time products are included in a Reverse ETL-only purchase.
Fivetran Activations: evaluate the current Census successor
Fivetran Activations documentation describes managed reverse ETL and migration from Census. Its current pricing rules apply consumption treatment to Activations as well as the wider platform.
It deserves early evaluation when the warehouse already relies on Fivetran and the team wants ingestion and activation under one commercial relationship. Inspect the exact connector configuration, transformation requirements and operational visibility instead of assuming the existing extraction pipeline automatically defines a safe CRM write model.
Obtain the current active-row counting rules, destination treatment, plan and discount assumptions. Do not use an older Census seat or sync price as the current invoice model. Choose it for a coherent supported estate; avoid treating a familiar vendor relationship as sufficient proof that every required destination object and update mode works.
RudderStack: activation within a customer-data programme
RudderStack Reverse ETL places activation alongside warehouse-centred data pipelines. Its pricing page lists product scope, including Reverse ETL and identity capabilities across offers.
It fits a technical team already building customer-data models and wanting activation to share that operating environment. Ask which source models, destination mappings, schedule controls and error outputs are included. Event collection, profiles and reverse ETL are related products, not a guarantee that one entry allowance buys every layer.
Use the scoped offer for the selected functionality and workload. Choose it when the broader data programme is relevant. It can be excessive for a small team whose existing scheduled integration reliably writes one uncomplicated field.
Polytomic: broader operational data movement
Polytomic provides ETL and Reverse ETL interfaces across operational sources. Its pricing page says pricing begins at $500 per month, with Standard supporting multiple destinations and Enterprise adding deployment and support requirements.
It deserves evaluation when the workflow draws on warehouses, databases, spreadsheets and application APIs rather than one warehouse audience. Require a demonstration of your matching key, update mode and row-error recovery in the exact destination.
Treat $500 as an entry statement, not a quote for four destinations, 500,000 rows and every governance control. Specify schedule, volume, connectors, support and deployment requirements. Choose it for the broader movement pattern; avoid selecting it from price alone without establishing the precise CRM action it can safely perform.
Protect CRM ownership
Publish a field contract before the first sync. The warehouse might own product-usage totals, segmentation and computed eligibility. The CRM might own account owner, opportunity stage, commercial notes and final suppression policy.
| Mapping decision | Safer rule | Failure avoided |
|---|---|---|
| Account identity | Stable CRM ID or approved key map | Namesake or subsidiary overwrite |
| Seller-owned field | Exclude from activation | Warehouse snapshot erases current sales work |
| Null source value | Defined ignore/clear semantics | Missing data becomes an unintended deletion |
| Removed source row | Explicit audience/attribute policy | Account deletion caused by filter change |
| Stale model | Pause or flag under freshness rule | Old usage treated as a current signal |
| Retry | Reuse row/action identity and inspect outcome | Duplicate side effects after a timeout |
An expansion score can create a review task rather than reassign the account. Keep derived suggestions separate from authoritative decisions when the commercial action requires human ownership.
Suppression should be applied before audience export and at the sender's final action where appropriate. A warehouse model refreshed overnight can lag a withdrawal made this morning. Activation reliability includes respecting the authoritative current restriction, not just copying the most recent analytical table.
A 500,000-row workload
Assume 500,000 source rows sent initially to four destinations. That is 2 million initial destination-row operations, before connector batching and filtering. It is not automatically 2 million billable units under every provider's model.
Suppose 2% of rows change daily: 10,000 changed source rows. Four destination projections produce 40,000 update operations per day, or 1.2 million over a 30-day month, before retries. If 1% of those operations needs one additional attempt, add 12,000 attempts.
Consumption pricing may count distinct monthly active rows under its rules rather than repeated daily operations. Active-sync pricing may count configured relationships rather than rows. Send the same workload specification to each vendor and ask it to explain its billable quantity.
Use a hypothetical monthly allowance of $700 platform, $150 warehouse compute and six operator hours at $60. Total recurring cost is $1,210, excluding tax, destination fees and initial implementation. None is a provider quote.
If 9,500 changed accounts are fully applied to all required destinations in a daily cohort, allocated monthly cost per daily cohort is $1,210/30, and per fully activated account is about $0.00425. The remaining 500 should stay visible as exceptions. Do not count successful individual destination writes as complete accounts.
Doubling operator effort adds $360 monthly. Doubling daily delta can increase API and compute work without doubling an active-sync licence. Resetting change state or a changed matching key can trigger a large resync, so include that failure in both the budget and destination capacity plan.
Acceptance and ongoing operation
Test initial load, unchanged rows, changed values, nulls, removed rows, duplicate keys, revoked credentials and destination throttling. Use a limited permitted cohort and compare the actual destination state with expected output.
Do not equate a completed sync with complete business acceptance. Count rows rejected by validation, unmatched destination keys and stale records. Give each exception an owner and a replay path.
Version the source model and mapping together. A SQL change can alter which rows appear even when the connector configuration is unchanged. Review ownership and removal consequences before promoting it.
Choose Hightouch for inspectable managed activation, Fivetran Activations for a supported integrated estate, RudderStack for the broader warehouse customer-data programme, and Polytomic for a wider operational movement pattern. The right purchase makes the agreed model current in the destination while preserving fields the warehouse does not own.
FAQ
Is Reverse ETL bidirectional sync?
Its main role is activating warehouse data into operational destinations. Other ingestion or sync processes may move data back. Define ownership so those paths do not create a loop or overwrite each other's fields.
Should a missing warehouse row delete a CRM record?
Only under an explicitly approved use case and supported mode. Often it should remove audience membership or clear a derived flag instead. A changed filter is not sufficient evidence that the account should cease to exist.
Can we sync more often to solve every freshness problem?
More frequent runs can reduce some lag, but destination limits, source freshness and consent updates still matter. Measure the end-to-end age of the value and choose a schedule the whole path can support.
What should we retain for an error investigation?
Keep source model version, primary key, mapping version, run ID, request/result and destination error under the permitted retention policy. A total failure count without affected row identity is difficult to repair safely.
