← Blog
9 Min. Lesezeit

Fivetran stellt das Löschen von Daten in Rechnung

Seit 1. Januar 2026 zählen gelöschte Zeilen zu den bezahlten Monthly Active Rows. Was einen Full Table Re-Sync auslöst, dokumentiert Fivetran ebenfalls selbst.

Ray Kameda
Ray Kameda
Co-Founder & Chief Product Officer
Zwei Entscheidungen, die außerhalb Ihres Unternehmens fallen, und was jede davon kostet. Eine Spalte taucht in Ihrer Quelle auf, um die Sie nicht gebeten haben, und laut Fivetrans Dokumentation sind Schemaänderungen in der Quelldatenbank der häufigste Auslöser für einen Full Table Re-Sync. Getrennt davon hat sich am 1. Januar 2026 eine Preisregel geändert, und gelöschte Zeilen zählen nun zu den bezahlten Monthly Active Rows.

Seit dem 1. Januar 2026 stellt Fivetran Ihnen das Löschen von Daten in Rechnung. Eine gelöschte Zeile zählt jetzt zu Ihren bezahlten Monthly Active Rows. Vor diesem Datum war das nicht so. An Ihrer Pipeline hat sich am 31. Dezember nichts geändert und an Ihrem Geschäft ebenso wenig.

Das steht auf Fivetrans eigener Preisseite, und von dort stammt jede Aussage in diesem Beitrag. Die Rechnungs-Horrorgeschichten, die gerade die Runde machen, beweisen für sich genommen nichts. Was die Dokumentation über das Verhalten des Produkts sagt, beweist eine ganze Menge. Zwei Punkte daraus lohnen genaues Lesen, wenn Ihr Geschäft auf gemieteten Connectors läuft.

Wann Ihre Tabellen neu geladen werden

Beginnen wir mit dem Verhalten, um das herum das Produkt gebaut ist. Fivetran beschreibt es selbst deutlich: „If your source adds a new column, we will detect the change and add the same column in our warehouse, backfilling the data if applicable."

Für diese Aufgabe ist das genau das richtige Design. Ein ELT-Werkzeug existiert, um ein Ziel deckungsgleich mit einer Quelle zu halten, die ihm nicht gehört. Also muss es auf alles reagieren, was die Quelle tut.

Was diese Reaktion kostet, steht in der Connector-Dokumentation: „Schema changes in the source database are the most common trigger for a full table re-sync. When the schema changes in the source, a full table re-sync lets us propagate these changes to your destination."

Lesen Sie diesen Satz aus der Betriebsperspektive. Sie entscheiden nicht, wann eine Schemaänderung stattfindet. Bei einer mandantenfähigen SaaS-Quelle kann eine Spalte auftauchen, weil der Anbieter ein Feature für einen ganz anderen Kunden ausgeliefert hat. Sie haben nicht darum gebeten, Sie werden sie womöglich nie nutzen, und der Re-Sync läuft trotzdem.

Zur Abrechnung gehört allerdings Genauigkeit, denn dieser Teil ist großzügiger als die meisten annehmen. In Fivetrans Preisdokumentation heißt es: „we only count a row once per month, even if it syncs multiple times". Ein Re-Sync innerhalb desselben Kalendermonats ist damit keine zweite Belastung für dieselbe Zeile. Die Kosten fallen als Sync-Zeit und Ziel-Compute an. Auf der Rechnung tauchen sie nicht auf. Wenn Sie mitten in einem Cutover stecken oder ein Bericht auf Zahlen wartet, ist Sync-Zeit die teure Währung.

Ob eine neue Spalte tatsächlich einen Reload kostet, hängt von Dingen ab, die Sie nicht ausgesucht haben. Bei SQL Server mit Teleport Sync gilt: ADD COLUMN operations do not prompt a table re-sync because we are able to process the schema change without it", bei DROP COLUMN dagegen schon. Bei Oracle dreht es sich teilweise um: ADD COLUMN with a default value and RENAME COLUMN triggers a table re-sync. ADD COLUMN without a default value and DROP COLUMN are handled without triggering a table re-sync." Bei MySQL synchronisiert Fivetran die Tabelle neu, statt sie zu migrieren, wenn die Tabelle keinen Primärschlüssel hat, wenn sich die Spaltenreihenfolge ändert, wenn sich Primärschlüssel ändern, wenn ENUM- oder SET-Spalten geändert werden oder wenn das DDL-Statement nicht sauber geparst werden kann.

Lesen Sie diese Liste noch einmal als Betreiber. Ihr Connector, Ihre Sync-Methode, ob die Tabelle einen Primärschlüssel hat, ob die neue Spalte einen Default-Wert trägt: das entscheidet, was eine Schemaänderung Sie kostet. Die Datenbankadministration im Quellsystem trifft die meisten dieser Entscheidungen, ohne zu wissen, dass Fivetran dahinter hängt.

Was eine Zeile kostet

Die Gebühr fürs Löschen aus der Einleitung ist eine Zeile in Fivetrans Preisänderungen für 2026, und sie liest sich unmissverständlich: Deletes zählen nun zu den bezahlten MAR, zuvor waren sie ausgenommen.

Denken Sie das operativ durch. Zeilen zu löschen ist üblicherweise Aufräumarbeit, eine Aufbewahrungsrichtlinie, die ihre Arbeit tut, oder ein Kunde, der sein Recht auf Löschung wahrnimmt. Nach der alten Regel war diese Aktivität kostenlos. Nach der neuen wird sie zum selben Satz abgerechnet wie ankommende Daten. Ihre Pipelines haben sich nicht geändert und Ihr Geschäft auch nicht. Die Rechnung schon.

Am selben Tag kamen zwei weitere Änderungen. History-Mode-Zeilen werden abgerechnet, inklusive wiederholter Updates, und Verbindungen zwischen 1 und 1 Million MAR im Standard-Tarif tragen eine Mindestgebühr von 5 US-Dollar. Den History Mode schalten Sie immerhin bewusst ein. Deletes schaltet niemand ein.

Was bei Fivetran als bezahlte Monthly Active Row zählt, vorher und ab dem 1. Januar 2026. Eingefügte Zeilen zählten vorher und zählen jetzt. Aktualisierte Zeilen zählten vorher und zählen jetzt. Gelöschte Zeilen zählten vorher nicht und zählen jetzt, als geändert markiert. History-Mode-Zeilen inklusive wiederholter Updates zählten vorher nicht und werden jetzt abgerechnet, als geändert markiert. Verbindungen zwischen 1 und 1 Million Monthly Active Rows im Standard-Tarif hatten vorher keine Mindestgebühr und tragen jetzt eine Mindestgebühr von 5 US-Dollar, als geändert markiert. Drei der fünf Zeilen haben sich geändert, und keine davon, weil sich die Pipelines des Kunden geändert hätten.

Die drei Zeilen, die sich am 1. Januar 2026 bewegt haben.

Zur Größenordnung: Ein Kunde hat vor der Änderung im März 2025 Fivetrans Schätzrechner laufen lassen und das Ergebnis gepostet: „we are due to increase ~36%." Das ist die Ausgabe eines Schätzrechners und keine Rechnung, aus einem Account, der MySQL nach Snowflake repliziert, bei rund 8 bis 10 Milliarden Zeilen im Monat.

Was Fivetran richtig macht

Der wütendste Fivetran-Thread der letzten Zeit hat auch den fairsten Kommentar dazu hervorgebracht, mit 43 Punkten: „all these tools in the 'connector' space are varying degrees of bad." Ein paar Kommentare weiter unten, von jemandem, der die ganze Beschwerde gelesen hatte: „Personally I like Fivetran. It allows us to focus on other DE tasks (and let them deal with changing API's...etc)."

Der zweite Kommentar beschreibt das eigentliche Wertversprechen, und es ist ein gutes. Jemand anderem die Arbeit zu überlassen, einer sich ändernden API hinterherzupflegen, ist eine echte Ersparnis, und die meisten Teams, die dafür zahlen, bekommen sie auch.

Wir verkaufen Integrationssoftware und sind hier also keine neutrale Partei. Der Verfasser des Threads über die Preiserhöhung hat es vor uns ausgesprochen: „I imagine this thread will turn into people promoting their products, but I hope I get some valuable comments from people." Er hatte recht, genau das ist passiert. Deshalb sind die beiden Aussagen oben mit Fivetran belegt und nicht mit uns. Prüfen Sie sie nach.

Wofür wir uns entschieden haben

Wir bauen und betreiben die Flows, statt Connectors stückweise zu verkaufen, was den Handel, den wir eingegangen sind, zu einem anderen macht.

Die erste Entscheidung: Quelllogik bleibt explizit. Ein Connector auf unserer Plattform ist Code, der benennt, was er abholt und wie er mappt, lesbar und änderbar für die Leute, denen die Daten gehören. Wenn eine Quelle eine Spalte hinzufügt, um die niemand gebeten hat, ist das eine Zeile, die Sie sich ansehen können, und kein Verhalten, das Sie erben und dann an einem Dienstag entdecken. Das kostet vorab mehr als das Anschalten eines Connectors, und es bedeutet, dass sich an einem von uns gewählten Datum nichts an diesem Pfad ändert. Wir haben zuvor über das Mapping geschrieben, das Ihr ERP-Anbieter nie dokumentiert hat, was dasselbe Argument ist, gerichtet auf ein anderes System.

Die zweite Entscheidung betrifft das andere Ende, wenn das Ziel ein laufendes Geschäftssystem wie ein ERP ist und kein Warehouse. Ein Warehouse verzeiht. Laden Sie dieselben Zeilen zweimal, deduplizieren Sie hinterher in SQL. Ein laufendes System verzeiht auf diese Weise nicht, weil das Anlegen eines Kunden oder das Buchen einer Transaktion eine Aktion mit Folgen ist. Lassen Sie einen halb durchgelaufenen Ladevorgang erneut laufen, bekommen Sie zwei davon, und keine Abfrage räumt das wieder auf.

Was passiert, wenn ein halb durchgelaufener Ladevorgang erneut gestartet wird. Ins Warehouse schreibt der erste Lauf zwei Zeilen und der zweite Lauf dieselben zwei Zeilen noch einmal, macht vier; ein Dedupliziert-Schritt in SQL bringt es zurück auf zwei. Ins Geschäftssystem legt der erste Lauf einen Kunden an und bucht eine Rechnung. Der zweite Lauf fügt einen zweiten Kunden und eine zweite Rechnung daneben, hervorgehoben dargestellt, sodass vier Datensätze existieren, wo zwei sein sollten. Nichts entfernt sie, weil jeder Schreibvorgang eine Aktion mit Folgen war.

Eine Wiederholung ins Warehouse lässt sich hinterher reparieren. Eine Wiederholung ins laufende System erzeugt Datensätze.

Ein Schreibpfad in ein operatives System muss also wissen, was er bereits gesendet hat und was bereits angenommen wurde, Datensatz für Datensatz, damit ein erneuter Lauf fortsetzt statt zu wiederholen. Diese Mechanik ist der größte Teil der eigentlichen Arbeit. Und es ist dieselbe Mechanik, ob Sie sie einmal während einer Migration laufen lassen oder alle 20 Minuten für immer, weshalb wir beides als zwei Modi eines Datenpfads behandeln und nicht als zwei Produkte.

Zu prüfen, ob ein Ladevorgang tatsächlich abgestimmt ist, ist ein eigenes Problem und einen eigenen Beitrag wert statt eines Absatzes hier. Am nächsten kommt dem, was wir über die unsaubere Hälfte der Datenqualität geschrieben haben.

Eines behaupten wir nicht: Es gibt keine Transaktion über zwei entfernte Systeme hinweg, weil entfernte Systeme so etwas nicht anbieten können, und jedes Werkzeug, das anderes suggeriert, verkauft zu viel. Und wir sind ein kleines Team. Wenn Ihr erstes Kriterium ist, welcher Anbieter 2030 noch existiert, gewinnt Fivetran das klar.

Beide Verhaltensweisen in diesem Beitrag sind veröffentlicht, und keine davon ist ein Geheimnis. Genau das ist der Punkt. Sie können exakt nachlesen, was Ihre Datenplattform mit Ihnen machen wird, und haben trotzdem kein Mitspracherecht darüber, wann es passiert, weil der Auslöser bei einer Datenbankadministration in einem System liegt, das Sie nicht betreiben, oder bei einer Preisseite, die im Januar überarbeitet wurde. Wenn dieser Handel es Ihnen wert ist, gehen Sie ihn bewusst ein. Wir haben den anderen gebaut.

Häufige Fragen

Verdoppelt ein Full Table Re-Sync meine Fivetran-Rechnung?
Nein. Laut Fivetrans Dokumentation wird eine Zeile pro Kalendermonat nur einmal gezählt, auch wenn sie mehrfach synchronisiert wird. Ein Re-Sync innerhalb desselben Monats ist also keine zweite Belastung für dieselbe Zeile. Die Kosten fallen stattdessen als Sync-Zeit und Ziel-Compute an, und genau die sind während eines Cutovers oder vor einem Reporting-Termin teuer.
Was löst bei Fivetran einen Full Table Re-Sync aus?
Fivetrans Connector-Dokumentation nennt Schemaänderungen in der Quelldatenbank als häufigsten Auslöser. Ob eine konkrete Änderung einen Re-Sync auslöst, hängt vom Connector ab: Bei SQL Server mit Teleport Sync löst ADD COLUMN keinen Re-Sync aus, DROP COLUMN dagegen schon. Bei Oracle vermeidet ADD COLUMN ohne Default-Wert einen Re-Sync, dieselbe Spalte mit Default-Wert löst einen aus. Bei MySQL kommt es zum Re-Sync, wenn die Tabelle keinen Primärschlüssel hat, wenn sich Spaltenreihenfolge oder Primärschlüssel ändern, wenn ENUM- oder SET-Spalten geändert werden oder wenn das DDL nicht geparst werden kann.
Zählen gelöschte Zeilen zu Fivetrans Monthly Active Rows?
Seit dem 1. Januar 2026 ja. Fivetrans Preisänderungen für 2026 führen Deletes als anrechenbar auf die bezahlten MAR auf, zuvor waren sie ausgenommen. Dieselbe Änderung stellt History-Mode-Zeilen in Rechnung, inklusive wiederholter Updates, und setzt eine Mindestgebühr von 5 US-Dollar je Verbindung für Verbindungen zwischen 1 und 1 Million MAR im Standard-Tarif an.
Warum ist ein idempotenter Schreibvorgang in ein ERP wichtiger als in ein Warehouse?
Weil ein Schreibvorgang in ein Warehouse eine Zeile erzeugt und ein Schreibvorgang in ein laufendes Geschäftssystem eine Aktion auslöst. Läuft ein Ladevorgang ins Warehouse zweimal, deduplizieren Sie hinterher in SQL. Läuft er zweimal ins ERP, haben Sie zwei Kunden oder eine doppelte Buchung, und keine Abfrage entfernt die wieder. Sichere Wiederholungen brauchen eine Nachverfolgung pro Datensatz, was das Ziel bereits angenommen hat.

Möchten Sie das mit Ihren Daten sehen?

Kontakt aufnehmen