Widersprechen wir uns da? Nicht ganz. Beide Entscheidungen hatten damals gute Gründe. Hier steht, was Fusion im Alltag wirklich besser macht, warum unser erster Test schiefging, was eine Migration von dbt Core kostet und wann du besser noch wartest.

Was ist dbt Fusion?

dbt Fusion ist die neue Engine hinter dbt. dbt Labs hat sie von Grund auf neu geschrieben, in Rust statt in Python. Inzwischen spricht dbt Labs von "dbt v2": Wer dbt heute neu installiert, bekommt standardmäßig diese Version (dbt Docs).

Der wichtigste Unterschied steckt unter der Haube. dbt Core rendert dein Jinja zu SQL und schickt es an das Warehouse. Ob das SQL stimmt, merkst du erst, wenn das Warehouse einen Fehler zurückgibt. Fusion hingegen versteht SQL, es kennt Spalten, Typen und Abhängigkeiten, bevor irgendetwas läuft.

Praktisch für den Umstieg: Zum Ausprobieren installieren wir Fusion als eigenständiges Programm systemweit, nicht in der Python-Umgebung des Projekts. So läuft es problemlos neben einer bestehenden dbt-Core-Installation. Bei uns ruft der Befehl dbtf immer Fusion auf, dbt im aktiven venv weiterhin dbt Core. So kannst du beide an einem Projekt vergleichen, ohne etwas kaputt zu machen. Ist ein Projekt umgestellt, legen wir die Fusion-Version im Projekt selbst fest (mehr dazu bei der Migration).

Was Fusion im Alltag besser macht

Am meisten merken wir das schnellere Feedback beim Schreiben, mehr als die reine Geschwindigkeit. Vier Dinge fallen uns jeden Tag auf:

1. Fehler, bevor etwas läuft. Die offizielle dbt-Extension für VS Code markiert falsches SQL und kaputtes Jinja direkt im Editor. Ein vertippter Spaltenname fällt also beim Tippen auf, nicht nach drei Minuten Build. Die Extension braucht Fusion und ist kostenlos. Für einige Funktionen brauchst du ein ebenfalls kostenloses Konto bei dbt.
2. Vorschau und Lineage im Editor. Du kannst dir Modelle und einzelne CTEs direkt im Editor ansehen, dazu die Lineage bis auf Spaltenebene. Der Wechsel ins Warehouse für schnelle Kontrollabfragen wird seltener.
3. Schnelles Parsen. Zum Start hat dbt Labs mit bis zu 30-mal schnellerem Parsen geworben. Ehrlich gesagt war das Kompilieren bei uns selten der Engpass. Bei großen Projekten mit vielen Modellen spürst du den Unterschied aber, gerade in der CI.
4. Schnelles Feedback auch ohne Editor. Immer mehr Arbeit an dbt-Projekten passiert im Terminal, oft mit KI-Agenten wie Claude Code. Die statische Analyse von Fusion läuft auch bei dbtf compile. Ein Agent erfährt so in Sekunden, dass sein SQL nicht passt, ohne eine einzige Abfrage im Warehouse. Wichtig: Im Standardmodus baseline sind die Funde nur Warnungen. Typfehler erkennt Fusion erst im Modus strict.

Alte Projekte haben einen Haken: Die Fehlermarkierung folgt der aktuellen Syntax. Bei einem Repo auf einer alten dbt-Version wirst du anfangs mit Warnungen zugeschüttet. Das nervt, ist aber auch ein ziemlich deutlicher Hinweis, dass ein Update fällig ist.

Unser erster Test: schneller und langsamer zugleich

Im Februar 2026 haben wir Fusion an zwei Projekten ausprobiert. Das Ergebnis war widersprüchlich:

Beim Demo-Projekt war Fusion mehr als doppelt so schnell. Bei unserem eigenen Projekt dauerte der Build sechsmal so lang.

Die Ursache war kein Fehler in unserem Code. Fusion hat damals die Einstellung threads für Snowflake ignoriert, als Teil seiner eigenen Performance-Optimierung. Es schickte also mehr Abfragen gleichzeitig ab, als wir eingestellt hatten. Unser kleines XS-Warehouse kam damit nicht hinterher, die Abfragen stauten sich. Mehr Parallelität hat das Ganze also langsamer gemacht.

Daher kam unser Urteil "nicht produktionsreif". Die wichtigere Lehre war aber eine andere: Benchmarks aus Blogposts sagen wenig über dein Projekt (auch die aus diesem).

Warum Fusion trotzdem unser Standard wurde

Zwischen Februar und September hat sich einiges geändert. Mitte September hat dbt Labs Fusion als dbt v2.0.0 offiziell freigegeben. Seitdem erscheinen stabile Releases statt Preview-Versionen.

Auch das Threads-Problem aus unserem Test ist gelöst. Wir hatten es im Februar bei dbt Labs gemeldet, und nach und nach kamen viele Nutzer mit demselben Problem dazu, auch auf BigQuery und Redshift. Seit Mai 2026 behandelt Fusion threads als Obergrenze (dbt Docs). Wer ein kleines Warehouse hat, kann die Parallelität also wieder begrenzen. Im November haben wir unseren Test mit denselben Einstellungen wiederholt. Diesmal war Fusion etwas schneller als dbt Core: rund 18 statt 22 Sekunden.

Und das Feedback im Editor lohnt sich jeden Tag, am meisten in der Einarbeitung. Wer neu im Team ist, sieht Fehler sofort und nicht erst im fehlgeschlagenen Build.

Unser neues internes Datenprojekt läuft komplett auf Fusion, auch die dbt-Jobs in unserem Airflow. Wir arbeiten also selbst mit dem, was wir unseren Kunden einrichten.

Migration von dbt Core zu Fusion: Aufwand und Stolperfallen

Wenn dein Projekt schon auf aktuellem dbt Core ohne Deprecation-Warnungen läuft, ist der Umstieg etwa so aufwendig wie ein normales Versions-Update. Genau das nennt dbt Labs auch als Voraussetzung. Fusion ist weitgehend rückwärtskompatibel. Bei älteren Projekten kommt zuerst die Arbeit, die du bei jedem größeren Update hättest. Unser Template sprang von 1.6 direkt auf Fusion. Diese Schritte waren nötig:

1. Versionsgrenze anpassen. In der dbt_project.yml steht jetzt require-dbt-version: ['>=2.0.0-preview', '<3.0.0'].
2. Testparameter umziehen. Parameter von generischen Tests gehören unter arguments:. Wir haben dazu die Flag require_generic_test_arguments_property: true gesetzt, damit alte Schreibweisen sofort auffallen.
3. tags und meta unter config: schieben. Auch das ist eine reine Syntaxänderung, betrifft aber fast jede yaml.
4. Pakete aktualisieren. dbt deps meldet, welche Pakete nicht kompatibel sind. Bei uns waren es dbt_utils (jetzt 1.4.1) und dbt_snowflake_monitoring (jetzt 5.x).
5. sql_header prüfen. Bei Snapshots, Seeds und Analysen bricht Fusion beim Parsen ab, wenn dort +sql_header gesetzt ist. Wir haben es dort entfernt. Für Modelle und Tests setzen wir die Zeitzone weiterhin per +sql_header in der dbt_project.yml.
6. Version im Projekt festlegen. Zum Testen reicht das Binary (curl, brew oder winget). Im umgestellten Projekt installieren wir Fusion per pip oder uv in die Python-Umgebung des Projekts, mit fester Version, denn das Paket dbt installiert inzwischen dbt v2. So steht die Version im Repo, und jede Änderung läuft über einen Pull Request. dbt Core und Fusion können sich allerdings keine Python-Umgebung teilen. Für den Vergleich nebeneinander bleibt deshalb das Binary der einfachere Weg.

Zwei Dinge haben wir erst später gelernt:

• Pinne die Version überall gleich. Fusion entwickelt sich schnell. Bei einem Kunden hat das Release von Fusion 2.0 den CI-Build gebrochen. Wir legen die Version deshalb fest, und zwar lokal, in der CI und im Orchestrierungs-Image (bei uns Airflow) identisch. Am einfachsten geht das mit einer Lockfile im Repo, aus der alle drei installieren.
• SQLFluff passt nicht direkt zu Fusion. Wenn dein Team stark auf SQLFluff setzt, plane hier Zeit ein. dbt Labs beschreibt in der Dokumentation mehrere Wege, aber keiner ist ein reines Plug-and-play.

Der Rest unserer Struktur, Ordner und Konventionen blieb gleich. Den Großteil eines Projekts musst du also nicht anfassen.

Wann du (noch) nicht wechseln solltest

Fusion ist für uns der neue Standard, aber nicht für jedes Projekt sofort die richtige Wahl. In diesen Fällen würden wir abwarten:

• Dein Warehouse wird nicht unterstützt. Fusion läuft mit Snowflake, BigQuery, Databricks und Redshift, dazu DuckDB lokal. ClickHouse und Spark sind noch in der Beta. Postgres oder Microsoft Fabric fehlen derzeit (Stand November 2026).
• Deine Tools lesen die Logs von dbt Core. Fusion schreibt andere Logs. Monitoring oder Skripte, die genau dieses Format erwarten, musst du anpassen.
• Du brauchst Funktionen der dbt-Plattform, die v2 noch nicht kann, zum Beispiel Benachrichtigungen auf Modellebene.

Auch wenn dein Projekt passt: Teste zuerst nebenher. Weil Fusion neben dbt Core läuft, zeigt dir dbtf parse ohne Risiko, wie viel Migrationsarbeit vor dir liegt, bevor du die CI umstellst.

FAQ zu dbt Fusion

Ist dbt Fusion dasselbe wie dbt 2.0? Ja. Fusion ist die Engine, dbt Labs nennt die Version inzwischen dbt v2. dbt Core (v1) wird parallel weiter gepflegt.

Ist dbt Fusion kostenlos? Die Engine und die VS-Code-Extension kannst du kostenlos nutzen. Einige Funktionen brauchen ein kostenloses Konto bei dbt. Die Standard-Distribution von dbt v2 ist allerdings proprietär und steht unter der Lizenz von dbt Labs. Brauchst du zwingend Open Source, gibt es mit dbt-oss eine Apache-2.0-Variante auf derselben Rust-Engine, mit weniger Funktionen. dbt Core (v1) bleibt ebenfalls Apache 2.0.

Kann ich dbt Core und Fusion parallel nutzen? Ja. Installier Fusion als Binary systemweit und dbt Core wie gewohnt in deiner Python-Umgebung. Mit einem Alias wie dbtf rufst du gezielt Fusion auf.

Ist Fusion immer schneller als dbt Core? Nein. Das Parsen ist deutlich schneller, die Laufzeit eines Builds hängt aber auch von deinem Warehouse ab. In unserem ersten Test im Februar 2026 war Fusion auf einem kleinen Snowflake-Warehouse sechsmal langsamer, weil es die Einstellung threads ignorierte. Das ist seit Mai 2026 behoben. Stell threads passend zu deinem Warehouse ein und vergleiche selbst.

Lohnt sich Fusion, wenn ich mit KI-Agenten arbeite? Ja, vielleicht sogar mehr als im Editor. Ein Agent wie Claude Code prüft sein SQL mit dbtf compile in Sekunden und ohne Abfrage im Warehouse. Weil ein Agent pro Aufgabe oft dutzende Male kompiliert, zählt hier auch das schnelle Parsen. Im Standardmodus baseline sind die Funde nur Warnungen, die ein Agent leicht übersieht. Mit static_analysis: strict prüft Fusion gründlicher, zum Beispiel auch Datentypen.

Wie aufwendig ist die Migration? Wenn dein Projekt auf aktuellem dbt Core ohne Deprecation-Warnungen läuft, etwa so wie ein normales Versions-Update. Die meisten Änderungen betreffen Syntax in YAML-Dateien und Paketversionen. dbt Labs bietet außerdem Agent-Skills an, die einen Teil der Migration automatisieren.

Fazit: Testen, messen, dann umsteigen

Unser erster Eindruck von Fusion war schlecht, und er war damals berechtigt. Sieben Monate später ist Fusion unser Standard für neue Projekte. Den Ausschlag gaben nicht die Benchmarks, sondern die tägliche Arbeit, im Editor wie im Terminal, und die Erfahrung aus echten Projekten.

Wenn du über den Umstieg nachdenkst, fang klein an: Installier Fusion neben dbt Core und lass dbtf parse laufen. Nach ein paar Minuten weißt du, wie weit dein Projekt von Fusion entfernt ist. Vieles davon behebt dbt-autofix automatisch, der Rest sind meist die Stolperfallen von oben.

Du willst ein bestehendes dbt-Projekt migrieren oder eine neue Datenplattform direkt auf Fusion aufsetzen? Sprich mit uns, wir sind diesen Weg schon mehrfach gegangen.

Are we contradicting ourselves? Not quite. Both decisions had good reasons at the time. This piece covers what Fusion actually does better day to day, why our first test went wrong, what a migration from dbt Core costs, and when you're better off waiting.

What is dbt Fusion?

dbt Fusion is the new engine behind dbt. dbt Labs rewrote it from scratch, in Rust instead of Python, and now calls it "dbt v2". If you install dbt fresh today, this is the version you get (dbt Docs).

The big difference is under the hood. dbt Core renders your Jinja to SQL and sends it to the warehouse. Whether the SQL is correct, you only find out when the warehouse sends back an error. Fusion understands SQL. It knows columns, types and dependencies before anything runs.

Handy for the switch: to try Fusion out, we install it system-wide as a standalone program, not in the project's Python environment. That way it sits next to an existing dbt Core installation without getting in its way. For us, dbtf always calls Fusion, and dbt in the active venv still calls dbt Core. You can compare both on the same project without breaking anything. Once a project has switched, we pin the Fusion version in the project itself (more on that in the migration section).

What Fusion improves day to day

What we notice most is faster feedback while writing, more than raw speed. Four things stand out:

1. Errors before anything runs. The official dbt extension for VS Code flags bad SQL and broken Jinja right in the editor. A mistyped column name shows up as you type, not after a three-minute build. The extension needs Fusion and is free. Some features need a dbt account, also free.
2. Preview and lineage in the editor. You can preview models and individual CTEs without leaving the editor, and see lineage down to column level. We switch to the warehouse for quick sanity checks less often.
3. Fast parsing. At launch, dbt Labs advertised up to 30 times faster parsing. To be honest, compilation was rarely our bottleneck. On large projects with many models you do feel it, though, especially in CI.
4. Fast feedback without an editor, too. More and more work on dbt projects happens in the terminal, often with AI agents like Claude Code. Fusion's static analysis also runs on dbtf compile, so an agent learns within seconds that its SQL doesn't fit, without a single query to the warehouse. One catch: in the default baseline mode, the findings are only warnings. Fusion only detects type errors in strict mode.

Old projects have a catch of their own: the error highlighting follows the current syntax. Open a repo on an old dbt version and you'll be buried in warnings at first. That's annoying, but it's also a pretty clear hint that an upgrade is due.

Our first test: faster and slower at the same time

In February 2026 we tried Fusion on two projects. The results contradicted each other:

On the demo project, Fusion was more than twice as fast. On our own project, the build took six times as long.

Our code wasn't the problem. At the time, Fusion ignored the threads setting for Snowflake as part of its own performance optimisation, so it fired off more queries at once than we had configured. Our small XS warehouse couldn't keep up and the queries piled up. More parallelism made everything slower.

That's where our "not production-ready" verdict came from. The more useful lesson was a different one: benchmarks from blog posts say little about your project (this one included).

Why Fusion became our standard anyway

A lot changed between February and September. In mid-September, dbt Labs officially released Fusion as dbt v2.0.0, and stable releases have replaced the previews since then.

The threads problem from our test is solved, too. We had reported it to dbt Labs in February, and over the following months plenty of other users turned up with the same issue, on BigQuery and Redshift as well. Since May 2026, Fusion treats threads as an upper limit (dbt Docs), so on a small warehouse you can cap parallelism again. In November we reran our test with the same settings. This time Fusion was slightly faster than dbt Core: around 18 seconds instead of 22.

And the editor feedback pays off every day, most of all during onboarding. Someone new to the team sees errors right away instead of in a failed build.

Our new internal data project runs entirely on Fusion, including the dbt jobs in our Airflow. We work with the same setup we build for our clients.

Migrating from dbt Core to Fusion: effort and pitfalls

If your project already runs on current dbt Core without deprecation warnings, the switch is about as much work as a normal version upgrade. That's also the prerequisite dbt Labs names. Fusion is largely backwards compatible. Older projects first need the work any major upgrade would bring. Our template jumped straight from 1.6 to Fusion, and these were the steps:

1. Adjust the version constraint. The dbt_project.yml now says require-dbt-version: ['>=2.0.0-preview', '<3.0.0'].
2. Move test parameters. Parameters of generic tests go under arguments:. We set the flag require_generic_test_arguments_property: true so old notation shows up immediately.
3. Move tags and meta under config:. Another pure syntax change, but it touches almost every YAML file.
4. Update packages. dbt deps tells you which packages aren't compatible. For us that was dbt_utils (now 1.4.1) and dbt_snowflake_monitoring (now 5.x).
5. Check sql_header. Fusion stops parsing if +sql_header is set on snapshots, seeds or analyses. We removed it there. For models and tests, we still set the time zone via +sql_header in the dbt_project.yml.
6. Pin the version in the project. For testing, the binary (curl, brew or winget) is enough. In a project that has switched, we install Fusion with pip or uv into the project's Python environment, with a fixed version, since the dbt package now installs dbt v2. The version then lives in the repo, and every change to it goes through a pull request. dbt Core and Fusion can't share a Python environment, though, so for a side-by-side comparison the binary is still the simpler route.

Two things we only learned later:

• Pin the same version everywhere. Fusion moves fast. At one client, the Fusion 2.0 release broke the CI build. So we pin the version, and identically: locally, in CI and in the orchestration image (Airflow, in our case). The easiest way is a lockfile in the repo that all three install from.
• SQLFluff doesn't fit Fusion directly. If your team leans heavily on SQLFluff, plan time for this. dbt Labs describes several approaches in the documentation, but none of them is plug-and-play.

Everything else stayed the same: structure, folders, conventions. Most of a project you won't have to touch.

When you shouldn't switch (yet)

Fusion is our new standard, but it isn't the right call for every project right now. In these cases we'd wait:

• Your warehouse isn't supported. Fusion runs on Snowflake, BigQuery, Databricks and Redshift, plus DuckDB locally. ClickHouse and Spark are still in beta. Postgres and Microsoft Fabric are missing for now (as of November 2026).
• Your tools read dbt Core's logs. Fusion writes different logs. Monitoring or scripts that expect exactly that format will need adapting.
• You need dbt platform features that v2 doesn't support yet, for example model-level notifications.

Even if your project fits: test on the side first. Since Fusion runs alongside dbt Core, dbtf parse shows you, at no risk, how much migration work lies ahead before you touch your CI.

FAQ about dbt Fusion

Is dbt Fusion the same as dbt 2.0? Yes. Fusion is the engine, and dbt Labs now calls the version dbt v2. dbt Core (v1) is still maintained in parallel.

Is dbt Fusion free? The engine and the VS Code extension are free to use. Some features need a free dbt account. The standard distribution of dbt v2 is proprietary, though, and licensed by dbt Labs. If you need open source, dbt-oss is an Apache 2.0 variant on the same Rust engine, with fewer features. dbt Core (v1) also stays Apache 2.0.

Can I use dbt Core and Fusion side by side? Yes. Install Fusion system-wide as a binary and dbt Core as usual in your Python environment. An alias like dbtf lets you call Fusion explicitly.

Is Fusion always faster than dbt Core? No. Parsing is much faster, but how long a build runs also depends on your warehouse. In our first test in February 2026, Fusion was six times slower on a small Snowflake warehouse because it ignored the threads setting. That's been fixed since May 2026. Set threads to match your warehouse and compare for yourself.

Is Fusion worth it if I work with AI agents? Yes, maybe even more than in the editor. An agent like Claude Code checks its SQL with dbtf compile in seconds, without querying the warehouse. And because an agent often compiles dozens of times per task, fast parsing matters here too. In the default baseline mode, the findings are only warnings, and an agent can easily miss them. With static_analysis: strict, Fusion checks more thoroughly, data types included.

How much work is the migration? If your project runs on current dbt Core without deprecation warnings, about as much as a normal version upgrade. Most changes are YAML syntax and package versions. dbt Labs also offers agent skills that automate part of the migration.

Conclusion: test, measure, then switch

Our first impression of Fusion was bad, and back then it was justified. Seven months later, Fusion is our standard for new projects. Benchmarks weren't what tipped it. The daily work did, in the editor and in the terminal, along with what we saw in real projects.

If you're thinking about switching, start small. Install Fusion next to dbt Core and run dbtf parse. A few minutes later you'll know how far your project is from Fusion. dbt-autofix fixes a lot of that automatically, and the rest is usually the pitfalls above.

Want to migrate an existing dbt project, or set up a new data platform on Fusion from day one? Talk to us. We've been down this road several times.

Die eigentliche Kompetenz liegt woanders: KI so einzusetzen, dass man für das Ergebnis geradestehen kann. Das ist gute Praxis und seit Februar 2025 auch gesetzlich gefordert. Laut Artikel 4 des EU AI Act müssen Unternehmen für ausreichende KI-Kompetenz ihrer Mitarbeitenden sorgen. Bleibt die Frage: Wie misst man das?

Am einfachsten fängt man bei sich selbst an.

1. Kannst du das Ergebnis erklären?

Wenn ein Modell SQL, eine Analyse oder einen Text liefert, könntest du jede Zeile vor einem Kunden vertreten? Wer KI-Output ungeprüft weitergibt, schiebt die Verantwortung und die Prüfarbeit an den Empfänger ab.

2. Weißt du, wo deine Daten landen?

Nicht jede Information gehört in jedes Tool. Bei uns laufen Kundendaten nur über Infrastruktur, die wir selbst kontrollieren. Wer nicht sagen kann, was mit einem Prompt nach dem Absenden passiert, hat ein Problem, auch wenn das Ergebnis gut aussieht.

3. Weißt du, welche Entscheidungen auf deinem Ergebnis aufbauen?

KI-Modelle übernehmen Verzerrungen (Bias) aus ihren Trainingsdaten. Bei einer Mail ist das egal. Entscheidet aber ein KI-generiertes Kundensegment, wer einen Rabatt bekommt, oder fließt eine Analyse in eine Personalentscheidung ein, reicht „sieht gut und/oder plausibel aus“ nicht. Ethisch zu handeln heißt dann, zwei Fragen zu stellen: Stimmt das Ergebnis, und ist es fair? Wer ist betroffen, wer könnte benachteiligt werden, und wer trägt die Verantwortung, wenn es falsch ist?

4. Sagst du, wann KI beteiligt war?

Transparenz kostet nichts und schafft Vertrauen. Ein Satz wie „Entwurf durch KI, fachlich von mir geprüft“ reicht dafür aus.

Die Zahl der Agenten oder der eingesparten Stunden erfasst also nur einen Teil der KI-Kompetenz. Der größere Teil steckt in den vier Fragen oben: Verstehst du das Ergebnis, weißt du, wo deine Daten landen, hast du die Folgen bedacht, und gehst du offen damit um?

Die Frage ist nicht mehr „Nutzt du KI?“, sondern „Verantwortest du das Ergebnis?“

Dieser Text wurde mit KI-Unterstützung skizziert und von Bianca Frost geprüft und überarbeitet.

The real competence lies elsewhere: using AI in a way that lets you stand behind the result. It's good practice, and since February 2025 it's also the law. Under Article 4 of the EU AI Act, companies must ensure that their employees have sufficient AI literacy. Which leaves the question: how do you measure that?

The easiest place to start is yourself.

1. Can you explain the result?

When a model delivers SQL, an analysis or a text, could you defend every line in front of a client? Pass AI output on unchecked, and you've handed your responsibility, along with the review work, to whoever receives it.

2. Do you know where your data ends up?

Not every piece of information belongs in every tool. At Gemma, client data only runs through infrastructure we control ourselves. If you can't say what happens to a prompt after you hit send, you have a problem, even if the result looks good.

3. Do you know which decisions build on your result?

AI models pick up biases from their training data. In an email, that doesn't matter. But if an AI-generated customer segment decides who gets a discount, or an analysis feeds into a personnel decision, "looks good and/or plausible" isn't enough. Then acting ethically means asking two questions: is the result correct, and is it fair? Who is affected, who could be disadvantaged, and who is responsible if it's wrong?

4. Do you say when AI was involved?

Transparency costs nothing and builds trust. A sentence like "Drafted by AI, reviewed for substance by me" is enough.

Counting agents or hours saved only measures part of AI competence. The bigger part is in the four questions above: do you understand the result, do you know where your data goes, have you thought through the consequences, and are you open about it?

The question is no longer "Do you use AI?" but "Do you take responsibility for the result?"

This text was outlined with AI support and reviewed and revised by Bianca Frost.