DVC

Kurzfazit

DVC ist seit Jahren der De-facto-Standard für Git-artige Versionierung in ML-Projekten — überall dort, wo Datasets und Modelle zu groß für Git sind, aber die gleiche Nachvollziehbarkeit verlangen wie Code. Mit Befehlen wie dvc add, dvc push und dvc pull arbeitet das Tool nach genau dem Muster, das Entwickler aus Git kennen — nur dass die eigentlichen Daten in einem Cloud-Storage-Backend (S3, GCS, Azure Blob, MinIO) landen. Das Framework selbst ist quelloffen unter Apache 2.0, läuft auf jeder Plattform und kostet nichts. Komfort und visuelle Tools liefert die kommerzielle SaaS DataChain Studio (vormals Iterative Studio). 2025 hat lakeFS die Iterative.ai übernommen — DVC bleibt eigenständig, der strategische Schwerpunkt der neuen Eigentümer liegt aber auf der Enterprise-Plattform lakeFS. Für reproduzierbare ML-Pipelines mit kleinen bis mittelgroßen Daten weiterhin Pflicht — bei Petabyte-Workloads inzwischen Konkurrenz aus dem eigenen Konzern.

Für wen ist DVC?

ML-Engineers in Python-Stacks: Wer Modelle trainiert, deren Trainingsdaten und Outputs nicht in Git passen, bekommt mit DVC die fehlende Hälfte des Workflows. Ein dvc add data/train.parquet legt einen kleinen Pointer in Git ab, die eigentliche Datei landet im konfigurierten Storage. Beim Klonen des Repos auf einer anderen Maschine reicht dvc pull — und das Team arbeitet auf identischen Datenständen.

MLOps-Teams mit Reproduzierbarkeitsanforderungen: Für Anwendungsfälle, in denen ein Modellergebnis Monate oder Jahre später exakt nachvollzogen werden muss (Compliance, regulatorische Audits, wissenschaftliche Veröffentlichungen), ist DVC ein Hebel: Code, Datenversion, Pipeline-Definition und Modellartefakt sind über Git-Commits eindeutig verknüpft. Ein git checkout <commit> plus dvc checkout bringt das gesamte Projekt in einen bekannten Zustand zurück.

Forschungslabore und Universitäten: Open Source, kostenlos, läuft auf eigener Infrastruktur — DVC ist seit 2019 in vielen ML-Forschungsgruppen Standard. Reproduzierbare Experimente, Versionierung von Trainingsdaten, klare Dokumentation der genutzten Datenstände: alles ohne Lizenzkosten oder Cloud-Bindung.

Teams mit Multi-Cloud- oder On-Prem-Strategie: Weil DVC das Storage-Backend abstrahiert, bleibt das Setup portabel. Ein Wechsel von AWS S3 auf Azure Blob oder zu einem MinIO-Cluster im eigenen Rechenzentrum ändert nur die Remote-Konfiguration — die Pipeline-Definition bleibt gleich. Für Unternehmen mit hybriden Cloud-Strategien ein realer Vorteil.

Data Scientists, die mit Pipelines arbeiten: Die dvc.yaml-Datei beschreibt Pipeline-Stages mit Inputs, Outputs und Befehlen. DVC erkennt automatisch, welche Stages bei einer Änderung neu laufen müssen — ähnlich wie make, aber mit Daten- statt Datei-Tracking. Für Workflows mit mehreren Schritten (Datenvorverarbeitung, Feature-Engineering, Training, Evaluation) ein nützliches Werkzeug.

Weniger geeignet für: Datenanalysten ohne Terminal-Erfahrung (DVC ist CLI-only und git-zentriert), Teams mit Petabyte-Storage und Millionen winziger Dateien (dafür ist lakeFS oder Pachyderm besser), Anwender, die auf deutschen Support angewiesen sind, und Echtzeit-Streaming-Pipelines (DVC ist auf Batch-Workflows ausgelegt).

Preise im Detail

Komponente	Preis	Was du bekommst
DVC CLI	0 USD (Apache 2.0)	Vollständiges Open-Source-Tool, Datenversionierung, Pipeline-Definition, Experiment-Tracking, alle Storage-Backends
DataChain Studio Free	0 USD	Persönliche Projekte, begrenzte Anzahl öffentlicher und privater Repositories, Community-Support
DataChain Studio Team	ab ca. 50 USD/Sitz/Monat	Visuelles Experiment-Tracking, Modell-Registry, Team-Kollaboration, Branch-Vergleiche, E-Mail-Support
DataChain Studio Enterprise	Auf Anfrage	SSO, SCIM, Audit-Logs, Self-Hosted-Option, dediziertes Support-Team, AVV
Cloud-Storage (S3, GCS, Azure)	Nach Verbrauch beim jeweiligen Anbieter	Speicherkosten und Traffic-Gebühren beim gewählten Storage-Backend

Einordnung: Die wichtigste Botschaft zuerst: DVC selbst kostet nichts. Du installierst per pip install dvc[s3] (oder den Backend-Variant deiner Wahl) und legst los. Die Kosten entstehen woanders: beim Storage-Backend (S3-Speicher etwa 0,023 USD/GB/Monat in eu-central-1) und optional bei DataChain Studio, wenn du ein visuelles Frontend für Experimente und Modelle willst. Der Free-Tier von Studio reicht für Solo-Entwickler und kleine Open-Source-Projekte; Team-Pläne werden interessant, sobald mehrere Data Scientists Experimente vergleichen wollen. Wer DSGVO-konformes Self-Hosting braucht, landet beim Enterprise-Plan — Preise hier vierstellig pro Monat üblich. Pricing-Details für Studio sind seit der Iterative-Übernahme durch lakeFS in Bewegung; aktuelle Konditionen lohnt sich direkt anzufragen.

Stärken im Detail

Git-Workflow für Daten — vertraut und mächtig. DVC kopiert das mentale Modell von Git fast eins zu eins: dvc add ist git add, dvc push ist git push, dvc pull ist git pull. Wer Git beherrscht, lernt DVC in einem Nachmittag. Das ist gleichzeitig der größte Hebel: Die gewohnten Branching-, Diff- und History-Konzepte gelten plötzlich auch für Datasets — und Code-Reviewer können in einem Pull Request sehen, dass nicht nur der Trainingscode geändert wurde, sondern auch die Trainingsdaten.

Storage-Backend ist frei wählbar. AWS S3, Google Cloud Storage, Azure Blob, MinIO, SSH-Verzeichnisse, HDFS, lokale Pfade — DVC abstrahiert all das hinter einer einheitlichen Remote-Konfiguration. Das macht Migrationen schmerzlos und entkoppelt das Versionierungswerkzeug vom Cloud-Anbieter. Für Unternehmen mit Multi-Cloud- oder On-Prem-Anforderungen ist das ein echter strategischer Vorteil.

Pipeline-Definition über dvc.yaml — reproduzierbar und versionierbar. Eine ML-Pipeline lässt sich als YAML-Datei mit Stages, Dependencies und Outputs beschreiben. DVC baut daraus einen DAG, erkennt veränderte Inputs automatisch und führt nur die betroffenen Stages neu aus. Das spart in iterativer Forschungsarbeit massiv Zeit — und macht jede Pipeline reproduzierbar, weil die Definition selbst im Git-Repo lebt.

Experiment-Tracking ohne externes Tool. Mit dvc exp run lassen sich Trainingsläufe als Experimente markieren, vergleichen und in den Hauptbranch übernehmen. Das ist kein Ersatz für ausgereifte Plattformen wie MLflow oder Weights & Biases, aber für viele kleinere Teams reicht es vollkommen — und es funktioniert ohne zusätzliche Infrastruktur.

Apache-2.0-Lizenz und vollständiges Self-Hosting. Anders als viele MLOps-Tools, die zwar „Open Source” sind, aber für ernsthafte Nutzung eine SaaS-Komponente verlangen, läuft DVC vollständig autonom auf eigener Infrastruktur. Kein API-Call zu einem externen Anbieter, keine Telemetrie, kein Vendor-Lock-in. Für regulierte Branchen (Medizintechnik, Finanzdienstleister, Behörden) ist das ein entscheidender Faktor.

Solide Integration in CI/CD-Stacks. DVC arbeitet sauber mit GitHub Actions, GitLab CI und Jenkins zusammen. Pipelines lassen sich automatisiert in CI starten, mit dvc repro Reproducibility prüfen und mit dvc metrics show Modellqualitätsmetriken in Pull Requests einbauen. Das macht ML-Reviews ähnlich strukturiert wie klassische Code-Reviews.

Schwächen ehrlich betrachtet

Reines CLI-Tool — Komfort kostet extra. Die Open-Source-Version von DVC bietet keine grafische Oberfläche, keine visuelle Pipeline-Darstellung, keine Drag-and-Drop-Datenexploration. Wer das will, muss zu DataChain Studio (kostenpflichtig ab Team-Plan) greifen oder eigene Lösungen bauen. Für Teams mit weniger entwicklungsaffinen Mitgliedern (etwa klassische Statistiker oder Domänenexperten) ist die Schwelle hoch.

Performance bei sehr vielen kleinen Dateien. DVC speichert Metadaten zu jeder versionierten Datei. Bei Datasets mit Millionen kleiner Dateien (z. B. Bildklassifikation mit jedem Bild als eigene Datei) wird dvc add und dvc push spürbar langsam — manchmal Stunden für initiale Synchronisationen. Ein Workaround ist, Daten in Tar- oder Parquet-Containern zu bündeln, aber das verliert die feingranulare Versionierung. Hier zeigt sich die strategische Lücke, die lakeFS schließen will: Petabyte-Workloads gehören dort hin.

Steile Lernkurve über Git hinaus. Wer DVC ernsthaft einsetzen will, muss neben Git auch das DVC-eigene Vokabular lernen: Stages, Outputs, Cache, Remote, Experiment-Branches, MetricFiles. Die Konzepte sind logisch, aber es sind viele auf einmal. Realistischer Aufwand für einen Senior-Entwickler bis zur produktiven Nutzung: zwei bis drei Tage konzentrierte Einarbeitung.

Dokumentation Python-lastig. Die offizielle Dokumentation und 90 % aller Beispiele konzentrieren sich auf Python-basierte ML-Stacks (PyTorch, TensorFlow, scikit-learn). Wer mit R, Julia oder JVM-basierten ML-Werkzeugen arbeitet, findet weniger Material und muss mehr selbst herausfinden. Das schließt diese Stacks nicht aus — DVC ist sprachagnostisch — aber der Einstieg ist holpriger.

Kein deutscher Support, keine deutschsprachige Dokumentation. Iterative.ai und nun lakeFS sind US-Unternehmen mit englischer Dokumentation und englischem Support. Für deutsche Mittelständler ohne starke englischsprachige Entwickler-Teams ist das eine reale Hürde — auch wenn die Software selbst international gut funktioniert.

Strategische Unklarheit nach der Übernahme. Die Akquisition von Iterative.ai durch lakeFS in 2025 hat die Frage offen gelassen, wo DVC langfristig hinwandert. Bleibt das Tool eigenständig und gleichberechtigt? Wird es zur Einsteiger-Variante von lakeFS? Werden Investitionen weiter in DVC fließen oder primär in die Enterprise-Plattform? Die Antworten sind 2026 noch nicht abschließend gegeben — wer DVC neu einführt, sollte die Roadmap aktiv beobachten.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Den vollständigen Open-Source-MLOps-Stack mit Plattform-Charakter brauchst	MLflow
Modelle und Datasets aus dem Hub nutzen und teilen willst	Hugging Face
Eine LLM-Orchestrierung statt reine Datenversionierung suchst	LangChain
Open-Source-LLMs feintunen und tracken willst	Hugging Face

Erwähnenswert ohne eigene Tool-Seite: lakeFS (die neue Konzernschwester, geeignet für Petabyte-Datenseen und multimodale Workloads), Pachyderm (mit stärker kontainerisierter Pipeline-Architektur), Weights & Biases (Experiment-Tracking-Spezialist mit besserer GUI, aber proprietär) und DagsHub (gehostete Plattform, die DVC und Git unter einer Oberfläche kombiniert). DVC bleibt 2026 der Standard für „Git für Daten” im kleinen bis mittleren Maßstab — wer in den Petabyte-Bereich vorstößt, sollte parallel lakeFS evaluieren.

So steigst du ein

Schritt 1: Erstes Repo mit dvc init aufsetzen. Installiere mit pip install "dvc[s3]" (oder dem Backend deiner Wahl) und initialisiere ein bestehendes Git-Repo per dvc init. Konfiguriere ein Remote-Storage mit dvc remote add -d storage s3://mein-bucket/dvc-storage und teste den Workflow an einem kleinen Test-Datensatz: dvc add data/test.csv, git add data/test.csv.dvc .gitignore, git commit -m "Track test data", dvc push. Wer diesen Loop einmal durchgespielt hat, hat 80 % des mentalen Modells verstanden.

Schritt 2: Pipeline-Definition mit dvc.yaml strukturieren. Sobald die Datenversionierung sitzt, definiere deine Trainings-Pipeline als YAML-Datei mit klaren Stages: Datenvorverarbeitung → Feature-Engineering → Training → Evaluation. Jede Stage bekommt Inputs, Outputs und einen Befehl. Mit dvc repro führt DVC nur die Stages aus, deren Inputs sich geändert haben — das spart bei iterativer Arbeit massiv Zeit und macht Pipelines reproduzierbar.

Schritt 3: Experimente und Metriken nutzen. Markiere Trainingsläufe mit dvc exp run, vergleiche sie mit dvc exp show und übernimm vielversprechende Varianten in den Hauptbranch mit dvc exp apply. Modellmetriken (Accuracy, F1, Loss) lassen sich in JSON-Dateien ablegen und mit dvc metrics show über Branches hinweg vergleichen — das macht ML-Reviews datengestützt statt bauchgesteuert.

Schritt 4: Optional — DataChain Studio für Visualisierung. Wenn dein Team mehr Komfort braucht (visuelle Experiment-Vergleiche, Modell-Registry, Web-Oberfläche für Nicht-Entwickler), verbinde dein Repo mit DataChain Studio. Free-Tier reicht für erste Erfahrungen — den Team-Plan lohnt sich erst, wenn mehrere Data Scientists regelmäßig Experimente vergleichen.

Ein konkretes Beispiel

Ein Berliner Medizintechnik-Startup (12 Personen, baut ein Deep-Learning-Modell zur Erkennung von Hautläsionen) führt DVC ein, um regulatorische Reproduzierbarkeit nach MDR und FDA-Anforderungen zu erfüllen. Setup: Trainingsdaten (rund 80 GB anonymisierter Dermatoskopie-Bilder) liegen in einem AWS-S3-Bucket in Frankfurt. Das ML-Repo auf GitLab nutzt DVC, um Datasets, Modellartefakte und Experimente zu versionieren. Jede Modellfreigabe für klinische Tests bekommt einen Git-Tag — über git checkout <tag> plus dvc checkout lässt sich Monate später exakt der Trainingszustand rekonstruieren. Pipeline: dvc.yaml definiert vier Stages (Datenvalidierung, Augmentation, Training, Evaluation). Bei jedem Pull Request läuft eine GitLab-CI-Pipeline, die dvc repro ausführt und Metrik-Vergleiche in den Merge Request kommentiert. Effekt: Ein Audit, der vor DVC drei Wochen Recherchearbeit pro Modellversion bedeutete, ist jetzt in einem halben Tag erledigt — die regulatorisch geforderte Nachvollziehbarkeit liegt automatisch im Git-History. Das Team nutzt die Open-Source-Version ohne Studio; die zentrale Investition war die Einarbeitung von zwei Tagen pro Entwickler:in.

DSGVO & Datenschutz

• DVC selbst: Reines Open-Source-Tool, das auf deiner Infrastruktur läuft. Keine Daten verlassen deine Umgebung — die DSGVO-Bewertung hängt allein davon ab, wo dein Storage-Backend liegt (S3 in Frankfurt, eigener MinIO-Cluster, Azure Blob in Westeuropa).
• Kein Telemetrie-Zwang: DVC sammelt anonyme Nutzungsstatistiken, die per dvc config core.analytics false deaktiviert werden können. In regulierten Umgebungen sollte das standardmäßig abgeschaltet werden.
• DataChain Studio (SaaS): Daten werden je nach Plan in den USA oder konfigurierbaren Cloud-Regionen verarbeitet. Für DSGVO-sensible Workloads empfiehlt sich die Self-Hosted-Variante (Enterprise-Plan).
• Auftragsverarbeitung (AVV): Für die Open-Source-Variante nicht erforderlich (kein Datenfluss zu Iterative/lakeFS). Für DataChain Studio Enterprise verfügbar.
• Cloud-Backend-AVV: Beim genutzten Storage-Anbieter (AWS, Google, Azure) gelten die jeweiligen AVV. Für Frankfurt-Region bei AWS S3 ist DSGVO-Konformität gut etablierter Standard.
• Empfehlung für Unternehmen: DVC selbst ist DSGVO-unkritisch — alles hängt am Storage-Backend. Empfohlene Konstellation: DVC + S3 (Frankfurt) oder DVC + MinIO Self-Hosted im eigenen Rechenzentrum. Bei Studio-Nutzung sensibler Daten zwingend Enterprise mit Self-Hosting.

Gut kombiniert mit

• MLflow — DVC versioniert Datasets und Modelle, MLflow trackt Experimente, Parameter und Metriken über mehrere Trainingsläufe. Beide Tools ergänzen sich gut: DVC für „was war der Datenstand”, MLflow für „welche Hyperparameter ergaben welches Ergebnis”.
• Hugging Face — Vortrainierte Modelle aus dem Hub fließen als Inputs in DVC-Pipelines, finetuned-Versionen werden mit DVC versioniert und über dvc push ins eigene Storage gespielt. Standardpfad für Transfer-Learning-Workflows.
• LangChain — wer auf Basis eigener Datasets RAG-Anwendungen baut, kann die Embedding-Pipelines mit DVC versionieren. Eine dvc.yaml-Stage erzeugt aus den Quelldokumenten neue Embeddings, sobald sich die Datengrundlage ändert.

Unser Testurteil

DVC verdient 4 von 5 Sternen. Es ist seit Jahren der De-facto-Standard für Git-artige Datenversionierung im ML-Bereich — open source, storage-agnostisch, vollständig selbst hostbar und in der Community fest verankert. Für reproduzierbare ML-Pipelines, regulatorische Audits und kleine bis mittlere Datenvolumen ist DVC die offensichtliche Wahl. Den fünften Stern verlieren wir wegen der CLI-only-Natur (für gemischte Teams mit Nicht-Entwicklern hohe Schwelle), der Performance-Limits bei sehr vielen kleinen Dateien, des fehlenden deutschen Supports und der strategischen Unsicherheit nach der lakeFS-Übernahme in 2025. Trotzdem: Wer 2026 ein ernsthaftes ML-Projekt startet, in dem Datasets nachvollziehbar versioniert sein müssen, sollte DVC mindestens evaluieren. In den meisten Fällen wird es im Stack landen — und für viele Teams ist es das einzige MLOps-Tool, das sie ohne Lizenzkosten produktiv nutzen können.

Was wir bemerkt haben

• 2025 — lakeFS hat Iterative.ai übernommen. Die Übernahme positioniert DVC als Einstiegs-Tool für kleinere Projekte und lakeFS als Enterprise-Plattform für Petabyte-Workloads. Was das langfristig für DVC bedeutet (eigenständige Roadmap oder Migration-Pfad zu lakeFS?), ist 2026 noch nicht abschließend geklärt. Wer DVC neu einführt, sollte die Entwicklung aktiv verfolgen.
• 2024/2025 — Iterative Studio wurde in DataChain Studio umbenannt, parallel zur Veröffentlichung der DataChain-Library für ML-Datenpipelines. Bestehende Nutzer behalten ihre Zugänge, aber die Marke „Iterative” wird zunehmend abgelöst.
• 2024 — DVC hat seine Performance-Limits bei sehr großen Datasets (Millionen kleiner Dateien) selbst offen kommuniziert. Diese Lücke war ein wesentlicher Treiber für die Annäherung an lakeFS, deren Architektur genau diese Workloads adressiert.
• Mai 2026 — Die Open-Source-Version unter Apache 2.0 bleibt vollständig kostenfrei und aktiv gepflegt. GitHub-Aktivität (github.com/iterative/dvc) ist konstant — keine Anzeichen, dass das Open-Source-Projekt vernachlässigt wird. Für reine Daten-Versionierung ohne Studio-Komfort bleibt DVC eine sichere Wahl.