Data warehouse egress as exit cost

When an organization considers leaving a data warehouse, the transfer bill is one of the most visible costs: it is concrete, priced and capable of being calculated.

Snowflake documents data transfer as the movement of data into and out of Snowflake, and documents a per-byte data transfer fee when data is transferred from a Snowflake account into a different region on the same cloud platform, or into a different cloud platform (Understanding data transfer cost). The same documentation is equally clear about the limitation: transfers within the same region are not charged under that model.

That limitation matters, and this paper states it up front so that nothing following can be read as implying that every export from a warehouse carries an egress charge. It does not. Whether a charge applies depends on where the data is going.

If the data can be exported, what exactly has been exited?

That is the question of this paper. It does not begin from the assumption that warehouse exit is prohibitively expensive, and it makes no attempt to calculate a universal cost of leaving. The proposition under examination is narrower: that egress is one visible and measurable component of exit, and that the wider reversibility question concerns whether the data, schemas, SQL logic, transformations and surrounding operating practices can be reconstructed elsewhere.

Snowflake documents supported mechanisms for unloading data. COPY INTO <location> unloads data from a table — or from a query result — into one or more files in an internal stage or in external cloud storage, with Amazon S3, Google Cloud Storage and Microsoft Azure documented as supported external locations (COPY INTO <location>; Overview of data unloading). The documentation describes unloading to delimited files such as CSV, and to JSON and Parquet.

This should be said plainly: the platform provides genuine, documented export mechanisms. Nothing in this paper argues that Snowflake technically prevents customers from retrieving their data, and any reading in that direction is a misreading.

Snowflake also documents how transfer can be observed. Data transfer volumes and the associated costs can be examined through the documented usage and cost views and in Snowsight (Exploring data transfer cost).

That establishes something genuinely useful. Where Snowflake’s documented egress charges apply, the network-transfer component is in principle calculable from the applicable transfer rate and observed transfer volume. System Drift offers no example figure here — no terabyte assumption, no illustrative total, no industry average. Any such number would be arbitrary, and an arbitrary number presented in an evidence-led paper does more harm than an absent one.

The most visible component of exit may also be the easiest to quantify. That is not a reason to assume it is the largest.

The observation above is System Drift interpretation. The documented facts are only that a per-byte rate exists for certain transfers and that transfer volumes are observable in the platform’s own tooling.

Pricing mechanisms differ between platforms, and a second documented example makes the point better than argument does. Google documents no processing charge for exporting BigQuery table data using a batch extract job. Batch exports can use the shared slot pool subject to Google’s documented limits, while cross-region exports can incur data-transfer charges (BigQuery pricing).

This is not a comparison, and it is not offered as one. Neither platform is being scored against the other, and the differences in how each meters export are product-design choices, not evidence of intent.

The analytical point is about the shape of the question. “Can I export the data?” and “what does exporting the data cost?” depend substantially on where the data is going — which region, which cloud — and not simply on which warehouse it is leaving. Egress is therefore partly a geographic and cloud-architecture question, decided by choices that may have been made years before anyone considered an exit. That framing is System Drift analysis; the pricing behaviours cited above are documented.

Here the paper moves past network charges. Google’s Snowflake SQL translation guide states that Snowflake scripts may need to be altered before use in BigQuery, because the SQL dialects vary between the two services (Snowflake SQL translation guide). Google also documents SQL translation tooling intended for warehouse migrations (Enable SQL translations for BigQuery migrations).

That is primary evidence — from a platform vendor, about its own migration path — that the concerns of a warehouse migration extend beyond moving stored table data.

The System Drift interpretation: a warehouse holds not only data but executable analytical logic. Queries, views, transformations and scripts express how an organization turns stored rows into information it can act on. Moving the rows does not automatically move that logic into an executable form on another platform.

The limits deserve equal weight. The documentation says dialects vary and scripts may need alteration; it does not say that every query requires manual rewriting, and translation tooling exists precisely because much of the work is mechanisable. System Drift offers no estimate of translation effort, because we have no evidence that would support one.

Google documents a BigQuery migration assessment that can examine metadata and query logs from an existing warehouse, intended to help prepare a migration plan that addresses the time and effort a data-warehouse migration requires (BigQuery migration assessment).

This should be handled carefully. The existence of an assessment product is not evidence that migrations are inherently difficult; vendors build tooling for many reasons, and a smooth migration path is itself a commercial proposition.

Why would a warehouse migration assessment need metadata and query history, if warehouse exit were simply a matter of copying stored bytes?

The System Drift inference — and it is an inference, drawn from the documented shape of the process rather than from any measured outcome — is that the operational object being migrated includes the structures and workloads surrounding the data, not merely the data itself. Query history is a record of how the warehouse is used. That it is an input to migration planning suggests usage patterns, not just stored rows, are part of what has to be reproduced.

A useful way to hold the whole picture is as a chain:

Stored data → Schema → Views → Queries → Transformations → Scheduled workloads → Downstream use

Each step adds organizational meaning to the layer beneath it:

• stored data is the underlying information;
• schemas describe how it is structured;
• views encode representations somebody found useful;
• queries encode the analytical questions being asked;
• transformations turn source data into operational or analytical models;
• scheduled workloads make those transformations recurring;
• downstream systems and people come to depend on their outputs.

Not all of these components are necessarily warehouse-specific. Plenty of transformation logic lives in portable tooling outside the warehouse, and plenty of schemas are ordinary relational structures. The question this paper poses is not whether these layers are proprietary. It is how much of each remains usable when the warehouse underneath them changes — and that is an organization-specific answer, not a general one.

This is the accumulation pattern examined in R-001, appearing in the analytical data layer.

The distinction that follows is the analytical contribution of R-005.

A CSV or Parquet export can satisfy the first entirely. The documentation cited in section 02 shows that such exports are well-supported. What such an export does not by itself resolve is dialect difference, views, transformations and scheduled workloads — each of which has to be addressed on its own terms.

None of this implies those components cannot be migrated. They plainly can; vendor translation tooling exists for exactly that purpose. The issue is reconstruction and translation, not impossibility — and reconstruction is a distinct activity from transfer, with a distinct set of inputs.

This parallels, without being identical to, R-004. There, portable telemetry did not automatically preserve the operational layer built around telemetry. Here, portable stored data does not automatically preserve the analytical system built around it. The mechanisms are related in shape; they are not the same mechanism, and the evidence for each stands separately.

It is useful to separate what the single word “cost” is being asked to carry. These are analytical categories, not measured financial ones:

• Transfer cost — associated with moving data between locations or cloud environments. This is the component the cited pricing documentation addresses directly.
• Translation cost — the work required where SQL dialects, data types, functions or platform semantics differ.
• Reconstruction cost — the work required to recreate structures, transformations, schedules and surrounding integrations that do not transfer directly.
• Knowledge cost — the operational understanding people have accumulated about how the existing warehouse behaves.

“Cost” here can mean money, engineering effort, elapsed time, operational disruption or lost institutional knowledge, and the four categories are not denominated in the same unit. That is precisely why they should not be summed.

System Drift attaches no weights, scores or ordering to these categories, and makes no claim about which is normally largest. Any such ranking would require migration evidence we do not have and have not gathered. The categories are offered as a way to ask better questions, not as a model that produces a number.

These are diagnostic questions rather than recommendations. Most are answerable from an organization’s own configuration and query history.

• Where would exported data physically need to move?
• Which of those transfers would cross regions or cloud providers?
• Which data can be exported into broadly supported formats, and which cannot?
• Which operationally important workloads depend on platform-specific SQL syntax or functions?
• Which views and transformations would need translation?
• Where are scheduled analytical workloads defined — inside the warehouse, or outside it?
• Which downstream systems expect warehouse-specific behaviour?
• Which historical data must remain immediately queryable after a migration?
• Which operating procedures assume the current platform?
• If every table were successfully exported tomorrow, what would still need to be rebuilt before the organization could operate normally?

System Drift attaches no numerical scoring to these questions. An index here would imply a measurement basis that does not exist.

Egress is real and measurable, but an egress charge does not apply in every case. Snowflake documents same-region transfers as free, while Google documents BigQuery batch exports without a processing charge under the conditions described above, although network-transfer charges can still apply depending on destination. Egress is a genuine component of exit, and it is not a proxy for exit.

A warehouse can make its stored data exportable while the analytical system built around that data remains partly platform-shaped.

The useful question is therefore not only “how much will it cost to move the bytes?” but “what must remain functional after the bytes have moved?” That second question is the substance of F·02 Reversibility and F·05 Exit Complexity: an exit that recovers the data but not the operating capability is not a completed exit.

Nothing here implies that warehouse exit is necessarily difficult, that egress fees dominate migration economics, or that Snowflake or Google Cloud designs for dependency. Both vendors document export mechanisms, publish their pricing, and in one case build tooling specifically to assist migration away from a competitor. The subject of this paper is the structure of reversibility, not vendor intent.