DEV Community: Krishna Tangudu

My Snowflake Agent Was Wrong. So Was My Evaluation.

Krishna Tangudu — Mon, 28 Sep 2026 03:00:59 +0000

What production conversations taught me about fixing the right layer—and checking whether the fix actually worked.

When an agent gets a disappointing evaluation score, I now ask three questions:

Did it answer the question correctly?
Did it take an appropriate path to the answer?
Was the evaluation measuring the behavior I actually wanted?

In my Snowflake agent, those answers did not always agree. A revised lookup recovered an object but still received partial tool-selection credit. Other test expectations omitted steps my instructions required. And one application counter made missing telemetry look like zero tool use.

I was maintaining three things at once: the agent, the evidence about its behavior, and the tests judging it. Changing the prompt was only one possible fix.

These examples are drawn from my work with a Snowflake Cortex Agent and have been anonymized. The outcomes described are specific observations and retests, not a controlled benchmark.

The fix lived between the agent and its tool

My agent said an object did not exist. The metadata contained it—but as a source consumed by other views, not as the view the agent was searching for.

I added a fallback instruction. The lookup still failed.

The investigation then suggested the semantic tool could not search by source. Inspecting its definition corrected that explanation: the source dimension already existed. Its SQL-generation guidance emphasized view-name searches.

The successful revision changed both layers. The agent received a fallback telling it when to ask which views consume this source? The semantic view received guidance explaining that lookup to Cortex Analyst. The recorded retest recovered the object and its consumers.

An anonymized reconstruction. The source dimension already existed; the change clarified its use.

This matters because “the data is missing,” “the tool cannot do it,” and “the agent did not ask correctly” lead to very different fixes. The investigation briefly entertained each explanation. Inspecting the definition and retesting was more useful than accepting the first diagnosis.

Even the successful retest had a boundary. Finding downstream consumers did not establish how every upstream object was loaded. A later correction in the conversation made that distinction explicit. A lineage lookup should not turn into an unsupported explanation of the ingestion architecture.

The evidence I actually used

I read real questions, responses, and follow-ups alongside native execution traces. A scheduled Cortex Code review triaged instruction gaps, data gaps, and tool limitations; its findings were leads to investigate. I materialized trace summaries to retain a longer investigation trail. That addressed the history available in my environment, not a universal retention limit. Snowflake monitoring documentation

Comparing sources mattered: my application's tool-call counter defaulted missing metadata to zero, while native traces showed activity it had missed. A missing measurement had been made to look like a measured zero.

How I judge an evaluation

“What was the score?” needs a second question: the score for what?

Snowflake separates several checks:

Check	What it judges
Answer correctness	An LLM judges the answer against expected content.
Tool selection accuracy	Deterministic matching of expected and actual tool names and call counts; order is ignored.
Tool execution accuracy	Expected inputs and outputs are compared with matching tool invocations.
Logical consistency	An LLM checks consistency across instructions, planning, and actions without reference answers.

Tool selection can penalize extra calls even when the answer improves. A low tool-selection score is therefore not an answer-accuracy percentage. The mechanics are in the appendix and Snowflake’s evaluation documentation.

That distinction explained some of my confusing results. Expected tool lists sometimes omitted prerequisites required by the instructions. Other cases allowed only one route where more than one route could be appropriate.

But I should not make a test easier just because the agent failed it. Each change to the expected behavior needs an independent reason: a verified alternative route, a documented prerequisite, or a correction to the case itself.

The missing-object case illustrates why I inspect individual records. The combined fix recovered the lookup, while extra calls still limited its tool-selection score. That supported a narrow conclusion: the retrieval behavior improved in that retest. It did not prove that every returned statement was correct or that the whole agent improved.

Real questions are good test inputs. Old answers are not automatically ground truth.

Real conversations supply questions I would not invent in a demo. Turning them into tests also creates traps. A follow-up such as “generate the query for this model” loses its meaning when detached from the preceding conversation. A previously successful API response may contain a wrong answer. A time-sensitive answer can become stale.

For a useful regression case, I need the question's context, independently checked expectations, acceptable uncertainty, and the behavior that must not recur. I also keep successful examples so that a targeted fix does not quietly damage an existing workflow.

Changing the questions or expected answers creates a new test baseline. Comparing its average with an older baseline as if only the agent changed would overstate the improvement.

Did the test exercise the capability?

The traces also challenged what I thought my tests covered. After enabling a Python sandbox, even XML-focused cases did not show its use in the recorded inspection. A targeted test described programmatic parsing but followed the existing retrieval-and-skill path. Configured, mentioned in planning, and invoked are different states. A correct answer through another route could pass an answer test while leaving the sandbox untested. I needed evidence of invocation and correct extraction before attributing an improvement to Python.

The right answer can still be the wrong interaction

Another incident involved an object name with words in the wrong order. The agent found a plausible alternative and began analysing it. The user had to correct the selection.

I introduced similar-name search and confirmation. Tool checks showed that candidate retrieval worked. Then I tested through the application.

The revised agent found the intended candidate—and continued into analysis without asking me to confirm it.

Retrieval had improved. The interaction still violated the requirement.

Illustrative animation. The conversation records my confirmation that the strengthened rule worked in a manual retest; it does not establish a broad success rate.

The stronger instruction specified the stopping boundary: present candidates, ask which one to use, and end the response before doing lineage or column analysis. It also included examples of the unwanted and intended behavior.

For this case, my proposed regression checks are concrete:

Situation	Expected behavior
Exact object exists	Analyse that object.
Exact object is absent; alternatives exist	Present candidates and ask; do not analyse a substitute yet.
No candidates exist	Explain the search boundary without inventing an object.
User confirms a candidate	Continue with the confirmed object.

Here is a synthetic test pattern a reader can adapt. It is a proposed regression fixture, not a reproduced production test or response:

Test: approximate object name requires confirmation
Given:
  Exact-name lookup returns no match.
  Candidate lookup returns synthetic objects A and B.
Before: the agent chooses a candidate and begins analysis.
Required after:
  Present A and B with distinguishing context.
  Ask the user to choose, then end the turn.
Pass only if:
  The final response asks for a choice AND contains no
  lineage results, column analysis, or assumed selection.
Fail if:
  The agent analyses either candidate before confirmation,
  even if it also includes a question.
Next turn:
  User selects B; analysis must refer to B, not A.

Use fixed lookup fixtures to isolate the interaction rule, then repeat through the real application with its actual tools. A question mark alone is not a pass. Inspect the meaning of the response and the trace for premature analysis.

A final-answer similarity score alone would miss part of that contract. I need to check the turn where the agent was supposed to stop.

There was a deeper reason to care about that pause. During these reviews, I worried that someone less familiar with our domain might accept a confident response without knowing when to challenge it. A domain expert might catch the wrong object; another user might build on the explanation. That concern was not a measured comparison between user groups. It changed how I reviewed answers: lack of pushback could not count as evidence of correctness. Asking for confirmation exposes a choice the agent would otherwise make silently, though confirmation alone does not verify the analysis that follows.

Each revision should explain its reason

My changes were not all additions to the main prompt. They addressed different layers:

Symptom	Layer to investigate
Wrong object selected without confirmation	Agent interaction instructions
Metadata exists but the lookup asks the wrong question	Agent routing and semantic-view guidance
Specialist parsing or traversal is incomplete	Domain skill and source coverage
Needed computation is unavailable	Tool capability, followed by invocation tests
Generated output cannot be accessed in the application	Delivery channel and response format
Plausible answer receives unexpected evaluation penalties	Expected behavior and per-case scoring
Tool use appears absent in one dashboard	Instrumentation and native trace evidence

A deployment mistake changed my rule. The agent was recreated during this work, resetting its native version history while our conversation still used the old labels. I explicitly said not to recreate it again without asking me. For routine revisions, my preferred workflow became modifying and committing a version of the existing agent; recreation needed a separate, explicit decision. A configuration edit should not casually become an object replacement.

That experience made the release record concrete: connect each change to the native agent identity and version, skill revision, semantic-view definition, dataset, and scoring configuration. A conversation label cannot substitute for that record. The appendix shows selected version reasons.

None of this happened in a quiet, finished post-mortem. I was correcting evaluation expectations while also checking whether recent questions from stakeholders had received reasonable answers, responding to feedback, and inspecting the next interaction. The service remained in use while I was learning how to evaluate it. The tidy sequence in this article emerged from that overlap; it was not a process I had perfected before users arrived.

What I would do first on the next agent

I did not begin with a formal AI lifecycle. I began with people correcting the agent.

That grew into a repeatable engineering practice: retain the relevant evidence, investigate the failure, change the appropriate layer, and test the behavior again. Keep observations separate from hypotheses. Keep a successful component test separate from an application retest. Keep a better evaluation score separate from a better answer.

If I were starting again, I would write the regression case before the fix:

What should the agent do differently when someone asks this again—and what evidence would convince me it did?

That question has been more useful than asking whether the agent is finally “good.”

Appendix: the details behind the story

Evaluation mechanics

For tool selection, the documented formula is matched calls divided by the larger of expected entries or actual calls. An illustrative, invented example: one expected call and four actual calls, with one match, scores 0.25. That does not mean the answer is 25% correct. Tool execution handles extra calls differently. Its inputs and outputs are optional; omitting both checks invocation presence rather than execution quality. Tool-level coverage is limited, so unsupported tool behavior needs another check. Cortex Agent evaluations

Retaining an investigation trail

I materialized trace summaries on a schedule to extend the investigation window, with known limitations around join precision and late-arriving spans.

Selected version reasons

Selected native versions and their reasons. These labels belong to the retained history after agent recreation; they do not measure performance gains.

Natural Language Is the Interface, Not the Semantic Layer

Krishna Tangudu — Tue, 15 Sep 2026 18:48:24 +0000

This is Part 2 of a two-part technical series. Part 1 showed how an Enterprise Data Discovery Assistant recovers legacy logic and produces grounded SQL. Rupak's article on AI-ready data products provides the larger context: agents need machine-readable semantics, active contracts, and engineering guardrails. This post follows the next step—from a business question to governed execution and an explained answer.

All names, identifiers, queries, and results below are synthetic. Quantities are rounded to communicate scale without publishing an internal inventory.

Natural language does not remove the need for data modeling. It makes good data modeling visible to more people.

Our preview tests asked whether business users could explore an enterprise-scale Customer 360 domain—more than 100 million records across multiple curated tables—without first learning schemas, joins, or SQL.

The answer was encouraging, with an important qualification: natural language is the interface, not the semantic layer.

One question hides several decisions

Consider a straightforward request:

Which customer segments had the highest order value last quarter, and how did that change from the previous quarter?

Before SQL can run, the system must resolve what order value means, which field represents customer segment, how orders relate to customers, which calendar defines last quarter, whether the user is allowed to see the requested data—and whether the data product is trustworthy right now.

A language model looking only at table and column names may guess. A semantic view makes the analytical decisions explicit: grain, metrics, time semantics, filters, and supported relationships. Snowflake policies determine who may access the result, while our runtime contract check determines whether the data product is fit to use now.

It defines:

Logical tables, row grain, primary keys, and unique keys, so the meaning of one row is explicit.
Dimensions and time dimensions, such as customer segment and fiscal quarter.
Facts and governed metrics, including aggregation and distinct-count behavior.
Relationships, including bridge tables for many-to-many associations, so join paths are modeled rather than improvised.
Filters, synonyms, and question-handling instructions.
Verified queries, which pair important question patterns with reviewed SQL.

Snowflake recommends semantic views for new Cortex Analyst implementations. They are schema-level objects integrated with Snowflake privileges and metadata—not prompt text pretending to be governance.

A semantic view tells the assistant what the data means. A data contract tells it whether that data product is fit to use now.

For governed business questions in our preview, the assistant performs a mandatory contract check before using the analytical semantic view. It evaluates the target domain's contract health, freshness, latest validation result, and any failure reason.

The contract check is application logic around the agent; it is not performed automatically by the semantic view itself.

From question to governed answer

The flow is deliberately simple:

The Enterprise Data Assistant identifies the user's intent and target business domain.
A data-contract check evaluates contract status, freshness, quality, and the latest validation outcome before the business query runs.
The contract result determines the response path: proceed normally when trustworthy, or attach the appropriate warning when the data is degraded, stale, inactive, or failed.
Cortex Analyst interprets the question using the selected semantic view, which supplies the governed dimensions, metrics, relationships, filters, and examples needed to generate SQL.
The SQL runs inside the governed data platform. Snowflake privileges and data-protection policies still apply.
The response returns the result together with the SQL, definitions, scope, and any required warning.

The distinction matters. When the contract is active, fresh, and passing, the check stays behind the scenes and the user gets a clean answer. A stale or degraded contract adds a caution. An inactive or failed contract produces a prominent warning that the result is not guaranteed before the preview attempts the query. For a higher-risk domain, the same decision point can be implemented as a hard stop.

Cortex Agents can use Cortex Analyst for structured data and route across multiple semantic views. Cortex Analyst first attempts semantic SQL, where metrics, dimensions, and relationships come from the semantic view. When the modeled coverage cannot satisfy a request, Routing Mode can fall back to standard SQL on physical tables. That flexibility is useful, but for governed metrics the fallback should be treated as a different confidence path: expose it for review, request clarification, or block it for higher-risk questions rather than imply that it carries the same semantic guarantees. Snowflake documents this behavior as Routing Mode.

The answer should show its work

The experience should still feel conversational. The difference is that the answer exposes enough evidence for a user or engineer to challenge it.

Synthetic demonstration: no production interface or customer data is shown.

For the example above, the response contract is more important than the visual polish. It should make six things clear:

What the user sees	Why it matters
A concise answer	The user gets the result without reading SQL first.
Metric and dimension definitions	Business terms are not left open to interpretation.
Time range and filters	The scope of the answer is explicit.
Contract warning, when relevant	Users know when freshness or quality may affect trust.
Generated SQL	An engineer can inspect and reproduce the query.
Warnings or clarification	Ambiguity is surfaced instead of silently resolved.

That is a more useful standard than “the chatbot returned an answer.”

Accuracy is an engineering loop

Semantic metadata improves grounding, but it does not prove that every generated query is correct.

Important question patterns should be captured in a Verified Query Repository: a natural-language question paired with SQL whose logic and result have been validated by a qualified reviewer. The SQL should use the logical tables and columns defined by the semantic view rather than bypassing them for physical objects. Cortex Analyst can use relevant verified queries to guide similar requests. A verified example is guidance—not a blanket certification of every future answer. Snowflake's Verified Query Repository documentation makes that distinction concrete.

The next layer is repeatable evaluation. Current Cortex Analyst evaluations compare generated SQL results with selected verified queries, track regressions, and record latency. This turns semantic-layer tuning into a measurable build-test-run-improve cycle instead of a collection of impressive demos. Snowflake documents the evaluation workflow here.

We also learned to compare results, not only SQL. Reconciliation must use the same as-of timestamp, fiscal calendar, currency logic, exclusion rules, and entity scope. Two syntactically valid queries can still answer different business questions.

Our practical checklist is:

Start with a narrow, coherent business domain.
Define grain, keys, relationship cardinality, metrics, filters, and synonyms explicitly.
Add reviewed queries for high-value and high-risk questions.
Test ambiguous wording, invalid requests, boundary cases, and every contract state—not only the happy path.
Track accuracy, regression, latency, and workload cost with representative questions.
Show the generated SQL and scope when the audience needs traceability.

Governance does not disappear behind chat

A conversational interface must not become a shortcut around access controls.

Access control and data contracts answer different questions. Privileges determine whether this user may access the data. The contract check determines whether the selected data product should be trusted in its current state. A governed assistant needs both decisions; neither replaces the other.

Semantic views participate in Snowflake's privilege model. Row-access and masking policies applied to underlying tables can propagate to the semantic view and remain enforced. One subtle but important caution from Snowflake's guidance is that sample values stored as semantic metadata are not masked, so sensitive examples should not be embedded there. See Snowflake's development and deployment guidance.

There are product boundaries too. Cortex Analyst is designed for questions that can be resolved with SQL; it is not automatically a general business-insight engine. It also cannot refer to the results of a previous SQL query as if it had retained that result set. Those limits should shape both the user experience and the test suite. The current limitations are documented here.

What changed between Part 1 and Part 2

Part 1 recovered the knowledge needed to rebuild a data product: joins, filters, calculations, ownership, and dependencies.

Part 2 makes approved knowledge queryable:

Recovered legacy knowledge
          ↓
Governed data product + semantic view + contract
          ↓
Natural-language question
          ↓
Data-contract decision
          ↓
Semantic grounding + governed SQL
          ↓
Explained result

The language model is useful at the top of this stack because the hard decisions are represented beneath it.

That is the larger lesson from the preview. Natural-language analytics is not a replacement for engineering discipline. Done well, it is a new interface to that discipline—one that lets more people ask useful questions while keeping definitions, access, SQL, and validation visible.

Mirroring Snowflake Iceberg into Microsoft Fabric : The Gotchas - Part 2:

Krishna Tangudu — Thu, 10 Sep 2026 17:32:05 +0000

Previously: In Mirroring Snowflake Iceberg into Microsoft Fabric: The Gotchas, I documented connection issues, permissions, and the difference between healthy mirroring and a usable SQL analytics endpoint.

The goal remains the same: give analysts a shared serving layer in Fabric without making every downstream workflow query Snowflake independently.

Since that post, two support investigations have added to the picture. One concerns the cost of continuous mirroring when the source changes only a few times daily. The other reverses an earlier troubleshooting pattern: the SQL analytics endpoint reads the data, but Spark fails.

This is the checklist of what we have learned, which workarounds we have used, and the options we plan to evaluate next. Checked items describe experience or completed investigation. Unchecked items are future tests, not claimed results.

1. What we have done so far

[x] Established the Snowflake–Fabric integration. The first post covers the connection and permission fixes, including separate access to Iceberg storage.
[x] Separated replication health from query behavior. We validate actual results through the consuming engine, rather than treating a healthy status as sufficient.
[x] Compared SQL analytics endpoint and Spark behavior on the decimal issue. SQL succeeded where the affected Spark read failed.
[x] Validated the source, table, and file schemas. We submitted those findings to Microsoft support.
[x] Tested the non-vectorized Spark workaround. Reads succeeded; we subsequently reported performance and capacity impact.
[x] Investigated mirroring schedules, restart behavior, and Delta CDF. Support confirmed the limitations described below.
[ ] Measure whether Snowflake AWS-to-Azure replication improves the total economics. This is our next architecture experiment.

2. Continuous mirroring: the business clock matters

Our source data changes approximately three times per day. The mirroring support case described a Snowflake cloud Layer cost spike and asked a practical question: can we run replication around those updates instead of continuously?

At roughly 2,500 tables across the estate, maintaining an individual pipeline for every table would also be a substantial burden. That concern is about operational scale; it does not mean every batch design requires a separate pipeline per table.

What the investigation established:

[x] Scheduling: Microsoft documents no configurable mirroring schedules or replication windows today. Snowflake mirroring guidance
[x] Stop/start behavior: support confirmed a full reload rather than continuation from the previous CDC position, consistent with the public FAQ. A timer around stop/start is therefore not equivalent to a scheduled incremental load. Snowflake mirroring FAQ
[x] Disabling the service user: support explained that this is not a supported scheduling mechanism; connection retries and recovery become part of the problem.
[x] Alternative suggested: support recommended evaluating a Copy activity or Copy job, while acknowledging that this requires architectural work.

The case is closed, but the correspondence acknowledges a scheduling limitation. It does not record delivery of a scheduling fix.

3. The decimal issue: SQL worked, Spark did not

The second case captured this error, with the column anonymized:

Parquet column cannot be converted ...
Column: [AMOUNT], Expected: decimal(15,2), Found: INT32

Our diagnostics showed:

Layer	Reported representation
Snowflake source column	NUMBER(15,2)
Fabric table schema	decimal(15,2)
Examined Parquet file	decimal(9,2), backed by INT32
SQL analytics endpoint	Query succeeded
Affected Spark read	Failed with vectorization enabled
Spark with vectorization disabled	Read succeeded

The logical table schema and a file's physical encoding are different layers. The failing read path did not successfully reconcile the narrower file representation with the declared decimal type. The observed result was a read failure, not evidence of corrupted business values.

Microsoft's public guidance lists the type-width issue and the Spark workaround. OneLake Iceberg limitations

[x] Workaround used: disable the vectorized Parquet reader in the affected Spark session.
[x] Impact reported: performance and capacity concerns

Here is a scoped illustration of the workaround, using fictional table and column names:

# Fabric PySpark: use a small, known slice of an affected table.
setting = "spark.sql.parquet.enableVectorizedReader"
original = spark.conf.get(setting)

try:
    spark.conf.set(setting, "false")
    rows = spark.sql("""
        SELECT order_id, amount
        FROM dbo.orders_iceberg
        WHERE order_id IN (101, 102, 103)
    """).collect()
    print(rows)
finally:
    spark.conf.set(setting, original)

The action runs before the setting is restored. This example illustrates the configuration used; it is not a new benchmark or a reproduction executed for this article. A simple query showed a performance difference from 20 seconds to 2 minutes 26 seconds.

The lesson extends my previous post: SQL and Spark both need independent acceptance tests. Either engine can expose a limitation that the other does not.

4. Options on our checklist

Option	Our status	Why it is relevant	What still needs proof
Existing Snowflake mirroring / Iceberg integration	Used; support cases investigated	Shared Fabric serving layer	Sustainable cost and consistent engine behavior
SQL analytics endpoint for affected reads	Worked in the reported case	Keeps compatible SQL workloads usable	Coverage of workloads that currently require Spark
Spark non-vectorized reader	Tested workaround	Restores affected reads	Performance and capacity at production scale
Scheduled Copy job or reusable Copy pipeline	Official option; not benchmarked here	Direct control over movement frequency	CDC eligibility, deletes, schema changes, cost, and management at scale
Snowflake AWS → Snowflake Azure replication	Planned next experiment	Place a controlled replica nearer Azure consumers	Eligible objects, consumer access, freshness, and total cost
Direct Snowflake access	Tested workaround	Keeps users productive	Source load and total BI/query cost

5. What comes next: Snowflake AWS → Snowflake Azure

Our hypothesis: a scheduled Azure replica may be cheaper to operate when it replaces substantial repeated reads across the cloud boundary. We have not established savings yet.

The candidate flow is:

Snowflake AWS source
        |
        | scheduled Snowflake replication
        v
Snowflake Azure secondary + target-region storage where required
        |
        | consumer path to validate separately
        v
Fabric Iceberg access

Snowflake officially supports replication across AWS and Azure within an organization. Replication groups provide read-only secondaries and configurable refresh schedules. Database replication is available across editions; failover groups and various account-object capabilities have additional edition requirements. Replication overview, Replication schedules

We are evaluating replication for read access. Failover is a separate operating requirement and should not be introduced merely to make a read-only secondary writable for an integration.

6. The cost test that will decide the direction

Snowflake replication adds transfer and service-compute charges, billed to the target account, plus target storage costs. Refresh frequency and changed data volume affect the total. The initial seed must be measured separately from steady-state refreshes. Snowflake replication cost

Our comparison will be:

Current path:
  source integration activity + transfer/storage requests
  + Fabric serving cost + operating effort

Azure replica path:
  replication transfer + replication compute + target storage
  + Azure-side integration/query cost + Fabric serving cost
  + operating effort

These are measurement categories, not a savings estimate. For external Iceberg storage, include the applicable cloud-storage bill as well as Snowflake and Fabric usage.

My current direction is to test Azure replication. The former tests whether data location is driving unnecessary cost; the latter tests whether movement frequency is the larger problem. The decimal issue remains its own compatibility test.

That is what I want the next installment to report: which option we tested, what improved, what it cost, and what still required a workaround.

Moving Data Is Easier Than Moving Knowledge

Krishna Tangudu — Mon, 07 Sep 2026 04:15:25 +0000

This is Part 1 of a two-part technical series. Rupak's article on building AI-ready data products describes the larger destination: a machine-readable context layer, governed semantics, and engineering guardrails. This post tackles the migration problem that comes first—recovering legacy knowledge and turning it into grounded SQL. Part 2 will cover natural-language questions, governed execution, and explained answers.

All examples and names below are synthetic

Moving data is often the easier part of an SAP-to-cloud migration. Moving the knowledge is harder.

A pipeline can copy a table. It does not automatically carry forward why two tables are joined, which filter defines an open order, how technical statuses become business terms, or who owns the report.

Without that context, a new platform can produce a technically valid answer that is wrong for the business.

A question the copied tables cannot answer

Imagine an estate with more than 5,000 SAP HANA calculation views, hundreds of Qlik and Spotfire applications, and more than 2,500 cloud tables.

A data engineer receives a simple request:

Rebuild our sales-order backlog dashboard. What existing logic should I preserve?

The answer is scattered. A HANA calculation view may define the joins, filters, and open quantity. A Qlik application may map technical statuses and write a shared QVD. A Spotfire analysis may implement its own aging logic. Ownership and downstream usage may live in reporting metadata, while field-level dependencies live in a lineage graph.

Qlik and Spotfire are parallel reporting platforms over HANA. They are not sequential stages feeding one another; the same HANA model may support applications in either or both.

The migration task is therefore not just code conversion. It is evidence discovery.

How the assistant builds context

We call the user experience an Enterprise Data Discovery Assistant. Under the hood, a bounded Snowflake Cortex Agent selects retrieval and analysis tools. “Agent” describes the architecture; “assistant” describes its read-only responsibility. It does not change source systems, deploy code, or promote pipelines.

Engineer question
       |
       v
Enterprise Data Discovery Assistant
       |
       +-- HANA repository code
       +-- Parallel BI artifacts
       |      +-- Qlik scripts and QVDs
       |      +-- Spotfire queries and metadata
       +-- Reporting metadata catalog
       +-- Schema, object, and column lineage
       |
       v
Recovered logic + ownership + dependencies
       |
       v
Grounded SQL draft -> data-engineer validation

The four evidence layers play different roles:

HANA repository code provides the calculation-view definition. Parsing indexed .hdbcalculationview XML reveals sources, joins, filters, calculated columns, unions, and nested-view dependencies.
Parallel BI artifacts reveal reporting logic. Qlik contributes load queries, aliases, mappings, resident loads, and QVD flow. Spotfire contributes source queries, columns, and any calculations present in its indexed metadata or exports.
The reporting metadata catalog connects Qlik and Spotfire applications to HANA models, queries, fields, owners, paths, saved-query details, and comments. It adds operational context around the code; it does not replace the code.
Schema and lineage metadata traces upstream sources, downstream consumers, object dependencies, and column paths, then helps map recovered logic to approved target objects.

Together, these sources answer more than “What SQL should I write?” They can also answer: Who owns this dashboard? Which reports use this HANA view? Which QVDs feed the application? What could break if the model changes?

Search locates the artifacts. Deterministic parsers extract their structure. The language model relates the findings to the engineer's question.

From a question to grounded SQL

The experience should feel like a conversation, not a metadata report. The engineer asks one question; the assistant shows what it checked and returns an evidence-backed answer with SQL.

Synthetic chat demonstration: no production data or internal interface is shown.

The response separates recovered facts from the proposed target design. In this example, the assistant verifies the HANA joins and filter, recovers the Qlik status mapping and QVD flow, identifies the owner, and finds downstream Qlik and Spotfire consumers before drafting SQL.

Only then does the assistant propose a starting point:

SELECT
    i.order_id,
    i.ordered_qty - i.confirmed_qty AS open_quantity,
    s.business_status
FROM sales_order_item AS i
LEFT JOIN status_map AS s
    ON i.status_code = s.status_code
WHERE i.cancelled_flag = 'N';

The SQL is useful because its origin and limitations are visible—not because it appeared quickly.

Grounded SQL is a handoff

The draft is not a production pipeline. A data engineer still confirms the grain, compares results with the legacy report, maps the logic to canonical target names, and preserves null, fallback, and refresh behavior. Production work also requires incremental patterns such as CDC or watermarks, data-quality tests, security, documentation, owner approval, and CI/CD which was covered in Developer Toolkit.

Trust comes from a few explicit boundaries:

Prefer exact identifiers when available; use semantic search for discovery, then verify the selected objects.
Parse large HANA XML and Qlik scripts deterministically.
Separate verified evidence, proposed design, and missing evidence.
Keep generated code read-only until it passes normal engineering review and testing.

If an expected Qlik or Spotfire expression is absent from the indexed sources, the assistant says so instead of reconstructing it from assumptions.

The same human-in-the-loop pattern shaped the assistant itself. Snowflake CoCo,supported the build-and-tune cycle by helping refine tool instructions, test prompts, failure analysis, and response behavior. Engineers decided which changes to adopt and validated the results.

Moving data gives a new platform rows and columns. Moving knowledge preserves the meaning, ownership, and dependencies people rely on—and provides the context needed to build governed data products.

Part 2 will follow a natural-language question through governed SQL execution and show how the final answer explains its sources and limitations.

From Optimization to Protection: Adding a Security and Governance Agent to Your Snowflake Multi-Agent Team (Part 3)

Krishna Tangudu — Thu, 09 Jul 2026 21:26:01 +0000

From Optimization to Protection: Adding a Security and Governance Agent to Your Snowflake Multi-Agent Team (Part 3)

In Part 1, we built an Admin Agent for usage and cost visibility.
In Part 2, we added a Cost Optimizer Agent and an Orchestrator that routes questions to specialists.

Now we close the loop with the third specialist: a Security and Governance Agent.

This turns your assistant from "what happened" and "what to optimize" into a full team that also answers "what is risky right now".

By the end of this post, you will have:

A Security and Governance Agent with focused security tools
Security semantic views mapped to natural language
Orchestrator routing across Admin, Cost Optimizer, and Security agents
A practical triage workflow for failed logins, privilege risk, and unauthorized access

Why Add a Security Specialist?

The first two agents are strong for operations and spend, but security requires a different lens:

Access control and role hygiene
Failed login patterns and anomaly detection
Unauthorized access attempts
Inactive users with active privileges
Compliance-friendly audit summaries

Could one large agent do everything? Sometimes. But specialized agents are easier to maintain, safer to evolve, and easier to test.

Final Team Architecture

User Question (natural language)
        |
  Orchestrator Agent
   /      |        \
Admin   Cost     Security
Agent  Optimizer Governance
                 Agent
        \    |    /
      Unified Response

Role of each specialist

Admin Agent: usage, credits, storage, operational metrics
Cost Optimizer Agent: idle compute, rightsizing, optimization opportunities
Security and Governance Agent: roles, privileges, failed logins, unauthorized access, audits

The Security Pattern (Same Foundation as Parts 1 and 2)

Step 1: Base Views

Create security-focused views over SNOWFLAKE.ACCOUNT_USAGE, including:

Role hierarchy and privilege grants
Failed login attempts and anomaly severity
Excessive or unused privileged access
Unauthorized access attempts
User and role audit summaries
Network policy activity

Implementation file:

sql/08_create_security_governance_views.sql

Step 2: Semantic Views

Map these views into natural language dimensions, facts, and metrics so Cortex Analyst can reason over them.

Examples:

SV_LOGIN_ANOMALIES
SV_EXCESSIVE_PRIVILEGES
SV_UNAUTHORIZED_ACCESS_ATTEMPTS
SV_USER_ROLE_AUDIT

Implementation file:

sql/09_create_security_governance_semantic_views.sql

Step 3: Create the Security Agent

Define a dedicated agent with explicit analyst tools for each security domain:

CREATE OR REPLACE AGENT <APP_DB>.<APP_SCHEMA>.<SECURITY_AGENT_NAME>
  COMMENT = 'Security and Governance agent for access control and compliance'
  FROM SPECIFICATION
  $$
  instructions:
    response: "You are a Security and Governance assistant..."
    orchestration: "Route role hierarchy questions to RoleHierarchyAnalyst; \
                   privilege grants to PrivilegeGrantAnalyst; \
                   failed logins to FailedLoginAnalyst; \
                   login anomalies to LoginAnomalyDetector..."

  tools:
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "RoleHierarchyAnalyst" }
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "PrivilegeGrantAnalyst" }
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "FailedLoginAnalyst" }
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "LoginAnomalyDetector" }
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "ExcessivePrivilegeAnalyst" }
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "UnauthorizedAccessAnalyst" }
    - tool_spec: { type: "cortex_analyst_text_to_sql", name: "UserAuditAnalyst" }
  $$;

Implementation file:

sql/11_create_security_governance_agent.sql

Step 4: Route Through the Orchestrator

Your orchestrator now includes SecurityAgent as a first-class route target.

-- in sql/12_create_orchestrator_agent.sql
-- Questions about security, roles, privileges, failed logins, unauthorized access -> SecurityAgent

It can also fan out to multiple agents for blended questions.

Example 1: Security-Only Routing

Question:
"Are there suspicious login failures in the last 7 days?"

What happens:

Orchestrator classifies this as security monitoring
Routes to SecurityAgent
SecurityAgent uses SV_LOGIN_ANOMALIES
Returns severity-based findings and recommendations

Example response:

Login Anomaly Summary (Last 7 Days)

Critical: 2 users with >= 10 failed attempts/hour
High: 5 users with 5-9 failed attempts/hour
Pattern: Multiple failed attempts from distinct IPs for USER_X

Recommendation:
- Lock and verify impacted accounts
- Enforce MFA re-registration for affected users
- Review network policy and source IP ranges

Example 2: Privilege Governance

Question:
"Which users have ACCOUNTADMIN or SECURITYADMIN but low recent usage?"

What happens:

Routed to SecurityAgent
Uses SV_EXCESSIVE_PRIVILEGES
Identifies high-risk assignments with low usage

Example response:

Excessive Privilege Findings

Users flagged: 4
Critical: 2 users with no privileged role usage in 60+ days
High: 2 users with < 5 privileged queries in 90 days

Recommendation:
- Revoke unused privileged grants
- Replace standing privilege with just-in-time elevation
- Document business justification for remaining elevated users

Example 3: Cross-Agent Investigation

Question:
"Why are costs up and is there any security risk around this?"

What happens:

Orchestrator identifies multi-domain intent
Routes to AdminAgent + CostOptimizerAgent + SecurityAgent
Aggregates usage, optimization, and security posture into one answer

Example response:

Integrated Account Assessment

Operations (Admin Agent)
- Compute credits up 18% month-over-month
- Growth concentrated in two ETL warehouses

Optimization (Cost Optimizer Agent)
- Idle percentage > 60% on one ETL warehouse
- Suggested AUTO_SUSPEND change could reduce waste materially

Security (Security Agent)
- One privileged user inactive but still assigned elevated role
- Increased failed login attempts from multiple IPs for two accounts

Priority Actions
1) Apply warehouse auto-suspend tuning
2) Review elevated role assignments and revoke unused grants
3) Investigate failed-login anomalies and tighten network controls

Deployment Sequence

If you already deployed Parts 1 and 2:

# 1) Security views
sql/08_create_security_governance_views.sql

# 2) Security semantic layer
sql/09_create_security_governance_semantic_views.sql

# 3) Security agent
sql/11_create_security_governance_agent.sql

# 4) Orchestrator (includes SecurityAgent routing)
sql/12_create_orchestrator_agent.sql

Testing Queries

Direct test:

SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN(
  '<APP_DB>.<APP_SCHEMA>.<SECURITY_AGENT_NAME>',
  '{"messages":[{"role":"user","content":[{"type":"text","text":"Show failed login anomalies by severity"}]}]}'
);

Orchestrated test:

SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN(
  '<APP_DB>.<APP_SCHEMA>.<ORCHESTRATOR_AGENT_NAME>',
  '{"messages":[{"role":"user","content":[{"type":"text","text":"Analyze account risk: costs, idle warehouses, and failed logins"}]}]}'
);

Practical Notes

SNOWFLAKE.ACCOUNT_USAGE views have latency. For near-real-time incident response, combine this with event-driven telemetry.
Keep role and privilege reviews on a recurring schedule (monthly or quarterly depending on policy).
Use placeholders and environment-specific grants consistently:
- <APP_DB>.<APP_SCHEMA>
- <EXEC_WAREHOUSE>
- <ADMIN_ROLE>, <DEVELOPER_ROLE>

What We Have Now

After Part 3, you have a complete multi-agent Snowflake administration team:

Admin Agent for operational visibility
Cost Optimizer Agent for efficiency and savings
Security and Governance Agent for risk and compliance
Orchestrator Agent for seamless, natural-language routing across all three

This is where multi-agent design pays off: each specialist stays focused, and users still ask one simple question.

Code References

Security base views: sql/08_create_security_governance_views.sql
Security semantic views: sql/09_create_security_governance_semantic_views.sql
Security agent: sql/11_create_security_governance_agent.sql
Orchestrator routing: sql/12_create_orchestrator_agent.sql
Security skill guidance: skills/security-governance/SKILL.md

Code Repository

Complete implementation:

Conclusion

Part 1 gave us visibility.
Part 2 gave us optimization.
Part 3 gives us governance and risk control.

Same architecture pattern, broader coverage:
Views -> Semantic Views -> Specialist Agent -> Orchestrator

Next directions:

Add automated alerting and ticket creation workflows
Add remediation playbooks per risk severity
Add environment-level policy checks for continuous compliance

Questions or feedback? Drop a comment below.

Part 1: Ask Your Snowflake Account Anything - Build an AI Admin Agent
Part 2: From One Agent to Many - Building a Multi-Agent Team
Part 3: Security and Governance Agent (this post)

Mirroring Snowflake Iceberg into Microsoft Fabric: The Gotchas - Part 1:

Krishna Tangudu — Thu, 11 Jun 2026 22:53:42 +0000

Previously: In Power BI Connectivity with Azure AD, I walked through enabling end-to-end SSO from Power BI to Snowflake.

In this post: A hands-on implementation log for Snowflake mirroring (including Iceberg tables) in Microsoft Fabric — what official docs confirm, what broke in production, and the runbook that now works. If you're seeing differences between Mirroring Status and SQL Analytics Endpoint, this should help.

Our goal was to serve analysts from Fabric's shared OneLake layer instead of having every downstream workflow repeatedly query Snowflake directly.

TL;DR

Fabric Mirroring for Snowflake continuously replicates source data into OneLake.
For Iceberg tables, Fabric replicates metadata to OneLake via shortcuts to the underlying storage and OneLake exposes data in Delta format for Fabric workloads.
SQL Analytics Endpoint is read-only and can show type/metadata limitations even when mirroring is healthy.
New or changed tables can take time to appear consistently in SQL Analytics Endpoint because replication and SQL metadata sync are separate steps.
Connection configuration accuracy matters (especially warehouse identity and permissions).
Not all Snowflake table types are eligible for mirroring.

What I validated against official Microsoft docs

1. How mirroring works for Snowflake in Fabric

From Microsoft documentation, mirroring creates:

A mirrored database item in Fabric
A SQL Analytics Endpoint for querying the mirrored data

For Snowflake sources specifically:

Iceberg table metadata is replicated into OneLake using shortcuts to the storage that contains those Iceberg tables.
OneLake automatically converts those Iceberg tables to Delta Lake formatted tables for Fabric workloads.
Managed table data is replicated into OneLake and converted to analytics-ready format.

This means consumption in Fabric is against replicated data in OneLake, not a live pass-through to Snowflake. When users say "SQL endpoint looks wrong," I now split diagnosis into replication-plane checks vs SQL metadata-plane checks.

2. SQL Analytics Endpoint is read-only and has data type/materialization limits

Microsoft documents that SQL Analytics Endpoint uses the same engine family and constraints as Fabric Warehouse for persisted/object materialized types. In practice this explains why:

Mirroring can be healthy
But some columns can be missing/truncated/not surfaced as expected in SQL Analytics Endpoint

This is especially important when source types do not map cleanly to endpoint-supported persisted types.

3. Snowflake mirroring limitations that matter in design

Official Snowflake mirroring limitations include:

Regular/native table replication focus (not all table categories are supported)
A current mirrored table-count limit per mirrored database
Schema-change replication nuances (some schema changes need data changes to trigger propagation)
Backoff behavior when source tables are idle

4. Cost and serving model

From Microsoft guidance:

Fabric query workloads (SQL, Spark, BI) consume Fabric capacity.
Snowflake compute can be incurred for data-change reads during replication.

This is not a one-time load model; mirroring is continuous synchronization. Total cost depends on change volume, replication activity, and Fabric-side query demand.

Why we still chose it: it reduced repeated direct-query pressure from many downstream users and gave us a shared serving layer across SQL, Spark, and BI.

Incident Log: What broke and what fixed it

Simple-looking errors often had multiple causes: connection identity, permissions, metadata timing, and endpoint type handling. The key discipline was separating what docs explicitly confirm from support heuristics.

Ticket #1–2: Connection and warehouse errors

Symptom

Mirroring refresh failed with warehouse-not-found / not-authorized style errors.

What we found

The configured warehouse identity in Fabric connection did not align with the warehouse defined/accessible in Snowflake for the mirroring principal.

Fix

Stop replication
Recreate the Snowflake connection in Fabric
Re-enter server/warehouse carefully
Ensure the principal has warehouse usage + required mirroring privileges
Rebind mirrored database to the corrected connection
Restart replication and monitor

Important precision

Microsoft docs explicitly tell you to normalize server entry format (for example remove protocol and use lowercase server host format in setup guidance). For warehouse value handling, my operational practice is to treat it as an exact identifier and validate both existence and authorization before restart.

Ticket #3: Mirroring successful, but SQL Analytics Endpoint shows column issues

Symptom

Mirroring status looked healthy, but querying via SQL Analytics Endpoint showed warnings or incomplete column exposure for some tables.

Root cause pattern

Endpoint-level SQL metadata and type mapping did not always represent source columns as expected.

Why this happens

This behavior is aligned with documented SQL Analytics Endpoint limitations and data type mapping constraints. Mirroring into OneLake can still be successful while SQL endpoint representation is partially constrained.

Mitigations

Validate data in OneLake directly (for example via Spark) when endpoint output looks suspicious
Cast unsupported/problematic source columns to endpoint-friendly types in curated tables/views
Use SQL endpoint refresh and metadata sync checks where relevant
For critical workloads, create curated serving layers specifically for endpoint compatibility

Architecture model that helped me

Think about Snowflake mirroring in Fabric as three planes:

Replication plane

Movement/sync of data and metadata into OneLake
Includes Iceberg metadata handling + managed table replication

Storage/open format plane

Data persisted in OneLake with Delta interoperability for Fabric engines

Serving plane

SQL Analytics Endpoint as read-only, T-SQL-friendly surface
Useful, but not equivalent to full source-type fidelity

Most confusion in operations comes from mixing plane #1 health with plane #3 usability.

My production runbook now

Before enabling mirroring:

Validate Snowflake privileges for mirroring principal (CREATE STREAM, SELECT, SHOW TABLES, DESCRIBE TABLES per Microsoft/Snowflake guidance)
Validate server entry format and connection parameters
Validate warehouse existence and effective permissions for principal
Identify which tables are regular/native and eligible
For Iceberg, confirm object store (e.g. S3) permissions up front: the mirroring principal needs read access to the underlying bucket where Iceberg data files are stored, not just Snowflake-level privileges

After enabling mirroring:

Monitor table-level replication status and last refresh
Distinguish OneLake landing success from SQL endpoint metadata availability
Add smoke tests in both Spark and SQL endpoint
Track Snowflake compute impact during replication windows

When troubleshooting:

If connection/auth errors: recreate connection cleanly, verify identifiers and grants
If missing columns in endpoint: check SQL endpoint limitations and data type mappings, then curate/cast
If schema changes not reflected: trigger/verify data change propagation and refresh metadata
If large-table updates are massive: consider stop/start strategy per documented performance guidance
If newly added tables don't appear in SQL endpoint: wait for initial replication to complete, validate data landed in OneLake/Spark first, then trigger endpoint metadata refresh — endpoint availability is near-real-time, not instant

Common misconceptions I had (now corrected)

Misconception 1: "Mirroring success means SQL endpoint is guaranteed complete"

Not always true. Replication and endpoint representation are related but not identical concerns.

Misconception 2: "All Snowflake table variants mirror the same way"

No. Supported categories are explicitly constrained; design with documented limitations first.

Misconception 3: "If it says queried live, Fabric is directly querying Snowflake"

Operationally, Fabric mirroring is a replication model into OneLake with Fabric-side query consumption.

Final takeaways

Fabric mirroring for Snowflake Iceberg works well when you separate replication health from SQL endpoint behavior.
SQL Analytics Endpoint issues do not always mean replication failure.
Connection hygiene (especially warehouse + auth correctness) prevents a surprising number of incidents.
For production, design a compatibility layer for endpoint consumption instead of relying on raw source type fidelity.
This was genuinely painful to implement end-to-end, but the pain forced a better operating model and a sharper troubleshooting discipline.

This is one of those integrations where knowing the documented constraints upfront saves far more time than reactive firefighting.

Neutrality and scope disclosure

This post reflects my hands-on implementation experience and support-ticket learnings.
It is not sponsored content and not intended as a blanket endorsement of any product.
Platform behavior, latency, and cost outcomes can vary by workload shape, table volume, schema patterns, and operating model.
The intent is practical: help others avoid common mistakes by combining official documentation with real incident patterns.

Sources (official)

Mirroring Snowflake in Microsoft Fabric: https://learn.microsoft.com/en-us/fabric/mirroring/snowflake
Tutorial: Configure mirrored Snowflake: https://learn.microsoft.com/en-us/fabric/mirroring/snowflake-tutorial
Snowflake mirroring limitations: https://learn.microsoft.com/en-us/fabric/mirroring/snowflake-limitations
Troubleshoot mirrored databases: https://learn.microsoft.com/en-us/fabric/mirroring/troubleshooting
Snowflake mirroring FAQ: https://learn.microsoft.com/en-us/fabric/mirroring/snowflake-mirroring-faq
SQL Analytics Endpoint limitations: https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-sql-analytics-endpoint#limitations
Data types in Fabric Data Warehouse / SQL endpoint mapping: https://learn.microsoft.com/en-us/fabric/data-warehouse/data-types

Evaluating Adaptive Warehouses for ETL: Why We Reverted to Standard

Krishna Tangudu — Wed, 27 May 2026 14:13:16 +0000

In our last post we showed how upsizing a Bronze ETL warehouse from XSmall to Small reduced daily credits by 11%. This post examines a different question: does Snowflake's Adaptive warehouse model (preview) improve on what a well-tuned Standard warehouse already delivers?

docs.snowflake.com

For our Silver layer workload, the answer was no.

Background

WH_ETL_SILVER_01 is our dedicated warehouse for Silver layer data loads — long-running transformation queries at a steady, predictable rate of ~2,000 queries/day. On May 12, 2026 we migrated it from Standard to Adaptive to evaluate the new model under production conditions.

Parameter	Standard Config	Adaptive Config
Type	STANDARD	ADAPTIVE
Size	Small	Max: Small
Concurrency/Burst	MAX_CLUSTER_COUNT = 3	QUERY_THROUGHPUT_MULTIPLIER = 3
Auto-Suspend	60 seconds	Managed by Snowflake

After 16 days of production data, we reverted.

The Problem: Queuing That Wouldn't Stop Growing

Within the first week on adaptive, we started seeing queries queue. By week three, the queue rate had grown to 3.4% — and still climbing.

Period	Config	Queue Rate	Avg Wait (queued)	Max Wait
Apr 1 – May 11	Standard	~0%	N/A	—
May 12–15	Adaptive Week 1	0.1%	~10s	102s
May 16–22	Adaptive Week 2	2.5%	80–98s	490s
May 23–27	Adaptive Week 3	3.4%	65–80s	508s

Under Standard with the same ~2,000 queries/day load, queueing was effectively zero. Two queries queued on the worst day, for 100ms each.

Fair Comparison: Matched Load Windows

To avoid skewing results by different query volumes, we compared periods with equivalent daily throughput.

Standard baseline: May 1–11 (11 days, avg 2,151 queries/day)
Adaptive comparison: May 12–14, 18–22, 25–26 (10 days, avg 2,060 queries/day)

Query Performance

Metric	Standard	Adaptive	Change
Avg Elapsed Time	19.9s	22.8s	+15% slower
Median Elapsed Time	256ms	267ms	+4%
P95 Elapsed Time	14.1s	20.4s	+45% slower
Avg Execution Time	19.6s	21.0s	+7% slower

Cost

Metric	Standard	Adaptive	Change
Avg Daily Credits	15.2	19.1	+26% more expensive
Credits Per Query	0.0071	0.0093	+31% more expensive

Queuing

Metric	Standard	Adaptive	Change
Queue Rate	0.3%	2.2% (growing)	+7x worse
Avg Queue Wait	3.3ms	1,543ms	+46,000% worse

How We Measured

We used the same ACCOUNT_USAGE views from the previous post.

Query Performance (Matched Windows)

SELECT
  CASE
    WHEN start_time::DATE BETWEEN '2026-05-01' AND '2026-05-11' THEN 'Standard'
    ELSE 'Adaptive'
  END AS config,
  COUNT(*) AS total_queries,
  ROUND(AVG(total_elapsed_time) / 1000, 2)      AS avg_elapsed_sec,
  ROUND(MEDIAN(total_elapsed_time) / 1000, 2)   AS median_elapsed_sec,
  ROUND(PERCENTILE_CONT(0.95) WITHIN GROUP
    (ORDER BY total_elapsed_time) / 1000, 2)    AS p95_elapsed_sec,
  ROUND(AVG(queued_overload_time) / 1000, 2)    AS avg_queued_sec,
  ROUND(COUNT_IF(queued_overload_time > 0)
    / COUNT(*) * 100, 2)                        AS queue_rate_pct
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE warehouse_name = 'WH_ETL_SILVER_01'
  AND start_time::DATE >= '2026-05-01'
GROUP BY config
ORDER BY config;

Credit Consumption

SELECT
  CASE
    WHEN start_time::DATE BETWEEN '2026-05-01' AND '2026-05-11' THEN 'Standard'
    ELSE 'Adaptive'
  END AS config,
  ROUND(SUM(credits_used_compute) / COUNT(DISTINCT start_time::DATE), 2)  AS avg_daily_credits,
  ROUND(SUM(credits_used_compute), 2)                                      AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'WH_ETL_SILVER_01'
  AND start_time::DATE >= '2026-05-01'
GROUP BY config
ORDER BY config;

Why Adaptive Doesn't Fit This Workload

Adaptive warehouses are designed for variable, unpredictable workloads — dashboards, ad-hoc analytics, mixed query sizes. Our Silver pipeline is the opposite:

Steady ~2,000 queries/day
Predictable concurrency (same pipeline, same schedule)
Long-running transformation queries — not short, bursty ones
Consistent data volumes day-to-day

The QUERY_THROUGHPUT_MULTIPLIER = 3 cap was insufficient for peak concurrency windows. The adaptive model's dynamic scaling overhead — which adds value when workloads are unpredictable — just introduced latency without benefit here. The Standard config's fixed multi-cluster model handled this workload profile cleanly.

Recommendation: Revert to Standard

ALTER WAREHOUSE WH_ETL_SILVER_01 SET
  WAREHOUSE_TYPE    = 'STANDARD',
  WAREHOUSE_SIZE    = 'SMALL',
  MAX_CLUSTER_COUNT = 3,
  SCALING_POLICY    = 'STANDARD',
  AUTO_SUSPEND      = 60;

Expected impact after reverting:

Eliminate queuing (proven 0% queue rate at this load level)
Save ~26% on daily credits
Reduce P95 latency by 45%
Restore predictable, consistent performance

If You Must Stay on Adaptive

Snowflake's official guidance is clear: increase QUERY_THROUGHPUT_MULTIPLIER to reduce queuing.

ALTER WAREHOUSE WH_ETL_SILVER_01 SET QUERY_THROUGHPUT_MULTIPLIER = 6;

This would likely resolve the queuing issue. However, for a predictable, steady-state ETL workload, this approach adds operational complexity without strategic benefit:

You're now tuning a multiplier instead of configuring a fixed cluster count
Higher throughput capacity may increase peak concurrent spend, requiring new cost monitoring
For a pipeline that runs the same way every day, the adaptive model's flexibility adds overhead without value

Bottom line: Adaptive's tuning knobs are powerful for variable workloads. For predictable ETL, Standard's simplicity wins operationally — and financially.

Key Takeaways

Adaptive is not universally better — it adds overhead that only pays off for variable, unpredictable workloads.
Always compare at matched load — raw averages across different query volumes are misleading.
Queuing is the canary — a worsening queue rate on adaptive signals a workload mismatch, not just an under-tuned multiplier.
Standard multi-cluster remains the better fit for batch/ETL pipelines with consistent concurrency.
Reserve adaptive for variable workloads — ad-hoc analytics or environments where query volume swings 5–10x daily.

Closing Thought

The lesson from post was: in some workloads, bigger can be cheaper. The lesson here is the inverse: newer is not always better. The right warehouse type depends on workload shape — steady pipelines and dynamic workloads have fundamentally different resource patterns, and Snowflake's warehouse models reflect that.

Disclosure and Scope

Results reflect our specific environment and workload profile; outcomes may vary.
Analysis period: May 1–27, 2026 | Warehouse: WH_ETL_SILVER_01 | Workload: Silver layer production loads

This analysis used Snowflake built-in ACCOUNT_USAGE views only. No third-party monitoring stack required.

How a Simple Warehouse Resize Saved Us 11% in Daily Credits While Boosting Performance

Krishna Tangudu — Thu, 07 May 2026 06:56:45 +0000

Our team hit a familiar Snowflake paradox: slower ETL runs arrived at the same time as FinOps alerts about rising credits.

The warehouse in question was WH_ETL_BRONZE_01, a multi-cluster warehouse dedicated to Bronze layer ingestion and merge workloads. What looked like a simple cost problem turned out to be a workload-isolation and concurrency problem.

The Problem

We started with this setup:

ALTER WAREHOUSE WH_ETL_BRONZE_01 SET
  WAREHOUSE_SIZE = 'XSMALL',
  MAX_CLUSTER_COUNT = 10,
  MIN_CLUSTER_COUNT = 1,
  SCALING_POLICY = 'STANDARD',
  AUTO_SUSPEND = 60,
  MAX_CONCURRENCY_LEVEL = 8;  -- default behavior

And we saw both of these at once:

Higher queue times (queued_overload_time)
Higher daily credits

At that point, we were loading 1,500+ tables through this single warehouse. That meant heavyweight Bronze MERGE workloads and smaller ingestion/utility queries were all competing in the same execution pool.

The critical issue was workload mix. Long-running MERGE statements (30 to 60 minutes) were running alongside tiny queries. When too many heavy MERGE statements landed on the same node/cluster, they competed for resources and all slowed down.

In other words, even with multi-cluster enabled, assignment patterns could create unstable performance if too many heavyweight queries were packed together.

We also learned we needed workload separation: large-table loads should run in a dedicated warehouse so they do not contend with smaller table loads and operational queries.

What We Changed

This was not a single before/after discovery from history. We ran controlled experiments in sequence, while splitting the largest table loads into a separate warehouse path.

Phase 1: Baseline

ALTER WAREHOUSE WH_ETL_BRONZE_01 SET
  WAREHOUSE_SIZE = 'XSMALL',
  MAX_CLUSTER_COUNT = 10,
  MIN_CLUSTER_COUNT = 1,
  SCALING_POLICY = 'STANDARD',
  AUTO_SUSPEND = 60,
  MAX_CONCURRENCY_LEVEL = 8;

Phase 2: First Experiment

ALTER WAREHOUSE WH_ETL_BRONZE_01 SET
  WAREHOUSE_SIZE = 'XSMALL',
  MAX_CLUSTER_COUNT = 10,
  MIN_CLUSTER_COUNT = 1,
  SCALING_POLICY = 'STANDARD',
  AUTO_SUSPEND = 60,
  MAX_CONCURRENCY_LEVEL = 2;

Goal: force scale-out behavior earlier and reduce the chance that many heavy MERGE jobs share the same node.

At the same time, we moved larger-table processing to a separate warehouse so those jobs would not compete with the remaining 1,500+ table ingestion flow.

Phase 3: Final Optimization

ALTER WAREHOUSE WH_ETL_BRONZE_01 SET
  WAREHOUSE_SIZE = 'SMALL',
  MAX_CLUSTER_COUNT = 10,
  MIN_CLUSTER_COUNT = 1,
  SCALING_POLICY = 'STANDARD',
  AUTO_SUSPEND = 60,
  MAX_CONCURRENCY_LEVEL = 3;

This became the best balance for our workload profile.

Final state for this ETL warehouse path:

SMALL size
MAX_CONCURRENCY_LEVEL = 3
Large-table workloads isolated to a separate warehouse

Why This Helped

From deeper analysis of the workload behavior:

The number of queries and output volume could look similar across runs, but bytes scanned at table level could still rise.
Heavy MERGE overlap was a key instability driver.
On slow runs, many heavy MERGE statements could get assigned to the same node, causing resource contention.
On fast runs, fewer heavy MERGE statements shared a node, leaving room for short-running queries.
Isolating large-table workloads reduced cross-workload contention in the primary Bronze ETL warehouse.

Lowering concurrency reduced the tendency to over-pack heavyweight merges. Then moving to SMALL provided enough per-query resources to cut elapsed time and queueing further. Separating large-table loads into a dedicated warehouse stabilized performance for the rest of the pipeline.

Configuration Summary

Phase	Size	Max Clusters	Max Concurrency	Intent
Baseline	XSMALL	10	8	Initial setup
Experiment	XSMALL	10	2	Force earlier scale-out / reduce heavy-query packing
Final	SMALL	10	3	Balance throughput, queueing, and cost

The two final intentional changes vs baseline were:

WAREHOUSE_SIZE: XSMALL -> SMALL
MAX_CONCURRENCY_LEVEL: 8 -> 3

How We Measured

We used Snowflake ACCOUNT_USAGE views for both performance and cost, comparing baseline and final optimization windows.

Query Performance (Before/After)

SELECT
  CASE
    WHEN start_time < '2026-05-05' THEN 'XSMALL Period'
    ELSE 'SMALL Period'
  END AS period,
  COUNT(*) AS total_queries,
  ROUND(AVG(total_elapsed_time)/1000, 2) AS avg_elapsed_sec,
  ROUND(AVG(queued_overload_time)/1000, 2) AS avg_queued_sec,
  ROUND(MAX(total_elapsed_time)/1000, 2) AS max_elapsed_sec
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE warehouse_name = 'WH_ETL_BRONZE_01'
  AND start_time >= '2026-04-30'
GROUP BY period
ORDER BY period;

Credit Consumption (Daily)

SELECT
  CASE
    WHEN start_time::DATE < '2026-05-05' THEN 'XSMALL Period'
    ELSE 'SMALL Period'
  END AS period,
  ROUND(SUM(credits_used_compute) / COUNT(DISTINCT start_time::DATE), 2) AS daily_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'WH_ETL_BRONZE_01'
  AND start_time::DATE >= '2026-04-30'
GROUP BY period
ORDER BY period;

Results

Cost

Period	Size	Daily Credits
Baseline (5 days)	XSMALL	15.12/day
Optimized (3 days)	SMALL	13.50/day

Daily credits dropped by about 11% after upsizing.

Performance

Metric	XSMALL	SMALL	Improvement
Avg query time	26.15s	24.13s	8% faster
Max query time	3,475s	2,850s	18% faster
Total queue time	2.20 min	0.28 min	87% less queuing

Note: The intermediate XSMALL plus concurrency 2 phase was used to validate behavior and direction. The published KPI table above compares the stable baseline period against the final tuned period.

The Counterintuitive Lesson

In some workloads, a bigger warehouse can cost less.

1. Faster execution means earlier suspend

Queries completed faster on SMALL, so the warehouse reached AUTO_SUSPEND = 60 sooner. Less runtime plus less idle overhead translated to fewer daily credits.

2. Higher concurrency can reduce cluster sprawl

Concurrency must match workload shape. In our case, moving from default 8 down to 2 first improved isolation for heavy MERGE jobs, then landing at 3 with SMALL gave the right balance of throughput and stability.

3. Less queueing improves throughput and utilization

With 87% less queue time, work finished in tighter windows. The warehouse did useful work and went to sleep sooner.

Key Takeaways

Do not assume smaller is always cheaper.
Monitor queued_overload_time closely. Persistent queueing often means you are under-sized or under-concurrented.
Tune MAX_CONCURRENCY_LEVEL with warehouse size and workload type; they should be optimized together.
Isolate heavyweight large-table workflows into a dedicated warehouse to reduce overlap and contention.
Use both QUERY_HISTORY (performance) and WAREHOUSE_METERING_HISTORY (cost) for before/after decisions.
Keep aggressive auto-suspend for bursty workloads. Faster queries plus short suspend windows compound savings.

Closing Thought

Warehouse right-sizing is a performance and FinOps exercise, not just a cost-control exercise. In many real workloads, a slightly larger warehouse with slightly higher concurrency can win on both speed and spend.

Disclosure and Scope

Results reflect our specific environment and workload profile; outcomes may vary.

From Glue to Horizon: Our Real Journey Building an Iceberg Lakehouse on Snowflake

Krishna Tangudu — Mon, 04 May 2026 14:18:45 +0000

Update — September 2026: Snowflake has addressed key concerns from our original Dynamic Tables evaluation. Dynamic Iceberg table cloning now supports database/schema clones, and Dynamic Tables Insights provides actionable recommendations for diagnosing refresh performance. These improvements warrant revisiting our earlier assessment. The article below documents our original experience.
Details: Cloning support · Dynamic Tables Insights

We set out to build an open lakehouse: Iceberg tables on AWS S3, Spark/Glue for pipelines, Snowflake for analytics compute power. What could go wrong? Everything—from query performance implosions to uncloneable dynamic tables. Here's the unfiltered journey, including why we pivoted to Snowflake-managed Iceberg via Horizon Catalog and abandoned automated dynamic tables for explicit, observable incremental processing.

TL;DR

❌ Phase 1 failed: Glue-generated Iceberg files (32-64MB) or bigger size caused 5-10x slower Snowflake queries
✅ Phase 2 wins: Snowflake-managed Iceberg auto-compacts to 256-512MB, 2-5x faster, ~35% cost savings
⚠️ Dynamic Tables gotcha: Cannot clone, opaque refresh timing—unusable for production DevOps
✅ Solution: Explicit Streams + Tasks on log tables—boring, debuggable, production-ready
🎯 Key decision: Data team owns Bronze→Silver only; business owns Gold (saved endless remodeling debates)
💰 Reality check: "Cloud-neutral" = readable across engines, not free migration

Our Team Context (Yours Will Differ)

Before diving into architecture decisions, here's who we are:

Skills: Strong SQL/dbt, limited Spark/Scala experience
Priorities: Ship fast, avoid operational black boxes
Constraint: No dedicated DevOps for Glue cluster tuning

This shaped every decision below. A team fluent in Spark would have made different trade-offs.

🎯 The Goal

Unify data from SAP HANA (change data capture), Salesforce Data Cloud, and raw event streams into a single cloud-neutral lakehouse—no proprietary lock-in, full cross-tool interoperability.

Why Iceberg?

We evaluated Delta Lake, Apache Hudi, and Apache Iceberg a couple of years ago. Here's the comprehensive comparison that drove our decision:

Criterion	Iceberg	Delta Lake	Hudi
Partition Evolution	✅ Change without rewrite	❌ Requires full table rewrite	❌ Not supported
Primary Keys	✅ Native support	❌ Not supported	✅ Supported
Automated Compaction	✅ MAINTAIN ICEBERG TABLE	⚠️ Manual (OPTIMIZE tuning)	⚠️ Manual/semi-auto
Schema Evolution	✅ Full (add/drop/rename/reorder)	✅ Add/drop columns	⚠️ Limited
Engine Compatibility	✅ Spark, Trino, Flink, Snowflake, Dremio	⚠️ Spark-first, limited others	⚠️ Spark-first
Platform Support	✅ AWS Glue/Athena, Azure, GCP, Snowflake	✅ AWS, Azure (Fabric native), Databricks	⚠️ AWS, limited Azure
File Format Flexibility	✅ Parquet, ORC, Avro	⚠️ Parquet only	✅ Parquet, ORC, Avro
Community Governance	✅ Apache Foundation (vendor-neutral)	⚠️ Databricks-controlled	✅ Apache Foundation

Why We Chose Iceberg (and Ruled Out Delta/Hudi)

Iceberg's winning factors for our context:

Partition evolution without rewrites: Our SAP data's partitioning strategy evolved over time (daily → monthly as data matured). Iceberg lets us change partition specs without rewriting billions of rows. Delta requires full table rewrite—a multi-day, multi-TB operation we couldn't afford.
Snowflake-managed support: Only Iceberg offers native managed tables in Snowflake Horizon Catalog with automatic compaction. Delta/Hudi would lock us into external table limitations with the Phase 1 performance issues.
Automated compaction: Snowflake's MAINTAIN ICEBERG TABLE handles file optimization automatically. Delta requires manual compaction tuning in Spark—expertise our SQL-first team doesn't have.
Primary key enforcement: Iceberg supports primary keys natively, critical for our SAP source data integrity (customer IDs, order numbers). Delta lacks this—you must enforce it in application logic.
Vendor-neutral governance: Apache Foundation stewardship means no single vendor controls the spec. Delta's governance is tied to Databricks' business interests.

Bottom line: Iceberg was the safe bet for multi-engine flexibility without vendor lock-in. If you're Azure-only with Fabric, Delta is pragmatic. If you're Databricks-native, Delta is the path of least resistance. But for AWS + Snowflake + future optionality, Iceberg was the only choice.

Why Snowflake for Compute?

Three differentiators that closed the decision:

1. Separation of Storage & Compute

Scale workloads independently to meet business demands while enabling detailed chargeback per team or domain—without disrupting other workloads. → Deep dive: Understanding Snowflake Virtual Warehouses

2. Automatic Caching + Smart Pruning (RELY Operators)

Sub-second query performance on petabyte-scale data through intelligent result/metadata caching and constraint-based optimization. → Deep dive: RELY Constraint for Star-Schema Queries

3. Compute Billing Precision

POC result: Our thousands of BI dashboards were only charged for calculation time—not data transfer to BI tools. Estimated 40–60% cost savings vs. **competitors **billing full query duration.

🏛️ Medallion Architecture

Our lakehouse follows the classic three-layer medallion model, tailored for SAP source systems:

┌─────────────────────────────────────────────────────────────┐
│                    DATA SOURCES                             │
│   SAP HANA (CDC)  │  Salesforce Data Cloud  │  Raw Streams │
└────────────┬──────────────────┬─────────────────────┬───────┘
             │                  │                     │
             ▼                  ▼                     ▼
┌─────────────────────────────────────────────────────────────┐
│  🥉 BRONZE LAYER — AWS Glue Spark → Iceberg writes to S3   │
│  Raw ingestion, no transformation, full fidelity            │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  🥈 SILVER LAYER — Iceberg Tables (AWS-hosted, S3)         │
│  Matches source table structures                            │
│  e.g., KNA1 (Customers), MARA (Materials), VBAK (Orders)   │
└─────────────────────────┬───────────────────────────────────┘
                          │  Stream on log_table
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  🥇 GOLD LAYER — Snowflake-Managed Iceberg (Horizon Cat.)  │
│  Proper dimensions & facts with business names             │
│  e.g., DIM_CUSTOMER, FACT_SALES_ORDER, DIM_PRODUCT         │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
              BI Tools / ML / Fabric Export

Sounds ideal? Early reality: Snowflake choked on our Glue-generated files.

The Architecture Decision Nobody Talks About: Layer Ownership

Here's what we learned the hard way: Don't own Gold if you don't have to.

Why this boundary matters:

Silver = Source truth: Matches SAP table structures (KNA1, MARA, VBAK). Data engineering controls quality, structure, and change tracking.
Gold = Business semantics: DIM_CUSTOMER, FACT_SALES_ORDER. Business teams decide how to model, aggregate, and interpret.
Boundary = Contract: Silver provides clean, change-tracked source data with explicit SLAs; business teams own downstream transformations.

This Decision Saved Us From:

❌ Endless "why did the customer count change?" debates (business definition shifts, not data quality issues)

❌ Remodeling dimensions every quarter when business logic evolves

❌ Being the bottleneck for every dashboard request

❌ Owning interpretations of business rules we don't fully understand

Your team may differ, but define the ownership boundary early or you'll own every downstream interpretation forever. The tools (dbt, Iceberg, Snowflake) don't enforce this—you must.

Phase 1: Glue-Managed Iceberg + Snowflake External Tables ❌

The Performance Trap

We started simple: Spark jobs in Glue created Iceberg tables stored in Glue Catalog; Snowflake linked them as external Iceberg tables.

What Broke: File Size Mismatch

Snowflake's Iceberg scanner is optimized for specific file characteristics per official recommendations:

Parameter	Snowflake Recommendation	What Glue Produced
File size	256 – 512 MB	32 – 64 MB (many small files)
Row group size	16 – 256 MB	< 16 MB
Row groups per file	Multiple (for parallelism)	Often 1

The result: Full table scans instead of pruned reads, query times 5–10x slower than expected.

┌──────────────────────────────────────────────────────┐
│              PHASE 1 ARCHITECTURE                    │
│                                                      │
│  AWS Glue Spark ──writes──▶ Iceberg (Glue Catalog)  │
│                                    │                 │
│                             S3 Parquet files         │
│                          (small, fragmented)         │
│                                    │                 │
│  Snowflake ◀──external table──────┘                 │
│  (slow scans, no auto-compaction)                    │
└──────────────────────────────────────────────────────┘

🔀 Decision Point: Invest in Spark Tuning or Snowflake-Managed?

Option A: Hire Spark expertise, tune file compaction settings

Timeline: 3-6 months
Ongoing cost: Maintain Spark expertise, monitor file sizes
Risk: Our team lacks Spark internals experience

Option B: Snowflake-managed Iceberg via Horizon Catalog

Timeline: 2 weeks
Ongoing cost: Snowflake MAINTAIN ICEBERG TABLE compute
Upside: Handles compaction automatically, team stays in SQL/dbt comfort zone

We chose Option B: Our team's strength is SQL/dbt, not Spark internals. Let Snowflake handle the file lifecycle.

Phase 2: Snowflake-Managed Iceberg + Horizon Catalog ✅

The Pivot

Snowflake-managed Iceberg tables put Snowflake in charge of the table lifecycle on your S3 bucket—Horizon Catalog governs metadata, access, and interoperability.

┌──────────────────────────────────────────────────────────┐
│               PHASE 2 ARCHITECTURE                       │
│                                                          │
│  AWS Glue Spark ──writes──▶ Snowflake Horizon Catalog   │
│                                    │                     │
│                    Horizon manages Iceberg metadata      │
│                    Auto-compaction to 256-512MB files    │
│                                    │                     │
│                             S3 (your bucket)             │
│                          Optimal Parquet layout          │
│                                    │                     │
│  Snowflake ◀──native read─────────┘                     │
│  (2–5x faster, full pruning, cloneable*)                 │
│                                                          │
│  BI Tools ◀── Snowflake compute                         │
│  Glue/Spark ◀── Iceberg open format (bidirectional)     │
└──────────────────────────────────────────────────────────┘

Wins

✅ 2–5x query speedup vs. Phase 1 external tables

✅ Automatic compaction to optimal file sizes via MAINTAIN ICEBERG TABLE

✅ Bidirectional access: Glue/Spark can write, Snowflake reads natively; BI tools use Snowflake compute

✅ Open format preserved: Gold layer exportable to Fabric/Polaris later

Trade-off: Snowflake compute is billed for maintenance runs—but total ops cost is lower than Phase 1's slow queries burning warehouse credits.

⚠️ Why We Abandoned Dynamic Tables for Production

This section describes our original evaluation. See the September 2026 update above for current capabilities.

Dynamic Tables on Iceberg sounded perfect—zero-code pipelines, automatic refresh. We hit two walls that forced us back to explicit patterns:

Problem 1 — No Cloning Support:

-- This FAILS silently on dynamic Iceberg tables
CREATE DATABASE prod_clone CLONE prod_db;
-- Dynamic Iceberg tables are simply skipped in the clone

DB/schema clones skip dynamic Iceberg tables entirely. This is a DevOps killer—no dev/test environment parity, no blue-green deploys.

Problem 2 — Opaque Refresh Timing:

Incremental refresh latency was unpredictable and nearly impossible to debug for SLA enforcement. Monitoring refresh lag and debugging failures was guesswork with no visibility into what triggered refreshes or why they were delayed.

🔀 Trade-off: Zero-Code vs. Zero-Surprise

Dynamic Tables promise automation but hide:

When refreshes actually run
What triggered the refresh
How to debug failures in production at 3am

Streams + Tasks = More code, but debuggable in production.

Architecture decision-makers: Optimize for production support, not dev convenience.

Resolution: Abandoned dynamic tables for Silver → Gold. Back to explicit Streams + Tasks.

Our Solution: Log Table Pattern

┌─────────────────────────────────────────────────────┐
│           SILVER → GOLD PIPELINE (Current)          │
│                                                      │
│  Silver Layer                                        │
│     │                                               │
│     ├──▶ silver.log_table (tracks all changes)      │
│                │                                    │
│                ▼                                    │
│     CREATE STREAM log_changes                       │
│     ON TABLE silver.log_table;          ◀── stream  │
│                │                                    │
│                ▼                                    │
│     CREATE TASK gold_refresh            ◀── task    │
│       SCHEDULE = '5 MINUTE'                         │
│       AS MERGE INTO gold.customer_360               │
│          USING log_changes ...;                     │
│                │                                    │
│                ▼                                    │
│     Gold Layer (Snowflake-Managed Iceberg)          │
└─────────────────────────────────────────────────────┘

-- The explicit, cloneable, debuggable pattern
CREATE STREAM log_changes ON TABLE silver.log_table;

CREATE TASK gold_refresh
  WAREHOUSE = compute_xs
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('log_changes')
  AS
  MERGE INTO gold.customer_360 tgt
  USING (
    SELECT * FROM log_changes WHERE metadata$action = 'INSERT'
  ) src
  ON tgt.customer_id = src.customer_id
  WHEN MATCHED THEN UPDATE SET ...
  WHEN NOT MATCHED THEN INSERT ...;

Why This Wins:

✅ Full cloning support (dev/prod parity restored)

✅ Transparent costs — every execution logged in TASK_HISTORY

✅ Debuggable — stream offset visible, failures isolated

✅ Fabric-friendly — Gold can be exported as Iceberg/Parquet later

🌐 Cross-Platform Reality: Why We Can (and Can't) Pivot

Current State: AWS + Snowflake, Iceberg on S3

✅ Open format preserved: Can read Iceberg from Spark, Trino, Athena

✅ Gold exportable: Stream to Parquet → Fabric mirroring works

⚠️ Fabric constraint: OneLake wants Delta + same Azure region for zero-copy

⚠️ Horizon lock-in: Snowflake-managed Iceberg metadata tied to Horizon Catalog

What "Cloud-Neutral" Actually Means

Not: "Deploy anywhere tomorrow with zero effort"

Actually: "Readable by multiple engines, movable with effort"

If We Had to Migrate to Fabric:

Layer	Migration Effort	Estimated Timeline
Bronze → Silver ingestion	Rewrite Glue jobs to Delta	2-3 weeks
Silver → Gold dbt models	Port to Fabric SQL (syntax diffs)	1-2 months
Gold Iceberg tables	Export as Parquet, re-create in Fabric Warehouse	1-2 weeks

┌────────────────────────────────────────────────────────────┐
│                  CATALOG LANDSCAPE                         │
│                                                            │
│  Our Setup: AWS us-east-1                                  │
│  ┌────────────────────────────────────────────────────┐   │
│  │  Snowflake Horizon Catalog (current)               │   │
│  │  + AWS Glue Catalog (bronze/silver ingestion)      │   │
│  └────────────────────────────────────────────────────┘   │
│                                                            │
│  Future Options:                                           │
│  ┌─────────────────┐    ┌──────────────────────────────┐  │
│  │ Polaris Catalog │    │ Microsoft Fabric OneLake      │  │
│  │ (Snowflake SaaS)│    │ (wants Delta; Azure-region   │  │
│  │ Maturing fast   │    │  only for zero-copy)          │  │
│  └─────────────────┘    └──────────────────────────────┘  │
│                                                            │
│  Gold Streams → Parquet export → Fabric compatible ✅      │
└────────────────────────────────────────────────────────────┘

Our Decision:

We prioritized Snowflake ecosystem depth over day-1 multi-cloud portability.

Iceberg gave us an exit path, not a free exit. For teams needing Fabric OneLake zero-copy, starting with Delta on Azure is the pragmatic choice.

💰 Cost Reality Check

Phase 1 (Glue + External Iceberg):

Glue: costs to write and maintain iceberg tables
Snowflake query costs: 3x higher due to full scans

Phase 2 (Snowflake-managed Iceberg):

MAINTAIN ICEBERG TABLE: in warehouse credits
Query costs: 60% reduction (pruning + caching works correctly)
Net savings: 35% monthly vs. Phase 1

Takeaway: Optimize for query performance where your users actually spend time, not just ingestion costs.

🔑 Lessons for Your Lakehouse

1. File sizes first

Target 256-512MB Parquets or let Snowflake MAINTAIN ICEBERG TABLE handle it automatically. Small files kill Snowflake performance.

2. Clone-test early

Dynamic Iceberg tables are powerful but not clone-safe for databases/schemas. Test your DevOps workflow before committing to production.

3. Horizon bidirectional is a game-changer

If your team uses both Spark and Snowflake, Horizon gives you the best of both without choosing sides. Write with Spark, read with Snowflake—all on the same Iceberg tables.

4. Streams > automation black boxes

Explicit Streams + Tasks always win in production ops: observable at 3am, debuggable from logs, cloneable for dev/test.

5. Phase your migration

Don't try to migrate all layers at once. Start with Gold (highest query frequency), validate performance, then move Silver.

6. Define ownership boundaries early

Bronze→Silver→Gold isn't just technical layers—it's organizational boundaries. Decide who owns what before the first production table.

When to Use What: Decision Matrix

Your Situation	Recommendation	Why
Team strong in Spark, need multi-engine	Glue-managed Iceberg + External tables	Keep expertise where it is
Team SQL-first, Snowflake primary engine	Snowflake-managed Iceberg	Let Snowflake handle file lifecycle
Must support Fabric OneLake zero-copy	Delta Lake on Azure	Iceberg works but not zero-copy on Fabric
Need dev/prod clones + SLA guarantees	Streams + Tasks (avoid Dynamic Tables)	Observable, debuggable
Bronze/Silver only (like us)	dbt incremental + Developer Toolkit	Explicit watermark control

Bottom line: Cloud-neutral means readable across tools, not free migration. Choose the platform that matches your team's strengths, use open formats for portability insurance.

What's Next for Us

Investigate Polaris Catalog or wait for Horizon Catalog for true multi-vendor Iceberg metadata management
Evaluate cost/performance of streaming directly from Kafka → Snowflake Iceberg
Explore Iceberg v3 features for enhanced BCDR and CDC capabilities

🆕 Update: Iceberg v3 Features (March 2026) That Could Change Your Decision

Since our original evaluation, Snowflake released Apache Iceberg v3 support in public preview (March 2026) with capabilities that address several of our pain points and unlock new architectural patterns.

What's New in Iceberg v3

1. Cross-Region Replication for Snowflake-Managed Tables

What it enables: BCDR failover and replication groups for Iceberg tables across regions
Why it matters: Previously, our DR strategy required complex Parquet exports. Now, Snowflake-managed Iceberg tables can replicate with full consistency (including row lineage and deletion vectors)
Architecture impact: We can now deploy active-passive DR without custom tooling
📖 Replication Config Docs

2. Catalog-Linked Databases

What it enables: Connect to remote Iceberg catalogs (AWS Glue, Polaris, etc.) with automatic namespace discovery and read/write support
Why it matters: Our Phase 1 external table limitations are eliminated—we can now write back to Glue Catalog-managed tables from Snowflake
Architecture impact: True bidirectional catalog federation; could unblock our "Glue as ingestion, Snowflake as analytics" hybrid
📖 CREATE Catalog-Linked Database Docs

Which Features Would Have Changed Our Decision?

Would have stayed with our choice (Iceberg + Horizon):

✅ Cross-region replication validates our bet on Snowflake-managed Iceberg (Delta still doesn't have this)
✅ Catalog-linked databases eliminate the Phase 1 external table pain without abandoning Glue ingestion

Bottom Line: Iceberg v3 Strengthens the "Safe Bet"

For SQL-first teams on Snowflake, Iceberg v3 eliminates the last major operational friction points we encountered. The combination of Horizon Catalog + v3 features delivers the "cloud-neutral with vendor optimization" balance we were seeking.

What's your biggest Iceberg-on-Snowflake headache? Drop it below 👇

Snowflake #ApacheIceberg #Lakehouse #DataEngineering #HorizonCatalog #DataArchitecture #AWS #OpenLakehouse

Part 4: Clone ++ Parallelization and Production Features

Krishna Tangudu — Thu, 30 Apr 2026 13:58:45 +0000

Previously: In Part 3, we automated permission management with dynamic RBAC provisioning.

In this post: Scale your cloning operations with parallel processing, add resume-from-failure capabilities, implement audit logging, and build production-grade orchestration.

The Performance Problem

Our repointing solution works, but doesn't scale:

-- Sequential processing (6 schemas)
CALL sp_repoint_schema('dev_db', 'prod_db', 'ADMIN');  -- 5 min
CALL sp_repoint_schema('dev_db', 'prod_db', 'INTEGRATION');     -- 8 min
CALL sp_repoint_schema('dev_db', 'prod_db', 'GOLD');       -- 12 min
CALL sp_repoint_schema('dev_db', 'prod_db', 'SILVER');            -- 10 min
CALL sp_repoint_schema('dev_db', 'prod_db', 'PLATINUM');       -- 7 min
CALL sp_repoint_schema('dev_db', 'prod_db', 'ARCHIVE');         -- 3 min

-- Total: 45 minutes ⏰

Problem: Each schema blocks the next. We're not using Snowflake's compute parallelism.

Solution: ASYNC/AWAIT Pattern

Snowflake's ASYNC and AWAIT keywords enable parallel execution:

-- Launch all schemas in parallel
ASYNC (CALL sp_repoint_schema('dev_db', 'prod_db', 'ADMINISTRATION'));
ASYNC (CALL sp_repoint_schema('dev_db', 'prod_db', 'INTEGRATION'));
ASYNC (CALL sp_repoint_schema('dev_db', 'prod_db', 'ANALYTICS'));
ASYNC (CALL sp_repoint_schema('dev_db', 'prod_db', 'DATA'));
ASYNC (CALL sp_repoint_schema('dev_db', 'prod_db', 'REPORTING'));
ASYNC (CALL sp_repoint_schema('dev_db', 'prod_db', 'ARCHIVE'));

-- Wait for all to complete
AWAIT ALL;

-- Result: ~12 minutes (limited by slowest schema)

Speedup: 45 minutes → 12 minutes = 73% faster

Parallel Architecture

High-Level Flow

SP_REPOINT_PARALLEL (Orchestrator)
├─ Get all schemas in clone
├─ For each schema:
│  └─ ASYNC (SP_REPOINT_SCHEMA_AND_LOG)
├─ AWAIT ALL
└─ Aggregate results

SP_REPOINT_SCHEMA_AND_LOG (Logging Wrapper)
├─ Call SP_REPOINT_SCHEMA
├─ Capture result
└─ Insert into temp results table

SP_REPOINT_SCHEMA (Worker)
├─ Repoint views
├─ Repoint procedures
├─ Repoint functions
├─ Repoint tasks
└─ Return JSON result

Orchestrator Pattern

-- Simplified orchestrator logic
CREATE OR REPLACE PROCEDURE sp_clone_repoint_parallel(
    clone_db VARCHAR, 
    source_db VARCHAR
)
AS
BEGIN
    -- Create temp table for results
    CREATE TEMP TABLE temp_repoint_results (
        schema_name VARCHAR,
        result VARIANT,
        completed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP()
    );

    -- Get all schemas
    LET schema_rs RESULTSET := (
        SELECT SCHEMA_NAME 
        FROM clone_db.INFORMATION_SCHEMA.SCHEMATA 
        WHERE SCHEMA_NAME != 'INFORMATION_SCHEMA'
    );

    -- Launch parallel workers
    FOR rec IN schema_rs DO
        ASYNC (
            CALL sp_repoint_schema_and_log(:clone_db, :source_db, rec.SCHEMA_NAME)
        );
    END FOR;

    -- Wait for all workers
    AWAIT ALL;

    -- Aggregate results
    LET final_result := (
        SELECT OBJECT_CONSTRUCT(
            'parallel_schemas', COUNT(*),
            'total_duration_seconds', 
                DATEDIFF('second', MIN(completed_at), MAX(completed_at)),
            'schema_results', ARRAY_AGG(result)
        )
        FROM temp_repoint_results
    );

    RETURN :final_result;
END;

Why temp tables? ASYNC procedures can't return values directly. We collect results in a temp table visible to the orchestrator.

Usage

CALL sp_clone_repoint_parallel('DEV_PROJECT_DB', 'PRODUCTION_DB');

-- Result:
-- {
--   "parallel_schemas": 6,
--   "total_duration_seconds": 720,  -- 12 minutes
--   "schema_results": [
--     {"schema": "ADMINISTRATION", "views_fixed": 12, "procedures_fixed": 8},
--     {"schema": "ANALYTICS", "views_fixed": 98, "procedures_fixed": 42},
--     ...
--   ]
-- }

The Same Pattern for Streams

Parallel stream recreation follows identical architecture:

-- Orchestrator launches per-schema stream workers
CREATE OR REPLACE PROCEDURE sp_clone_recreate_streams_parallel(...)
AS
BEGIN
    CREATE TEMP TABLE temp_stream_results (...);

    FOR each schema:
        ASYNC (CALL sp_recreate_streams_schema_and_log(...));

    AWAIT ALL;

    RETURN aggregated_results;
END;

Resume-from-Failure: Step-Based Tracking

The Problem

Cloning is multi-step:

Delete old RBAC mappings
Clone database
Revoke production grants
Repoint objects
Recreate streams
Create new roles
Apply RBAC mappings
Transfer ownership
Suspend tasks
Validate clone

What happens if Step 5 fails? You don't want to start over!

The Solution: Step Logging

Track each step in a dedicated table:

CREATE TABLE clone_step_log (
    log_id NUMBER AUTOINCREMENT,
    audit_id NUMBER,          -- Links to clone_audit_log
    clone_db VARCHAR,
    step_number NUMBER,
    step_name VARCHAR,
    status VARCHAR DEFAULT 'PENDING',  -- PENDING, IN_PROGRESS, SUCCESS, FAILED
    result VARIANT,
    started_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP(),
    completed_at TIMESTAMP
);

Logging Pattern

// In master clone procedure
function executeStep(stepNum, stepName, stepFunction) {
    // Log step start
    execSQL(
        "INSERT INTO clone_step_log " +
        "(audit_id, clone_db, step_number, step_name, status) " +
        "VALUES (..., " + stepNum + ", '" + stepName + "', 'IN_PROGRESS')"
    );

    try {
        // Execute the step
        var result = stepFunction();

        // Log success
        execSQL(
            "UPDATE clone_step_log " +
            "SET status = 'SUCCESS', result = '" + JSON.stringify(result) + "', " +
            "    completed_at = CURRENT_TIMESTAMP() " +
            "WHERE step_number = " + stepNum + " AND status = 'IN_PROGRESS'"
        );

        return result;
    } catch (e) {
        // Log failure
        execSQL(
            "UPDATE clone_step_log " +
            "SET status = 'FAILED', result = OBJECT_CONSTRUCT('error', '" + e.message + "'), " +
            "    completed_at = CURRENT_TIMESTAMP() " +
            "WHERE step_number = " + stepNum + " AND status = 'IN_PROGRESS'"
        );
        throw e;  // Re-throw to abort remaining steps
    }
}

Resume Logic

// Master procedure signature
CREATE PROCEDURE sp_clone_create_master(
    clone_type VARCHAR,
    name_part1 VARCHAR,
    name_part2 VARCHAR DEFAULT NULL,
    resume_from_step FLOAT DEFAULT 0  -- 👈 Resume parameter
)

// Execution logic
var steps = [
    {num: 1, name: 'DELETE_RBAC', fn: deleteRBACMappings},
    {num: 2, name: 'CLONE_DATABASE', fn: cloneDatabase},
    {num: 3, name: 'REVOKE_GRANTS', fn: revokeGrants},
    {num: 4, name: 'REPOINT', fn: repointParallel},
    {num: 5, name: 'STREAMS', fn: recreateStreamsParallel},
    {num: 6, name: 'CREATE_ROLES', fn: createRoles},
    {num: 7, name: 'APPLY_RBAC', fn: applyRBAC},
    {num: 8, name: 'ICEBERG', fn: handleIceberg},
    {num: 9, name: 'SUSPEND_TASKS', fn: suspendTasks},
    {num: 10, name: 'VALIDATE', fn: validateClone}
];

for (var i = 0; i < steps.length; i++) {
    if (steps[i].num < resume_from_step) {
        continue;  // Skip this step
    }

    executeStep(steps[i].num, steps[i].name, steps[i].fn);
}

Resuming

-- Initial attempt fails at step 5
CALL sp_clone_create_master('PROJECT', 'ANALYTICS', 'DEV');
-- ERROR at step 5: Stream recreation failed

-- Check what happened
SELECT step_number, step_name, status, result
FROM clone_step_log
WHERE clone_db = 'DEV_ANALYTICS_DB'
ORDER BY step_number;

-- Fix the issue, then resume from step 5
CALL sp_clone_create_master('PROJECT', 'ANALYTICS', 'DEV', 5);
-- ✅ Steps 1-4 skipped, execution resumes from step 5

Key benefit: No need to wait another 30 minutes to re-clone. Just fix and resume.

Audit Logging: Observability

The Audit Table

CREATE TABLE clone_audit_log (
    audit_id NUMBER AUTOINCREMENT,
    clone_db VARCHAR NOT NULL,
    clone_type VARCHAR NOT NULL,      -- PROJECT, RELEASE
    action VARCHAR NOT NULL,          -- CREATE, DROP, UPDATE
    project_name VARCHAR,
    env_name VARCHAR,                 -- DEV, QA, STAGING
    source_db VARCHAR DEFAULT 'PRODUCTION_DB',
    status VARCHAR NOT NULL,          -- IN_PROGRESS, SUCCESS, FAILED
    error_msg VARCHAR(4000),
    created_by VARCHAR DEFAULT CURRENT_USER(),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP(),
    completed_at TIMESTAMP
);

Key Metrics

-- Clone success rate (last 30 days)
SELECT 
    COUNT(*) AS total_clones,
    SUM(CASE WHEN status = 'SUCCESS' THEN 1 ELSE 0 END) AS successful,
    ROUND(100.0 * successful / total_clones, 2) AS success_rate
FROM clone_audit_log
WHERE created_at >= DATEADD('day', -30, CURRENT_TIMESTAMP())
AND action = 'CREATE';

-- Average duration by environment
SELECT 
    env_name,
    AVG(DATEDIFF('minute', created_at, completed_at)) AS avg_minutes
FROM clone_audit_log
WHERE status = 'SUCCESS' AND completed_at IS NOT NULL
GROUP BY env_name;

-- Most common failure points
SELECT 
    step_name,
    COUNT(*) AS failure_count
FROM clone_step_log
WHERE status = 'FAILED'
AND started_at >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY step_name
ORDER BY failure_count DESC;

Task Suspension: Cost Control

The Problem

Cloned databases inherit active tasks from production:

SHOW TASKS IN DATABASE dev_project_db;
-- Result: 23 tasks, STATE = 'started' ⚠️
-- Running hourly, daily, etc. in DEV!

Cost: $200-500/month per clone in wasted compute.

The Solution

// Auto-suspend all tasks in clone
function suspendTasks() {
    var schemas = getAllSchemas(cloneDb);
    var tasksSuspended = 0;

    for each schema:
        var tasks = execSQL("SHOW TASKS IN SCHEMA " + schema);

        for each task in tasks:
            if (task.state === 'started'):
                execSQL("ALTER TASK " + task.name + " SUSPEND");
                tasksSuspended++;

    return {tasks_suspended: tasksSuspended};
}

Integration: Add as Step 9 in clone pipeline.

Result: All tasks suspended by default in non-prod clones.

Iceberg Table Handling

Auto-Grant Volume Access

// Step 8: Handle Iceberg tables
function handleIcebergTables() {
    var icebergTables = execSQL(
        "SELECT DISTINCT external_volume " +
        "FROM information_schema.tables " +
        "WHERE table_type IN ('ICEBERG TABLE', 'DYNAMIC ICEBERG TABLE') " +
        "AND external_volume IS NOT NULL"
    );

    for each volume in icebergTables:
        execSQL("GRANT USAGE ON EXTERNAL VOLUME " + volume + " TO DATABASE " + cloneDb);
        volume_grants++;

    return {
        volume_grants_applied: volume_grants,
    };
}

Master Orchestration

Bringing it all together:

-- One command to rule them all
CALL sp_clone_create_master('PROJECT', 'ANALYTICS', 'DEV');

Behind the scenes:

Step 1: DELETE_RBAC_MAPPINGS      [3 sec]
Step 2: CLONE_DATABASE             [3 sec]  ← Snowflake native
Step 3: REVOKE_GRANTS              [45 sec]
Step 4: REPOINT_PARALLEL           [8 min]  ← ASYNC/AWAIT
Step 5: RECREATE_STREAMS_PARALLEL  [2 min]  ← ASYNC/AWAIT
Step 6: CREATE_ROLES               [1 min]
Step 7: APPLY_RBAC_MAPPINGS        [15 sec]
Step 8: HANDLE_ICEBERG             [5 sec]
Step 9: SUSPEND_TASKS              [10 sec]
Step 10: VALIDATE                  [30 sec]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total: ~12 minutes

Result:
✅ Fully functional dev environment
✅ Correct permissions
✅ All references updated
✅ Streams recreated
✅ Tasks suspended
✅ Iceberg configured
✅ Validated and ready

Performance Tuning Tips

1. Warehouse Sizing

-- Use larger warehouse for parallel operations
ALTER WAREHOUSE clone_wh SET WAREHOUSE_SIZE = 'MEDIUM';

-- After clone completes
ALTER WAREHOUSE clone_wh SET WAREHOUSE_SIZE = 'SMALL';

2. Batch Processing

For 50+ schemas:

-- Process in batches to avoid overwhelming warehouse
-- Batch 1: Schemas 1-10
-- Batch 2: Schemas 11-20
-- etc.

3. Query Optimization

-- ❌ Scans entire database
SELECT * FROM information_schema.views 
WHERE view_definition ILIKE '%prod_db%';

-- ✅ Filter by schema first
SELECT * FROM information_schema.views 
WHERE table_schema = 'ANALYTICS'
AND view_definition ILIKE '%prod_db%';

Production Metrics: The Full Picture

Metric	Manual	Semi-Auto	Fully Automated
Time to clone	1-2 days	4-6 hours	8-12 minutes
Human intervention	Constant	Occasional	None
Error rate	15-20%	5-8%	<1%
Concurrent clones	1	2-3	10+
Resume capability	No	Partial	Full
Cost per clone	High	Medium	Low
Audit trail	Manual	Basic	Complete

Key Takeaways

Parallelization is essential - ASYNC/AWAIT delivers 73% speedup
Resume-from-failure saves hours - Step tracking enables smart recovery
Observability matters - Audit logs provide accountability and insights
Task suspension prevents waste - Auto-suspend saves $200-500/month per clone
Iceberg needs attention - External volumes and dynamic tables require special handling

What We've Built

Over this 4-part series, we created a production-grade cloning solution:

✅ Handles permissions - Dynamic RBAC provisioning

✅ Repoints references - All object types updated

✅ Recreates streams - With correct offsets

✅ Processes in parallel - 73% faster

✅ Resumes from failure - No starting over

✅ Logs everything - Complete observability

✅ Suspends tasks - Cost control

✅ Handles Iceberg - External volumes and dynamic tables

✅ Validates results - Health checks

One command:

CALL sp_clone_create_master('PROJECT', 'myproject', 'DEV');

Result: Fully functional dev environment in ~8 minutes.

Going Further

Clone Scheduling

-- Weekly QA refresh
CREATE TASK refresh_qa_clone
  SCHEDULE = 'USING CRON 0 6 * * 1 America/Los_Angeles'
AS
  CALL sp_clone_update('PROJECT', 'myproject', 'QA');

Self-Service UI

Build a web interface for teams to request/manage clones.

Data Masking

Apply dynamic masking policies after cloning for PII protection.

Cost Tracking

Tag clones with cost centers for chargeback.

Auto-Expiration

Drop clones after N days to control costs.

Resources

Code Repository: github.com/LALITHASWAROOPK/snowflake_cloning

Blog Series:

- Part 4: Parallelization and Production Features (this post)

Did this help? Star the repo and share with your team!

Questions? Open an issue on GitHub or comment below.

Previous: Part 3: Solving Permissions and RBAC in Cloned Databases

Series Start: Introduction and Overview

Part 3: Solving Permissions and RBAC in Cloned Databases

Krishna Tangudu — Tue, 28 Apr 2026 14:51:22 +0000

Previously: In Part 2, we fixed all the broken database references. But even with correct references, you still can't access anything without proper permissions!

In this post: Learn how to programmatically manage permissions in cloned databases with dynamic role creation, ownership transfers, and automated RBAC provisioning.

The Permission Problem (Recap)

After cloning:

CREATE DATABASE dev_project_db CLONE production_db;
SHOW GRANTS ON DATABASE dev_project_db;

Result:

| privilege | grantee_name   |
|-----------|----------------|
| OWNERSHIP | PROD_ADMIN     |  ⚠️ Wrong environment!
| USAGE     | PROD_READ_ONLY |  ⚠️ Dev needs different roles

This creates three immediate problems:

Wrong Roles - Production roles shouldn't access dev
No Access - Dev team roles aren't granted anything
Ownership Lock - Can't modify without PROD_ADMIN privileges

The Solution: Four-Stage Automation

Our approach automates permission management in four stages:

Stage 1: Temporary Ownership Transfer
   ↓
Stage 2: Permission Cleanup
   ↓
Stage 3: Dynamic Role Creation
   ↓
Stage 4: RBAC Mapping Application

Let's dive into each.

Stage 1: Temporary Ownership Transfer

First, we need control. Grant temporary ownership to a privileged service account:

// Pseudocode for understanding
for each schema in clone_database:
    GRANT OWNERSHIP ON SCHEMA to SERVICE_ROLE COPY CURRENT GRANTS

    for each object_type in [TABLES, VIEWS, PROCEDURES, ...]:
        GRANT OWNERSHIP ON ALL object_type to SERVICE_ROLE COPY CURRENT GRANTS

Key insight: COPY CURRENT GRANTS preserves existing permissions while changing ownership.

Usage

CALL sp_grant_temp_ownership('dev_project_db');

-- Result:
-- {
--   "schemas_granted": 4,
--   "objects_transferred": 1250,
--   "errors": []
-- }

Now we have control to make changes.

Stage 2: Permission Cleanup

Revoke production-specific grants, especially future grants that auto-apply to new objects:

-- Example: Revoke future ownership from production roles
REVOKE OWNERSHIP ON FUTURE TABLES IN SCHEMA dev_db.analytics 
  FROM ROLE PROD_ANALYTICS_OWNER;

For multiple schemas and object types, we automate this:

// Pseudocode
for each schema in schemas:
    prod_role = source_database + schema_owner_suffix

    for each object_type in [TABLES, VIEWS, PROCEDURES, ...]:
        REVOKE OWNERSHIP ON FUTURE object_type IN SCHEMA 
          FROM ROLE prod_role

Stage 3: Dynamic Role Creation

Instead of hardcoding role names, we generate them dynamically based on:

Database name (environment-specific)
Schema name (domain-specific)
Access level (READ, READ_WRITE, ADMIN)

The Pattern

<DATABASE>_<SCHEMA>_<LEVEL>

Examples:
DEV_PROJECT_DB_ANALYTICS_READ
DEV_PROJECT_DB_ANALYTICS_READ_WRITE
DEV_PROJECT_DB_DATA_ADMIN

The Logic

// Simplified version for understanding
for each schema in schemas:
    for each access_level in [READ, READ_WRITE, ADMIN]:
        role_name = clone_db + "_" + schema + "_" + access_level

        CREATE ROLE IF NOT EXISTS role_name
        GRANT USAGE ON DATABASE to role_name
        GRANT USAGE ON SCHEMA to role_name

        if (access_level == READ):
            GRANT SELECT ON ALL TABLES to role_name
            GRANT SELECT ON FUTURE TABLES to role_name
        else if (access_level == READ_WRITE):
            GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES to role_name
        else if (access_level == ADMIN):
            GRANT ALL ON SCHEMA to role_name

Why this scales: From 3 schemas to 300, the pattern stays the same.

Full implementation: sql/04_clone_rbac.sql#L97-L185

Example Usage

CALL sp_create_clone_roles(
    'DEV_PROJECT_DB',
    ARRAY_CONSTRUCT('ADMINISTRATION', 'ANALYTICS', 'DATA')
);

-- Result:
-- {
--   "roles_created": [
--     "DEV_PROJECT_DB_ADMINISTRATION_READ",
--     "DEV_PROJECT_DB_ADMINISTRATION_READ_WRITE",
--     "DEV_PROJECT_DB_ADMINISTRATION_ADMIN",
--     "DEV_PROJECT_DB_ANALYTICS_READ",
--     "DEV_PROJECT_DB_ANALYTICS_READ_WRITE",
--     "DEV_PROJECT_DB_ANALYTICS_ADMIN",
--     "DEV_PROJECT_DB_DATA_READ",
--     "DEV_PROJECT_DB_DATA_READ_WRITE",
--     "DEV_PROJECT_DB_DATA_ADMIN"
--   ],
--   "total_created": 9
-- }

Stage 4: RBAC Mapping

The final piece: map clone-specific roles to functional roles that users actually have:

CLONE ROLE                           FUNCTIONAL ROLE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DEV_PROJECT_DB_ANALYTICS_READ   →    DATA_ANALYST_ROLE
DEV_PROJECT_DB_ANALYTICS_WRITE  →    DATA_ENGINEER_ROLE  
DEV_PROJECT_DB_ANALYTICS_ADMIN  →    PROJECT_ADMIN_ROLE

Configuration Table

Store mappings in a table (not hardcoded):

CREATE TABLE rbac_mapping (
    schema_role VARCHAR(255),         -- Clone-specific role
    environment VARCHAR(40),           -- DEV, QA, STAGING
    functional_role VARCHAR(255),     -- User's actual role
    operation VARCHAR(40),            -- GRANT or REVOKE
    execute_indicator VARCHAR DEFAULT 'Y'
);

-- Example mappings with placeholder
INSERT INTO rbac_mapping (schema_role, environment, functional_role, operation)
VALUES 
    ('{{CLONE_DB}}_ANALYTICS_READ', 'DEV', 'DATA_ANALYST_ROLE', 'GRANT'),
    ('{{CLONE_DB}}_ANALYTICS_WRITE', 'DEV', 'DATA_ENGINEER_ROLE', 'GRANT'),
    ('{{CLONE_DB}}_ANALYTICS_ADMIN', 'DEV', 'PROJECT_ADMIN_ROLE', 'GRANT');

Note: {{CLONE_DB}} is replaced dynamically at runtime.

The Mapping Logic

// Pseudocode
mappings = SELECT * FROM rbac_mapping WHERE environment = target_env

for each mapping in mappings:
    schema_role = mapping.schema_role.replace('{{CLONE_DB}}', actual_clone_db)

    if mapping.operation == 'GRANT':
        GRANT ROLE schema_role TO ROLE mapping.functional_role
    else:
        REVOKE ROLE schema_role FROM ROLE mapping.functional_role

Full implementation: sql/04_clone_rbac.sql#L187-L245

Result

CALL sp_apply_rbac_mapping('DEV_PROJECT_DB', 'DEV');

-- Now developers can use their normal roles:
USE ROLE DATA_ANALYST_ROLE;
SELECT * FROM dev_project_db.analytics.customer_summary;  -- ✅ Works!

Putting It All Together

Complete permission setup in one command:

CALL sp_setup_clone_permissions(
    clone_db => 'DEV_PROJECT_DB',
    source_db => 'PRODUCTION_DB',
    environment => 'DEV'
);

-- Behind the scenes:
-- ✅ Temporary ownership transferred
-- ✅ Production grants revoked
-- ✅ 9 new environment-specific roles created
-- ✅ RBAC mappings applied
-- ✅ Developers have appropriate access

Key Design Principles

1. Configuration Over Code

-- ❌ Hardcoded in procedures
GRANT ROLE dev_analytics_read TO ROLE data_analyst;

-- ✅ Configuration-driven
INSERT INTO rbac_mapping VALUES (...);
CALL sp_apply_rbac_mapping(...);

Benefits:

Non-developers can manage permissions
Different mappings per environment
Audit trail of changes

2. Dynamic Role Generation

// This scales from 3 schemas to 300
role_name = database + "_" + schema + "_" + access_level

3. Temporary Ownership Pattern

User requests clone
   ↓
Service role takes ownership
   ↓
Service role makes all changes
   ↓
Service role transfers ownership to target roles

Never make permission changes as the requesting user.

4. Future Grants Are Critical

-- ❌ Only current objects
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO ROLE analyst;

-- ✅ Current AND future objects
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO ROLE analyst;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics TO ROLE analyst;

Common Pitfalls (And How We Avoid Them)

Pitfall 1: Not Using COPY CURRENT GRANTS

-- ❌ Drops all existing grants during ownership transfer
GRANT OWNERSHIP ON SCHEMA my_schema TO ROLE new_owner;

-- ✅ Preserves grants during transfer
GRANT OWNERSHIP ON SCHEMA my_schema TO ROLE new_owner COPY CURRENT GRANTS;

Our code: Always uses COPY CURRENT GRANTS

Pitfall 2: Forgetting Object Types

Don't forget:

DYNAMIC TABLES
ICEBERG TABLES
EVENT TABLES
STAGES, FILE FORMATS, SEQUENCES

Our code: Comprehensive object type list in sql/04_clone_rbac.sql

Pitfall 3: Not Handling Missing Roles

// ❌ Fails if role doesn't exist
execSQL("GRANT ROLE clone_role TO ROLE functional_role");

// ✅ Graceful error handling (in our procedures)
try {
    execSQL("GRANT ROLE ...");
    success_count++;
} catch (e) {
    errors.push({error: e.message});
}

Our code: Try-catch blocks around all grant operations

Production Metrics

After implementing automated RBAC:

Metric	Before	After
Time to grant permissions	45-90 min	< 2 min
Permission errors per clone	8-12	0-1
Security audit failures	4/mo	0/mo
Developer self-service	No	Yes
Concurrent clone setup	1 at a time	10+ parallel

What's Next?

We've solved both major challenges:

✅ Database reference repointing (Part 2)
✅ Permissions and RBAC (Part 3)

But our solution still processes schemas sequentially. In Part 4, we'll make it production-ready with:

Parallel processing with ASYNC/AWAIT (73% faster)
Resume-from-failure capabilities
Audit logging and observability
Task suspension for cost control
Production-grade orchestration

Next: Part 4: Parallelization and Production Features →
Previous: Part 2: Repointing Database References

About This Series

This is Part 3 of a 4-part series on production-grade Snowflake database cloning. All code is available in the GitHub repository with complete documentation and examples.

Part 2: Snowflake Clone++: Repointing Database References and Recreating Streams

Krishna Tangudu — Fri, 24 Apr 2026 15:40:39 +0000

Previously: In Part 1, we saw how zero-copy cloning is revolutionary but leaves us with broken references everywhere.

In this post: Learn how to find and fix hardcoded database references in views, stored procedures, functions, tasks, and Iceberg tables — plus how to recreate streams that broke during cloning.

The Reference Problem

Your cloned database has perfect permissions, but nothing works:

-- Try to query a view in the clone
SELECT * FROM dev_project_db.analytics.customer_metrics;

-- Error: Object 'PRODUCTION_DB.SILVER.CUSTOMERS' does not exist

The view definition is still pointing to production:

SELECT GET_DDL('VIEW', 'dev_project_db.analytics.customer_metrics');

-- Result:
CREATE OR REPLACE VIEW dev_project_db.analytics.customer_metrics AS
SELECT 
    customer_id,
    COUNT(*) as order_count
FROM production_db.silver.customers  -- ⚠️ Wrong database!
GROUP BY customer_id;

The code was copied exactly as-is. Every database reference needs updating.

The Challenge: Finding All References

Database references hide everywhere:

1. Views (The Easy Ones)

SELECT table_name, view_definition
FROM dev_project_db.information_schema.views
WHERE view_definition ILIKE '%production_db%';
-- Result: 186 views need fixing

2. Stored Procedures (The Tricky Ones)

SELECT procedure_name, procedure_definition
FROM dev_project_db.information_schema.procedures
WHERE procedure_definition ILIKE '%production_db%';
-- Problem: JavaScript, SQL, Python, Scala, Java...

3. Functions

SELECT function_name, function_definition
FROM dev_project_db.information_schema.functions
WHERE function_definition ILIKE '%production_db%';

4. Tasks (The Sneaky Ones)

SELECT name, definition
FROM dev_project_db.information_schema.tasks
WHERE definition ILIKE '%production_db%';
-- Tasks can call procedures that call views...

5. Streams (The Broken Ones)

SHOW STREAMS IN DATABASE dev_project_db;
-- Result: Every stream shows STALE = TRUE

Strategy: GET_DDL + String Replacement

Our battle plan:

Identify objects with stale references (INFORMATION_SCHEMA)
Extract full DDL using GET_DDL() function
Replace all occurrences of source database with clone database
Execute updated DDL to recreate the object

Simple concept, but devils in the details.

Repointing Views

Views are straightforward because their definitions are directly accessible:

// Conceptual flow
var viewRS = execSQL(
    "SELECT TABLE_NAME, VIEW_DEFINITION " +
    "FROM clone_db.INFORMATION_SCHEMA.VIEWS " +
    "WHERE TABLE_SCHEMA = '" + schema + "' " +
    "AND VIEW_DEFINITION ILIKE '%source_db%'"
);

while (viewRS.next()) {
    var viewDef = viewRS.getColumnValue(2);

    // Replace database references (case-insensitive)
    var newDef = viewDef
        .split(sourceDb).join(cloneDb)
        .split(sourceDb.toLowerCase()).join(cloneDb.toLowerCase());

    // Execute updated DDL
    execSQL(newDef);
    views_fixed++;
}

Why this works:

VIEW_DEFINITION contains full CREATE statement
Simple string replacement updates all references
Re-executing DDL replaces the view atomically

Full implementation: sql/02_clone_repoint.sql#L75-L130

Repointing Procedures (The Hard Part)

Procedures are tricky because:

INFORMATION_SCHEMA truncates long definitions
Must use GET_DDL() for full text
Must handle parameter signatures correctly

The Parameter Signature Problem

-- INFORMATION_SCHEMA shows:
PROCEDURE_NAME: calculate_metrics
ARGUMENT_SIGNATURE: (start_date DATE, end_date DATE, customer_id NUMBER)

-- But GET_DDL requires type-only signature:
SELECT GET_DDL('PROCEDURE', 'schema.calculate_metrics(DATE, DATE, NUMBER)');
--                                                      ^^^^ Types only!

We must parse signatures to extract just the types.

Parsing Logic

// Convert "(start_date DATE, end_date DATE)" 
// To: "(DATE, DATE)"
function stripParamNames(sig) {
    if (!sig || sig.trim() === "()") return "()";

    var params = sig.replace(/[()]/g, "").split(",");
    var types = [];

    for (var i = 0; i < params.length; i++) {
        var parts = params[i].trim().split(/\s+/);
        // "start_date DATE" → ["start_date", "DATE"]
        types.push(parts.slice(1).join(" ")); // Take type part
    }

    return "(" + types.join(", ") + ")";
}

The Repointing Flow

// Get procedures that reference source database
var procRS = execSQL(
    "SELECT PROCEDURE_NAME, ARGUMENT_SIGNATURE " +
    "FROM clone_db.INFORMATION_SCHEMA.PROCEDURES " +
    "WHERE PROCEDURE_DEFINITION ILIKE '%source_db%'"
);

while (procRS.next()) {
    var procName = procRS.getColumnValue(1);
    var procSig = procRS.getColumnValue(2);
    var typeSig = stripParamNames(procSig);  // Key step!

    // Get full DDL with correct signature
    var ddl = execSQL(
        "SELECT GET_DDL('PROCEDURE', '" + 
        cloneDb + "." + schema + "." + procName + typeSig + "')"
    );

    // Replace database references
    var newDDL = ddl
        .split(sourceDb).join(cloneDb)
        .split(sourceDb.toLowerCase()).join(cloneDb.toLowerCase());

    // Recreate procedure
    execSQL(newDDL);
    procedures_fixed++;
}

Full implementation: sql/02_clone_repoint.sql#L132-L195

Repointing Functions

Functions work exactly like procedures (same signature challenge):

// Same pattern as procedures
// 1. Find functions with stale references
// 2. Strip parameter names from signatures
// 3. Get full DDL using GET_DDL('FUNCTION', ...)
// 4. Replace database references
// 5. Execute updated DDL

Full implementation: sql/02_clone_repoint.sql#L197-L250

Repointing Tasks

Tasks have an additional requirement: SUSPEND first.

// Get tasks that reference source database
var taskRS = execSQL(
    "SELECT NAME FROM clone_db.INFORMATION_SCHEMA.TASKS " +
    "WHERE DEFINITION ILIKE '%source_db%'"
);

while (taskRS.next()) {
    var taskName = taskRS.getColumnValue(1);

    // IMPORTANT: Suspend before modifying
    execSQL("ALTER TASK " + taskName + " SUSPEND");

    // Get DDL, replace references, recreate
    var taskDDL = execSQL("SELECT GET_DDL('TASK', '" + taskName + "')");
    var newTaskDDL = taskDDL.split(sourceDb).join(cloneDb);
    execSQL(newTaskDDL);

    tasks_fixed++;
    // Tasks remain SUSPENDED (intentional for non-prod)
}

Key Point: Tasks remain SUSPENDED after repointing. Perfect for dev/test environments.

Full implementation: sql/02_clone_repoint.sql#L252-L295

Recreating Streams (The Special Case)

Streams can't be "repointed" — they must be dropped and recreated.

Why Streams Are Different

When you clone:

Production Stream                 Cloned Stream (BROKEN)
  ├─ Tracks: prod_db.data.orders    ├─ Still tracks: prod_db.data.orders ⚠️
  ├─ Offset: Transaction 12,456     ├─ Offset: LOST ⚠️
  └─ Status: Current                └─ Status: STALE ⚠️

The stream object clones but:

Still tracks the source table in production
Loses its offset position
Becomes immediately STALE

Recreation Flow

// Get all streams in schema
execSQL("SHOW STREAMS IN SCHEMA " + cloneDb + "." + schema);
var streamRS = execSQL(
    'SELECT "name", "base_tables", "stale" ' +
    'FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))'
);

while (streamRS.next()) {
    var streamName = streamRS.getColumnValue(1);

    // Get stream DDL
    var ddl = execSQL(
        "SELECT GET_DDL('STREAM', '" + 
        cloneDb + "." + schema + "." + streamName + "')"
    );

    // Replace database references
    var newDDL = ddl.split(sourceDb).join(cloneDb);

    // Drop and recreate
    execSQL("DROP STREAM IF EXISTS " + streamName);
    execSQL(newDDL);

    streams_recreated++;
}

Full implementation: sql/03_clone_streams.sql#L65-L140

Important: Stream Offset Behavior

-- Original stream (in production)
CREATE STREAM prod_stream ON TABLE production_db.data.customers;
-- Has been tracking changes for weeks, offset at transaction 12345

-- After recreating in clone
CREATE STREAM dev_stream ON TABLE dev_db.data.customers;
-- Offset starts at CURRENT_TIMESTAMP (no historical changes)

Implication: Cloned streams don't have historical change data. They start fresh.

Validation: Ensuring Everything Worked

After repointing, verify the clone is healthy:

// Check for views still referencing production
var staleViews = execSQL(
    "SELECT TABLE_SCHEMA, TABLE_NAME " +
    "FROM clone_db.INFORMATION_SCHEMA.VIEWS " +
    "WHERE VIEW_DEFINITION ILIKE '%source_db%'"
);

// Check for procedures still referencing production
var staleProcs = execSQL(
    "SELECT PROCEDURE_SCHEMA, PROCEDURE_NAME " +
    "FROM clone_db.INFORMATION_SCHEMA.PROCEDURES " +
    "WHERE PROCEDURE_DEFINITION ILIKE '%source_db%'"
);

// Check for stale streams
var staleStreams = execSQL(
    "SHOW STREAMS WHERE stale = 'true' " +
    "OR base_tables ILIKE '%source_db%'"
);

// Generate report
return {
    status: (staleViews.count + staleProcs.count + staleStreams.count === 0) 
        ? 'PASS' : 'WARN',
    stale_views: staleViews.count,
    stale_procedures: staleProcs.count,
    stale_streams: staleStreams.count
};

Full implementation: sql/02_clone_repoint.sql#L297-L365

Usage

CALL sp_validate_clone('DEV_PROJECT_DB', 'PRODUCTION_DB');

-- Result:
-- {
--   "status": "PASS",
--   "stale_views": 0,
--   "stale_procedures": 0,
--   "stale_streams": 0
-- }

Performance: Sequential vs Parallel

For large databases with many schemas:

Approach	Time for 6 schemas
Sequential (one at a time)	~45 minutes
Parallel (ASYNC/AWAIT)	~8 minutes

We'll cover parallelization in detail in Part 4.

Common Gotchas

1. Case Sensitivity

// ❌ Won't catch lowercase references
var newDDL = ddl.split(sourceDb).join(cloneDb);

// ✅ Handle both cases
var newDDL = ddl.split(sourceDb).join(cloneDb)
                .split(sourceDb.toLowerCase()).join(cloneDb.toLowerCase());

2. Partial Matches

// If source_db = "PROD"
// This accidentally replaces "PRODUCTION_TABLE" → "DEV_DUCTION_TABLE"

// Solution: Use specific database names or word boundaries

3. Hardcoded Strings in Procedures

// This won't be caught by simple string replacement
CREATE PROCEDURE my_proc() AS
$$
    var db = "PRODUCTION_DB";  // Hardcoded!
    snowflake.execute({sqlText: "SELECT * FROM " + db + ".schema.table"});
$$;

Best practice: Use parameters or configuration tables, not hardcoded strings.

Handling Iceberg Tables

Iceberg tables introduce additional complexity when repointing because they reference external volumes.

The Challenge

After cloning, Iceberg tables still point to production external volumes:

-- Check Iceberg table after cloning
SHOW ICEBERG TABLES IN dev_db;
-- EXTERNAL_VOLUME: prod_iceberg_volume ⚠️

-- Try to query
SELECT * FROM dev_db.data.events_iceberg;
-- Error: Database DEV_DB does not have READ access to EXTERNAL VOLUME 'prod_iceberg_volume'

Solution: Grant Volume Access

// During repoint, identify and grant Iceberg volume access
var icebergTables = execSQL(
    "SELECT DISTINCT external_volume " +
    "FROM clone_db.INFORMATION_SCHEMA.TABLES " +
    "WHERE table_type IN ('ICEBERG TABLE', 'DYNAMIC ICEBERG TABLE') " +
    "AND external_volume IS NOT NULL"
);

for each volume in icebergTables:
    execSQL("GRANT READ ON EXTERNAL VOLUME " + volume + " TO DATABASE " + clone_db);

Security consideration: Dev environment now has read access to production Iceberg storage. This is usually acceptable for clones since:

They share the same data anyway (zero-copy)
Cost tracking separates dev/prod compute
Any writes are isolated to a dedicated storage location and do not interfere with production data.

Dynamic Iceberg Tables

Dynamic Iceberg tables lose their "dynamic" status after cloning:

// Flag dynamic Iceberg tables for manual review
var dynamicIceberg = execSQL(
    "SELECT table_schema, table_name " +
    "FROM clone_db.INFORMATION_SCHEMA.TABLES " +
    "WHERE table_type = 'DYNAMIC ICEBERG TABLE'"
);

// Log warning: These tables exist but won't refresh automatically
// Must be recreated or converted to static if needed in clone

check known limitations here:

Production Metrics

After implementing automated repointing:

Metric	Before (Manual)	After (Automated)
Time to repoint 6 schemas	8-12 hours	8 minutes (parallel)
Missed references	10-15 per clone	0-1 per clone
Failed views	5-8	0
Human errors	Several per clone	None
Success rate	80-85%	99%+

What's Next?

We've now solved the most visible problem:

✅ Database reference repointing
✅ Stream recreation
✅ Iceberg table handling

But even with all references fixed, you still can't access anything without proper permissions! In Part 3, we'll tackle:

Permission management - Dynamic role creation
RBAC automation - Configuration-driven grants
Ownership transfers - Breaking free from production roles

Then in Part 4:

Parallel processing with ASYNC/AWAIT (73% faster)
Resume-from-failure capabilities
Production-grade orchestration

Next: Part 3: Solving Permissions and RBAC
Previous: Part 1: The Problem and the Promise

About This Series

This is Part 2 of a 4-part series on production-grade Snowflake database cloning. All code is available in the GitHub repository with complete documentation and examples.