# Monorepo vs Polyrepo: Die richtige Wahl für dein Team URL: https://formula.dog/de/journal/monorepo-vs-polyrepo Type: blog Locale: de Published: 2026-08-29 Updated: 2026-09-02 --- > Monorepo versus Polyrepo: Die Antwort hängt nicht von der Anzahl Repos ab, sondern davon, wie eng deine Services gekoppelt sind und wie unabhängig deine Teams sein können. ## Monorepo vs Polyrepo Monorepo versus Polyrepo ist eine Debatte, die immer wieder auftaucht, wenn dein Engineering-Team schneller wächst als deine Build-Zeiten. Die kurze Antwort: Ein Monorepo gewinnt, wenn Teams regelmäßig Code teilen und Änderungen über eine gemeinsame Oberfläche koordinieren; ein Polyrepo gewinnt, wenn Teams wirklich unabhängig sind und deployten, ohne je aufeinander zu warten. Alles dazwischen hängt davon ab, wie eng deine Services wirklich gekoppelt sind und wie viel Koordinations-Overhead du bereit bist zu akzeptieren. Dieser Artikel führt durch die echten Trade-offs, die Signale, die in die eine oder andere Richtung zeigen, und ein praktisches Framework für die Entscheidung. ## Die echte Frage dreht sich um Kopplung, nicht um die Anzahl der Repos Die meisten Monorepo- versus Polyrepo-Debatten beginnen mit der falschen Frage. Die Anzahl der Repos ist nicht das Problem. Das Problem ist, ob deine Teams gemeinsam voranschreiten müssen. Wenn die Änderungen von Team A routinemäßig erfordern, dass Team B auf dem gleichen Release-Zyklus etwas aktualisiert, hast du eng gekoppeltes Arbeiten. Ein Repo dafür ist fast immer die sauberere Antwort. Wenn Team A und Team B auf ihren eigenen Zeitplänen ausliefern, verschiedene Teile des Systems anfassen und nie aufeinander warten müssen, ergeben separate Repos echten Sinn. Das schlimmste mögliche Ergebnis: zwei separate Repos für Code, der immer noch zusammen deployten muss. Du bekommst alle Koordinationskosten eines Monorepos ohne Vorteile. Deine Teams eröffnen PRs in Repo A und Repo B gleichzeitig und hoffen, beide bestehen CI zur gleichen Zeit. Dieses Muster ist überraschend verbreitet bei Organisationen, die sich früh für Polyrepo entschieden haben und dann ihre Services enger abhängig machen ließen als ursprünglich geplant. Der erste Schritt vor jeder Entscheidung ist, eine einfache Abhängigkeitskarte zu zeichnen. Liste alle Services oder Packages auf, die du besitzt, und zeichne Pfeile, wo einer von einem anderen abhängt. Falls die Pfeile einen dichten Cluster bilden, gehört dieser Cluster in ein Repo. ![Softwareentwicklungsteam versammelt sich um ein Whiteboard mit Code-Architektur-Diagrammen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/be767c-img-1-inline.webp) ## Warum Google, Meta und Microsoft alle bei Monorepos im großen Maßstab gelandet sind Google führt den größten Teil seines Codes in einem einzigen Repository aus, geschätzt über 80 TB Daten und 2 Milliarden Zeilen Code. Meta und Microsoft machen das Gleiche für ihre Kerprodukt-Oberflächen. Das liegt nicht daran, dass große Unternehmen Komplexität lieben – es ist, weil bei großem Maßstab die Synchronisierung von Abhängigkeiten über Hunderte von Repos zu einem Vollzeit-Engineering-Problem wird. Eine einzelne API-Änderung in einer gemeinsam genutzten Bibliothek könnte koordinierte Updates über 40 verschiedene Repos erfordern. In einem Monorepo ist das ein Pull Request. Eine Review. Ein Merge. Ein Rollback, falls etwas schief läuft. Nach einer von Sourcegraph veröffentlichten Forschung nutzen 63% der Unternehmen mit 50 oder mehr Entwicklern jetzt ein Monorepo für zumindest einen Teil ihrer Codebasis – ein starker Anstieg gegenüber früheren Zahlen vor drei Jahren. Der konkrete Vorteil, der am meisten zählt: atomare Commits. Wenn eine Breaking Change in deiner API auch Frontend- und Backend-Updates erfordert, ermöglicht dir ein Monorepo, alle drei Änderungen in einem PR zu landen, sie zusammen zu testen und alle drei als Einheit zurückzurollen, falls etwas schiefgeht. Mit Polyrepo öffnest du drei separate PRs, wartest auf drei separate Review-Zyklen und managst ein Fenster, in dem deine Services mismatched Versionen laufen. Ein Entwicklungsteam berichtete, dass es von gelegentlichen Deployments zu über 40 App-Releases pro Woche wechselte, nachdem seine Frontend-Packages in ein Nx-Monorepo migriert wurden. Angular-Upgrades, die vorher Monate dauerten, wurden zu Routineaufgaben, die Teams ohne Störung anderer Arbeiten behandeln konnten. ## Die versteckte Koordinations-Steuer von Polyrepo Polyrepo hat echte Vorteile, die ernst zu nehmen sind. Jedes Team kontrolliert seine eigene CI/CD-Pipeline, seinen eigenen Release-Rhythmus, seine eigenen Zugriffskontrolle. Security- und Compliance-Teams bevorzugen es oft: Zugriff auf Code kann auf Basis pro Repo auf benannte Personen beschränkt werden, was in regulierten Industrien zählt. Open-Source-Komponenten leben sauberer in ihren eigenen öffentlichen Repos, ohne internen Code freizulegen. Für Teams, die wirklich unabhängig sind, sind diese Vorteile real. Ein kleines Services-Team, das einen Datenpipeline besitzt, der auf seinem eigenen Zeitplan läuft und keinen gemeinsamen Code anfasst, hat wenig zu gewinnen davon, dass es in einem größeren Monorepo sitzt. Aber Polyrepo-Organisationen sammeln stillschweigend Kosten an, die in der ursprünglichen Entscheidung nicht auftauchten. Abhängigkeitsversionierung über Repos wird zu einer eigenen Disziplin. Eine gemeinsam genutzte Hilfsbibliothek wird in einigen Repos veraltet, während sie in anderen aktuell bleibt. Jemand muss eine Kompatibilitätsmatrix pflegen, um nur zu wissen, welche Version welcher Bibliothek mit welcher Version welchen Services funktioniert. Eine wertvolle Metrik: Die mediane PR-Zykluszeit in Monorepos beträgt etwa 19 Stunden, gegenüber etwa 2 Stunden in Polyrepos. PRs in Monorepos sind tendenziell größer, weil sie mehr Oberflächen anfassen, was Review verlangsamt. Aber wenn eine Polyrepo-Änderung drei koordinierte PRs über drei Repos erfordert, um einen einzelnen Feature zu landen, übersteigt die aggregierte Zykluszeit oft die Monorepo-Zahl ohnehin – mit dem zusätzlichen Risiko von Partial Merges, die Services in inkonsistenten Zuständen lassen. Das Muster, das Teams überraschend trifft: „Wir haben mit separate Repos für Unabhängigkeit begonnen, aber jetzt erfordert jeder Release, PRs an vier Orten zu eröffnen." An diesem Punkt hast du das Schlechteste beider Welten. ## Build-Zeiten sind 2024 nicht mehr der entscheidende Faktor Der klassische Einwand gegen Monorepos waren Build-Zeiten. Falls dein Repo 200 Packages hat und du änderst eine Datei, willst du wirklich alle 200 neu bauen? Dieses Argument ist irgendwann zwischen 2022 und 2024 abgelaufen, je nachdem, welcher Stack du verwendest. Moderne Build-Tools verwenden Content-aware Caching. Sie bauen nur das neu, das sich geändert hat, und überspringen alles mit identischen Inputs. Eine Änderung am `payments`-Package triggert keinen Rebuild von `design-system`, wenn sich dort nichts geändert hat. GitHub Actions bietet 10 GB kostenlosen Cache-Speicher, bevor du eine kostenpflichtige Remote-Cache-Lösung brauchst. Turborepo bearbeitet die meisten JavaScript- und TypeScript-Teams gut bis zu etwa 20 Packages. Die Konfiguration ist eine einzige `turbo.json`, Remote-Caching funktioniert kostenlos auf Vercel oder selbst gehostet, und die Lernkurve ist niedrig genug, dass ein Team innerhalb eines Tages produktiv sein kann. Über 20 Packages oder wenn der Build mehrere Sprachen umfasst, rechtfertigt Nx' strukturierterer Ansatz tendenziell die steilere Lernkurve. Nx fügt Code-Generierung, automatische CI-Verteilung und fein-granulariges Abhängigkeits-Tracking hinzu, das zunehmend wertvoll wird, wenn das Repo wächst. Für sehr große Organisationen, die Tausende von Packages über mehrere Sprachen laufen lassen, ist Bazel (Googles Open-Source Build-System) das einzige Tool, das für diesen Maßstab ausgelegt ist. Der Setup-Aufwand ist erheblich und erfordert fast immer ein dediziertes Platform-Engineering-Team. ![Mehrere parallele Deployment-Pipelines fließen von einer zentralen Codebasis aus, abstraktes DevOps-Infrastruktur-Konzept](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/6761f6-img-2-inline.webp) ## Vier Fragen, die die Debatte für dein Team klären Es gibt keine universale richtige Antwort, aber es gibt ein zuverlässiges Framework. **1. Teilen deine Teams Code, der sich häufig ändert?** Falls ja – ein gemeinsames Design System, eine gemeinsame API-Client-Bibliothek, gemeinsame Authentifizierungs-Logik – ist ein Monorepo fast immer die bessere Wahl. Eine gemeinsam genutzte Bibliothek über mehrere Repos synchron zu halten erfordert ständige Disziplin und driftet fast immer. **2. Deployten deine Teams unabhängig?** Falls Team A seinen Service am Dienstag ausliefert und Team B am Donnerstag ohne koordination nötig, verdient Polyrepo seinen Platz. Falls das Ausliefern eines Services ein gleichzeitiges Ausliefern eines anderen erfordert, gehört diese Kopplungskosten in die Gleichung. **3. Wie viele Ingenieure bearbeiten diese Codebasis?** Unter 20 Ingenieuren interessiert Repo-Struktur weniger als du denkst. Über 50 beginnen sich die Koordinationskosten von Polyrepo sichtbar zu summieren. Über 200 wird die These für ein Monorepo sehr stark, es sei denn, Teams sind wirklich nach Produkt und Technologie isoliert. **4. Hast du Security- oder Compliance-Anforderungen, die Code pro Team isolieren?** In regulierten Industrien – Finanzen, Gesundheitswesen, einige Regierungs-Kontexte – könnte der Zugriff auf Code auf benannte Personen beschränkt werden müssen. Diese Einschränkung kann die anderen Antworten außer Kraft setzen. Falls harte Code-Isolation eine Compliance-Anforderung ist, ist Polyrepo keine Wahl, es ist eine Einschränkung. Falls du „ja" zu Frage 1 und „nein" zu Frage 4 antwortest, ist ein Monorepo fast sicher die richtige Antwort. Falls du „nein" zu Frage 1 und „ja" zu Frage 2 antwortest, ist Polyrepo eine verteidigbare Wahl. Alles andere ist ein Urteilsspruch. ## Wohin die meisten wachsenden Teams wirklich landen Sehr wenige reife Engineering-Organisationen operieren an extremen Enden. Das Muster, das am häufigsten auftaucht: ein Monorepo für das Kernprodukt (Frontend, gemeinsame Bibliotheken, Backend-Services, die voneinander abhängen), und separate Repos für wirklich unabhängige Komponenten. Eine Datenpipeline, die auf ihrem eigenen Zeitplan läuft und keinen Code mit dem Hauptprodukt teilt, gehört außerhalb des Monorepos. Ein internes Tool, das von einem Ein-Personen-Team gepflegt wird, gehört außerhalb. Eine Open-Source-Bibliothek, die öffentliche Sichtbarkeit braucht, gehört außerhalb. Das ist nicht ein Kompromiss. Das ist die richtige Antwort auf eine Frage, die selten eine saubere binäre Antwort hat. Halte Dinge zusammen, die zusammen bewegt werden müssen. Trenne, was wirklich unabhängig ist. Das Wichtigste ist, die Entscheidung absichtlich zu treffen, nicht by default. Die meisten Teams, die bei Polyrepo-Zersplitterung landen, haben sich dafür nicht entschieden: Sie begannen einen Service, dann einen anderen, dann einen anderen, und hörten nie auf zu fragen, ob diese Services zusammenleben mussten. ## Die Tools, die jeden Ansatz wirklich funktionieren lassen **Für Monorepos:** - Nx: stärkste Feature-Set, gut für Polyglot Builds und Teams über 20 Packages. Höhere Lernkurve aber skaliert weiter. - Turborepo: einfacher zu starten, ausgezeichnet für JS/TS-Teams unter 20 Packages. Native Vercel-Caching oder selbst-gehostete Optionen. - Bazel: für sehr große Multi-Language-Repos im Enterprise-Maßstab. Erhebliche Setup-Investition erforderlich. **Für Polyrepos:** - Eine Versionierungs-Disziplin für gemeinsam genutzte Bibliotheken ist nicht optional. Ohne Semantic Versioning und einen konsistenten Changelog-Prozess wird Abhängigkeitsdrift innerhalb von sechs Monaten zur Norm. - CI/CD-Tools, die Cross-Repo-Pipelines triggern, wenn eine gemeinsam genutzte Abhängigkeit sich ändert. GitHub Actions unterstützt das via `workflow_dispatch` und `repository_dispatch`-Events zwischen Repos. - Ein Abhängigkeits-Registry (npm private Registry, GitHub Packages, Artifactory), um gemeinsam genutzte Paketverteilung zu verwalten. Biscuit kann die Config-Datei holen. Der Ruf, welche zu verwenden, kommt immer noch auf diese vier Fragen an. ![Developer, der an dual Monitor Setup Pull Requests in einem dunklen Home Office überprüft](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/47a076-img-3-inline.webp) ## Häufig gestellte Fragen zu Monorepo vs Polyrepo **Kann ich mit einem Monorepo beginnen und später zu Polyrepo wechseln?** Ja, aber es ist schwierig. Teams, die mit Monorepo starten und später teilen, brauchen viel Arbeit, um Abhängigkeiten zu entwirren. Der umgekehrte Weg ist einfacher: von Polyrepo zu Monorepo ist vor allem eine Tooling-Frage. **Wie lange sollte eine Monorepo sein, bevor ich mich Sorgen um Performance mache?** Mit modernen Tools nicht sehr lange. GitHub Actions bietet 10 GB freien Cache. Mit Turborepo können 20+ Packages problemlos verwaltet werden, mit Nx auch über 100. **Ist Monorepo nur für große Unternehmen gedacht?** Nein. Viele kleinere Teams mit 5-10 Personen verwenden Monorepos erfolgreich, wenn sie gemeinsamen Code teilen. Die Entscheidung hängt von Abhängigkeiten ab, nicht von Größe. **Was ist mit Open-Source-Projekten – sollten sie Monorepo nutzen?** Kommt darauf an. Wenn dein Open-Source-Projekt mehrere zusammengehörige Packages hat (z.B. CLI + Library), ist Monorepo clever. Wenn es standalone ist, separate Repo ist sauberer. **Können wir Monorepo und Polyrepo gleichzeitig nutzen?** Ja, das ist tatsächlich das häufigste Pattern. Monorepo für Kernprodukt (Frontend + Backend + Shared Libraries), separate Repos für unabhängige Komponenten, interne Tools und Open-Source-Projekte. ## FAQ ### Kann ich mit einem Monorepo beginnen und später zu Polyrepo wechseln? Ja, aber es ist schwierig. Teams, die mit Monorepo starten und später teilen, brauchen viel Arbeit, um Abhängigkeiten zu entwirren. Der umgekehrte Weg ist einfacher: von Polyrepo zu Monorepo ist vor allem eine Tooling-Frage. ### Wie lange sollte eine Monorepo sein, bevor ich mich Sorgen um Performance mache? Mit modernen Tools nicht sehr lange. GitHub Actions bietet 10 GB freien Cache. Mit Turborepo können 20+ Packages problemlos verwaltet werden, mit Nx auch über 100. ### Ist Monorepo nur für große Unternehmen gedacht? Nein. Viele kleinere Teams mit 5-10 Personen verwenden Monorepos erfolgreich, wenn sie gemeinsamen Code teilen. Die Entscheidung hängt von Abhängigkeiten ab, nicht von Größe. ### Was ist mit Open-Source-Projekten – sollten sie Monorepo nutzen? Kommt darauf an. Wenn dein Open-Source-Projekt mehrere zusammengehörige Packages hat (z.B. CLI + Library), ist Monorepo clever. Wenn es standalone ist, separate Repo ist sauberer. ### Können wir Monorepo und Polyrepo gleichzeitig nutzen? Ja, das ist tatsächlich das häufigste Pattern. Monorepo für Kernprodukt (Frontend + Backend + Shared Libraries), separate Repos für unabhängige Komponenten, interne Tools und Open-Source-Projekte.