We're syncing several tables from Amazon Redshift into Salesforce Data 360 via a Redshift Connector. Our initial ingestion consumed a large percentage of our Data Service Credits, so we're now trying to understand the credit implications of subsequent updates.
Question:
If an entire source table in Redshift is updated (e.g., a bulk UPDATE that touches every row, or a full table rebuild/recreate), does the next Data 360 refresh treat this as a full re-ingestion — consuming roughly the same number of credits as the initial load? Or does Data 360's incremental sync still detect and ingest only the changed rows in that case?
What we've already tried:
- We've set up incremental sync using a datetime field per Salesforce's documentation.
- We created Redshift views (rather than syncing raw tables directly) to limit scope and reduce transformation-related credit consumption, since we confirmed transformations also draw from the credit pool.
Additional question — guardrails: What's the recommended way to set up guardrails against unexpected credit overspend on Redshift-connected streams? Specifically: is there a way to cap or alert on credit consumption per data stream/connector, or to simulate/estimate credit cost before a scheduled refresh runs against a large or recently-modified table?
Hey Thomas,
Yes, a bulk update that touches every row will trigger a full re-ingestion at roughly the initial-load cost. Incremental sync works off your cursor datetime field, it pulls any row where that field is newer than the last sync point. It doesn't diff actual content, so if every row's timestamp advances, every row looks new and gets re-pulled. A full table rebuild/recreate causes the same result. Ingestion is metered per row processed, so re-ingesting the full table costs close to the original load (upserts by primary key, so no duplicates, but you still pay to process every row).
To avoid this: only update the datetime field on rows that actually changed, leave others untouched, and avoid full table rebuilds/recreates for the same reason.
On guardrails:
- Digital Wallet is Salesforce's built-in credit tracking tool, shows real-time and historical usage by type, and supports threshold alerts (commonly set at 70-80%) so you're warned before a runaway refresh drains the pool.
- There's no native hard cap per stream/connector, alerts are the mechanism, not a stop-gap.
- There's no built-in cost simulator before a scheduled run. Estimate manually using row count × the rate-card multiplier for your usage type, and watch Digital Wallet trends after each run.
- Consider splitting high-churn tables into their own stream so a bad restamp event is easier to isolate and spot in reporting.
Reference:
https://help.salesforce.com/s/articleView?id=data.c360_a_data_usage_types.htm&language=en_US&type=5
