# Monorepo vs polyrepo jämförelse: välj rätt repo-struktur URL: https://upstreamapi.com/sv/journal/monorepo-vs-polyrepo-jamforelse Type: blog Locale: sv Published: 2026-09-12 Updated: 2026-09-13 --- > Faros AI-benchmarks, 30%-regeln och en blast radius-analys som ger dig ett faktabaserat svar på monorepo vs polyrepo jämförelse för din organisation. Svaret på monorepo vs polyrepo jämförelse är inte en rekommendation, det är ett mätproblem. Specifikt: hur stor andel av era features kräver ändringar över mer än en servicegräns? Om du inte vet det talet fattar du ett infrastrukturbeslut baserat på teampreferens snarare än data. Och i en organisation med 50 ingenjörer kostar den preferensen någon en söndagsnatt. Det centrala är beräkningen. Båda tillvägagångssätten medför kostnader. Frågan är vilka kostnader din organisation kan absorbera bättre, koordinationsskatten i polyrepo eller verktygsinvesteringen i monorepo. Det finns ingen universellt korrekt arkitektur. Det finns en arkitektur som passar din nuvarande cross-service-frekvens, din plattformsingenjörskapacitet och ditt rollout-primitiv. De tre faktorerna avgör, inte teamkulturen eller vad Google gör. ## PR-cykeltid: data som borde avgöra saken, men inte gör det [Faros AI analyserade 320 ingenjörsteam](https://www.faros.ai/blog/monorepo-vs-polyrepo-benchmark-data) under 12 månader och fann att monorepo-miljöer har en median PR-cykeltid på 19 timmar. Polyrepo-miljöer: 2 timmar. Det är ett 9,5x gap vid medianen. Vid den 90:e percentilen minskar gapet till 8,6 dagar mot 5,5 dagar, men båda svansar är långsamma. Medelvärdet minskar också: 3,6 dagar för monorepo, 2,8 dagar för polyrepo. Motargumentet är välkänt: monorepos har snabbare individuella byggtider när caching fungerar. Ett polyrepo-team som koordinerar en cross-service-ändring över fem repositories med fem separata CI-pipelines och fem separata CODEOWNERS-krav stänger inte en PR på två timmar heller. Datan fångar cykeltider för typiska PRar, inte worst-case cross-cutting-ändringar. Den distinktionen är viktig. Polyrepo-team citerar sin median, snabb eftersom de flesta PRar är isolerade. Monorepo-förespråkare lyfter smärtan av att koordinera över repos, också verklig och dokumenterad i deras worst-case PR-svansar. Båda sidor har rätt om olika scenarier. Datan avgör inte debatten. Den beskriver avvägningen mer precist än magkänsla gör. En viktig observation: Faros AI-benchmarken mäter alla PRar i respektive miljö. Det inkluderar interna refaktoreringar, buggfixar i ett enda bibliotek och enkla konfigurationsändringar. I en monorepo är andelen isolerade PRar lägre per definition, eftersom codebase-bredden inbjuder till bredare ändringar. Det snedvrider medianen. Det förklarar inte hela 9,5x-gapet, men det förklarar en del av det. ![SRE-ingenjör övervakar driftsättningsmetrik vid arbetsstation med flera dashboards](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6a5eb6-inline1.webp) ## Blast radius som du inte beräknar Det som sällan syns på konferensbilderna: i en monorepo landar ett trasigt delat beroende i varje service som importerar det, i samma commit, innan någon med nedströmsägarskap har granskat ändringen. I en polyrepo bryter ett trasigt paket de services som uppgraderar det, men bara när de uppgraderar. Blast radius är uppskjuten och begränsad av konsumentens val. Det spelar roll för SLO-grindade utrullningar. Ett dåligt delat bibliotek i en monorepo ger dig inte ett canary-fönster. Det ger dig ett cross-service blast radius i ett enda driftsättningsevent. Din felbudget börjar brännas över flera SLOer simultant innan din utrullningsautomation kan identifiera mönstret och utlösa en revert. I en polyrepo är utrullningen av en delad beroendeändring sekventiell till sin natur. Service A uppgraderar och du bevakar dess SLO. Service B uppgraderar tre dagar senare. Blast radius vid ett givet tillfälle begränsas av vilka som redan adopterat ändringen. Frågan är inte vilken struktur som är inneboende säkrare, det är vad ditt driftsättningsprimitiv är. Om din driftsättningsenhet är servicen med sin egna SLO-grind ger polyrepo dig naturlig isolering. Om din driftsättningsenhet är den atomiska feature-ändringen som konsekvent landar över frontend, API och bakgrundsarbetare simultant ger monorepo dig den koordinationen utan versionsglidning. De flesta team som levererar mikrotjänster har det första problemet. De flesta team som levererar en tätt kopplad produktyta har det andra. ## Varför polyrepo-team träffar koordinationsväggen vid 50 ingenjörer Koordinationsskatten förstärks. Vid 8 ingenjörer är det irriterande men hanterbart att sköta fyra repositories. Vid 50 blir det ett deltidsjobb för flera personer. Koncreta tecken på att polyrepo-koordinationsoverhead har blivit strukturell: - Ditt plattformsteam underhåller ett shared-libraries-repo som ingen har tydligt ägarskap av - Versionering över services har glidit så mycket att det är ett tvåveckorsprojekt att bumpa det delade biblioteket - En ny ingenjör kan inte bli produktiv utan att förstå vilket av dina 23 repositories som ska klonas först - Säkerhetspatcher för delade beroenden kräver koordinerade PRar över ett dussintal repos, med ett spårningskalkylblad Inget av detta är uppfunna patologier. Det är dokumenterade fellägen från team som nådde 80 ingenjörer och tittade tillbaka på sina repobeslut med ånger. Polyrepo fungerar när team är genuint oberoende, med olika releasecykler, olika teknikstackar, olika bakjoursrotationer. När team delar tillräckligt med kod för att en ändring i en service kräver resonemang om tre andra, blir den isolering som polyrepo köptes för mekanismen som gör koordination smärtsam. Den organisatoriska indikatorn: räkna hur många Slack-kanaler som finns specifikt för att koordinera cross-repo-releaser. Om svaret är mer än noll betalar du redan koordinationsskatten konsekvent. ## Vad monorepos egentligen kostar i 95:e percentilen P90-datan från Faros AI är lärorik: 8,6 dagar för monorepo-PRar vid den 90:e percentilen. Det är inte ett långsamt team, det är den strukturella konsekvensen av stora cross-cutting-ändringar som kräver koordination över flera kodägare, bredare CI-matriser och granskningscykler som sträcker sig över organisationsgränser. Google har Bazel. Meta byggde Buck. Nx Cloud och Turborepo remote cache finns eftersom verktygsinvesteringen för att få en monorepo att prestera inte är trivial. En monorepo med 200 ingenjörer utan affected-only build selection, distribuerad caching och automatiserade merge-köer producerar 45-minutersCIkörningar på PRar som rör en delad verktygsfunktion. Verktygskostnaden är verklig och rutinmässigt underuppskattad. Team som framgångsrikt driver monorepos i stor skala har typiskt anställt plattformsingenjörer specifikt fokuserade på den infrastrukturen. Att retroaktivt anpassa monorepo-verktyg till en växande kodbas, samtidigt som man levererar produkt, är en belastning som syns i driftsättningsfrekvens innan den syns i ett post-mortem. Om ditt plattformsteam redan är pressat är att lägga till underhåll av monorepo-verktyg ett meningsfullt åtagande, inte ett konfigurationsval. ![Arkitekturdiagram på whiteboard som visar grenade pipeline-strukturer för monorepo och polyrepo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6dbec8-inline2.webp) ## 30-procentregeln som högpresterande team faktiskt använder En användbar tumregel från team som fattat det här beslutet medvetet: om mer än 30% av era features kräver ändringar över flera servicegränser kommer koordinationsoverhead i ett polyrepo till slut att överstiga verktygsinvesteringen i en väldriven monorepo. Under 30%, där de flesta mikrotjänstorganisationer befinner sig, uppväger polyrepos isoleringsfördelar vanligtvis koordinationsskatten. Cross-service-ändringar förekommer, men inte tillräckligt ofta för att delad verktygsanvändning ska löna sig snabbare än isolering gör. Det är mätbart. Ta ut era senaste sex månaders mergade PRar och räkna hur många som krävde ändringar i mer än ett repository för att leverera en enda användarsynlig feature. Det förhållandet är din indata. Det kommer inte att vara precist till en decimal, men det kommer att vara riktningsenligt, och riktningsenligt räcker för att stoppa debatten från att köra på teampreferens. Ett team med 12% cross-service-frekvens behöver inte en monorepo. Ett team på 38% och stigande betalar koordinationsskatt som fortsätter förstärkas. Den verkliga utmaningen är att räkna. De flesta team gör det aldrig. De debatterar istället i sex månader baserat på vad senioraste ingenjören föredrar, och fattar sedan ett beslut som de lever med i tre år. Mätningen tar ett par timmar. Debatten tar månader. ## Hur rollout-strategi förändrar kalkylen Det finns en dimension i det här beslutet som nästan aldrig täcks: ditt rollout-primitiv. Om du kör procentbaserade utrullningar med SLO-grinder, skickar en feature till 5% av trafiken, bevakar felbudgetar och sedan gradvis expanderar, förändras din blast radius-beräkning beroende på om featuren spänner över en service eller flera. I ett polyrepo kräver en multi-service feature-utrullning koordinering av utrullningstillståndet över services. Service A kan vara på 20% medan Service B fortfarande är på 0%, vilket skapar inkonsekventa tillstånd som är genuint svåra att resonera kring under incidentförhållanden. Feature flags hjälper, men du hanterar fortfarande cross-service flag-tillstånd utan en enda sanningskälla för utrullningsframsteg. I en monorepo med atomiska commits landar featuren konsekvent över services. Utrullningen kan fortfarande vara procentbaserad på infrastrukturnivå, men koden är konsekvent från det att driftsättningen sker. Dina SLO-grinder aktiveras mot ett koherent tillstånd. Team som gör många atomiska multi-service-features och kör progressiva utrullningar med automatiserad rollback vid SLO-brott finner ofta att monorepos konsekvens eliminerar en hel kategori av incident som polyrepo inte har ett rent namn på: cross-service state divergence-incidenten som ser ut som en bugg men egentligen är ett driftsättningskoordinationsproblem. ## Vad post-mortem faktiskt kommer att säga De flesta ingenjörsorganisationer hamnar i en hybrid som ingen kallar hybrid eftersom det låter som en arkitektonisk utväg. En eller två monorepos för tätt kopplade produktytor. Separata repositories för genuint autonoma services med oberoende driftsättningscykler, sin egna bakjoursrotation och ett team som inte har behövt koordinera en delad biblioteksändring på sex månader. Signalen att se över din nuvarande setup: - Cross-service-ändringsfrekvensen har passerat 30% och CI-körtider förstärks - Du har anställt plattformsingenjörer med kapacitet att investera i monorepo-verktyg - En blast radius-incident visade att din polyrepo-isolering var falsk, att services delade tillräckligt med infrastruktur för att isoleringen gav komfort, inte säkerhet Signalen att beslutet är tillräckligt för tillfället: - Team är genuint oberoende och koordinationsoverhead är låg - Din värsta incident orsakades inte av cross-service beroendeglid - Plattformsingenjörskapacitet finns inte för att underhålla monorepo-verktyg utan att sakta ner produktleveransen Post-mortem berättar för dig vilken av dessa du faktiskt lever i. Det dokumentet är vanligtvis mer ärligt än det arkitekturbeslutsdokument som föregick systemet det beskriver. Den frågan att ställa innan nästa arkitekturmöte: om vi hade en allvarlig cross-service incident imorgon, vad skulle post-mortem säga om vårt repoval? Om du inte kan svara på det med data, är det tid att samla in den. ## FAQ ### Vad är den viktigaste skillnaden mellan monorepo och polyrepo? Den viktigaste skillnaden är koordinationsprimitivet. I monorepo landar ändringar atomiskt över alla services. I polyrepo är services oberoende och uppgraderar beroenden när de väljer. Välj baserat på hur stor andel av dina features kräver cross-service-ändringar. ### Är monorepo bättre för stora team? Inte nödvändigtvis. Faros AI fann att monorepo PR-cykler i median är 9,5 gånger långsammare än polyrepo. Monorepo kräver dedikerade plattformsingenjörer och avancerade verktyg som Bazel, Nx eller Turborepo för att fungera i stor skala. ### Hur beräknar jag om monorepo passar mitt team? Gå igenom de senaste sex månadernas mergade PRar och räkna hur många som krävde ändringar i mer än ett repository för en enda användarsynlig feature. Om den andelen överstiger 30% och växer talar det för monorepo. ### Vad är blast radius-problemet med monorepo? I en monorepo landar ett trasigt delat beroende i varje service simultant innan nedströmsägare har granskat ändringen. Det finns inget naturligt canary-fönster. I polyrepo är blast radius begränsad till services som redan har uppgraderat beroendet. ### Vad används Bazel och Turborepo till i monorepo-sammanhang? Google använder Bazel och Meta byggde Buck för att hantera monorepo-skalbarhet. Bazel och Turborepo erbjuder affected-only build selection och distribuerad caching, vilket minskar CI-körtiderna drastiskt i stora monorepos. ### När bör jag välja polyrepo? Välj polyrepo när team är genuint oberoende med egna releasecykler, när cross-service-ändringsfrekvensen är under 30% och när du saknar plattformsingenjörer med kapacitet att underhålla monorepo-verktyg. ### Kan man kombinera monorepo och polyrepo? Ja, och det är det vanligaste utfallet i praktiken. En eller två monorepos för tätt kopplade produktytor, separata repositories för genuint autonoma services med oberoende driftsättningscykler. Du behöver inte välja ett alternativ för hela din infrastruktur.