Skip to main content

Data Cloud SQL: the dialect you query the unified profile with

What Data Cloud SQL is: an ANSI-compliant dialect you run in the Query Editor and the Query API over DMOs, DLOs, and Calculated Insight Objects — the unified profile, not flat Data Extensions. The naming rules, the clause behavior, and what carries over from Marketing Cloud SQL.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

Data Cloud SQL is the ANSI-compliant dialect you use to ask the unified data model a question — in the Query Editor for ad-hoc work, or through the Query API for anything programmatic. If you write SQL against Marketing Cloud Data Extensions today, the surface looks familiar. The objects underneath it are not: you query Data Model Objects, Data Lake Objects, and Calculated Insight Objects over a resolved profile, not a flat table you loaded.

This page is the dialect reference — what Data Cloud SQL is. The full habit-by-habit crosswalk from Marketing Cloud SQL lives in its own page (see bridging from Marketing Cloud SQL); here we cover what you query, how to name it, and how the clauses behave.

What you query: tables over the unified profile

In Data 360 (formerly Data Cloud), "table" means one of three object types, and all three are queryable through the same SQL surface:

  • Data Model Objects (DMOs) — the harmonized layer. API names end in __dlm. Standard DMOs carry the ssot__ namespace (ssot__Individual__dlm, ssot__ContactPointEmail__dlm); the resolved, post-identity-resolution variants drop the prefix (UnifiedIndividual__dlm). This is what you should query almost all of the time.
  • Data Lake Objects (DLOs) — the raw landing of a stream, in the source system's shape. API names end in __dll. Queryable, but querying a DLO directly inherits the source's mess (see Query & Insights gotchas — gotcha 1).
  • Calculated Insight Objects (CIOs) — the dimensions and measures a Calculated Insight pre-computed, exposed as a queryable table.

The distinction that matters most for anyone arriving from Marketing Cloud: these are not Data Extensions. A DMO is a view over the unified profile that identity resolution built. Query UnifiedIndividual__dlm and you are counting people, not rows you imported — a difference that quietly breaks reconciliation if you assume otherwise.

Naming: qualify it and namespace it

Data 360 table and column names are the object and field API names, and they almost always contain uppercase characters. That shapes how you reference them.

  • Quote only when you must — but it's a safe habit. Double-quoting an identifier is required only when its case would otherwise fold, or when the name collides with a reserved word. Because Data 360 API names are case-mixed (ssot__Individual__dlm), reflexively double-quoting is a defensible habit. The examples in this subcategory stay unquoted for readability, since these names are unambiguous; reach for quotes the moment a name is at risk.
  • Custom fields end in __c. Standard fields carry the ssot__ namespace as well (ssot__Id__c). Fields you add land as __c.
  • Qualify with an alias when you join. Once more than one object is in play, prefix every column with its table alias so the engine — and the next reader — knows which object it came from.
-- Query the resolved profile directly. ssot__-namespaced fields; alias and qualify.
-- Counting unified individuals, NOT raw imported rows.
SELECT
  i.ssot__Id__c          AS individual_id,
  i.ssot__FirstName__c   AS first_name
FROM UnifiedIndividual__dlm i
WHERE i.ssot__FirstName__c IS NOT NULL
LIMIT 100;

The Query Editor

The Query Editor is the UI surface inside Data 360 where you run ad-hoc Data Cloud SQL and see results immediately — the equivalent of the Query Studio reflex a Marketing Cloud practitioner already has, but pointed at the unified model. It's where you explore an object, validate a JOIN path before you wire it into anything, and sanity-check a count against what you expected.

It is for interactive work. Anything that needs to run on a schedule, return to an application, or page through a large result set belongs in the Query API instead — and the Query API has its own pagination and async behavior that the Editor's single-screen results hide.

How the clauses behave

Because the dialect is ANSI-compliant, the shape of a statement is what you'd expect — and that's exactly what makes the few differences worth stating plainly.

  • SELECT / FROM — standard. The FROM target is a DMO, DLO, or CIO. Aliasing works as usual.
  • WHERE — ANSI predicates, AND/OR/IN/IS NULL. The filter runs over the resolved profile, so a WHERE on UnifiedIndividual__dlm filters people, not source rows.
  • JOIN — INNER, LEFT/FULL OUTER are available, but a join only works where the relationship exists in the model. A traversal nobody modeled isn't a runtime error you debug; the path simply isn't there. Joining a source object to the unified individual is not a direct join — you traverse through the IndividualIdentityLink__dlm bridge object that identity resolution maintains (the exact link and source field names follow your org's model). For nullable keys, Data Cloud SQL supports IS NOT DISTINCT FROM so that two NULLs match instead of dropping the row — a real difference from a naive = join.
  • GROUP BY / aggregates — COUNT, SUM, COUNT(DISTINCT …), MIN/MAX, and HAVING behave as in ANSI SQL. The grain you group by is the grain of the answer; group by the wrong key and the number is wrong everywhere it's read.
  • ORDER BY / LIMIT — supported. In the Query API, LIMIT does not save you from pagination — a large result set still pages regardless.
-- Aggregate at the grain of the buyer. The GROUP BY key IS the grain of the answer.
SELECT
  o.ssot__BuyerId__c                AS buyer,
  COUNT(DISTINCT o.ssot__Id__c)     AS order_count,
  SUM(o.ssot__GrandTotalAmount__c)  AS lifetime_value
FROM ssot__SalesOrder__dlm o
GROUP BY o.ssot__BuyerId__c
HAVING COUNT(DISTINCT o.ssot__Id__c) > 1
ORDER BY lifetime_value DESC;

What carries over from Marketing Cloud SQL, and what's different

For a Marketing Cloud practitioner, the resemblance is the trap: it's SQL, so it feels solved, right up until it isn't.

Carries over:

  • The core ANSI shape — SELECT … FROM … WHERE … GROUP BY … ORDER BY — is the same skeleton you already write.
  • Standard aggregates (COUNT, SUM, COUNT(DISTINCT …)) and predicate logic behave as you expect.
  • The discipline of choosing a stable key and counting the right object transfers directly — it's the same instinct you apply to SubscriberKey, now applied to the unified profile.

Different:

  • No System Data Views. There is no _Subscribers, _Sent, _Open, or _Click. Engagement lives in DMOs you model and ingest, not in views the platform hands you.
  • No flat Data Extensions. You query DMOs over a resolved profile. FROM UnifiedIndividual__dlm counts people; the old habit of counting rows in a DE doesn't map cleanly.
  • Identifiers are namespaced. ssot__Individual__dlm carries the ssot__ prefix and the __dlm suffix, not a bare DE name — double-quoted only when a case-mixed name is at risk.
  • Joins must be modeled. In MC you join any two DEs on any matching field. In Data 360 the relationship has to exist in the model first.
  • Two SQL dialects, not one. The dialect on this page — the one the Query Editor and Query API speak — is not the dialect you write to create a Calculated Insight. CI definitions use a different SQL surface with its own rules. Reading a CI's result back is normal SQL; authoring the CI is a separate dialect. Don't assume a function that works in one works in the other.

The crosswalk page walks each transferable habit and each misfire in detail. This page is the boundary: Data Cloud SQL is ANSI over the unified model, namespaced, with modeled joins and a sibling dialect for Calculated Insights.

Related

Reference: