Firebase Nedir? Firebase mi, Özel Backend mi? (2026)

Firebase, Google'ın kimlik doğrulama, veritabanı, dosya depolama, push bildirim ve analitiği hazır sunan backend platformudur. MVP ve küçük-orta ölçekli uygulamalarda haftalar kazandırır. Karmaşık sorgu, öngörülebilir fatura, veri konumu veya derin entegrasyon gerektiğinde ise özel backend ya da hibrit mimari daha doğru seçimdir.

Bu platform mobil dünyanın neredeyse varsayılan parçası. AppBrain'in 19 Eylül 2026 verisine göre Google Play'deki Android uygulamalarının %72,36'sı Firebase kütüphanesi içeriyor. En popüler uygulamalarda oran %82,12'ye çıkıyor. Bu rakam analitik ve bildirim gibi tekil servisleri de kapsıyor; yani herkes veritabanını Firebase'e emanet etmiyor.

Asıl karar da tam burada başlıyor. Uygulamanızın verisi nerede duracak, iş kuralları nerede çalışacak ve fatura büyüdüğünde kim kontrol edecek? Teklif aşamasında bu soruyu sormayan işletmeler, cevabı iki yıl sonra pahalı bir taşınma projesiyle öğreniyor.

Bu rehberi yazılımcı olmayan karar vericiler için hazırladık. Resmi fiyat sayfalarından doğruladığımız limitleri, Firebase'in gerçekten güçlü olduğu alanları, sınırlarını ve özel backend'in şart olduğu senaryoları bulacaksınız. Sonunda elinizde bir karar tablosu ve ajansınıza soracağınız sorular olacak.

Bu rehberde neler var?

• Firebase nedir, hangi servisleri kapsar?
• Firebase ücretli mi? Spark ve Blaze planları
• Okuma sayısı faturayı nasıl büyütür? Temsili hesap
• Firebase'in güçlü olduğu 5 alan
• Firebase'in sınırları: 5 başlıkta dürüst tablo
• Özel backend nedir, ne zaman şart olur?
• Firebase mi, özel backend mi? Karar tablosu
• Hibrit yaklaşım: ikisini birlikte kullanmak
• Supabase ve açık kaynak alternatifler nerede duruyor?
• Firebase'den özel backend'e geçiş nasıl planlanır?
• Ajansınıza sormanız gereken 8 soru
• Sıkça Sorulan Sorular

Firebase nedir, hangi servisleri kapsar?

Firebase 2011'de bağımsız bir girişim olarak yola çıktı; Google şirketi 2014'te satın aldı. Bugün tek bir ürün değil, yirmiye yakın servisten oluşan bir pakettir. Bu modele BaaS (Backend as a Service) denir: sunucu kurmaz, işletmez ve yamamazsınız; hazır servisleri uygulamanıza bağlarsınız.

Pazar da bu yönde büyüyor. Mordor Intelligence, mobil BaaS pazarını 2026 için 11,2 milyar dolar olarak hesaplıyor. Aynı rapor 2031'de 18,33 milyar dolar ve yıllık %10,34 büyüme öngörüyor.

İşletme gözüyle en sık kullandığınız servisler şunlar:

Bu listede önemli bir ayrım var. Bildirim, çökme raporu ve analitik servislerini neredeyse her proje kullanır ve bunlar sizi bağlamaz. Push bildirim stratejinizi FCM üzerine kurmak ya da uygulama analitiğini Firebase ile ölçmek, veritabanı kararından bağımsızdır.

Asıl mimari karar üç serviste düğümlenir: Authentication, Firestore ve Cloud Functions. Verinizi ve iş kurallarınızı bu üçlüye yerleştirdiğinizde Firebase artık yardımcı araç değil, uygulamanızın omurgası olur. Rehberin geri kalanı bu kararla ilgili.

Firebase ücretli mi? Spark ve Blaze planları

Firebase'in iki planı var. Spark ücretsizdir ve kart bilgisi istemez. Blaze kullandıkça öde modelidir; aynı ücretsiz kotaları korur, aşan kısmı faturalar. Aşağıdaki rakamları Eylül 2026'da Firebase'in resmi fiyat sayfasından doğruladık.

Tablodan üç pratik sonuç çıkıyor. Birincisi, ciddi bir uygulama Spark planında kalamaz. Google'ın duyurusuna göre Cloud Storage artık varsayılan bucket'lar dahil Blaze planı gerektiriyor. Cloud Functions ve SMS ile giriş de yalnızca Blaze'de çalışıyor. Yani kullanıcı fotoğraf yüklüyorsa ya da sunucu tarafında tek satır kod çalışıyorsa kart tanımlamak zorundasınız.

İkincisi, Blaze'e geçmek otomatik olarak para ödemek demek değildir. Ücretsiz kotalar aynen sürer. Birkaç yüz kullanıcılı bir uygulama aylarca sıfır faturayla çalışabilir.

Üçüncüsü, bugün ücretsiz olan yarın ücretli olabilir. Remote Config bunun güncel örneği: Google, 1 Eylül 2026'dan itibaren proje başına günlük 100.000 isteğin üzerini ücretlendiriyor. Tutar küçük, ama ders büyük: fiyat politikasını siz değil, sağlayıcı belirler.

SMS ile giriş ayrı bir parantezi hak ediyor. Google bu kalemi gönderdiğiniz SMS başına ve ülkeye göre faturalıyor. Kayıt akışını telefon doğrulamasına dayandıran ve yoğun üye alan bir uygulamada SMS gideri veritabanı faturasını geçebilir. Yerel bir SMS sağlayıcısıyla kendi doğrulama akışınızı kurmak değerlendirmeye değer bir alternatiftir; karar vermeden önce iki seçeneğin birim fiyatını karşılaştırın.

Firestore'un birim fiyatı bölgeye göre değişiyor. Google Cloud'un Firestore fiyat sayfasında 100.000 okuma için bölgeye göre 0,03 $, 0,039 $ ve 0,06 $ kademeleri yer alıyor. Yazma işlemleri bunun üç katı: 100.000 yazma 0,09 $ ile 0,18 $ arasında.

Okuma sayısı faturayı nasıl büyütür? Temsili hesap

Firestore sizi sunucu gücüne göre değil, okunan belge sayısına göre faturalar. Bu model iyi tasarlanmış bir uygulamada çok ucuzdur. Kötü tasarlanmış bir ekran ise aynı kullanıcı sayısıyla faturayı onlarca kat büyütür.

Aşağıdaki hesap temsilidir; gerçek bir projeye ait değildir. Günde 5.000 aktif kullanıcısı olan bir sipariş uygulaması düşünün:

• İyi tasarım: Kullanıcı günde ortalama 60 belge okuyor. Toplam 300.000 okuma eder. Ücretsiz 50.000 düşünce 250.000 okuma kalır. Günlük maliyet 0,08–0,15 $, aylık yaklaşık 2–5 $ olur.
• Kötü tasarım: Ana ekran her açılışta 500 belgelik listeyi baştan çekiyor ve kullanıcı uygulamayı günde 4 kez açıyor. Toplam 10 milyon okuma eder. Günlük maliyet 3–6 $, aylık 90–180 $ olur.

Aynı kullanıcı, aynı özellik, 40 kat fatura. Aradaki fark sayfalama, önbellek ve veri modeli kararlarından geliyor. Bu yüzden Firebase'de maliyet bir altyapı değil, bir mühendislik kalitesi konusudur.

Kötü senaryo bununla da sınırlı değil. Sonsuz döngüye giren bir fonksiyon ya da yanlış kurulmuş bir dinleyici, okuma sayısını saatler içinde milyonlara taşıyabilir.

Harcama sınırı var mı? Kısmen. Google'ın kendi dokümanı açık konuşuyor: bütçe uyarıları kullanımı ya da faturayı sınırlamaz, yalnızca haber verir. Eylül 2026'da gelen harcama sınırı (spend cap) özelliği ise bütçe dolunca servisi ay sonuna kadar durduruyor.

Ancak bu sınır şimdilik dört servisi kapsıyor: AI Logic, App Hosting, Cloud Functions ve Extensions. Firestore, Realtime Database, Cloud Storage ve Hosting kapsam dışında. Ayrıca uygulama anlık değil; doküman birkaç dakikalık gecikme olabileceğini ve o aralıktaki kullanımın faturalanacağını belirtiyor.

Bu tablo karşısında korunmanın yolu disiplindir. Yayından önce Blaze hesabına bütçe uyarısı kurun, Cloud Functions için harcama sınırı tanımlayın ve güvenlik kurallarını emülatörde test edin. Yayından sonraki ilk ay kullanım panelini her hafta inceleyin; beklenmeyen okuma artışlarını fatura kesilmeden yakalarsınız. Google da sürpriz faturalardan kaçınma rehberinde emülatörle test etmeyi, kullanım panelini izlemeyi ve bütçe kurmayı öneriyor.

Firebase'in güçlü olduğu 5 alan

Firebase'i küçümsemek de abartmak kadar yanlış. Aşağıdaki beş alanda özel backend ile yarışmak pahalıya patlar.

1. Pazara çıkış hızı. Üyelik, şifre sıfırlama, sosyal giriş, dosya yükleme ve bildirim altyapısını sıfırdan kurmak haftalar alır. Firebase'de bu parçalar hazırdır. MVP aşamasındaki bir girişim için bu fark, fikri erken test etmek ile bütçeyi altyapıya gömmek arasındaki farktır.

2. Düşük başlangıç maliyeti. Sunucu kiralamaz, DevOps uzmanı tutmazsınız. İlk kullanıcılarınız gelene kadar fatura çoğu zaman sıfırdır. Sabit gider yerine kullanıma bağlı gider ödersiniz.

3. Gerçek zamanlı eşitleme ve çevrimdışı çalışma. Firestore verideki değişikliği bağlı cihazlara anında iletir. Resmi dokümana göre çevrimdışı kalıcılık Android ve Apple platformlarında varsayılan olarak açık gelir; web'de ayrıca etkinleştirirsiniz. Kurye takibi, canlı sipariş durumu ya da sahada çekimsiz bölgede çalışan satış ekipleri için bu yetenek büyük zaman kazandırır.

4. Otomatik ölçeklenme. Kampanya günü trafik on katına çıktığında sunucu eklemek için kimseyi aramazsınız. Kapasite planlaması Google'ın işidir.

5. Bütünleşik mobil araçlar. Crashlytics, Analytics, Remote Config ve A/B testi aynı panelde çalışır. iOS, Android, web ve Flutter için resmi SDK'lar bulunur; React Native tarafında da olgun bir topluluk kütüphanesi var.

Temsili bir örnekle somutlaştıralım. Bursa'da üç şubeli bir spor salonu zincirinin üyelerine ders rezervasyonu sunmak istediğini düşünün. Birkaç bin üye, basit bir takvim, push bildirim ve üyelik kartı yeterli. Bu kapsamda özel sunucu kurmak gereksiz bir sabit giderdir. Firebase ile uygulama daha kısa sürede çıkar ve altyapı faturası uzun süre ücretsiz kotanın içinde kalır.

Firebase'in sınırları: 5 başlıkta dürüst tablo

Aynı platformun sizi zorlayacağı yerler de var. Bunların hiçbiri gizli değil; hepsi Google'ın kendi dokümanlarında yazıyor.

1. Vendor lock-in. Firestore verinizi dışa aktarabilirsiniz. Ancak güvenlik kuralları, Cloud Functions tetikleyicileri ve istemci tarafındaki sorgular Firebase'e özgüdür. Başka altyapıya geçmek, veriyi taşımak değil arka ucu yeniden yazmak demektir.

Bağımlılığın bir yüzü de ürün kararlarıdır. Google, Firebase Dynamic Links servisini 25 Ağustos 2025'te kapattı. O tarihten sonra servisin ürettiği tüm bağlantılar 404 hatası dönüyor. Kampanya linklerini ve QR kodlarını bu servise bağlayan işletmeler göç etmek zorunda kaldı.

2. Ölçekte maliyet ve öngörülemezlik. Okuma başına fiyat küçük uygulamada avantajdır. Okuma ağırlıklı ve kalabalık bir üründe ise fatura kullanıcı sayısından hızlı büyüyebilir. Yukarıdaki temsili hesap bunu gösteriyor. Veritabanı tarafında sabit tavan koyamamak, finans ekipleri için ayrı bir sorundur.

3. Sorgu ve veri modeli kısıtları. Firestore'un standart sürümü NoSQL mantığıyla çalışır; tablolar arası JOIN yoktur. Resmi dokümana göre bir in sorgusunda en fazla 30 değer birleştirirsiniz. Bir belge en fazla 1 MiB olabilir. Zaman damgası gibi sıralı artan bir alanı indekslediğinizde o koleksiyona yazma hızı saniyede 500 ile sınırlanır.

Pratikte bu şu demek: "geçen ay en çok sipariş veren 20 bayinin ürün bazlı cirosu" gibi bir rapor için ya veriyi kopyalayarak saklarsınız ya da ayrı bir raporlama veritabanı kurarsınız.

Google bu açığı kapatmaya çalışıyor. Google, 27 Nisan 2026'da Firestore Enterprise sürümünde pipeline sorgularını ve JOIN desteğini genel kullanıma açtı. Tam metin arama ve coğrafi sorgular ise önizleme aşamasında. Bu yetenekler ayrı fiyatlanan Enterprise sürümünü gerektiriyor ve indeks davranışı farklı çalışıyor. Yani kısıt ortadan kalkmadı; daha pahalı bir katmana taşındı.

4. Veri konumu ve KVKK. Firestore veritabanınızı oluştururken bir bölge seçersiniz. Google'ın bölge listesinde Frankfurt, Hollanda, Varşova, Doha ve Tel Aviv gibi lokasyonlar var; Türkiye yok. Aynı sayfa bir uyarı daha içeriyor: veritabanını kurduktan sonra konumu değiştiremezsiniz.

Bölge seçimi her servisi kapsamıyor. Google'ın gizlilik dokümanına göre Firebase Authentication yalnızca ABD veri merkezlerinden çalışıyor. Yani veritabanı için Frankfurt'u seçseniz bile kullanıcılarınızın giriş verilerini ABD'de işlersiniz.

KVKK açısından bunun anlamı nettir. Kurum'un Ocak 2025 tarihli Kişisel Verilerin Yurt Dışına Aktarılması Rehberi, yurt dışındaki bir bulutta depolamayı belirli koşullarda aktarım sayıyor. Standart sözleşme yolunu seçerseniz imzadan sonra beş iş günü içinde Kurum'a bildirmeniz gerekiyor.

Bu, Firebase kullanamayacağınız anlamına gelmez. Aktarımın hukuki dayanağını baştan kurmanız gerektiği anlamına gelir. Sağlık, finans ya da kamu verisi işliyorsanız konuyu bir hukukçuyla netleştirin; bu yazı hukuki görüş değildir. Ayrıntılar için mobil uygulama güvenliği ve KVKK rehberimize bakabilirsiniz.

5. Güvenlik kuralları sizin sorumluluğunuzda. Firebase'de istemci veritabanına doğrudan bağlanır. Aradaki tek kapı, sizin yazdığınız güvenlik kurallarıdır. SecurityWeek'in aktardığı 2024 araştırmasında üç araştırmacı, yanlış yapılandırılmış Firebase kurulumları yüzünden yaklaşık 900 sitede 125 milyon kullanıcı kaydının açıkta kaldığını buldu. Bunların 20 milyondan fazlası düz metin paroladı.

Sorun platformda değil, kurulumdaydı. Ama ders açık: "test modu" ile yayına çıkan bir uygulama, kilidi olmayan bir depoya benzer.

Özel backend nedir, ne zaman şart olur?

Özel backend, uygulamanızın sunucu tarafını sizin için yazılmış kodla kurmak demektir. Tipik yapı üç parçadan oluşur: bir API katmanı (Node.js, .NET, Laravel, Go gibi), bir ilişkisel veritabanı ve bunları barındıran sunucu ya da bulut hesabı.

Veritabanında en yaygın tercih PostgreSQL. Stack Overflow'un 2025 geliştirici anketinde PostgreSQL'i kullananların oranı %55,6; Cloud Firestore'da bu oran %5,7. Aynı ankette Firebase platformunu kullananların oranı %13,1. Bu fark işletme için şunu söyler: ilişkisel veritabanı bilen geliştirici bulmak çok daha kolaydır.

Şu altı durumdan biri sizin için geçerliyse özel backend'i ciddi biçimde değerlendirin:

1. Karmaşık ilişkisel veri. Stok, cari hesap, fiyat listesi, kampanya ve sipariş birbirine bağlıysa SQL doğal çözümdür. B2B bayi sistemleri bunun tipik örneğidir.
2. Yoğun raporlama. Yönetim paneli onlarca filtreyle çalışan raporlar istiyorsa NoSQL sizi yorar.
3. Derin entegrasyon. ERP, muhasebe, e-fatura ve kargo sistemleriyle çift yönlü konuşan bir uygulama kendi sunucusuna ihtiyaç duyar. Konuyu API entegrasyonu rehberimizde ayrıntılı anlattık.
4. Veri konumu zorunluluğu. Sözleşmeniz ya da sektörünüz verinin Türkiye'de kalmasını gerektiriyorsa seçenek bellidir.
5. Öngörülebilir maliyet. Sabit aylık sunucu bedeli, finans planlamasını kolaylaştırır.
6. Çok kiracılı ürünler. Müşteri bazında veri izolasyonu isteyen SaaS ürünlerinde mimariyi baştan kendiniz kurmak daha güvenlidir.

Özel backend'in bedelini de dürüstçe söylemek gerek. Kimlik doğrulama, dosya yükleme, yedekleme, izleme ve güvenlik yamaları artık sizin ekibinizin işidir. İlk sürüm daha geç çıkar ve geliştirme bütçesi büyür.

Bu yüzden özel backend kararını bakım planıyla birlikte verin. Sunucu izlemeyi, günlük yedeği ve güvenlik güncellemelerini kimin üstleneceğini sözleşmeye yazın. Bu maddeler eksikse altyapı sahipsiz kalır ve bedelini ilk kesintide ödersiniz.

İşletme giderinde ise tablo tersine dönebilir. Küçük ve orta ölçekli uygulamalarda sunucu giderinin tipik aralığını bakım maliyeti rehberimizde aylık 500–5.000 TL olarak vermiştik. Bu rakam kullanıcı sayınız ikiye katlandığında ikiye katlanmaz. Backend kapsamının toplam bütçeye etkisini mobil uygulama maliyet hesaplayıcımızla kabaca görebilirsiniz.

Firebase mi, özel backend mi? Karar tablosu

Aşağıdaki tabloyu teklif toplantısına götürün. Satırların çoğu sol sütunu gösteriyorsa Firebase ile başlamak mantıklıdır. Sağ sütun ağır basıyorsa özel backend'i baştan planlayın.

Tabloyu okurken bir tuzağa dikkat edin. "İleride büyürüz" varsayımıyla bugünden ağır altyapı kurmak, en sık yapılan bütçe hatalarından biridir. Bugünün ihtiyacını ölçün; yarının ihtiyacı için çıkış kapısını açık bırakın.

Hibrit yaklaşım: ikisini birlikte kullanmak

Gerçek projelerin çoğu iki uçtan birini seçmez. Firebase'in sizi bağlamayan servislerini kullanır, veriyi ve iş kurallarını kendi tarafında tutar. Yaygın üç model var.

Model 1: Firebase kenarda, veri sizde. Push bildirim, çökme raporu, analitik ve Remote Config Firebase'de kalır. Kullanıcı verisi, siparişler ve iş kuralları kendi API'nizde ve PostgreSQL'de durur. Bağımlılık düşüktür, çünkü bu servislerin her birini ayrı ayrı değiştirebilirsiniz.

Model 2: Giriş Firebase'de, gerisi sizde. Firebase Authentication girişi yönetir, sunucunuz gelen kimlik belirtecini doğrular. Sosyal giriş ve SMS doğrulama derdinden kurtulursunuz. Dikkat: kullanıcı hesaplarını ileride taşımak bu modelin en zahmetli kısmıdır.

Model 3: Gerçek zamanlı ekranlar Firebase'de. Sohbet, canlı konum ya da anlık sipariş durumu Firestore üzerinden akar. Kalıcı kaydı ve raporlamayı kendi veritabanınız tutar. İki sistem arasındaki eşitlemeyi sunucunuz yönetir.

Hibrit mimarinin altın kuralı tek cümledir: mobil uygulama Firebase ile doğrudan değil, mümkün olduğunca kendi API'niz üzerinden konuşsun. Araya koyduğunuz bu ince katman, ileride altyapıyı değiştirirken uygulamayı mağazaya yeniden göndermekten sizi kurtarır.

Firebase'in kendi içinde de bir ara yol oluştu. Eski adı Data Connect olan SQL Connect, Cloud SQL üzerinde çalışan PostgreSQL veritabanını Firebase SDK'larıyla kullanmanızı sağlıyor. İlişkisel veri sorununu çözer; ancak sizi yine Google Cloud ekosistemine bağlar.

Yapay zeka özellikleri ekliyorsanız aynı mantık geçerlidir. Model çağrılarını istemciden değil sunucudan yapmak hem anahtar güvenliği hem fatura kontrolü sağlar. Ayrıntılar mobil uygulamaya yapay zeka entegrasyonu yazımızda.

Supabase ve açık kaynak alternatifler nerede duruyor?

Firebase ile özel backend arasında üçüncü bir seçenek var: PostgreSQL üzerine kurulu açık kaynak BaaS platformları. En bilineni Supabase. Stack Overflow anketinde kullanım oranı 2024'ten 2025'e %3,8'den %5,4'e çıktı; Firebase ise %13,9'dan %13,1'e geriledi.

Bu platformların cazibesi iki noktada toplanıyor. Veriniz standart bir PostgreSQL veritabanında durur; ayrılmak isterseniz SQL dökümünü alıp gidersiniz. Ayrıca platformu kendi sunucunuzda barındırabilirsiniz, bu da veri konumu sorununa bir çıkış sunar.

Fiyat modeli de farklı. Supabase'in fiyat sayfasına göre ücretsiz plan 500 MB veritabanı ve 50.000 aylık aktif kullanıcı içeriyor. Supabase, bir hafta kullanmadığınız ücretsiz projeleri duraklatıyor. Pro plan aylık 25 dolar ve harcama sınırı varsayılan olarak açık geliyor.

Zayıf tarafları da var. Çevrimdışı eşitleme Firestore kadar olgun değil, mobil araç seti daha dar. Kendi sunucunuzda barındırdığınızda işletme yükü yine size geçer. Kısacası bu seçenek "Firebase'in hızı, SQL'in esnekliği" arayan ekiplere uygundur; herkes için sihirli çözüm değildir.

Firebase'den özel backend'e geçiş nasıl planlanır?

Firebase ile başlayıp büyüyen bir ürünün taşınması mümkündür, ama plansız yapılırsa pahalıdır. Geçişi beş adımda düşünün.

1. Sinyalleri doğrulayın. Fatura gelirden hızlı mı büyüyor? Raporlar için veriyi kopyalamak zorunda mı kalıyorsunuz? Yeni bir entegrasyon Firestore yüzünden mi tıkandı? Tek başına "büyüdük" duygusu geçiş gerekçesi değildir.
2. API katmanını önce kurun. Uygulama ile Firebase arasına kendi API'nizi koyun. Bu aşamada veri hâlâ Firestore'da durur; kullanıcı hiçbir fark görmez.
3. Modül modül taşıyın. Önce raporlama ve sipariş gibi ilişkisel modülleri yeni veritabanına alın. Bir süre iki sisteme birden yazın ve sonuçları karşılaştırın.
4. Kullanıcı hesaplarını en sona bırakın. Kimlik doğrulama taşıması en riskli adımdır. Parola özetlerini dışa aktarmak ve oturumları bozmadan geçmek ayrı bir planlama ister.
5. Eski sürümleri hesaba katın. Mağazadaki eski uygulama sürümleri aylarca kullanılmaya devam eder. Eski altyapıyı kapatmadan önce zorunlu güncelleme mekanizmanızın çalıştığını test sürecinizde doğrulayın.

Bu beş adımın ortak mesajı şudur: geçişin maliyetini ilk gün verdiğiniz kararlar belirler. Uygulama kodunda Firebase çağrılarını tek bir veri katmanında toplayan ekip, iki yıl sonra haftalarla ölçülen bir geçiş yapar. Çağrıları yüzlerce ekrana dağıtan ekip ise uygulamayı yeniden yazar.

Ajansınıza sormanız gereken 8 soru

Teklif alırken altyapı kararı çoğu zaman tek satırla geçer: "Backend: Firebase." O satırın arkasını şu sorularla açın.

1. Firebase'in hangi servislerini kullanacaksınız ve her birini neden seçtiniz?
2. Verimiz hangi bölgede duracak ve KVKK açısından aktarımın dayanağı ne olacak?
3. Firebase projesi ve faturalandırma hesabı kimin adına açılacak?
4. Güvenlik kurallarını kim yazacak, nasıl test edeceksiniz ve App Check kullanacak mısınız?
5. Bütçe uyarılarını ve harcama sınırlarını hangi tutarlarla kuracaksınız?
6. Beklenen kullanıcı sayısında aylık tahmini fatura nedir ve hangi varsayımlara dayanıyor?
7. Uygulama kodu Firebase'e doğrudan mı bağlanacak, yoksa arada bir veri katmanı olacak mı?
8. İleride özel backend'e geçmek istersek hangi parçaları yeniden yazmamız gerekir?

Üçüncü soru özellikle kritik. Proje ajansın Google hesabında açılırsa hem veri hem fatura kontrolü sizin dışınızda kalır. Yazılım firması seçerken hesap sahipliğini sözleşmeye yazdırın. Son sorunun cevabı ise ajansın mimariyi ne kadar düşündüğünü birkaç dakikada gösterir.

Sıkça Sorulan Sorular

Firebase nedir, kısaca ne işe yarar?

Firebase, Google'ın mobil ve web uygulamaları için sunduğu hazır backend platformudur. Kimlik doğrulama, veritabanı, dosya depolama, push bildirim, çökme raporlama ve analitik servislerini sunucu kurmadan kullanmanızı sağlar.

Firebase ücretsiz mi?

Spark planı ücretsizdir ve günde 50.000 Firestore okuması, 20.000 yazma, 1 GiB depolama ile 50.000 aylık aktif kullanıcı içerir. Cloud Storage, Cloud Functions ve SMS ile giriş için kullandıkça öde modeli olan Blaze planına geçmeniz gerekir. Blaze'de de aynı ücretsiz kotalar geçerlidir.

Firebase'de faturaya üst sınır koyabilir miyim?

Kısmen. Bütçe uyarıları yalnızca e-posta gönderir, kullanımı durdurmaz. Eylül 2026'da gelen harcama sınırı özelliği AI Logic, App Hosting, Cloud Functions ve Extensions servislerini bütçe dolunca durdurur; Firestore ve Cloud Storage bu kapsamın dışındadır.

Firebase büyük uygulamalar için uygun mu?

Teknik olarak ölçeklenir; Realtime Database Blaze planında veritabanı başına 200.000 eşzamanlı bağlantıyı destekler. Asıl sınır maliyet ve sorgu esnekliğidir. Okuma ağırlıklı, ilişkisel verili ve yoğun raporlama isteyen büyük ürünlerde özel backend ya da hibrit mimari genellikle daha ekonomiktir.

Firebase kullanmak KVKK'ya aykırı mı?

Hayır, kendiliğinden aykırı değildir. Ancak Firestore'un Türkiye'de bölgesi bulunmadığı için verinizi yurt dışında depolarsınız ve KVKK'nın yurt dışına aktarım hükümleri devreye girer. Standart sözleşme gibi bir dayanak kurmanız ve imzadan sonra beş iş günü içinde Kurum'a bildirmeniz gerekir; somut durumunuz için hukuki destek alın.

Firebase'den sonradan özel backend'e geçebilir miyim?

Geçebilirsiniz, ancak veriyi taşımak yetmez; güvenlik kurallarını, fonksiyonları ve sorguları yeniden yazarsınız. Uygulama kodunda Firebase çağrılarını baştan tek bir veri katmanında toplarsanız geçişi haftalar içinde tamamlarsınız. Aksi halde uygulamanın büyük kısmını yeniden geliştirmeniz gerekir.

Firebase mi Supabase mi?

Çevrimdışı çalışma, gerçek zamanlı eşitleme ve olgun mobil araçlar öncelikliyse Firebase öndedir. İlişkisel veri, SQL raporlama, kendi sunucunda barındırma ve kolay çıkış öncelikliyse PostgreSQL tabanlı Supabase daha uygundur. İkisi de sunucu yönetimini üstlenir; fark veri modelinde ve bağımlılık düzeyindedir.

Özel backend Firebase'den ne kadar pahalı?

Geliştirme tarafında daha pahalıdır, çünkü üyelik, dosya yükleme, yedekleme ve izleme gibi hazır gelen parçaları ekibiniz kurar. İşletme giderinde ise tablo değişebilir: küçük ve orta ölçekli uygulamalarda sunucu gideri tipik olarak aylık 500–5.000 TL aralığındadır ve okuma sayısına göre dalgalanmaz.

Altyapı seçimi bir teknoloji tartışması gibi görünür, ama özünde bir iş kararıdır. Hızlı çıkmak ve fikri ucuza doğrulamak istiyorsanız Firebase güçlü bir başlangıçtır. Veriniz ilişkisel, raporlarınız yoğun ve entegrasyonlarınız derinse özel backend yatırımı kendini geri öder. Çoğu işletme için doğru cevap ikisinin bilinçli bir karışımıdır.

Hangi seçeneğin projenize uyduğundan emin değilseniz kapsamınızı birlikte değerlendirelim. Mobil uygulama geliştirme ve web yazılım ekiplerimiz altyapı kararını teklifin ilk sayfasında gerekçesiyle sunar. Projenizi anlatmak için iletişim sayfamızdan bize ulaşın; size bugünün bütçesine ve yarının büyümesine uyan mimariyi önerelim.