Yazar: @atilayberber
Fabric mı, Databricks mı tartışması genellikle özellik listeleri üzerinden yapılır: Hangisinin Spark’ı daha hızlı, hangisinin notebook’u daha iyi, hangisinin yönetişimi daha olgun. Ama bir veri platformu seçerken CFO’nun gerçekten sorduğu soru farklıdır: Talep beklenenden fazla olduğunda ne olur?
Temmuz 2026’da yayımlanan bir karşılaştırma bu soruyu tek cümlede özetledi ve toplulukta çok konuşuldu: Fabric talepteki dalgalanmayı gecikmeye çeviriyor, Databricks ise maliyete. Kapasite bittiğinde Fabric yavaşlıyor ve sonunda işleri reddediyor; Databricks çalışmaya devam ediyor ve daha büyük bir fatura kesiyor.
Bu yazıda bu iki “acı” arasındaki seçimi, FabCon Barcelona’da gelen yeni maliyet seçenekleriyle birlikte tartışıyorum. Kısa versiyonu: 2026 sonunda bu ayrım eskisi kadar keskin değil.
Kısaca: Bu yazıda neler var?
- İki maliyet felsefesi: kapasite ve tüketim
- Gerçek fiyatlarla karşılaştırma (ve neden doğrudan karşılaştırılamaz)
- Fabric’in yeni kozları: kapasite aşımı (overage), F0 ve isteğe bağlı faturalama
- İki kamp: “Öngörülebilirlik” ve “Esneklik”
- Benim görüşüm: Asıl soru hangi riski yönetebileceğiniz
- Karar vermek için altı soru
İki maliyet felsefesi
Fabric bir kapasite satıyor. F2, F8, F64 gibi bir SKU alıyorsunuz; bu kapasite raporlar, refresh’ler, notebook’lar, pipeline’lar ve Copilot dahil bütün iş yükleri arasında paylaşılıyor. Fatura sabit; ama kapasiteyi aşarsanız smoothing devreye giriyor, ardından gecikme ve en sonunda reddedilen işler geliyor. Bu mekanizmayı kapasite ve Copilot maliyeti yazısında adım adım anlattım; burada tekrar etmeyeceğim.
Databricks tüketim satıyor. İş yükü türüne göre DBU (Databricks Unit) başına ödüyorsunuz. Yoğun bir gün geldiğinde cluster’lar büyüyor, iş bitiyor, ay sonunda fatura büyümüş oluyor. Kimse “rapor neden açılmıyor” diye aramıyor; finans “bu ay neden bu kadar yüksek” diye arıyor.
İkisinin de bir “başarısızlık modu” var. Fark, o başarısızlığın kime ve nasıl yansıdığında.
Gerçek fiyatlarla karşılaştırma
EPC Group’un Temmuz 2026 Azure perakende fiyatlarına (US West 2, USD) dayanan karşılaştırmasındaki rakamlar şöyle:
| Kalem | Fiyat |
|---|---|
| Fabric, kullandıkça öde | 0,18 $ / CU saati (tüm hesaplama dahil) |
| Fabric, 1 yıllık rezervasyon | Kullandıkça öde fiyatından yaklaşık %40,5 düşük; rezerve F64 yılda 60.032 $ |
| Fabric kapasite aşımı (overage) | 3 kat, yani 0,54 $ / CU saati |
| Databricks Jobs Compute (Premium) | 0,30 $ / DBU saati (VM, disk, ağ hariç) |
| Databricks All-purpose | 0,55 $ / DBU saati (VM hariç) |
| Databricks Serverless SQL | 0,70 $ / DBU saati (VM dahil) |
Aynı kaynak önemli bir uyarı da yapıyor: CU ile DBU arasında güvenilir bir dönüşüm yok. 60.032 dolar yaklaşık 200 bin Jobs Compute DBU saatine (VM maliyeti hariç) ya da yaklaşık 86 bin Serverless SQL DBU saatine denk geliyor; ama hangisinin daha fazla iş yaptığı tamamen iş yüküne bağlı. İnternette “Fabric X kat daha ucuz” ya da “Databricks X kat daha ucuz” diyen her grafiğe bu yüzden şüpheyle bakmak gerekiyor.
Bir ayrıntı daha sıklıkla unutuluyor: Databricks’i seçmek Power BI lisans maliyetini ortadan kaldırmıyor. Raporlar Power BI’da kalacaksa, F64 altında yine Pro (kullanıcı başı aylık 14 $) ya da PPU (24 $) lisansına veya kapasiteye ihtiyaç var. Toplam sahip olma maliyeti hesabına bu kalem girmezse, karşılaştırma eksik kalıyor.
Fabric’in yeni kozları
“Fabric yavaşlatır” eleştirisi bir yıl önce tamamen haklıydı. FabCon Barcelona’da gelen üç değişiklik tabloyu değiştiriyor:
1. Capacity overage (GA)
Kapasite aşımı, geçici aşırı yüklenmelerde throttling’i önlemek için uygun fazla tüketimi faturalandırıyor. Ücret, ilgili fazla CU saatleri için kullandıkça öde fiyatının üç katı; tüm kullanımın değil. Dikkat edilmesi gereken iki nokta var: Overage SKU’nun kaynaklarını artırmıyor ve kayan harcama eşiği kesin bir harcama tavanı değil.
Yani Fabric artık isterseniz “Databricks gibi” davranabiliyor: Yavaşlamak yerine fatura kesebiliyor. Ama üç katlık fiyatla.
2. F0 ve isteğe bağlı faturalama (genel önizleme duyuruldu, yayılım bekleniyor)
F0, önceden kapasite seçmeden Fabric ve OneLake’e girilebilen bir başlangıç noktası. İsteğe bağlı faturalama varsayılan olarak açık; desteklenen iş yükleri gerektiğinde hesaplama kullanıyor ve tüketime göre faturalanıyor. Buradaki “sıfır”, önceden ayrılan hesaplama demek; işlem kapasitesi ya da fiyat değil.
En önemli sonucu şu: Kuruluşlar, sadece göle erişmek için sürekli çalışan bir Fabric kapasitesi tutmadan OneLake’te okuma ve yazma yapabilecek. Ayrıca tek bir model seçmek zorunda değilsiniz: Düzenli raporlamayı rezerve kapasitede tutup, ara sıra çalışan Spark veri hazırlama işlerini isteğe bağlı çalıştırabilirsiniz.
3. Workspace düzeyinde surge protection
Bir workspace’in kapasitenin belli bir yüzdesinden fazlasını tüketmesini engelleyebiliyorsunuz; kritik workspace’ler muaf tutulabiliyor. “Bir analistin notebook’u bütün şirketin raporlarını durdurdu” senaryosunun ilacı bu.
İki kamp
Kamp 1: “Öngörülebilirlik her şeydir” (Fabric tarafı)
- Bütçe sabit. Finans ekibi yıl başında rakamı biliyor; sürpriz fatura yok.
- Tek bir kapasite bütün iş yüklerini taşıyor. Databricks DBU + Snowflake kredisi + Power BI kullanıcı lisansı gibi üç ayrı faturayı yönetmekten daha basit.
- BI ağırlıklı kurumlar için Direct Lake ve operasyonel veritabanlarının mirroring’i ciddi avantaj.
- Throttling acı verici ama hayatta kalınabilir; işleri gece saatlerine kaydırmak çoğu zaman yetiyor.
Kamp 2: “Esneklik her şeydir” (Databricks tarafı)
- Fabric’in kapasite modeli “kullan ya da kaybet” mantığında çalışıyor: Throttling’den kaçınmak için fazla kapasite alırsanız, sakin aylarda o kapasite boşa yanıyor.
- Büyük ölçekli ETL, makine öğrenimi ve çoklu bulut senaryolarında Databricks’in olgunluğu ve esnekliği öne çıkıyor.
- Throttling bir maliyet değil gibi görünüyor ama öyle: Sabah raporunu alamayan satış ekibinin kaybı faturada yazmıyor.
Ama bu kampın da bir zaafı var: Serverless SQL, anında ölçeklenen davranışıyla Snowflake’e çok benziyor; fakat Xomnia’nın analizine göre bu, platformun maliyet avantajını aşındıran belirgin şekilde daha yüksek bir fiyatla geliyor. Esneklik bedava değil.
Benim görüşüm: Asıl soru hangi riski yönetebileceğiniz
Bence “hangisi ucuz?” sorusunun cevabı yok, çünkü cevap iş yükünüzün şekline bağlı. Doğru soru şu: Talep patladığında, kurumunuz hangi acıyı daha iyi tolere eder?
- Finansınız sabit bir kapasite kalemiyle yaşayabiliyor ve ara sıra yavaşlama kabul edilebiliyorsa: Fabric’in doğal modeli size uyar.
- Finansınız değişken faturayı kaldırabiliyor ama yavaşlama kabul edilemezse: Databricks’in modeli size uyar.
2026 sonundaki yenilik şu: Fabric artık ikisini birden sunuyor. Overage ile yavaşlamak yerine fatura ödemeyi, F0 ve isteğe bağlı faturalama ile kapasite tutmadan çalışmayı seçebiliyorsunuz. Bu, Fabric’i otomatik olarak daha iyi yapmıyor; ama “Fabric sadece throttling yapar” eleştirisini artık eskimiş hale getiriyor. Benzer şekilde, “rezerve kapasite hiç büyütülemez” iddiası da güncel değil; kapasiteler yeniden boyutlandırılabiliyor.
Perakende açısından bakınca: Bir market zincirinde yük oldukça öngörülebilir. Her sabah raporlar, her gece refresh’ler, ay sonu ve bayram öncesi zirveler. Bu, kapasite modelinin en iyi çalıştığı şekil. Asıl risk, öngörülemeyen işlerde: Bir veri bilimcinin büyük bir notebook’u ya da kampanya döneminde Copilot kullanımının birden artması. İşte overage, surge protection ve F0 tam da bu boşlukları kapatmak için var.
Karar vermek için altı soru
EPC Group’un önerdiği altı eksenli test bence pratik bir başlangıç. Her soruyu “Fabric” ya da “Databricks” diye cevaplayın:
- Tüketim ağırlığı: Verinin büyük kısmı Power BI ve Microsoft 365’te mi tüketiliyor?
- Mühendislik ağırlığı: İş yükleriniz ağırlıklı olarak büyük ölçekli ETL ve ML mi?
- Bulut duruşu: Tek bulut (Azure) mu, çoklu bulut mu?
- Yönetişim zorunluluğu: Microsoft Purview ve Entra merkezli bir yönetişim mi gerekiyor?
- Yetenek arzı: Ekibiniz ve işe alabileceğiniz kişiler hangi platformu biliyor?
- Maliyet şekli toleransı: Finans sabit kalemi mi, değişken faturayı mı daha kolay yönetir?
Kaynağa göre beş ya da altı “F” Fabric ağırlıklı, beş ya da altı “D” Databricks ağırlıklı bir mimariye işaret ediyor. Tüketim Fabric’i, mühendislik Databricks’i gösteriyorsa ikisini birlikte çalıştırmak (veriyi OneLake’te paylaşıp her motoru güçlü olduğu yerde kullanmak) makul bir seçenek. Fabric’in Databricks verisini OneLake’te saklamayı üretimde desteklemesi de bu yolu kolaylaştırıyor.
Sonuç
“Fabric yavaşlatır, Databricks fatura keser” cümlesi hâlâ iki platformun doğal davranışını iyi anlatıyor. Ama 2026 sonunda Fabric’te bu davranışı değiştirmek için ayarlar var: Overage, F0, isteğe bağlı faturalama ve surge protection. Seçim artık “hangi platform” sorusundan çok “talep patladığında ne olmasını istiyorum ve bunun bedelini kim ödüyor” sorusuna dönüşüyor.
Siz hangi acıyı seçerdiniz: sabah raporunun gecikmesini mi, ay sonu sürpriz faturayı mı? Yorumlarda ya da LinkedIn’de tartışalım.
Kaynaklar
- Microsoft Fabric vs Databricks Decision Framework (EPC Group)
- Announcements from FabCon Barcelona 2026 (James Serra)
- Capacity overage overview (Microsoft Learn)
- Databricks, Fabric, or Snowflake: Pricing Model & Strategy (Xomnia)
- Microsoft Fabric Capacity Units and Cost Predictability Explained (Mayhemcode)
HABERDAR OL
Yeni rehberler, kategorilere ayrılmış tek bir e-postada.
Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.