Uzun zamandır kafamda olan bir testti bu. “Hangi veritabanı daha hızlı?” sorusunun cevabı forumlarda hep aynı üç cümleyle geçiştiriliyor: “PostgreSQL daha güçlü”, “MySQL daha yaygın”, “MariaDB zaten MySQL”. Ben de sonunda oturup üçünü aynı makinede, aynı kaynak sınırlarıyla, aynı veri ve aynı sorgularla karşılaştırdım.
Sonuç beklediğimden ilginç çıktı. Çünkü aradaki fark bazı yerlerde yüzde 5, bazı yerlerde 6 kat. Ve o 6 katlık farkın sebebi “motor yavaş” değil — tamamen başka bir şey. Ona da geleceğiz.
Bu veritabanı benchmark çalışmasının sonunda “ben hangi dille çalışıyorum, planıma hangisini almalıyım” sorusuna doğrudan cevap veren bir bölüm var. Acelesi olan oraya atlayabilir.
Daha önce sunucu tarafında benzer bir karşılaştırma yapmıştım: Apache vs Nginx benchmark testi. Bu yazı onun veritabanı katmanındaki devamı sayılır.
Veritabanı benchmark test ortamı
Test düzeneğini olabildiğince adil kurmaya çalıştım:
- Apple Silicon, 10 çekirdek, 16 GB RAM
- Docker Desktop (Linux ARM64)
- Her veritabanı container’ı 4 CPU + 4 GB RAM ile sınırlandı
- PostgreSQL 18.6 · MySQL 26.7.0 · MariaDB 12.2.2 (resmî ARM64 image’ları, digest ile sabitlendi)
- Hiçbir motora özel tuning yapılmadı, hepsi kutudan çıktığı ayarlarla çalıştı
- Motorlar asla aynı anda çalışmadı
- İstemci tarafı: Node.js,
pgvemysql2sürücüleri
Sürümler konusunda bir noktanın altını baştan çizeyim: test ettiğim MySQL 26.7.0 bir early access sürümü, yani henüz genel kullanıma sunulmuş kararlı bir yayın değil. Bunu bilerek seçtim, çünkü PostgreSQL ve MariaDB tarafında da o an mevcut olan en güncel sürümleri kullandım. Ama bu, aşağıdaki MySQL rakamlarını okurken aklınızda tutmanız gereken bir şey: early access sürümlerde varsayılan ayarlar ve performans profili GA sürümüne kadar değişebilir. Yazı boyunca MySQL sonuçlarını buna göre yorumluyorum.
Sıcaklık faktörünü de boşlamadım. Uzun benchmark’larda ilk test serin makinede, son test kızmış makinede koşarsa yazılım yerine sıcaklık ölçmeye başlarsınız. O yüzden her motor geçişinde üç container’ı da durdurdum, 60 saniye soğuma bekledim, sadece hedef motoru açtım, 10 saniye daha bekledim, şemayı sıfırdan kurdum ve ölçüme öyle başladım. Test sırasını da her turda döndürdüm.
Veri seti: 100 bin kullanıcı, 50 bin ürün, 250 bin sipariş, 1 milyon sipariş kalemi. Her tur aynı veriyle başladı.
Bir veritabanı benchmark’ının en zayıf noktası genellikle tek koşuya bakmaktır. O yüzden aşağıdaki bütün rakamlar 5 turun medyanı. Turlar arası sapma hücrelerin çoğunda %2’nin altında kaldı, en kötü hücrede %5. Yani bunlar tek atışlık, şansa bağlı sayılar değil.
Okuma testleri: fark küçük
Önce günlük hayatta en çok yaptığımız işe bakalım — okuma. 10 eşzamanlı bağlantı, saniyedeki sorgu:
| Senaryo | PostgreSQL | MySQL | MariaDB |
|---|---|---|---|
| Primary key ile kayıt getir | 22.977 | 20.299 | 20.531 |
| İndeksli kategori filtresi | 16.931 | 14.985 | 15.829 |
| Join + aggregate | 18.239 | 18.278 | 18.134 |
Bu veritabanı benchmark’ının en sakin kısmı burası; ortada bir dram yok. PostgreSQL primary key erişiminde %12 kadar önde, join testinde ise üçü istatistiksel olarak ayırt edilemez — turların değer aralıkları birbirinin içine giriyor.
Buradan çıkan ilk pratik sonuç şu: okuma ağırlıklı normal bir siteyi hangi motora kurarsanız kurun, veritabanı sizin darboğazınız olmayacak. Saniyede 15-20 bin sorgu, sıradan bir WordPress veya haber sitesinin göreceği yükün çok ötesinde. O sitelerde kazancı motor değişikliğinde değil, cache ve indekste ararsınız.
Asıl fark yazma tarafında başlıyor.
Yazma testleri: işte burada iş değişiyor
Aynı koşullar, aynı 10 bağlantı:
| Senaryo | PostgreSQL | MySQL | MariaDB |
|---|---|---|---|
| Tekil insert | 14.884 | 6.739 | 14.301 |
| İndeksli update | 14.563 | 4.105 | 14.184 |
| Sipariş transaction | 4.880 | 2.294 | 5.123 |
| Karma OLTP (%60 okuma, %20 update, %20 transaction) | 11.854 | 5.883 | 11.601 |
MySQL, indeksli update’te PostgreSQL’in 3,5 katı yavaş. Transaction’da yarısı kadar. Karma yükte yine yarısı.
PostgreSQL ve MariaDB ise burada neredeyse omuz omuza. Insert ve update’te PostgreSQL bir tık önde, transaction’da MariaDB önde.
İlk gördüğümde “bir şeyi yanlış kurdum” dedim ve testi baştan koşturdum. Aynı sonuç. Sonra telemetriye baktım ve olayın ne olduğunu anladım.
MySQL neden geride kaldı? (Cevap “yavaş olduğu” değil)
Ölçüm sırasında container’ların disk yazma sayaçlarını da kaydediyordum. Sipariş transaction testinde işlem başına diske yazılan veri şöyleydi:
| İşlem başına yazılan | |
|---|---|
| PostgreSQL | ~0,5 KB |
| MariaDB | ~1 KB |
| MySQL | ~15 KB |
MySQL, aynı işi yapmak için MariaDB’nin yaklaşık 14 katı, PostgreSQL’in 30 katı veri yazıyor. (Docker’ın sayacı kaba ölçüyor, bu rakamları büyüklük mertebesi olarak okuyun — ama fark mertebe düzeyinde zaten.)
Bu, işin özünü tek başına anlatan rakam. Çünkü saniyede kaç işlem yapabildiğiniz, o işlem başına diske ne kadar yazdığınızın doğrudan sonucu. MySQL yavaş çalışan bir motor değil; her commit’te belirgin biçimde daha fazla iş yapan bir motor.
Peki neden? En güçlü aday, MySQL’in commit yolundaki dayanıklılık ayarları. MySQL uzun süredir binary log’u varsayılan olarak açık getiriyor, MariaDB ise kapalı. Binlog açıkken motor her commit’te hem redo log’a hem binlog’a yazmak ve ikisi arasında iki fazlı commit yapmak zorunda — yani commit başına iki fsync. Binlog kapalıyken tek fsync yetiyor. innodb_doublewrite ve sync_binlog gibi ayarlar da aynı yola ekleniyor.
Dürüst olayım: bu açıklamayı ölçtüğüm veriden ve motorların bilinen davranışından çıkarıyorum, test container’larında SHOW VARIABLES çıktısını ayrıca kaydetmedim. Yani ölçüm kesin, açıklama en güçlü aday. Kendi sunucunuzda bir dakikada doğrulayabilirsiniz:
SHOW VARIABLES WHERE Variable_name IN
('log_bin','sync_binlog','innodb_flush_log_at_trx_commit','innodb_doublewrite');Bir de şunu eklemek gerek: test ettiğim sürüm early access. Bu tür sürümlerde hata ayıklama/telemetri kodu açık kalabiliyor ve varsayılanlar GA’ya kadar oturmamış olabiliyor. Yani buradaki yazma farkının bir kısmı sürümün olgunlaşmasıyla kapanabilir. Kararınızı bu rakama değil, kendi sürümünüzde kendi ölçtüğünüz rakama dayandırın.
Bunun anlamı önemli: MySQL bu testte daha yavaş değil, daha dayanıklı ayarlarla çalışıyor. Binlog sizin replikasyonunuz ve point-in-time recovery’niz. Kapatırsanız hız gelir, ama yedekleme stratejinizin bir ayağını kaybedersiniz.
Yani doğru cümle “MySQL yavaştır” değil, şu: MySQL kutudan çıktığı haliyle daha güvenli, MariaDB kutudan çıktığı haliyle daha hızlı bir varsayılan seçmiş. İkisini eşitlemek istiyorsanız ayarlara girmeniz gerekir — ve bu, bu yazının değil ayrı bir tuning yazısının konusu.
Yük artınca ne oluyor?
Bağlantı sayısını 10’dan 50’ye çıkardım. Sonuçlar:
| Senaryo | PostgreSQL | MySQL | MariaDB |
|---|---|---|---|
| Primary key | 45.979 | 28.816 | 29.320 |
| İndeksli filtre | 21.203 | 19.683 | 20.533 |
| Join + aggregate | 18.114 | 27.606 | 28.450 |
| Tekil insert | 32.319 | 13.133 | 28.621 |
| İndeksli update | 30.904 | 4.916 | 28.208 |
| Sipariş transaction | 9.569 | 3.668 | 10.631 |
| Karma OLTP | 22.734 | 9.108 | 23.335 |
Üç şey dikkat çekiyor:
PostgreSQL primary key okumada uçtu. 23 binden 46 bine, tam iki kat. Bağlantı sayısı arttıkça verim kaybetmemiş.
MySQL’in update’i hiç açılmadı. 4.105’ten 4.916’ya. Yani beş kat bağlantı, %20 kazanç. Aynı hücrede PostgreSQL 30.904’e çıktı — girişte bahsettiğim 6 katlık fark tam olarak burası. Burada CPU’ya da baktım: MySQL sadece %140 CPU kullanıyordu, oysa 400’e kadar hakkı vardı. Demek ki CPU’da değil, commit/disk tarafında tıkanmış. Yukarıdaki binlog hikâyesiyle birebir örtüşüyor.
PostgreSQL join’de hiç ölçeklenmedi (18.239 → 18.114). Buna da CPU’dan baktım: PostgreSQL bu hücrede %394 CPU kullanıyordu — yani container’a verdiğim 4 çekirdeğin (%400) tam tavanına vurmuş. Ölçeklenememesinin sebebi motor değil, kutunun duvarı. Dürüst olmak gerekirse burada test istemcimin de payı olabilir: PostgreSQL sürücüsü sorguları her seferinde yeniden planlatırken MySQL/MariaDB tarafı hazır sorgu (prepared statement) kullanıyordu. Bu hücreyi “PostgreSQL join’de kötüdür” diye okumayın, “bu kurulumda CPU tavanına çarptı” diye okuyun.
Gecikme: throughput’un anlatmadığı kısım
Saniyede kaç sorgu değil, kullanıcının beklediği süre. 50 bağlantıda p95 gecikme (yani isteklerin %95’i bu sürenin altında):
| Senaryo | PostgreSQL | MySQL | MariaDB |
|---|---|---|---|
| Tekil insert | 2,34 ms | 4,39 ms | 2,62 ms |
| İndeksli update | 2,48 ms | 13,00 ms | 2,66 ms |
| Sipariş transaction | 7,96 ms | 19,09 ms | 6,65 ms |
| Karma OLTP | 6,05 ms | 15,31 ms | 5,83 ms |
MySQL’in yazma kuyruğu hem throughput’ta hem yanıt süresinde kendini gösteriyor. Sepete ekleme, stok düşme, sipariş oluşturma gibi işlemlerin yoğun olduğu bir e-ticarette bu fark kullanıcıya hissettirir.
RAM ve CPU: küçük VPS’te önemli
10 bağlantılık seride ölçtüğüm tepe bellek kullanımı:
- PostgreSQL: 186 MB
- MariaDB: 252 MB
- MySQL: 663 MB
MySQL, PostgreSQL’in yaklaşık 3,6 katı bellek kullandı. Bunu tek başına kötü bir şey gibi okumayın — veritabanları belleği cache için kullanır, çok bellek kullanmak çoğu zaman iyidir. Ama bu testte o fazladan bellek daha yüksek yazma performansına dönüşmedi, ki asıl mesele bu.
(Küçük bir uyarı: PostgreSQL işletim sisteminin dosya cache’ine yaslanır, InnoDB kendi havuzunu tutar. Bu yüzden container’dan okunan rakamlar tam elma-elma değil. Ama 186’ya karşı 663 farkı, ölçüm belirsizliğiyle açıklanamayacak kadar büyük.)
CPU tarafında ilginç bir detay: join testinde MariaDB, PostgreSQL ile aynı throughput’u %116 CPU ile üretirken PostgreSQL %305 harcadı. MariaDB bu testin en verimli motoru oldu.
Pratik sonuç: Bu veritabanı benchmark’ının en doğrudan uygulanabilir çıktısı burada — 1-2 GB RAM’lik bir VPS’iniz varsa MySQL’i varsayılan ayarlarla kurmak, bütçenizin ciddi bir kısmını tek başına yer.
Peki hangisini planıma almalıyım?
İşte asıl kısım. Bir veritabanı benchmark’ının rakamları güzeldir ama karar verirken tek başına yeterli değildir — dilinizin ekosistemi çoğu zaman daha belirleyici olur.
Kullandığınız dile / framework’e göre
| Çalıştığınız yer | Önerim | Neden |
|---|---|---|
| WordPress, Joomla, Drupal, OpenCart, PrestaShop | MariaDB | Zaten seçeneğiniz yok, bu CMS’ler PostgreSQL ile çalışmaz. MySQL yerine MariaDB’yi seçin: bu testte her yazma senaryosunda önde, RAM’i yarısından az, geçiş drop-in. |
| Laravel / Symfony (modern PHP) | PostgreSQL (paylaşımlı hostingde kalacaksanız MariaDB) | Laravel ikisini de birinci sınıf destekler. Yeni projede PostgreSQL’in JSONB, CTE ve window fonksiyonlarını kullanırsınız. Ama hosting’iniz paylaşımlıysa PostgreSQL çoğu zaman yok. |
| Django / Python | PostgreSQL | Tartışmasız. Django ORM’i PostgreSQL’e özel alanlar sunuyor (ArrayField, JSONField, tam metin arama). Topluluk desteğinin ezici çoğunluğu orada. |
| Ruby on Rails | PostgreSQL | Ekosistemin fiili varsayılanı. Deploy edeceğiniz her platform PostgreSQL’i hazır sunuyor. |
| Node.js (Prisma, Drizzle, TypeORM) | PostgreSQL | Modern Node ORM’lerinin en olgun ve en iyi belgelenmiş yolu. |
| .NET | PostgreSQL | Npgsql çok olgun bir sürücü. SQL Server lisansından kaçıyorsanız doğal geçiş. |
| Go | PostgreSQL | pgx sürücüsü ekosistemin en iyi parçalarından biri. |
| Elle yazılmış eski PHP (mysqli / PDO) | MariaDB | Kod değişikliği gerektirmez, MySQL’in yerine doğrudan geçer, bu testte daha hızlı ve daha hafif. |
İş yükünüzün karakterine göre
- Okuma ağırlıklı blog, haber, kurumsal site: Üçü de fazlasıyla yeter. Enerjinizi motor seçmeye değil cache’e ve indekslere harcayın.
- Yazma ağırlıklı iş (e-ticaret sipariş akışı, log toplama, IoT, form/analitik kaydı): PostgreSQL veya MariaDB. MySQL’i varsayılan ayarlarla bu işe koymayın; koyacaksanız önce durability ayarlarını bilinçli olarak gözden geçirin.
- Dar VPS (1-2 GB RAM): MariaDB veya PostgreSQL. MySQL bu bütçede tek başına 650 MB ister.
- Yüksek eşzamanlılık + basit anahtar okumaları: PostgreSQL. 50 bağlantıda primary key okumada rakipsizdi.
- Transaction yoğun karma yük: MariaDB. Hem en yüksek throughput’u verdi hem en düşük p95’i, hem de en az CPU’yu.
Paylaşımlı hosting gerçeği
Bu yazıyı okuyanların çoğu cPanel’li paylaşımlı bir hosting kullanıyor. Orada durum basit: size ne verilmişse onu kullanırsınız, ki bu neredeyse her zaman MySQL veya MariaDB’dir. PostgreSQL paylaşımlı hostinglerde nadirdir.
O yüzden pratik tavsiyem: paylaşımlı hostingdeyseniz hosting firmanıza “MariaDB mi MySQL mi çalıştırıyorsunuz, sürümü ne?” diye sorun. Cevap MySQL 5.7 gibi bir şeyse, taşınmayı düşünün — sürüm farkı, bu yazıdaki motor farkından daha büyük bir performans kaynağı.
Bu veritabanı benchmark’ının söylemedikleri
Her veritabanı benchmark’ı gibi bunun da sınırları var, dürüst olmak gerekirse onları da yazmalıyım:
- Test edilen MySQL 26.7.0 bir early access sürümüydü, GA değil. Varsayılan ayarları ve performans profili kararlı sürüme kadar değişebilir. MySQL rakamlarını “bu motorun değişmez karakteri” diye değil, “bu sürümün o günkü hâli” diye okuyun.
- Ölçümler Apple Silicon üzerinde Docker Desktop ortamında yapıldı. Çıplak bir Linux sunucusunun disk davranışı farklıdır.
- Motorların varsayılan ayarları karşılaştırıldı. Bu “eşit yapılandırma” testi değil, “kutudan çıktığı hali” testidir. Tuning ile tablo ciddi biçimde değişebilir — özellikle MySQL tarafında.
- Ölçüm pencereleri kısaydı. Yani bunlar anlık yük rakamları; saatlerce süren yükte devreye giren checkpoint, purge ve bloat davranışlarını içermiyor.
- Test istemcisi Node.js’ti ve sürücü maliyeti de ölçüme dahil. Yukarıda yazdığım gibi, PostgreSQL join hücresinde bunun bir payı olabilir.
- Veri seti ~200 MB düzeyindeydi, yani üç motorda da büyük ölçüde belleğe sığdı. Diske taşan veri setlerinde sıralama değişebilir.
Üretim kararı verirken bu rakamların yanına kendi sorgularınızı, yedekleme ve replikasyon ihtiyacınızı, ekibinizin hangi motoru bildiğini ve hosting’inizin ne sunduğunu da koymanız gerekir.
Sonuç
Bu veritabanı benchmark’ından tek bir kazanan çıkmadı, ama net eğilimler çıktı:
PostgreSQL yüksek eşzamanlılıkta okuma ve yazmada en yüksek tavanı gösterdi, en az belleği kullandı. Yeni bir proje planlıyorsanız ve hosting’iniz izin veriyorsa, varsayılan tercihiniz bu olsun.
MariaDB bu testin en dengeli motoruydu. Transaction ve karma yükte en iyi sonucu, en düşük gecikmeyi ve en düşük CPU’yu verdi. WordPress ve PHP tabanlı CMS dünyasındaysanız tereddüt etmeyin.
MySQL okuma ve join’de rekabetçi kaldı ama varsayılan ayarlarıyla yazma tarafında geride, bellekte önde çıktı. Burada iki kayıt düşmek gerekiyor: test ettiğim sürüm early access’ti, ve fark büyük ölçüde motorun hızından değil dayanıklılık varsayılanlarından geliyor. Yani bu bir kusur değil, farklı bir varsayılan tercih — ama farkında olarak seçmeniz gereken bir tercih. Kararlı sürümde ve bilinçli tuning ile tablo değişir.
Ve son olarak, bu veritabanı benchmark’ından çıkardığım ve en çok tekrarlamak istediğim cümle: sıradan bir sitede bu üç motor arasındaki fark, kötü bir indeksin veya kapalı bir cache’in yanında önemsiz kalır. Önce onları halledin, motor tartışmasını sonra yapın.
Sıkça sorulan sorular
MariaDB, MySQL’in yerine doğrudan geçer mi?
Çoğu senaryoda evet, drop-in olarak tasarlandı. Ancak son yıllarda iki proje birbirinden uzaklaştı; MySQL’e özgü yeni özellikler (bazı JSON fonksiyonları, CTE davranışları, replikasyon detayları) birebir örtüşmeyebilir. Standart bir WordPress veya PHP uygulamasında sorun yaşamazsınız, ağır özelleşmiş bir sistemde önce test edin.
WordPress’i PostgreSQL ile çalıştırabilir miyim?
Pratikte hayır. Bazı topluluk eklentileri deniyor ama üretimde önerilmez. WordPress kullanacaksanız MySQL veya MariaDB kullanacaksınız.
MySQL’i hızlandırmak için ne yapabilirim?
Bu veritabanı benchmark’ındaki farkın büyük kısmı dayanıklılık ayarlarından geliyor. sync_binlog, innodb_flush_log_at_trx_commit ve binary log’un açık olup olmadığı doğrudan yazma hızını belirliyor. Ama bunlar yedekleme ve replikasyon güvenliğinizi de belirliyor — körlemesine değiştirmeyin, ne kaybettiğinizi bilerek değiştirin.
Sitem yavaş, veritabanını değiştirsem hızlanır mı?
Neredeyse kesinlikle hayır. Yavaşlığın kaynağı genellikle eksik indeks, N+1 sorgu, kapalı object cache veya ağır eklentilerdir. Önce yavaş sorgu logunu açıp bakın; motor değiştirmek listenin en sonunda gelir.
Bu veritabanı benchmark’ını kendi sunucumda tekrarlasam aynı sonucu alır mıyım?
Muhtemelen aynı sıralamayı, farklı rakamları alırsınız. Çıplak Linux sunucusunda disk davranışı Docker Desktop’tan farklıdır ve mutlak değerler değişir. Ama yazma amplifikasyonu ve bellek farkı gibi yapısal bulgular büyük ölçüde korunur.
Neden kararlı MySQL yerine early access sürümü test ettin?
Üç motorda da o an mevcut olan en güncel sürümü kullanmak istedim; MySQL tarafında bu bir early access yayınıydı. Karşılaştırmayı “hepsi en yeni hâliyle” kurmak tutarlı bir tercih ama bedeli şu: MySQL rakamları henüz olgunlaşmamış bir sürüme ait. Bu yüzden yazı boyunca MySQL sonuçlarını mutlak bir yargı değil, o sürümün o günkü fotoğrafı olarak sundum. Kararlı sürüm çıktığında testi tekrarlayıp sonuçları güncelleyeceğim.