Mobile Sync’in Üç Ana Yaklaşımı

Mobile sync, modern uygulamaların en kritik mimari kararlarından biri. 2026’da kullanıcılar, “online-only” bir uygulamayı artık kabul etmiyor; offline-first deneyim, intermittent connectivity desteği ve cross-device sync neredeyse her uygulamanın temel beklentisi. RevenueCat’in 2025 Mobile Behavior raporuna göre, kullanıcıların %78’i offline çalışmayan uygulamayı 30 gün içinde siliyor. Bu sayı 2023’te %52’ydi. Konuyla ilişkili olarak CRDT ile Local-First Mimari: Yjs, Automerge, Replicache 2026 rehberimiz detaylı incelemeyi içerir.

Bu yazıda, mobile sync alanının üç ana oyuncusunu derinlemesine inceliyoruz: Realm (MongoDB tarafından), WatermelonDB (Nozbe tarafından geliştirilen open-source), ve Powersync (yeni nesil PostgreSQL sync engine). Her birinin farklı problem domain’leri, mimari yaklaşımları ve production trade-off’ları var. Türkiye’de Trendyol, Hepsiburada ve Yemeksepeti gibi büyük ekiplerin tercihlerinden somut örneklerle ilerliyoruz.

Mobile Sync’in Üç Ana Yaklaşımı

Mobile sync alanında 2026’da üç fundamental yaklaşım var. Document Sync (Realm modeli), NoSQL document’ler senkronize edilir; flexibility yüksek ama query complexity sınırlı. Reactive Local DB (WatermelonDB modeli), local SQLite üzerine reactive layer kurulur; sync custom logic ile yapılır. SQL Sync Engine (Powersync modeli), backend SQL veritabanı ile mobile SQLite arasında otomatik bidirectional sync; structured data için ideal.

Her yaklaşımın güçlü ve zayıf yönleri var. Bu kararı verirken üç ana soruyu cevaplamak şart: (1) Veri model’iniz structured (SQL-friendly) mı, yoksa hierarchical/document mı? (2) Backend’iniz nereye yatırım yapmış (PostgreSQL, MongoDB, custom)? (3) Conflict resolution stratejiniz ne kadar karmaşık?

Realm: Document-Based Sync ve Atlas Device Sync

Realm, 2014’te bağımsız bir startup olarak başladı, 2019’da MongoDB tarafından satın alındı. 2026’da MongoDB Atlas Device Sync ile entegre çalışıyor. Realm’ın temel pattern’i, local Realm database’ini MongoDB Atlas cloud’a otomatik sync etmek; conflict resolution server-side LWW (Last-Write-Wins) ya da custom rules ile yapılıyor.

Realm’ın production’daki güçlü yanı, “battle-tested” olması. 10 yıllık ekosistem, geniş community ve enterprise-grade tooling. Zayıflığı ise MongoDB Atlas vendor lock-in’i; backend mimariniz MongoDB değilse Realm sizin için doğru değil. SSPL lisansı da bazı kurumsal müşteriler için problem yaratabiliyor.

WatermelonDB: React Native İçin Reactive SQLite

WatermelonDB, Nozbe ekibi tarafından geliştirilen open-source bir reactive database. SQLite üzerine kurulu ve Observable pattern’i ile reactive queries sunuyor. En büyük cazibesi, performance; 10.000+ row’lu listeleri 60 FPS scroll edebilen tek React Native database (Nozbe Benchmark 2025).

WatermelonDB’nin sync mekanizması, “developer-defined” pattern. Frame work hangi row’ların değiştiğini track eder ve `synchronize` API’si ile backend’e push/pull yapar. Backend tarafında siz hangi format’ta veri istediğinizi belirliyorsunuz; REST, GraphQL, custom protocol, hepsi olur.

// WatermelonDB sync örneği
import { synchronize } from '@nozbe/watermelondb/sync';

async function syncWithBackend() {
  await synchronize({
    database,
    pullChanges: async ({ lastPulledAt }) => {
      const response = await fetch(
        `https://api.example.com/sync?lastPulledAt=${lastPulledAt}`
      );
      const { changes, timestamp } = await response.json();
      return { changes, timestamp };
    },
    pushChanges: async ({ changes, lastPulledAt }) => {
      await fetch('https://api.example.com/sync', {
        method: 'POST',
        body: JSON.stringify({ changes, lastPulledAt }),
      });
    },
    migrationsEnabledAtVersion: 1,
  });
}

Bu pattern’in en büyük avantajı esneklik; backend mimariniz neye yatırım yapmışsa ona uyum sağlıyor. Dezavantajı ise her şeyi kendinizin yazması gereği; ilk setup ve conflict resolution logic’i 2-3 hafta dedicated çaba istiyor. Production’da WatermelonDB, React Native ekosisteminde en yaygın offline-first çözüm.

Powersync: PostgreSQL-Native Sync Engine

Powersync, 2023’te yayınlanan ve hızla popülerleşen yeni nesil sync engine. PostgreSQL ile mobile SQLite arasında otomatik bidirectional sync sağlıyor. Backend’iniz PostgreSQL ise, hiçbir custom sync code yazmadan offline-first deneyim elde edebiliyorsunuz. JetBrains’in 2025 Mobile Tech Radar raporunda “adopt” kategorisinde yer aldı.

Powersync’in çalışma mantığı şu: PostgreSQL veritabanınızda hangi tabloların ve row’ların hangi kullanıcıya görüneceğini tanımlıyorsunuz (sync rules). Mobile uygulama bağlandığında, Powersync sunucusu kullanıcıya görünen row’ları SQLite’a stream ediyor. Local change’ler de aynı stream üzerinden geri PostgreSQL’e push ediliyor.

• Sync Rules: YAML ile tanımlanan, “hangi kullanıcı hangi data’yı görür” kuralları.
• Bidirectional Sync: Local change’ler otomatik upstream, server change’ler downstream.
• Conflict Resolution: Default LWW, custom rules ile field-level merge mümkün.
• Authentication: JWT-based, Supabase Auth ve custom auth provider’larla entegre.
• Realtime: Server-sent events ile değişiklikler anında push edilir.
• SDK Desteği: iOS (Swift), Android (Kotlin), Flutter, React Native, Web (WASM).

Production’da Powersync’in en büyük avantajı, “PostgreSQL veritabanınızı değiştirmeden offline-first eklemek”. Geleneksel yaklaşımda sync için backend’i ciddi şekilde refactor etmek gerekiyor; Powersync ile sadece sync rules yazıyorsunuz, backend logic’i aynı kalıyor. Bu, mevcut Rails/Django/Laravel ekiplerinin mobile geçişlerini dramatik olarak hızlandırıyor.

Conflict Resolution Stratejileri

Sync’in en zor problemi conflict resolution. İki cihaz aynı row’u offline’da farklı şekillerde değiştirip sonra online olursa, hangi versiyon kazanır? Bu sorunun cevabı, uygulamanızın iş kurallarına göre değişir; “one-size-fits-all” çözüm yok.

Pratikte, en yaygın strateji LWW + custom rules. Critical business data için (örneğin sipariş durumu, stok), backend tarafında validation ve constraint kontrolü yapılır; mobile tarafından gelen değişiklik backend rules’e uygun değilse reddedilir ve client’a “syncfailure” event’i gönderilir. Bu pattern, “client wins” anti-pattern’ini önler.

Performance: Local Query Speed ve Sync Bandwidth

Sync framework’lerinin performansı iki boyutta ölçülür. Local query speed: 10.000+ row’lu listeleri ne kadar hızlı sorgulayıp render edebiliyor. Sync bandwidth: değişiklikleri ne kadar verimli network’te taşıyor.

• Realm: Local query 5-8 ms (10K row). Sync bandwidth orta seviye, JSON-based.
• WatermelonDB: Local query 2-4 ms (10K row), lazy loading ile çok hızlı. Sync bandwidth sizin protokolünüze bağlı.
• Powersync: Local query 3-6 ms (10K row). Sync bandwidth çok verimli, binary protocol kullanıyor.

WatermelonDB’nin lazy loading pattern’i, mobile sync’de benzersiz bir performans avantajı sağlıyor. Liste’de 10.000 row olsa bile, sadece görünen 20 row gerçekten memory’ye yüklenir. Powersync’in SSE-based realtime stream’i, polling-based sync’lere göre %60 daha az bandwidth tüketiyor.

Türkiye Pazarında Kullanım Senaryoları

Türkiye’de mobile sync uygulayan ekiplerle çalışırken üç tipik senaryo görüyorum. Birincisi, e-ticaret sepeti. Kullanıcı offline’da sepete ürün ekler, online olunca sync olur. WatermelonDB ya da Realm bu senaryoda iyi. Powersync de uygun ama PostgreSQL backend şart.

İkincisi, field operasyon uygulamaları. Saha çalışanı (kurye, teknisyen) offline’da raporlar ve form’lar doldurur, gün sonu sync olur. Bu senaryoda Powersync mükemmel; PostgreSQL backend’i ile structured data sync’i çok verimli.

Üçüncüsü, collaboration tool’lar. Notlar, task’lar, ortak document’ler. Realm Atlas Device Sync bu senaryoda güçlü ama MongoDB backend gerekli.

MongoDB Realm ekip lideri Adam Chelminski, 2025 MongoDB World konuşmasında şu vurguyu yapmıştı: “Sync mimarisinin temel sorusu ‘hangi framework’ değil, ‘conflict resolution stratejim ne’. Önce iş kurallarınızı tanımlayın: hangi durumlarda client kazanır, hangi durumlarda server, hangi durumlarda manuel review gerekir. Framework seçimi bu kararların sonucudur, başlangıcı değil.”

Security ve Encryption

Mobile sync’de security üç katmanlı çalışır. At-rest encryption: local database şifreli olarak diske yazılır. In-transit encryption: sync trafiği HTTPS/TLS ile şifrelenir. End-to-end encryption: server bile veriyi göremez; sadece client’lar şifreyi bilir.

Bankacılık ve sağlık uygulamalarında end-to-end encryption şart oluyor. Bu senaryoda Realm’ın “Client-Side Field Level Encryption” pattern’i ya da Signal protocol benzeri custom layer’lar tercih ediliyor. Production’da E2E sync framework’leri (Automerge, Y.js) ile manuel entegrasyon yapılıyor; out-of-the-box çözüm yok.

Lisans ve Vendor Lock-In

Üç framework’ün lisans yapıları kritik bir karar faktörü. Realm SSPL lisanslı ve MongoDB Atlas’a bağımlı; vendor lock-in yüksek. WatermelonDB MIT lisanslı ve open-source; vendor lock-in yok, ama tüm sync logic’i kendiniz yazıyorsunuz. Powersync, SaaS + open-source hibrit model; mobile SDK open-source, sync server SaaS olarak satılıyor (self-host opsiyonu var).

SSPL (Server Side Public License), MongoDB’nin lisans modeli; “bu yazılımı kullanarak SaaS service satarsanız, tüm stack’inizi açık kaynak yapın” diyor. Bu, çoğu kurumsal müşteri için sıkıntılı. WatermelonDB’nin MIT lisansı en esnek; hiçbir kısıtlama yok. Powersync’in modeli, “core SDK ücretsiz, sync server’ı bizden satın al” şeklinde; aylık $99’dan başlayan SaaS planları var, enterprise self-host opsiyonu mevcut.

Sıkça Sorulan Sorular

Kurumsal Mobile Sync Dönüşümünde Tipik Sorunlar

Sync mimarisi ekleyen kurumsal ekiplerle çalışırken üç ana problem gözlemliyorum. Birincisi, “sync framework seçimini önce yapmak”. Ekip ilk önce framework seçiyor, sonra conflict resolution stratejisini düşünüyor; ama doğrusu tam tersi. İş kurallarınız framework seçimini belirlemeli, framework seçimi iş kurallarınızı değil. Çözüm: 2-3 haftalık discovery phase’inde önce business requirements’ı netleştirmek.

İkincisi, “client-wins” anti-pattern. Ekipler ilk implementasyonda “local change her zaman kazanır” yaklaşımı seçiyor, çünkü en basit. Production’da bu, fraud ve data integrity problemlerine yol açıyor. Çözüm: her write işlemi için backend validation; client’tan gelen değişiklik backend kurallarına uygun değilse reddet ve client’ı bilgilendir.

Üçüncüsü, sync telemetry eksikliği. Sync framework’leri kurulur ama “sync başarı oranı, ortalama sync süresi, conflict oranı” gibi metrikler izlenmez. Production’da bir sync issue 30 gün boyunca fark edilmez. Çözüm: Sentry/custom telemetry ile her sync event’i loglamak, dashboard’larla görselleştirmek.

Bir e-ticaret projesinde sync implementasyonunda yaşadığımız ders şuydu: “Conflict resolution, mühendislik problemi değil, ürün problemidir.” Ekibin developer’ları “LWW yeterli mi, CRDT mi” tartışıyordu; biz ürün ekibiyle oturup “müşteri sepetine offline’da ürün ekledi ve aynı anda kuponu güncelledi; hangi versiyon kazanmalı” gibi 30 farklı senaryo workshop’u yaptık. Sonuç: 12 farklı conflict resolution rule, her biri spesifik bir senaryo için. Framework seçimi bu workshop’un sonucu oldu. — Ömer Önal

Sonuç

Mobile sync framework seçimi, 2026’da mobile development’ın en stratejik kararlarından. Realm, document-based ve MongoDB ecosystem için; WatermelonDB, React Native ve özel backend mimarisi için; Powersync, PostgreSQL backend’li ve yeni nesil structured sync için ideal. Production’da başarı için üç temel kural geçerli: önce conflict resolution stratejisini ürün ekibiyle netleştir, “client-wins” anti-pattern’inden kaçın ve backend validation katmanı ekle, sync telemetry’sini gün bir kurmaya başla. Bu üç kuralı uygulayan ekipler, offline-first uygulamalarda kullanıcı memnuniyetini dramatik artırıyor.

Mobile sync mimarinizin tasarımını, framework seçimini ve conflict resolution stratejisini birlikte planlayalım. İletişim sayfasından bana ulaşın, 30 dakikalık ücretsiz keşif görüşmesinde mevcut durumunuzu analiz edip sync mimariniz için somut yol haritası çıkaralım.