all insights

Salesforce Data 360 pricing: a practical guide to credits, consumption, and forecasting

Data 360 bills by consumption, and the spread between its cheapest and priciest operations is four orders of magnitude. Here's what a credit is, where they actually go, why streaming multiplies costs, and how to forecast a bill you can defend.

Salesforce Data 360 pricing: a practical guide to credits, consumption, and forecasting — article illustration

Two credits per million rows. That’s what Salesforce charges when Data 360 runs a data query. Unifying profiles in the same product costs 100,000 credits per million rows — fifty thousand times more. Both numbers sit on the same official rate card, both are paid in the same currency, and both will land on the same invoice. Whether your Data 360 bill is a rounding error or a budget crisis depends almost entirely on which of those operations your architecture leans on, and how often it runs them.

This is the part of Data 360 — the platform formerly known as Data Cloud — that buyers consistently underestimate. The licence conversation is short. The consumption conversation is the actual price, and it’s a function of design decisions: batch or streaming, full refresh or incremental, how many identity rulesets, how often segments republish. Most bill shock we see traces back to a decision nobody priced at the time it was made.

This guide covers the model as it stands in early 2026: what a credit is and costs, the consumption categories that matter, why streaming carries a 12x–160x premium over batch, the allowances you get before paying anything, how to watch consumption in Digital Wallet, and a worked forecasting method with every assumption labelled.

What a Data 360 credit is, and what one costs

A credit is the billing unit for compute in Data 360. Salesforce’s own training describes credits as digital currency that you use to pay for Data 360 services: you buy a pool of them, and every billable operation draws the pool down. Storage is metered separately, so the total cost of Data 360 has three components — consumption credits, data storage billed at a flat monthly rate per terabyte (list price $23 per TB per month as of early 2026), and optional premium add-ons such as Data Spaces and Data 360 One.

Credits are sold in bundles of 100,000 at a list price of $500 as of early 2026 — half a cent per credit. You can pre-purchase for the contract term (the cheapest route), pay as you go monthly in arrears, or pre-commit to a usage baseline. One clause worth reading twice: rate card terms state credits must be used before the order end date, with no rollover. Unused credits are not a savings account.

Consumption itself is mechanical. Every billable usage type has a multiplier, and the maths is (volume ÷ 1,000,000) × multiplier. Run a batch calculated insight over 2 million rows at a multiplier of 15 and you’ve spent 30 credits. That’s the entire model. Everything difficult about Data 360 pricing lives in two questions: which usage types your design triggers, and how much volume flows through them.

Two 2025 changes simplified the picture considerably. In September 2025 Salesforce consolidated what had been four separate credit types into one fungible credit usable across sandbox and production, ingestion to activation — and set sandbox multipliers at a 20% discount to production. The same update made ingestion of structured data from Salesforce Core, Marketing Cloud Engagement, Marketing Cloud Personalization, and Commerce Cloud free. Before that, customers paid credits to move their own CRM data into their own CDP, which was as popular as it sounds.

One naming note. Salesforce introduced Flex Credits in May 2025 as the consumption currency for Agentforce — also $500 per 100,000. As of early 2026, Data 360 orgs typically run on Data Services credits, but the two currencies are visibly converging and your order form, not a blog post, is the source of truth for which one you hold. We’ve covered the Agentforce side of the credit economy separately.

The consumption categories: where the money actually goes

The official rate card groups billable usage into a handful of categories. The multipliers below are production batch rates per million rows as of early 2026 unless noted; sandbox runs 20% lower.

  • Connect (ingestion). The internal pipeline — CRM, Marketing Cloud, Commerce data — is included at zero. External batch pipelines cost 2,000 per million rows. This is often the first big meter, because it runs every day.
  • Harmonize (transforms). Batch data transforms cost 400 per million rows, and the billing counts the higher of rows read or rows written — after the first run, incremental transforms bill only changed rows.
  • Unify (identity resolution). Profile unification is the heavyweight at 100,000 per million source profiles processed. Mercifully, after a ruleset’s first run only new or modified source profiles count. The first run is a one-time capital cost; the daily delta is the recurring one.
  • Analyze and predict. Batch calculated insights are cheap per row (15) but are billed on all records in every underlying object each time they run — though an unchanged object triggers no charge. Model inferences cost 3,500 per million.
  • Segment and activate. Segmentation costs 20 per million rows processed, batch activation just 10. These look trivial until you multiply by refresh frequency: a segment refreshed every hour costs 24x one refreshed daily.
  • Act (queries). Data queries cost 2 per million rows processed — the cheapest meter on the card, though “rows processed” depends on query structure, not rows returned, so a badly-shaped query over a wide object costs more than the result set suggests.

There are more exotic meters — unstructured data at 60 credits per MB, AI-assisted “intelligent processing” at 750 per MB, sub-second real-time events at 70,000 per million — but for most implementations the six buckets above are 95% of the bill. In practice, two of them dominate: external ingestion, because it never stops, and unification, because its multiplier is three orders of magnitude above everything else. When we review a Digital Wallet breakdown, those two meters plus streaming misconfiguration explain nearly every unpleasant surprise.

Why streaming costs 12x to 160x more than batch

The rate card prices the same logical operation very differently depending on whether it runs in batch or streaming mode, and the gap is not subtle:

OperationBatch (credits/1M rows)Streaming (credits/1M rows)Streaming premium
External data pipeline2,0005,0002.5x
Data transforms4005,00012.5x
Calculated insights15800~53x
Activation101,600160x

All figures from the official Data 360 rate card as of early 2026; production rates shown.

The premium reflects real infrastructure — always-on stream processing versus scheduled jobs — but the practical takeaway is architectural. Streaming is a per-use-case decision, not a default. A cart-abandonment trigger that must fire while the shopper is still in session justifies streaming activation. A nightly loyalty-tier recalculation does not, and running it through streaming meters is the single most expensive habit we see in Data 360 orgs.

The same logic applies at the extreme end. Sub-second real-time processing — real-time data graphs, web and mobile SDK events, real-time ingestion APIs — bills at 70,000 credits per million combined events, API calls, and actions. That’s the price of genuine millisecond personalisation. It’s worth paying where revenue depends on it, and worth aggressively scoping everywhere else.

A useful discipline: for every data flow in your design, write down the freshness requirement a business owner actually signed off — “in-session”, “hourly”, “daily”. Anything daily goes batch. Anything hourly probably goes batch. What remains is your genuine streaming footprint, and it’s usually a fraction of what the initial architecture diagram assumed.

Included allowances: what you get before you spend a dollar

Salesforce has seeded Data 360 fairly generously, and a sensible buyer exhausts the free tier before signing a consumption contract.

Two cautions. First, 250,000 credits sounds like a lot and isn’t: one identity-resolution first run over 2.5 million source profiles consumes the entire allowance. It’s a proof-of-concept budget, not an operating budget. Second, if you’re grounding Agentforce on Data 360, note that Salesforce’s own Agentforce pricing examples carry a footnote that they don’t include Data 360 credits — the agent’s retrieval and indexing costs land on this meter, not the Agentforce one.

Digital Wallet: catching consumption before the invoice does

Digital Wallet is the free monitoring layer for consumption-based Salesforce products, available in Enterprise and Unlimited editions. Its consumption cards give near real-time usage tracking across contracts, broken down by usage type, with trend views over 7, 30, or 90 days and the exact units, multiplier, and credits for each meter. Since the September 2025 update it also carries feature-level usage tagging, out-of-the-box reports, and consumption threshold alerts that notify you when usage crosses a percentage of your entitlement.

Treat it as operational tooling, not a billing curiosity. The pattern we recommend is boring and effective: a weekly fifteen-minute review of the Data 360 card, with two questions. Did any meter move more than expected week-over-week? And which specific stream, transform, ruleset, or segment drove it? Consumption spikes almost always have a mundane cause — a new data stream someone pointed at the wrong meter, a transform switched from incremental to full refresh, a segment schedule changed from daily to hourly — and all of them are cheap to fix in week one and expensive to discover at renewal.

One caveat from Salesforce’s own documentation: wallet data is updated multiple times a day but your monthly statement is the definitive source of truth if the two differ. Use the wallet for steering, the invoice for accounting.

A worked forecast: from row counts to a defensible number

Forecasting Data 360 is not guesswork; it’s an inventory exercise. The method we use has five steps.

  1. Inventory every data flow. Sources, rows per day, batch or streaming, and the delta rate — what percentage of rows actually change daily. Delta rate is the number everyone skips and the one that matters most.
  2. Map each flow to rate-card usage types. Ingestion, transforms, unification, insights, segmentation, activation, queries. Note which are one-time (first runs) versus recurring.
  3. Apply the formula — (volume ÷ 1M) × multiplier — per meter, per month, using the current official rate card.
  4. Separate first-run costs from steady state. Unification and initial data shares bill heavily once, then bill deltas.
  5. Price it, add a buffer, and sanity-check against Salesforce’s pricing calculator. We’d suggest a 25–30% contingency in year one; nobody’s delta estimates survive contact with production.

Here’s the method applied to an illustrative mid-market B2C retailer. Every number below is an assumption for the worked example, not a benchmark: CRM and Marketing Cloud data (free internal ingestion), 2M external rows/day from commerce and warehouse feeds, batch transforms touching 3M rows/day, 6M source profiles unified with a 1% daily change rate, two calculated insights over 8M combined rows daily, 20 segments refreshed daily at about 1M rows processed each, 500K rows/day of batch activation, and about 100M query rows a month. The monthly steady state works out like this:

External ingestion   60M rows  × 2,000/1M   = 120,000 credits
Batch transforms     90M rows  × 400/1M     =  36,000 credits
Unification delta    1.8M rows × 100,000/1M = 180,000 credits
Calculated insights  240M rows × 15/1M      =   3,600 credits
Segmentation         600M rows × 20/1M      =  12,000 credits
Batch activation     15M rows  × 10/1M      =     150 credits
Data queries         100M rows × 2/1M       =     200 credits
                            Monthly total   ≈ 352,000 credits

At half a cent per credit that’s roughly $1,760 a month, or about $21,000 a year in steady state — plus a one-time first unification run (6M source profiles × 100,000 = 600,000 credits, about $3,000) and storage. Note the shape: unification deltas are half the bill, ingestion a third, and the glamorous stuff — segments, activations, queries — barely registers. Now stress-test the design decisions. Move those transforms to streaming and 36,000 becomes 450,000 credits a month. Switch activation to streaming DMO and 150 becomes 24,000. Same data, same use case, a bill several times the size. That sensitivity — not the point estimate — is what you should be presenting to whoever signs the contract.

Consumption pricing is an architecture test

The uncomfortable truth about Data 360 pricing is that it invoices your design quality. Seat licences forgive sloppy architecture; consumption models bill it monthly. The same use case, built twice, can differ by an order of magnitude depending on choices that look free on the whiteboard — full refresh versus incremental, hourly versus daily, streaming versus batch, one identity ruleset versus four.

That cuts both ways, and the levers are all in your hands. Batch by default, streaming by exception. Filter and deduplicate at the source so you never pay to ingest rows you’ll discard. Keep transforms incremental. Treat identity-resolution ruleset changes as costed engineering work, because every rerun touches your whole profile base. Match segment refresh schedules to campaign cadence rather than habit. Build in sandbox at the 20% discount, and put Digital Wallet on a weekly review from the first day of the pilot, not the first surprise invoice.

None of this is exotic. It’s the same discipline good data engineering has always required, with a price tag attached that finally makes the business case for it legible. Teams that cost their pipelines before building them don’t just avoid bill shock — they tend to build better pipelines, because “what does this refresh actually need to be fresh for?” is a design question worth asking even when compute is free. If you can walk into a Data 360 negotiation with a flow inventory, a meter-by-meter forecast, and a sensitivity range, you’re no longer buying a black box. You’re buying compute you’ve already scoped — which is a much better position, and a much smaller number. Sizing that forecast honestly is a core part of the data and AI strategy work we do with clients.

Understanding the basics

What is a Salesforce Data 360 credit?

A credit is the unit Salesforce uses to bill compute in Data 360 (formerly Data Cloud). Every billable operation — ingesting external data, transforming it, unifying profiles, building segments, running queries — consumes credits according to the formula (volume ÷ 1,000,000) × multiplier, where each usage type has its own multiplier on the official rate card. Credits list at $500 per 100,000 as of early 2026, and storage is billed separately.

Why does streaming cost more than batch in Data 360?

Streaming keeps processing infrastructure running continuously so data is acted on within seconds, and Salesforce prices that premium into the multipliers: streaming transforms cost 12.5x their batch equivalent, and streaming activation 160x, per the official rate card. Reserve streaming for use cases with a genuine in-session or sub-minute freshness requirement, and run everything else — nightly loads, daily segments, scheduled insights — in batch.

Is Data 360 free with Salesforce Enterprise Edition?

Partially. Since September 2023, customers on Enterprise Edition and above can provision Data 360 at no cost with 250,000 Data Services credits and 1 TB of storage included; Unlimited Plus customers receive 2.5 million credits. Ingesting structured data from Salesforce’s own CRM, Marketing Cloud, and Commerce connectors is also free. The allowance suits a proof of concept, but production workloads — especially identity resolution — consume it quickly.


Trying to put a defensible number on Data 360 for your own org? Talk to us — costing the consumption model before the contract is signed is exactly the work we do.

Keep reading

All insights