Supabase’den aşamalı geçiş rehberi

Kimler için?

Mobil uygulama ve backend geliştiren ekipler.

Başlamadan önce

Kendi staging ortamınız, örnek kullanıcı akışı ve erişim modeli.

1. Şema ve ürün bağımlılıklarını çıkarın

Tabloları, view’ları, trigger’ları, extension’ları, RLS politikalarını ve role grant’larını envantere alın. Mobil istemcinin doğrudan Supabase API çağrılarını ve Edge Functions kullanımını da listeleyin.

2. PostgreSQL uyumluluğunu doğrulayın

Kaynak ve hedef sürüm, extension ve collation farklarını kontrol edin. Dump’ı izole bir hedefe restore edin; admin rolüyle değil gerçek uygulama rolüyle sorguları ve izinleri sınayın.

3. Auth ve tenant sınırlarını yeniden kurun

Kullanıcı kimlikleri, sosyal sağlayıcı bağlantıları ve parola/oturum geçişi için ayrı plan yapın. RLS ile korunmuş kayıtlar yeni API üzerinden erişiliyorsa aynı tenant ayrımı backend’de doğrulanmalıdır.

4. Dosya ve realtime akışlarını ele alın

Storage nesnelerini, erişim politikalarını ve public / private URL kullanımını birlikte taşıyın. Realtime kanal üyeliği ve yeniden bağlanma davranışı SQL restore ile kendiliğinden gelmez.

5. Pilot, ölçüm ve kesim yapın

Mobil uygulamanın tek bir akışını yeni endpoint’e yönlendirin. SQL sonuçlarını ve izin kararlarını karşılaştırın; RAM, bağlantı havuzu ve sorgu sürelerini ölçün. Kesim anındaki yazmaları ve geri dönüş yolunu belirleyin.

6. İşletme sorumluluklarını planlayın

Self-host veya özel API yaklaşımı yedekleme, yükseltme ve monitoring işi getirir. Tüm Supabase stack’ini 2 GB VDS’ye garanti edemeyiz. Uygulama Cloud otomatik restore veya hazır Supabase hosting servisi sunmuyor; bu rehber uygulama planıdır.

7. Extension, rol ve RLS uyumunu kontrol edin

Şemanın yüklenmesi aynı davranışı garanti etmez. Hedef PostgreSQL sürümünü, extension listesini, trigger/function bağımlılıklarını ve API’nin kullandığı rolü envantere alın. RLS politikasında kullanılan auth fonksiyonu yeni ortamda yoksa politika çalışmaz veya farklı bağlamda çalışır. Yönetici rolüyle yapılan başarılı test, sıradan kullanıcının erişim sınırını kanıtlamaz.

Staging’de migration sırasını, başarısız bir adımın geri alınmasını ve yeniden çalıştırmayı deneyin. Global rollerin, sırların ve dış dosyaların dump içinde otomatik taşındığını varsaymayın.

8. Auth, Storage ve Realtime için ayrı geçiş planı

SQL verisini taşırken kullanıcı kimliği sabit kalmalı veya tutarlı bir mapping yapılmalıdır. Dosya nesneleriyle metadata’yı birlikte kontrol edin; eski URL’ler uygulama sürümlerinde kalabilir. Realtime kanalları ve Edge Functions özel sözleşmeler içerir. Yeni API’nin bu SDK çağrılarını drop-in olarak karşılayacağını söylemeyin; her çağrı için hedef akışı yazın.

9. Yedek, pilot ve geri dönüşü bağlayın

Önce ayrı ortamda restore yapın. Pilot kullanıcı grubunda giriş, liste, RLS sınırı, yükleme ve canlı güncelleme deneyin. Kesim anında hangi sistemin yazma otoritesi olduğunu belirleyin. Yeni sistemde oluşan kayıtların eskiye dönme yöntemi yoksa rollback yalnızca uygulamayı eski adrese çevirmek değildir.