> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/run-your-computation-in-the-warehouse.md).

# Run your computation in the warehouse

How segmentation and identity resolution execute on your warehouse, and what that changes for you.

## Your goal

Understand what the platform executes inside your warehouse in a [Hybrid or Zero-copy deployment](/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md#the-three-modes), so you can predict the results, the schedule, and the cost.

## Expected outcome

Segments that compute on warehouse data, an identity graph maintained there, and a clear view of which warehouse workload the platform is responsible for.

{% hint style="info" %}
This feature is in Alpha. Contact your account manager to learn more.
{% endhint %}

## What moves, and what does not

|                                      | Hosted                   | Hybrid and Zero-copy          |
| ------------------------------------ | ------------------------ | ----------------------------- |
| Where you build segments             | Navigator, in OTQL       | Navigator, in OTQL            |
| The schema you build against         | Your datamart schema     | Your datamart schema          |
| Where the segment query executes     | The platform             | Your warehouse                |
| Where the identity graph is computed | The platform             | Your warehouse                |
| Who pays for the computation         | Included in the platform | Your warehouse compute budget |

The row that matters most is the second one. Your teams keep working against the same model, in the same builders, in the same query language.

## Segments: you keep OTQL

A segment query you write in [OTQL](/setup-and-monitor/operate-and-monitor/query-your-datamart/otql.md) is translated into an equivalent SQL query in your warehouse's dialect - BigQuery or Snowflake - and executed there. The translated query is what runs; the OTQL you wrote remains the definition you maintain.

The practical consequences:

* **Your existing segment definitions carry over.** They are expressed against the same schema, so a deployment change does not oblige you to rewrite them.
* **The builders behave as documented.** See [Segment builders](https://app.gitbook.com/s/XSPACE_AUDIENCE/build-your-audiences/segment-reference/segment-builders).
* **Recompute cost lands in your warehouse.** A segment that recomputes often, over a wide time window, is a warehouse workload like any other.

## Identity resolution: the graph is computed, your data is not rewritten

Activities and profiles are stored with the identifiers they arrived with, and are **not** enriched with a UserPoint reference. Only the graph itself is computed and maintained.

That is what makes the graph reproducible. Because the original link between each activity and its identifiers survives in your warehouse, the graph can be rebuilt from that history rather than from data that has already been merged.

Two kinds of recomputation follow from it:

| Recomputation   | When it happens                                                                                                                                                                                      |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Incremental** | On a regular schedule, applying what has arrived since the last run.                                                                                                                                 |
| **Full**        | When the configuration that decides *how* identities join changes: adding or removing an identifier from the graph, changing identifier priority, or adding or removing a data source in the schema. |

{% hint style="warning" %}
A full recomputation reads the whole history, so it is the most expensive operation the platform runs on your warehouse. Group identity-configuration changes together rather than applying them one at a time, and agree a window for them with whoever owns your warehouse budget.
{% endhint %}

For what the graph is and when two UserPoints become one, see [UserPoint & Identity graph](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/userpoint-and-identity-graph.md).

## Keeping the cost predictable

Computing a segment on unreconciled data means joining activities to their identifiers and resolving users as the query runs. Four things keep that under control:

{% stepper %}
{% step %}

### Index only what you filter on

Every indexed property adds work to the queries that touch the table behind it. See [Map your warehouse tables to a schema](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/map-your-warehouse-tables-to-a-schema.md).
{% endstep %}

{% step %}

### Check the shape of the tables you expose

A structure that has to be scanned in full to answer a question about one user is the usual source of an unexpected bill.
{% endstep %}

{% step %}

### Bound your segment time windows

A condition over the last 30 days and one over all history are the same query to write and not the same query to run.
{% endstep %}

{% step %}

### Watch what recomputes, and how often

Treat recompute frequency as a cost decision, and review it with the team that owns warehouse spend.
{% endstep %}
{% endstepper %}

## Verify

* A segment built in Navigator returns a size consistent with the equivalent question asked directly in your warehouse.
* Two users you know to be the same person resolve to one UserPoint after the graph has been computed.
* An identity-configuration change is followed by a full recomputation, and the graph reflects it afterwards.
* Warehouse compute consumption matches the schedule you agreed, with no unexplained peaks.

## Related pages

<table data-view="cards" data-search="false"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Replicate live tracking to your warehouse</strong></td><td>How the activity this computation reads gets there.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/replicate-live-tracking-to-your-warehouse.md">Replicate live tracking to your warehouse</a></td></tr><tr><td><strong>Resolve identities</strong></td><td>What you can do to improve how many users are recognised.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/resolve-identities.md">Resolve identities</a></td></tr><tr><td><strong>Choose your deployment mode</strong></td><td>The decision this page is a consequence of.</td><td><a href="/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md">Choose your deployment mode</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mediarithmics.io/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/run-your-computation-in-the-warehouse.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.