Göreve başladığım ilk haftalardan birinde, ekipten bir arkadaş toplantıda gündemi açtı: "MySQL'den PostgreSQL'e geçelim." Nedenini sordum. Cevap, kelimesi kelimesine: "Postgres daha modern, herkes ona geçiyor." Servise birlikte baktık — klasik bir sipariş yönetimi uygulaması, ağırlıklı okuma yükü, üç kişilik bir ekip bakıyor, hepsi yıllardır MySQL kullanıyor. Geçişin maliyetini hesapladık: dört ay efor, sıfır ölçülebilir kazanç. Geçmedik; servis bugün hâlâ mutlu mesut MySQL'de dönüyor.
İki veritabanıyla da yüzlerce proje yaşamış biri olarak baştan söyleyeyim: 2026'da ikisi de mükemmel durumda. "Yanlış seçim" diye bir şey neredeyse yok; ama "yanlış gerekçe" diye bir şey var ve çok yaygın. "Duyduk ki daha havalı" bir gerekçe değildir. Bu yazıda kendi karar çerçevemizi, iki tarafın gerçekten parladığı yerleri anlatarak paylaşacağım.
PostgreSQL'i seçtiren senaryolar
Bizim için en net ayrım noktası coğrafi veri. Yıllarca araç takip sistemleri geliştirdim; PostGIS o dönemin ekmek teknesiydi, bugün de kurye operasyonumuzda aynı işi görüyor: yüz binlerce konum noktası üzerinde "bu kurye şu bölgeye girdi mi", "siparişe en yakın kurye hangisi" gibi sorguları veritabanı seviyesinde, indeksli ve hızlı çalıştırabilmek, uygulama katmanında koordinat hesaplamaya çalışmakla kıyaslanmayacak bir konfor. Projede ciddi coğrafi veri varsa bizde tartışma açılmaz, PostgreSQL yazılır.
İkinci senaryo, rapor ağırlıklı sistemler. PostgreSQL'in sorgu planlayıcısı karmaşık sorgularda gerçekten parlıyor: window fonksiyonları, CTE'ler, paralel sorgu yürütme... Yönetim panelinde "son 12 ayın kohort analizi" tarzı sorgular dönen bir projede bu fark hissediliyor. Basit CRUD'da iki motor arasında kullanıcının fark edeceği bir şey yok; analitik yük bindikçe makas Postgres lehine açılıyor.
Üçüncüsü JSONB. Şemalı bir tablonun içinde birinci sınıf, indekslenebilir JSON tutabilmek, "ilişkisel disiplin + esnek belge" karışımı isteyen projelerde ciddi rahatlık. Somut örnek: bizim platformda ürün özellikleri kategoriden kategoriye değişiyor — ayakkabıda numara, telefonda hafıza. Klasik çözümler (EAV tabloları, ucu açık kolonlar) hep sancılıdır; JSONB kolonu + GIN indeksi ile hem esnekliği hem sorgu performansını aynı anda aldık.
Bir de karakter meselesi var, bu daha az konuşulur: PostgreSQL varsayılanlarıyla daha kuralcıdır. Tipi uymayan veriyi sessizce kırpıp kabul etmez, hata verir. İlk bakışta huysuzluk gibi görünen bu tavır, beş yıl sonra verinize baktığınızda teşekkür ettiğiniz şeydir. Sessizce bozulan veri, gürültüyle patlayan hatadan çok daha pahalıdır.
MySQL'i seçtiren senaryolar
Şimdi madalyonun öbür yüzü — çünkü MySQL'i "eski teknoloji" diye küçümseyen furyaya katılmıyoruz. Klasik web CRUD'unda, yani okuma ağırlıklı, sorguları görece basit yüklerde MySQL son derece hızlı, öngörülebilir ve az bakım isteyen bir işçidir. On altı yıldır MySQL üzerinde koşan, on yılda belki iki kez veritabanı kaynaklı sorun çıkarmış projeler gördüm. Bu sicil, hiçbir konferans sunumunun sağlayamayacağı bir güven verir.
Ekosistem ve barınma tarafı da hâlâ MySQL lehine: paylaşımlı hosting'den yönetilen bulut hizmetlerine kadar her yerde birinci sınıf destek bulursunuz, PHP dünyasıyla tarihsel uyumu tamdır ve MySQL bilen geliştirici/DBA bulmak her şehirde kolaydır. Replikasyon pratiği de öyle — basit master-replica kurulumları onlarca yıldır sahada pişmiş; okuma yükünü replikaya devretmek gibi standart ihtiyaçlarda deneme yanılmaya gerek kalmaz, reçete hazırdır.
Bir örnek vereyim: ajans yıllarımda uzun süre baktığım bir bayi yönetim sistemi vardı — binlerce günlük kullanıcı, on milyonlarca satırlık sipariş tablosu, MySQL üzerinde. Yıllar içinde iki kez "Postgres'e geçsek mi" sorusu masaya geldi; iki kez de dürüst cevap aynıydı: geçişin çözeceği tek bir mevcut problem yok. Sistem ben ayrılırken de sorunsuzdu; sorunsuz sistemi motor merakıyla ameliyat etmemek de bir mühendislik kararıdır.
Mevcut ekip MySQL biliyorsa ve projenin Postgres'e özgü bir ihtiyacı yoksa, "modernlik" adına ekibi konfor alanından çıkarmanın faturasını da hesaba katmak gerekir. Yeni motor öğrenmek güzel bir hedeftir ama teslim tarihi olan bir projenin sırtında öğrenilmez.
Geçiş kararının görünmeyen faturası
Girişteki "dört ay efor" hesabını biraz açayım, çünkü motor değiştirmenin maliyeti hep küçümseniyor. Şema taşımak işin en kolay kısmı; araçlar bunu büyük oranda hallediyor. Asıl efor üç yerde birikiyor. Birincisi, SQL lehçe farkları: yıllar içinde yazılmış raporlama sorguları, tarih fonksiyonları, group by davranışları — hepsi tek tek elden geçer. İkincisi, ORM'in iki motorda farklı davrandığı köşeler; testi olmayan projede bunlar üretimde bulunur. Üçüncüsü ve en pahalısı, ekibin operasyonel bilgisi: yedekleme rutini, replikasyon kurulumu, performans sorunlarında nereye bakılacağı gibi yıllarda biriken refleksler sıfırlanır. Bunların hepsi aşılır elbette — ama "daha modern" hissiyatı için değil, ölçülebilir bir kazanç için aşılmalı.
Bir ara not: iki motoru aynı anda kullanmak da meşru bir seçenek. Ana uygulaması MySQL'de koşarken, coğrafi analiz modülü için yanına PostGIS'li bir PostgreSQL koyduğumuz projeler oldu. "Tek doğru veritabanı" diye bir kural yok; doğru iş için doğru araç var.
Bizim karar tablomuz ve asıl mesele
Çerçevemiz kabaca şöyle işliyor: coğrafi veri, ağır raporlama, JSONB ihtiyacı ya da karmaşık iş kuralları varsa PostgreSQL. Standart bir web uygulamasıysa, ekip MySQL'e hâkimse, hosting kısıtı varsa MySQL — ve mutluluk. İki liste de kısa, çünkü vakaların çoğunda dürüst cevap "ikisi de olur"dur. O noktada seçimi ekip bilgisi ve operasyonel alışkanlıklar yapmalı, moda değil. Yönetilen bulut hizmetlerinin yaygınlaşması da bu dengeyi etkiledi bu arada: yedekleme, yama ve replikasyon derdini sağlayıcı üstlenince, iki motorun operasyonel yükü birbirine epey yaklaştı — seçim artık her zamankinden fazla, iş yükünün karakteriyle ilgili.
Ve asıl söylemek istediğim şey şu — bunu her veritabanı tartışmasında tekrarlıyorum: performans farkını yaratan motor seçimi değil, şema tasarımı, indeksleme ve sorgu disiplinidir. Kötü şemalı, indekssiz, N+1 sorgularla dövülen bir PostgreSQL, iyi tasarlanmış bir MySQL'e her gün kaybeder. Tersi de aynen doğru. Motor tartışmasına harcanan enerjinin yarısı şema gözden geçirmesine harcansa, sektördeki performans şikâyetlerinin çoğu ortadan kalkardı. (İddialı cümle, arkasındayım — çünkü yıllar içinde performans için çağrıldığım projelerde motoru değiştirerek çözdüğümüz vaka sayısı bir elin parmağını geçmezken, indeks ve şema düzeltmesiyle çözdüklerimiz yüzleri buluyor.)
Yeni bir projeye başlıyorsanız bu karar toplantısını atlamayın — çoğu zaman bir saat sürüyor ve dört aylık gereksiz göçlerden çok daha ucuza geliyor. Gerekçesi sağlam olan seçim, iki motorda da iyi yaşlanır. Veritabanı muhabbetini her zaman severim; iletişim sayfası açık.