dbt Labs 2025 State of Analytics Engineering raporu, çoklu proje mimarisine geçen ekiplerin oranının %58’e ulaştığını, ortalama model sayısının 24 ayda 5 katına çıktığını ve monorepo ekiplerin %47’sinde CI run süresinin 30 dakikayı geçtiğini gösteriyor. dbt Mesh tam buraya çözüm getiriyor.
dbt Mesh 2026: Multi-Project Mimarisinin Yükselişi
dbt Cloud 2024 sonunda multi-project (Mesh) özelliğini genel kullanıma açtı; 18 ay içinde 1.200+ kurum mesh paradigmasına geçti. dbt Labs 2025 raporunda mesh kullanan ekiplerde CI run süresinin ortalama %63 azaldığı, breaking change kaynaklı production incident’lerin %71 düştüğü tespit edildi. Forrester 2025 Analytics Engineering değerlendirmesinde mesh, “Strong Performer” kategorisinden “Leader” konumuna yükseldi. Konuyla ilişkili olarak Django 5.1 ASGI Production Mimarisinin Olgunlaşması rehberimiz detaylı incelemeyi içerir.
Monorepo dbt projeleri ekibin ilk 18 ayında verimli çalışır; ancak 800-1.000 model eşiğinden sonra üç temel sorun belirir: CI run süresi 30 dk+ olur, git conflict sayısı haftalık 12+’ya çıkar, domain ownership belirsizleşir. dbt Mesh bu üç sorunu birden çözer ama yanlış uygulandığında daha büyük kaos üretir. Snowflake 2025 dbt Adoption raporunda mesh kullanan müşterilerin %72’si time-to-insight metriğinde anlamlı iyileşme bildiriyor.
Multi-Project Setup: Adım Adım Konfigürasyon
Mesh kurulumu temel olarak iki dosyada yapılır: dbt_project.yml üst düzey proje meta’sını tanımlar, dependencies.yml ise diğer projelere referansı yönetir. Üretici proje (publisher) modeli “public” olarak işaretlemeli; tüketici proje (subscriber) bunu cross-project ref sintaksıyla kullanır. Ortalama mesh kurulumu 3-5 hafta sürüyor.
| Dosya | Görev | Anahtar Alanlar | Zorunlu |
|---|---|---|---|
| dbt_project.yml | Proje meta + ortak config | name, version, model-paths | Evet |
| dependencies.yml | Cross-project ref tanımı | projects, version | Tüketici için |
| models/_groups.yml | Group + access modifier | group, access, owner | Önerilen |
| models/_contracts.yml | Public model sözleşmesi | contract, constraints | Public için |
| .github/workflows/ci.yml | CI/CD entegrasyon | defer, state | Önerilen |
Cross-Project Reference ve Versioning Semantiği
dbt Mesh’in en kritik yeniliği versioned model’lardir. Aynı public model’in v1, v2 ve v3 sürümleri eşzamanlı yayında olabilir; downstream tüketiciler kademeli olarak yeni sürüme geçer. Bu özellik breaking change’i deprecation süreciyle yönetilebilir hale getiriyor. dbt Labs 2025 raporunda versioned model kullanan ekiplerde production breaking change sayısı %78 azaldı, deprecation süresi ortalama 67 gün.
- v1, v2, v3 model’leri ayrı materializasyonlarla aynı warehouse’da yaşar
- Tüketici proje spesifik sürüme bağlanabilir veya latest pattern’ini kullanabilir
- Deprecation date tanımlanırsa eski sürüm otomatik uyarı verir, sonra siliniyor
- Latest version işaretlenmemişse default olarak en yüksek numaralı sürüm kullanılıyor
- Migration window ortalama 60-90 gün arası, bu süre dbt Cloud’da otomatik takip ediliyor
Detaylı versioning patternleri için data contract rehberimize bakabilirsiniz.
Group, Access Modifier ve Domain Ownership
dbt 1.5+ ile gelen group ve access modifier’lar, mesh’in domain-driven veri mimarisinin temelini oluşturur. Group sahip ekibi tanımlar, access modifier ise modelin görünürlüğünü kontrol eder. “private” sadece aynı group içinde, “protected” aynı proje içinde, “public” cross-project erişime izin verir. dbt resmi dokümantasyonunda bu üç modifier detayıyla açıklanıyor.
Müşteri vakalarımda gördüğüm en sık hata: “domain” olarak isimlendirilen group’ların tek bir merkezi ekibe ait olması. Bu durumda mesh sadece etiket; gerçek ownership olmayınca on-call ve SLA tanımlanamıyor, hesap verebilirlik zayıflıyor.
Public Model Contract: Breaking Change Engelleme
Mesh’in başarılı uygulanması için public model’lere kontrat zorunlu kılınmalı. Kontrat olmadan downstream proje bir gün aniden kırılabilir. dbt model contract şu garantileri sağlar: kolon adı + veri tipi sabitlenir, NOT NULL ve unique constraint’leri zorunlu kılınır, CI’de breaking change tespit edilir. dbt Labs 2025 verilerine göre contract uygulayan ekiplerde production incident sayısı %58 azaldı, ortalama issue resolution süresi 12 saatten 90 dakikaya düştü. Konuyla ilişkili olarak Zero-Downtime Database Migration 2026: Expand-Contract Pattern rehberimiz detaylı incelemeyi içerir.
| Constraint Tipi | Kullanım | CI Davranışı | Production Davranışı |
|---|---|---|---|
| Column type | Kolon veri tipi | Build hatası verir | Warehouse kontrolü |
| not_null | Zorunlu alan | Test fail | DB level kontrol |
| unique | Benzersizlik | Test fail | Manual check |
| primary_key | Birincil anahtar | Validation | DB seviyesinde |
| foreign_key | Yabancı anahtar | Cross-model ref | Opsiyonel |
CI/CD Entegrasyonu: Defer ve Slim CI Stratejisi
Mesh’te CI hızlandırma için defer ve state:modified+ kullanımı kritik. Defer mekanizması production manifest’inden değişmeyen modelleri okur, sadece değişen ve downstream modelleri build eder. dbt Cloud kullanıcılarında slim CI pattern’i ortalama CI süresini 38 dakikadan 7 dakikaya indiriyor, GitHub Actions maliyetini %72 azaltıyor. dbt test pattern’leri rehberimizde CI/CD entegrasyonunu detaylandırdık.
Kurumsal dbt Mesh Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Domain ekipleri hâlâ tek “data team” sahipliğinde; mesh sadece etiket olarak kalıyor
- Public model contract eksik bırakılıyor, breaking change 3 ay sonra patlıyor
- Versioned model deprecation date tanımlanmıyor, 6 eski sürüm warehouse’da birikiyor
- Cross-project lineage Slack üzerinden konuşuluyor; impact analysis manuel ve hatalı
- Defer + state:modified kurulmuyor, CI süreleri 40 dk+ kalıyor
- Mesh’e geçiş öncesi monorepo refactoring atlanıyor; kötü bağımlılıklar yeni projelere taşınıyor
Sonuç
dbt Mesh 1.000+ model ölçeğindeki ekipler için zorunlu hale geliyor; ancak başarı domain ownership kültürüne, public model contract disiplinine ve CI/CD slim defer pattern’ine bağlı. Mesh’e geçiş öncesi mutlaka şu üç soruyu cevaplayın: Hangi 3-5 domain’in net sahibi var? Public modellerin contract’ları yazılmaya hazır mı? CI/CD defer altyapısı kurulu mu? Bu üç koşul sağlanmadan mesh sadece monorepo’yu çoklu repo’ya bölmek olur ve eski sorunları beraberinde getirir. Doğru uygulandığında ise data platform’un ölçek limitini kaldırıyor.
Sıkça Sorulan Sorular
Kaç model olunca mesh’e geçmek mantıklı?
dbt Labs 2025 verilerine göre mesh ROI eşiği yaklaşık 800-1.000 model ve 3+ domain ekibi. Bu rakamların altında mesh overhead’i kazanımdan fazla. 1.500+ model ve 5+ domain ekibinde mesh kaçınılmaz hale geliyor.
dbt Core ile mesh kullanılabilir mi yoksa Cloud zorunlu mu?
Multi-project ref özelliği dbt Core 1.6+ ile geliyor ancak cross-project discovery ve lineage UI sadece dbt Cloud Enterprise’da var. Core ile mesh kullanmak mümkün ama lineage manual yönetim gerektiriyor ve operasyonel maliyet artıyor.
Public model contract’larını test etmek için en iyi pattern nedir?
CI/CD pipeline’da dbt build –select state:modified+ ve custom contract validation step kombinasyonu standart. dbt Cloud’da slim CI otomatik defer’lar; self-hosted Core’da manifest comparison job’u kurmak gerekiyor.
Versioned model’leri kaç ay tutmak gerekir?
Tipik öneri: yeni sürüm yayınlandıktan sonra eski sürümü 90 gün deprecation window’da tutmak. Bu süre downstream takımlara migration için yeterli; 180 günü geçince eski sürümler maintenance yükü oluşturuyor.
Domain ekipleri henüz olgun değilse mesh’e geçmek doğru mu?
Hayır. Mesh prematüre uygulandığında dağınık monorepo’dan daha kaotik hale geliyor. Önce 2-3 domain’de ownership ve on-call kültürü oturmalı, sonra mesh adım adım rollout edilmeli. ThoughtWorks 2025 verilerine göre kültürel olgunluk olmadan mesh deneyenlerin %58’i 12 ay içinde monorepo’ya dönüyor.
Ömer ÖNAL
Mayıs 23, 2026dbt Mesh tek bir monorepo’nun şişmesini önleyen mimari değil, domain sahipliği için sözleşmeli arayüz getirir. Müşterilerimde gördüğüm en sık hata: ‘public’ model işaretlemeden cross-project ref kurmak. Sözleşme yoksa breaking change kaçınılmaz. Doğru mesh için 4 katman gerekiyor: contract, version, group ve access. Bunlar yoksa monolitik dbt’den daha çok kaos üretiyor. — Ömer ÖNAL