Ingestion is the foundational operation in Data Cloud. Every downstream capability — identity resolution, segmentation, calculated insights, activation — depends on data first being ingested, profiled, and harmonized. It is also one of the operations where credit consumption is most consistently underestimated at contract signing, and where small assumptions about data shape produce large differences in the bill. This guide walks through how Salesforce prices ingestion, where the model creates risk for buyers, and how to model it accurately before you commit.
Our team has now negotiated and tuned Data Cloud ingestion economics across more than 80 enterprise deployments, contributing to over $420 million in documented Salesforce client savings. Ingestion is consistently one of the two or three largest credit consumers in mature deployments, and is the operation that most often surprises customers with year-one overage.
How Data Cloud meters ingestion
Ingestion in Data Cloud splits into two main modes. Batch ingestion handles scheduled loads from sources such as CRM, data warehouses, files, and APIs. Streaming ingestion handles real-time event flows from sources such as web behavior, mobile app events, IoT telemetry, and transactional systems.
Both modes consume credits, but at different rates and with different cost shapes. Batch ingestion is typically metered per million rows processed, and consumption is bounded by the volume of data flowing in during each scheduled run. Streaming ingestion is typically metered per million events, and consumption tracks the rate of events being generated.
An important nuance: ingestion credit cost is not only driven by the data volume entering the platform. It is also driven by reprocessing — re-running ingestion when schemas change, mappings are corrected, or source connections are reconfigured. Reprocessing can easily double an organization's ingestion consumption in the first twelve months of deployment.
| Driver | Effect on credit cost | Common misforecast |
|---|---|---|
| Source row count | Linear with rows ingested | Underestimating active source size |
| Ingestion frequency | Linear with run count | Hourly schedules where daily would do |
| Streaming event volume | Linear with event count | Peak rates, not average rates |
| Reprocessing | Full-volume re-run | Not modeled at all in initial forecast |
| Source schema changes | Trigger reprocessing | Frequency of schema evolution |
| Data quality fixes | Trigger reprocessing | Year-one data quality work is heavy |
Why ingestion forecasts under-shoot
Three patterns drive ingestion consumption above the original quote.
Active source size is larger than the documented size
When an organization documents a source for the ingestion forecast, the documentation usually reflects steady-state operational volumes. Initial ingestion, however, is typically a full historical load — sometimes covering years of records. The historical load alone can consume more credits than the first six months of steady-state operation.
Schedule cadence is set high by default
Source connectors are often configured at higher ingestion cadences than the business needs. Hourly batch ingestion when daily would suffice. Daily ingestion when weekly would suffice for slow-changing reference data. The cadence is set during deployment and rarely audited afterward.
Schema and mapping changes drive reprocessing
First-year deployments routinely run multiple reprocessing cycles as schemas are refined, mappings are corrected, and data quality issues are addressed. Each cycle re-runs ingestion against the full historical dataset for the affected source. Year-one reprocessing credit cost frequently exceeds the steady-state ingestion cost.
Modeling ingestion accurately before you sign
The buyer who wins a strong ingestion contract is the buyer who builds an internal ingestion model that captures the actual data shape and operational reality. The model should include:
- Per-source row counts and event volumes — broken down by source, with separate figures for initial historical load and steady-state.
- Per-source ingestion cadence — with explicit rationale for each cadence (real-time, hourly, daily, weekly).
- Schema change rate — how often schemas evolve in each source, and how that translates to reprocessing.
- Data quality reprocessing allowance — a defined budget for year-one data quality work, modeled as additional reprocessing cycles.
- Growth trajectory — how data volumes will evolve across the contract term.
This model produces a defensible ingestion forecast that the buyer can use both for contract sizing and for ongoing operations. It also becomes the basis for negotiating reprocessing allowances as a separate line item.
Negotiation levers for ingestion-heavy deployments
For deployments where ingestion will consume a large share of credits, several clauses are worth pursuing specifically.
Reprocessing allowance
Negotiate a defined number of reprocessing cycles per source per year that consume credits at a reduced rate, or that do not consume against the main credit block at all. Salesforce can accommodate this because they understand that data platform deployments require reprocessing as part of standard operation.
Historical load exclusion
Negotiate that the initial historical load — the one-time ingestion of years of historical data — consumes against a separate one-time pool rather than against the recurring credit block. This prevents the year-one ingestion forecast from being permanently inflated by a one-time event.
Cadence-flexible commitment
Negotiate that ingestion cadence can be tuned during the term without triggering a contract amendment. If a source can move from hourly to daily without business impact, you want the contractual freedom to make that change and capture the credit savings.
Per-source rate visibility
Negotiate the right to see ingestion credit consumption broken down by source on a monthly basis. Without per-source visibility, optimization is guesswork.
Operational disciplines that reduce ingestion cost
Several operating disciplines reduce ingestion consumption without affecting downstream capability.
Cadence audit
Audit ingestion cadence per source against actual business need at least annually. Sources whose downstream consumers run weekly do not need daily ingestion. Sources whose downstream consumers run daily do not need hourly ingestion.
Source filtering
Filter at the source where possible. If only the customer-domain subset of a CRM extract is needed in Data Cloud, ingest only that subset rather than the full extract. The credit savings are proportional to the volume excluded.
Schema discipline
Treat Data Cloud schemas with the same discipline as production data warehouse schemas. Avoid exploratory schema changes that trigger reprocessing. Batch schema evolution into defined releases.
Reprocessing change control
Require a change ticket for any operation that triggers reprocessing. Each ticket should estimate the credit impact. Reprocessing tickets that exceed a threshold require explicit approval.
Bringing it together
Ingestion is the operation Data Cloud cannot exist without, and the operation where forecasting most often goes wrong. The drivers are clear: source size, cadence, event volume, reprocessing frequency, and schema evolution rate. The controls are practical: source-level modeling, cadence audits, schema discipline, reprocessing change control. The contract levers are real: reprocessing allowances, historical load exclusions, cadence flexibility, and per-source visibility.
Buyers who build the model, negotiate the structure, and operate the discipline routinely run their ingestion consumption 20-40% below the first-year forecast — and arrive at renewal with the data to defend further structural concessions. Buyers who treat ingestion as a back-office data engineering task end up paying for the difference in year-three true-ups.
Frequently asked buyer questions on ingestion pricing
How do we estimate ingestion credits before signing?
Build a source-by-source model that captures row counts and event volumes, ingestion cadence, expected reprocessing cycles, and historical load size. The model produces a defensible ingestion forecast for contract sizing.
Why is our actual ingestion higher than the forecast?
Most often: historical load that was not modeled, schedule cadences set higher than business need, reprocessing cycles driven by schema or data quality work, and source size larger than initial documentation. All four are detectable through a thirty-day post-deployment audit.
Do streaming ingestion costs scale linearly with event volume?
Approximately yes, at the platform layer. The cost shape can shift if the platform applies different rates for bursts versus steady-state event flow, or if the event payload size affects the metering. Confirm the metering basis with Salesforce in writing before signing for streaming-heavy workloads.
Can we batch-ingest a high-frequency source instead of streaming?
For many use cases, yes — and the credit savings can be substantial. The trade-off is freshness: batch ingestion produces fresher profiles only at the cadence of the batch. For use cases where minute-level freshness is unnecessary, batching reduces cost without affecting outcomes.
A practical ingestion audit template
The first ingestion audit a Data Cloud deployment should run captures the following per source: source name, owner, current ingestion mode (batch or streaming), cadence, row or event volume per ingestion run, last schema change, last full reprocessing, and downstream consumers. The audit surfaces sources whose cadence exceeds business need, sources with unnecessary reprocessing patterns, and sources that have grown beyond their original forecast envelope.
The audit typically takes two to three weeks to complete the first time and one week thereafter on a quarterly cadence. The remediation actions — cadence adjustment, source filtering, schema discipline — typically reduce ingestion credit consumption by 15-30% on first cycle.
How ingestion cost interacts with downstream operations
Ingestion cost is a fraction of total Data Cloud consumption, but it sets the baseline for everything downstream. A larger ingested dataset increases the cost of identity resolution, segmentation, and calculated insights. Ingesting more than necessary creates an amplified cost downstream, often larger than the ingestion line item itself. The discipline of source filtering — only ingesting the data Data Cloud actually needs — has compounding returns across the rest of the credit consumption profile.
This compounding effect is why we recommend treating ingestion as a strategic, governed function rather than a routine data engineering task. Decisions made about what to ingest at deployment time set the trajectory of credit consumption for the life of the contract.
How ingestion shapes the broader contract negotiation
Ingestion is rarely the single largest cost line item, but it is often the most leverage-able line item at negotiation time. The mechanics are these: ingestion forecasts are unusually easy to model with internal data (your sources are knowable, their sizes are knowable, their cadences are knowable), and Salesforce's account team rarely arrives at the table with an equally well-grounded counter-forecast. The information asymmetry favors the buyer who has done the modeling work.
Buyers who present a defensible ingestion model in early negotiations set the tone for the rest of the contract. Salesforce account teams calibrate their broader pricing posture based on whether the buyer is operating on platform-promotional figures or on internal evidence. The buyer who has done the ingestion modeling work signals discipline and earns the structural concessions — reprocessing allowances, cadence flexibility, per-source visibility — that buyers without that work rarely receive.
A common pitfall: ingestion-led platform commitment
Some buyers, particularly those with very large datasets, commit to Data Cloud primarily because their data is already at a volume where ingestion alone justifies a substantial credit block. This is sometimes the right call. More often, it leads to overcommitment. The right test is not "how much data do we have?" but "how much of that data needs to be in Data Cloud, and to what use cases does that data contribute?" Buyers who answer the second question typically find they need to ingest substantially less than they initially assumed, and the platform commitment can be sized accordingly. This single reframing has produced material savings on multiple engagements we have run.