PostgreSQL mi MySQL mi? Sentetik hız farkı tek başına karar değildir

PostgreSQL, yayımlanan sentetik karşılaştırmada çoğu senaryoda öne çıktı; yine de yeni bir proje için MySQL’i yalnızca bu sonuca bakarak elemek doğru olmaz. Performans seçimi, uygulamanızın okuma, yazma ve JOIN sorgularının beklenen eşzamanlı yük altında ne kadar hızlı ve öngörülebilir çalıştığına bağlıdır.

PostgreSQL 18.1 ile MySQL 9.5’in yayımlanan yerel karşılaştırmasında yazar, 17 senaryonun 14’ünü PostgreSQL lehine, birini beraberlik ve iki JOIN sorgusunu MySQL lehine sınıflandırdı. Aynı makinede Docker içinde çalışan veritabanlarına eşit işlemci ve bellek sınırları verildi; bağlantı havuzu büyüklükleri ve motora özgü bellek ayarları ise farklıydı. Bu sonuçları başlangıç verisi olarak kullanıp kararı kendi sorgularınızın gecikmesi, kilit beklemesi ve bakım maliyetiyle vermek gerekir.

Sentetik testte hangi sorgu öne çıktı?

Karşılaştırmanın değeri, tek bir kazanan ilan etmesinden çok sorgu türlerini ayırmasında. Tekil kayıt okuma, ekleme, güncelleme, silme ve karma okuma-yazma yüklerinde PostgreSQL güçlüydü. MySQL’in daha yüksek QPS elde ettiği JOIN örnekleri ise siparişleri kullanıcılarla veya ürünlerle ilişkilendiriyordu. Bu, JOIN kullanan her uygulamada MySQL’in üstün geleceği anlamına gelmez; sorgunun bağladığı tablolar, indeksler ve veri dağılımı sonucu değiştirebilir.

Testin beraberlik saydığı toplu ekleme örneği de ölçütün önemini gösteriyor: MySQL daha fazla sorgu tamamladı, PostgreSQL’in sorgu gecikmesi daha düşüktü. QPS, belirli koşullarda tamamlanan iş miktarıdır; kullanıcıların en yavaş isteklerde ne kadar beklediğini tek başına anlatmaz. Özellikle bir işlemin birkaç sorgudan oluştuğu uygulamada, sorgu başına hız ile tamamlanan işlem sayısı da ayrı değerlendirilmelidir.

Aynı donanım sınırı karşılaştırma için yararlıdır, fakat eşit ayarların aynı etkiyi yarattığı anlamına gelmez. Bağlantı havuzu, önbellek, sorgu planı ve istenen sorgu hızı sonuca dahildir. Testteki üstünlüğün kendi uygulamanıza taşınıp taşınmadığını görmek için benzer veri modeli kadar benzer istek karışımı da gerekir.

Eşzamanlı okumada MVCC nasıl davranır?

PostgreSQL’in MVCC belgeleri, her SQL ifadesinin verinin tutarlı bir anlık görünümünü gördüğünü ve olağan MVCC okumalarının yazmaları bloke etmediğini açıklar. Okuma ile yazmanın aynı tablolarda buluştuğu bir uygulamada bu davranış önemlidir. Ancak aynı satırı değiştirmeye çalışan işlemler çatışabilir; açıkça kilit isteyen sorguların davranışı da sıradan okumadan farklıdır.

MySQL’in InnoDB motoru da çok sürümlü eşzamanlılık denetimi kullanır. Bu nedenle seçimi, motorlardan yalnızca birinin MVCC sunduğu varsayımına dayandırmak yanıltıcı olur. Asıl soru, uygulamanın işlem yalıtımı altında hangi görünümü beklediği ve yoğun eşzamanlı güncellemelerde bekleme ya da yeniden denemenin ne sıklıkla ortaya çıktığıdır.

Örneğin uzun süre açık tutulan bir okuma işlemiyle kısa işlemlerden oluşan bir web isteği aynı yük değildir. İlki eski bir veri görünümüne ihtiyaç duymayı sürdürebilir; ikincisinde görünüm daha çabuk serbest kalır. Denemede toplam başarılı sorgu sayısının yanında işlem süresini, kilit beklemelerini ve uygulamanın yeniden denediği işlemleri izlemek bu farkı görünür kılar.

Eski satır sürümlerinin bakım bedeli

MySQL 8.4 InnoDB belgelerine göre motor, eski satır sürümlerini yeniden oluşturmak için undo kayıtlarını kullanır; ilgili anlık görünüme ihtiyaç duyabilecek bir işlem açıkken bazı kayıtlar temizlenemez. Uzun süren işlemler, yalnızca okuma yapsalar bile, temizliği geciktirerek undo alanının büyümesine yol açabilir. Bu yüzden kısa ve temiz bir veri kümesiyle yapılan hız ölçümü, sürekli güncellenen üretim verisinin depolama davranışını göstermez.

PostgreSQL’de de güncellenen veya silinen satırların eski sürümleri hemen kaldırılmaz. PostgreSQL’in VACUUM kılavuzu, kullanılmayan alanın yeniden değerlendirilmesi, planlayıcı istatistikleri ve görünürlük haritası için düzenli bakımın rolünü açıklar. Standart VACUUM bakım sırasında disk giriş çıkışı üretir; yoğun güncelleme alan tablolarda bunun sorgu gecikmesine etkisi ölçülmelidir.

Bakım yükü iki motorda aynı sayaçla izlenmez. InnoDB tarafında undo geçmişinin birikmesi ve temizliğin yetişip yetişmediği, PostgreSQL tarafında eski satırların birikmesi ve autovacuum etkinliği anlamlı işaretlerdir. Deneme, arka plan temizliği devreye girmeden biterse uzun ömürlü kurulumun maliyeti görünmeyebilir.

Ayar eşitliği neden aynı sayıları girmek değildir?

İşlem yalıtımı önce uygulamanın ihtiyaç duyduğu tutarlılığa göre seçilmelidir. MySQL 8.4 işlem yalıtımı belgelerinde InnoDB’nin varsayılan düzeyi REPEATABLE READ olarak belirtilir; READ COMMITTED altında ise her tutarlı okuma yeni bir anlık görünüm kullanır. Yalıtım düzeyini değiştirmek yalnızca hız ayarı değildir: işlemin görebileceği veri ve bazı kilit davranışları da değişir.

Bellek ayarları için de eşit rakamlar eşit koşullar yaratmayabilir. InnoDB buffer pool ile PostgreSQL shared buffers aynı şekilde kullanılmaz; PostgreSQL işletim sisteminin sayfa önbelleğinden de yararlanır. Karşılaştırmada toplam donanım sınırını eşitlemek, ardından her motorun bellek ayarını ve gerekçesini kaydetmek daha anlamlıdır.

Sürücü, bağlantı havuzu, indeksler ve sorgu parametreleme biçimi de ölçülen gecikmeye dahildir. Bir motorun daha kalabalık bağlantı havuzuyla çalıştırılması otomatik olarak haksızlık sayılmaz; önemli olan seçilen düzenin belgelenmesi ve üretimde kullanılabilecek bir ayar olmasıdır. Yüksek QPS uğruna uygulamanın gerektirdiği yalıtım veya dayanıklılık koşullarını değiştirmek ise farklı bir sistemi ölçmek demektir.

Kendi verinizle kısa karar denemesi

Yeni proje için en yararlı deneme, beklenen tablo büyüklüğünü, ilişkileri, indeksleri ve kayıt değerlerinin dağılımını temsil eder. Sadece eşit sıklıkla seçilen rastgele kayıtlar kullanılırsa yoğun erişilen satırlardaki çatışma gizlenebilir. Kimlik üzerinden okuma, sıralama ve sayfalama, ekleme, güncelleme, karma yük ve JOIN sorgularını ayrı ölçmek, bir sorgu türünün toplam ortalamayı maskelemesini önler.

1. Her iki motorda aynı veri kümesini ve karşılaştırılabilir indeks amacını kurun; donanım sınırını, işlem yalıtımını ve bağlantı havuzunu kaydedin.
2. Kritik sorguları önce tek başına, sonra uygulamada beklenen okuma-yazma karışımı içinde çalıştırın.
3. İstek hızını kademeli artırırken tamamlanan iş miktarıyla birlikte p95 ve p99 gecikmesini izleyin. Aynı yük düzeyindeki sonuçları karşılaştırın.
4. Uzun süren işlem ve eşzamanlı güncelleme ekleyin; kilit beklemesini, işlem hatalarını ve yeniden denemeleri kaydedin.
5. Ölçümü bakım süreçlerini gözleyecek kadar sürdürün; tablo veya undo alanı büyümesini ve disk yükünü izleyin.

Karar, kritik sorguların kabul edilebilir gecikmeyle tamamlanmasına dayanmalı. Uygulamanız JOIN ağırlıklıysa o sorguların sonucu, çoğunlukla tekil okuma ve yazma yapıyorsa karma yükteki davranış daha belirleyici olabilir. Benzer sonuçlar elde edildiğinde ekibin yedekleme, izleme, bakım ve arıza giderme deneyimi de gerçek bir seçim ölçütüdür.

Ayrıca okuyun:

• Caterpillar fiziksel AI’ı sahaya taşıyor; karar yükü işçiyle makine arasında
• Beeline MCP açıldı: taşeron iş gücü verisine tek denetimli kapı
• Claude testleri durduruldu: Tek savunma katmanı yetersiz kaldı