PostgreSQL hosting ile MySQL’den geçiş rehberi

PostgreSQL hosting’e geçiş kararı tek bir ayarla verilmez. MySQL’de çalışan bir uygulama, PostgreSQL’de veri tipi, indeksleme, sorgu davranışı ve kilitlenme mantığı nedeniyle aynı performansı veremeyebilir. Bu rehberde MySQL’den PostgreSQL’e geçerken “sürpriz” çıkarmayan teknik kontrol listesini ve hosting tarafında nelere bakmanız gerektiğini adım adım anlatıyorum. Okuduktan sonra hangi noktaları ölçüp düzeltmeniz gerektiği netleşecek.

1) Ön hazırlık: Geçişi hangi ölçümle yöneteceksiniz?

Geçişin başarısı, geçişten önce performans tabanı (baseline) çıkarıp geçiş sonrası aynı metrikleri karşılaştırmaya bağlıdır. Aksi halde hatayı “hosting mi, veritabanı mı?” diye ayırmanız zorlaşır.

Ne ölçün (geçiş öncesi)

Uygulamanızın günlük çalışan sorgu seti: en sık çağrılan 20 sorgu
En yavaş 10 sorgu (p95/p99 gecikme hedefi ile)
Yazma yoğunluğu: saniye başına INSERT/UPDATE/DELETE
Bağlantı sayısı: eş zamanlı bağlantı ve ortalama çalışma süresi
Otomatik yedekleme/restore süresi ihtiyacı: tam (full) + artımlı (incremental) hedef

Geçiş sonrası tekrar ölçün

Aynı sorguların planları (EXPLAIN/EXPLAIN ANALYZE)
Kilit bekleme (lock wait) süreleri
İndeks kullanım oranı
Uygulama hata oranı (özellikle casting ve tarih-saat dönüşümleri)

Net hedef önerisi: En azından p95 gecikme ve lock wait sürelerini kıyaslayın. Hosting seçimini de bu metriklere göre netleştirin.

2) Hosting tarafı: PostgreSQL’de doğru altyapı hangi noktada fark yaratır?

MySQL’den geçiyorsunuz diye yalnızca “veritabanı sürümü”ne bakmak yetmez. PostgreSQL performansı; disk IOPS/latency, bağlantı yönetimi, RAM ve bakım (maintenance) pencereleri ile doğrudan etkilenir.

Sunucu/çözüm türünü seçerken kontrol listesi

Aşağıdaki başlıklarda net kriter belirleyin:

Depolama: NVMe SSD (tercih) + düşük latency (iç ölçüm)
RAM: work_mem/maintenance_work_mem davranışına uygun bellek
CPU: paralel sorgu (parallel query) ve indeks build süreleri için
Bağlantı limitleri: eş zamanlı bağlantı sayısı ve “maksimum bağlantı” ayarı
Yedekleme stratejisi: fiziksel/ mantıksal yedekleme seçenekleri
Log erişimi: yavaş sorgu logu (slow query log) karşılıkları
Sürüm yönetimi: PostgreSQL majör sürüm güncellemeleri planı

Hosting’de özellikle bakmanız gereken PostgreSQL özellikleri

MySQL’de alıştığınız davranışlar PostgreSQL’de farklıdır: - MVCC (multi-version concurrency control) mantığı kilitlenmeyi farklı yönetir. - VACUUM/ANALYZE düzeni performansı korur. Hosting tarafı VACUUM otomasyonunu sağlamalı. - İndeks türleri: btree dışında gin/gist gibi alternatifler sorgu deseninize göre kritik olur.

Aşağıdaki tablo, hosting seçerken “hangisi gerçekten işime yarar?” sorusunu somutlaştırır.

Karşılaştırma başlığı	MySQL’de gördüğünüz alışkanlık	PostgreSQL’de kritik etkisi	Ne yapmalısınız?
İndeksleme	B+tree çoğu iş için yeter	Yanlış indeks türü ciddi fark yaratır	EXPLAIN ile indeks kullanımını doğrulayın
Yazma performansı	Storage daha belirleyici	MVCC + VACUUM ile birlikte belirleyici	Günlük update/insert yoğunluğunu ölçün
Bağlantı yönetimi	max_connections ile yönetilir	Bağlantı havuzu/ek ayar ihtiyacı artabilir	Uygulama bağlantılarını azaltın, gerekiyorsa pooler kullanın
Bakım	bakım planları daha “genel”	VACUUM/ANALYZE planı performansın parçası	Otomatik VACUUM destekleniyor mu kontrol edin
Yedek/restore	mysqldump veya snapshot	pg_dump + point-in-time yaklaşımı	Restore süresini test edin

3) Veri türleri ve şema dönüşümü: Sık yapılan hatalar

MySQL’den PostgreSQL’e geçişte en çok zaman kaybettiren alan şema dönüşümleri olur. Aşağıdaki eşleştirmeler “işe yarar başlangıç”tır; uygulamanızın kullandığı kolonların gerçek kullanımını baz alın.

Yaygın dönüşüm örnekleri

AUTO_INCREMENT (MySQL) → SERIAL veya daha doğru yaklaşım: IDENTITY
DATETIME → timestamp (timezone ihtiyacına göre timestamptz seçin)
TINYINT(1) → PostgreSQL’de boolean (boolean) tercih edin
ENUM → uygulama yaklaşımına göre native enum veya lookup tablo
TEXT / VARCHAR → PostgreSQL’de uzunluk sabiti zorunlu değil; ancak indeksleniyorsa dikkat

Sayı ve para alanlarında net kural

MySQL’de float/double ile “idare edilen” para alanları PostgreSQL’de hataya daha açık hale gelir. - Para/kritik tutar alanları için numeric kullanın. - Tamsayı kimlik/kimlik türevleri için bigint gibi net tip seçin.

Net kural: Uygulama kodunuzda para alanlarını string/decimal’e nasıl çevirdiğinizi bilmeden sadece “en yakın tipi” seçmeyin.

4) Sorgu farkları: Çalışıyor gibi görünen ama yavaşlayan SQL

MySQL’de sorunsuz çalışan bazı sorgular PostgreSQL’de farklı planlar üretebilir. Bu fark çoğu zaman “aynı indeks var ama farklı davranıyor” problemini doğurur.

EXPLAIN ile kök neden bulun

PostgreSQL’de EXPLAIN (ANALYZE, BUFFERS) kullanın.
Özellikle şu sinyallere bakın:
Seq Scan (tam tablo taraması) beklediğiniz indeks yerine geçiyor mu?
“Rows removed by filter” yüksek mi?
Sort/Hash operasyonları bellek sınırına takılıyor mu?

Yaygın MySQL → PostgreSQL sorgu alanları

Günlük tarih filtreleri: where date(col) = ... tarzı kullanımlarda indeks kullanımını kaybedebilirsiniz.
Join koşulları: tip uyumsuzluğu (ör. varchar vs uuid) planı bozabilir.
Grup/aggregate: null davranışları ve cast’ler sonuçları değiştirir.

Uygulama seviyesinde net iyileştirme

Tüm parametreleri doğru tipleyin (ör. tarih filtresi için string yerine tarih parametresi).
Sık kullanılan sorguları tek tek hedefleyin; tüm sorguları “genel” optimize etmeye çalışmayın.

5) Performans için indeks ve maintenance planı (VACUUM)

PostgreSQL’de performansı uzun vadede belirleyen iki kavram vardır: indeks tasarımı ve bakım (maintenance).

Indeks stratejisi: İlk adım net olmalı

Geçişten hemen sonra şu yaklaşımı uygulayın: - En sık sorguların WHERE, JOIN, ORDER BY kısımlarını çıkarın. - Bu alanlarda eksik indeksleri belirleyin. - Metin araması yapıyorsanız GIN/GiST gibi indeks türlerini sorgu deseninize göre değerlendirin.

VACUUM/ANALYZE neden kritik?

MySQL’de görünmez şekilde işleyen temizlik işleri PostgreSQL’de VACUUM ile daha doğrudan hissedilir. - Yoğun update yapan tablolar hız kaybedebilir. - ANALYZE, istatistikleri güncel tutarak doğru plan seçimini destekler.

Hosting sağlayıcınızdan şu soruların yanıtını alın: - VACUUM otomatik mi yönetiliyor? - Yavaş sorgu logları erişilebilir mi? - Restore sonrası istatistikler nasıl ele alınıyor?

6) Yedekleme ve restore: Geçişin sigortası

MySQL’den PostgreSQL’e geçtiğinizde yedekleme yönteminizin restore süresi ve noktası kritikleşir. Çünkü uygulama kesintisi kabul edilebilir bir aralıkta kalmalı.

Hedef: “RTO/RPO”nuzu net tanımlayın

RPO (Recovery Point Objective): Ne kadar veri kaybına tolerans var?
RTO (Recovery Time Objective): Sistem kaç dakikada/saate geri dönmeli?

Test zorunludur

Şu testi yapın: - Aynı veri setiyle yedekten restore edin. - Uygulamanın migration adımlarını da (şema + seed) dahil edin. - Restore sonrası en kritik 10 sorguyu çalıştırıp plan değişimini kontrol edin.

Aşağıdaki liste, restore testinde “unutulan ama pahalı” noktaları yakalar: - Bağlantı kullanıcıları/roller (role) restore ediliyor mu? - Extensions (örn. postgis) restore ediliyor mu? - Zaman dilimi ayarları (timezone) uyuşuyor mu? - Uygulama migration’ları aynı sırayla çalışıyor mu?

7) Bağlantı sayısı ve connection pool: Sık rastlanan performans ucu

MySQL’de sorun çıkarmayan bağlantı modeli PostgreSQL’de daha görünür hale gelebilir. Çünkü bağlantı başına maliyet ve kaynak kullanımı daha belirgin hissedilebilir.

Net yaklaşım

Uygulama tarafında gereksiz bağlantı açıp kapatmayı azaltın.
Eş zamanlı bağlantı sayısını gerçek trafikten çıkarın.
Hosting’de bağlantı limitleri ve kaynak izolasyonu (CPU/RAM) nasıl yönetiliyor kontrol edin.

Eğer uygulama yüksek bağlantı açıyorsa şu yöntemi değerlendirin: - Connection pooler (örn. pgbouncer) kullanmak - Uygulama timeout ve retry davranışını PostgreSQL hatalarına göre ayarlamak

8) Geçiş süreci için pratik yol haritası

MySQL’den PostgreSQL’e geçişi tek hamlede yapmayın. Aşağıdaki sıralama, riski düzenler.

1. Sürüm ve uyumluluk kontrolü

PostgreSQL sürümünüzü belirleyin.
Uygulama sürücüsünün (driver) doğru sürümde olduğundan emin olun.

2. Şema dönüşümünü güvenli test ortamında yapın

Aynı veri setini test ortamına alın.
Tip dönüşümlerini birebir doğrulayın (boolean, tarih-saat, para/numeric).

3. Sorgu performansını plan bazlı doğrulayın

EXPLAIN (ANALYZE, BUFFERS) ile en yavaş sorguları hedefleyin.
İndeks eksiklerini düzeltin.

4. Yedek/restore testini geçişten önce tamamlayın

Kısmi veya tam restore senaryolarını deneyin.
Uygulama erişimini sağlayın ve kritik sorguları tekrar ölçün.

5. Kademeli geçiş (cutover)

Önce okuma yüklerini alın (varsa read-replica benzeri senaryolar).
Ardından yazma trafiğini kontrollü devredin.

Sonuç: Aksiyon planı

MySQL’den PostgreSQL’e geçişte başarı, “veritabanını değiştir” kadar “hosting ve operasyonu ölçerek değiştir” yaklaşımıyla gelir. İlk adım olarak en kritik 20 sorguyu baseline ile çıkarın; sonra PostgreSQL hosting’de NVMe depolama, VACUUM/maintenance yönetimi, restore test kabiliyeti ve log/plan erişimi kriterlerini netleştirin. Bu kontrolleri tamamladıktan sonra şema dönüşümü ve indeksleme optimizasyonuna geçin. En hızlı sonuç, sorgu planlarını (EXPLAIN ANALYZE) ve restore test sürelerini ölçerek verdiğiniz kararlardan gelir.