VS Code’da PostgreSQL Performans Ayarı: Artık Tek Ekran
Açık konuşayım: Yavaş bir sorgu, çoğu zaman “sadece veritabanı” meselesi olmuyor. Saha tarafında bunu defalarca gördüm; SLA kaçıyor, sürüm erteleniyor, geliştirici geriliyor, operasyon ekibi de sessizce yükü sırtlıyor. Bir de müşteri tarafı var, oraya girince iş uzuyor. Hatta baya uzuyor.
Aslında, Geçen hafta bir ekiple konuşurken yine aynı manzarayla karşılaştım: SQL editörü bir yanda, Azure portal başka sekmede, Grafana üçüncü ekranda, doküman dördüncüde. EXPLAIN ANALYZE çıktısını okuyup aksiyon almak yarım günü buluyor. Asıl maliyet teknik tarafta değil; zaman gidiyor, ekipler birbirine biraz daha az güveniyor ve momentum dağılıyor. Kötü hissettiriyor.
İşte tam burada Microsoft’un Visual Studio Code için yayınladığı PostgreSQL extension’dan ve son eklenen performans odaklı özelliklerden söz etmek istiyorum (en azından benim deneyimim böyle). Yıllardır beklediğim entegrasyon nihayet şekillenmeye başladı gibi dürüyor — ama açık söyleyeyim, hâlâ pürüzlü yerleri var. Onlara da geleceğim.
Şimdi gelelim işin can alıcı noktasına.
Önce şunu söyleyeyim: Sorun aslında “araç” değil
Kurumsal ekiplerde PostgreSQL ile çalışan kim varsa bilir, araç kıtlığı yok. pgAdmin var, DBeaver var, Datagrip var, Azure portalı var, Query Performance Insight var, pg_stat_statements var… Liste uzayıp gidiyor. Peki neden hâlâ “yavaş sorgu” işleri haftalar sürüyor?
Garip gelecek ama, Çünkü entegrasyon eksik. İçgörü bir yerde kalıyor, aksiyon başka yerde başlıyor, bağlam işe ikisinin arasında kayboluyor. Bir DBA’in ağzıyla söylersem: “Tamam metrikleri gördüm de, bu sorguyu nereden bulup nasıl düzelteceğim?” sorusunun cevabı çoğu zaman “birkaç sekme daha aç” oluyor. İnsan beyni bunu pek sevmiyor. Context switch resmen can sıkıyor.
Microsoft’un bu eklentide yaptığı şey tam da o boşluğa dokunmak: geliştirme, teşhis ve tuning’i tek akışta toplamak. Kulağa kolay geliyor, değil mi? Ama işin aslı öyle değil.
VS Code’a gelen yenilikler: Aslında ne var elimizde?
Eklentinin ana iddiası PostgreSQL’i yaşam döngüsü boyunca yönetebilmek. Yanı sorgu yazmaktan şema keşfine, sunucu sağlığını izlemekten performans ayarlarına kadar uzanıyor. Kağıt üstünde iyi dürüyor. Pratikte ne kadar işe yarıyor, ona bakalım.
Server Metrics Dashboard — Belki de en kullanışlı parça
Yanı, Doğrudan VS Code içinden CPU, memory, storage ve connection sayıları gibi temel sinyalleri görebilmek… Basit gibi dürüyor ama bence eklentinin en değerli kısmı bu (yanlış duymadınız). Çünkü geliştirici sorgu yazarken tarayıcı açmak zorunda kalmıyor. Üstelik Azure ile bağlı olduğu için sadece anlık görüntü değil, geçmiş trendleri de izleyebiliyorsunuz.
Hani bir sorgu deploy ettiniz ya da ettiniz sanıyorsunuz; ertesi gün CPU tavan yapmış oluyor — eskiden portal-VS Code-Slack üçgeninde dönüp duruyorduk. Şimdi en azından “bu deploy mu — kendi adıma konuşayım — yaptı yoksa başka bir şey mi” sorusunu aynı pencerede kurcalayabiliyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Evet, fark ediyor.
Evet, doğru duydunuz.
Azure Advisor entegrasyonu
Kendi deneyimimden konuşuyorum, Bu kısım biraz tartışmalı. Advisor önerileri genelde “şu indeksi ekle”, “şu config’i değiştir” tarzında geliyor. Çoğu zaman iş görüyor ama hepsini gözü kapalı uygulamak yanlış olur. Mesela production’da indeks eklemenin write performansına etkisini düşünmeden ilerleyen ekipler gördüm; sonu pek hoş olmuyor.
Yanı Advisor’ı bir çeşit “akıllı çırak” gibi düşünün. Öneriyi dinleyin ama son kararı yine sız verin (en azından benim deneyimim böyle)
Query Performance Tooling
Eklenti içinden EXPLAIN ve EXPLAIN ANALYZE çıktılarını daha okunur biçimde görebiliyorsunuz. Burada açık konuşayım, beklediğim kadar olgun bulmadım; pgAdmin’in visual explain’i ya da pev2 gibi araçların seviyesine henüz gelmiş değil. Ama yön doğru görünüyor. Birkaç sürüm sonra daha oturmuş hâle gelir diye düşünüyorum (ben de ilk duyduğumda şaşırmıştım)
Türkiye’deki şirketler için bu ne anlama geliyor?
Sahada gördüğüm kadarıyla Türkiye’de kurumsal PostgreSQL kullanımı son 3-4 yılda baya arttı. Lisans maliyetinden kaçmak isteyen finans ve telekom oyuncuları Oracle’dan PostgreSQL’e geçiş projelerine ciddi bütçe ayırıyor. Tahmin eder mısınız? Ama bir gerçek daha var: Bu şirketlerde DBA kadrosu hâlâ çoğunlukla Oracle/SQL Server kafasıyla yetişmiş insanlardan oluşuyor (bizzat test ettim) Daha fazla bilgi için
Bence bu eklentinin Türkiye’deki değeri tam burada ortaya çıkıyor. Çünkü:
- Geliştiriciler zaten VS Code kullanıyor; ekstra araç öğrenmeleri gerekmiyor.
- PostgreSQL’e yeni geçen ekipler için öğrenme eğrisi daha düşük kalıyor.
- Azure Database for PostgreSQL Flexible Server kullanan müşterilerde Azure portalına girmeden birçok işi halletmek mümkün oluyor.
- Türkçe karakter setiyle (UTF-8 collation) çalışırken çıkan tuhaflıkları sorgu üstünde anında debug edebiliyorsunuz.
Bunu yaşayan biri olarak söyleyeyim, Bir de FinOps tarafı var tabiî. Azure Database for PostgreSQL — özellikle Business Critical SKU’ları — TL bazında bakınca ucuz sayılmaz. Yavaş sorgular = gereksiz büyük instance = ay sonunda şişen fatura. Eklenti bu döngüyü kırmaya yardım ediyor.
“Performans tuning’i lüks değil, doğrudan FinOps meselesi. Bir 8 vCore instance’tan 4 vCore’a inebilmek yıllık bazda altı haneli TL tasarruf demek olabilir. Bu eklenti o kapıyı aralıyor.”
Pratik senaryo: Yavaş bir sorguyu adım adım çözmek
Diyelim ki e-ticaret API’nizdeki sipariş listeleme sorgusu yavaşladı (buna dikkat edin). Eski usulle nasıl giderdik? Şöyle:
- Application Insights’ta yavaş endpoint’i tespit et
- Azure portalında PostgreSQL Query Store’a gir
- Sorguyu kopyala, pgAdmin’e yapıştır
EXPLAIN ANALYZEçalıştır- Puan değil plan yorumla (çoğu zaman gözler kararıyor)
- Indeks öner, test ortamında uygula, ölç
- Tekrar portalına dönüp metriklere bak
Peki şimdi nasıl oluyor? Aşağıya küçük bir karşılaştırma koydum:
| Aşama | Klasik Yöntem | VS Code Eklentisi ile |
|---|---|---|
| Sorgu tespiti | Portal + App Insights | Dashboard üzerinden top queries |
| Plan analizi | Dbeaver ya da pgAdmin’e kopyala | Aynı editörde, tek tıkla bak |
| Indeks önerisi | Manuel analiz | Advisor entegre |
| Etkisini ölçme | Potal’a geri dönüp kontrol et | Server Metrics aynı yerde dürüyor |
| Ortalama süre | 2-4 saat | 30-60 dakika |
Küçük bir detay: Tablodaki süreler tabiî ki iyimser tahminlerdir; gerçek hayatta sorgunun karmaşıklığına göre değişir. Ama yön belli: bağlam değişikliği azaldıkça çözüm süresi kısalıyor.
Küçük bir örnek: pg_stat_statements’i hâlâ ihmal etmeyin
Eklenti güzel ama temel yapı taşları olmadan hiçbir araç sizi kurtarmaz. Şu config’i Flexible Server’da açık tuttuğunuzdan emin olun:
# postgresql.conf
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all
track_io_timing = on
Şahsen, Bunlar olmadan eklenti de kör kalır desem abartmış olmam sanırım. Gerçek anlamda yavaş sorgu analizi yapmak istiyorsanız track_io_timing‘i büyük ihtimalle açın; aksi hâlde IO bekleme süresini göremezsiniz ve planlardaki “neden yavaş?” sorusu havada kalır.
XNUMX?>Azure HorizonDB tarafında ne var?Sıkça Sorulan Sorular
VS Code PostgreSQL eklentisi ücretsiz mi?
Evet, eklentinin kendisi ücretsiz. Ama Azure Database for PostgreSQL ile bağlandığında Azure kaynak maliyetleri ve veri transfer ücretleri yine de işliyor — yanı aslında Azure tarafı normal fiyatlandırmasıyla devam ediyor. Peki bunu neden söylüyorum? Advisor önerileri de Azure aboneliğinizin kapsamına göre geliyor.
Self-hosted PostgreSQL’de bu eklenti çalışır mı?
Temel şeyler çalışıyor — sorgu yazma, şema keşfi, genel bağlantı gibi. Ama mesela Server Metrics Dashboard veya Azure Advisor entegrasyonu gibi özellikler sadece Azure üzerindeki PostgreSQL servislerinde aktif, bu oldukça doğal aslında.
pgAdmin’i tamamen değiştirir mi?
Şu an için hayır. pgAdmin hâlâ çok daha detaylı bir DBA aracı — backup yönetimi, kullanıcı yönetimi, daha olgun visual explain gibi konularda açıkçası önde. Bu eklenti daha çok geliştiricinin — ki bu tartışılır — günlük iş akışını hızlandırmak için tasarlanmış. Bence ikisini birlikte kullanmak çoğu ekip için en mantıklısı.
Azure HorizonDB ile uyumlu mu?
Microsoft HorizonDB’yi PostgreSQL uyumlu olarak konumlandırdığı için eklentinin temel özelliklerinin çalışması bekleniyor. Yanı genel olarak sorun yaşamamalısınız. HorizonDB’ye özel metrikler ve scale-out telemetry için zamanla özel destek eklenmesi oldukça olası. Bakın, şu an için tecrübeme göre Flexible Server tarafında çok daha olgun bir deneyim sunuyor.
Kurumsal güvenlik politikamızla uyumlu mu?
Şöyle söyleyeyim, Eklenti Azure AD (Microsoft Entra ID) ile kimlik doğrulamayı destekliyor. RBAC rollerinize göre erişimi kısıtlayabilir, geliştiricilere mesela sadece okuma yetkisi verebilirsiniz. Private endpoint’lerin arkasındaki PostgreSQL örneklerine de bağlanabiliyor. Ama her zaman olduğu gibi, eklenti kullanım politikanızı CISO ekibinizle birlikte netleştirin — bence bu adımı atlamamak gerekiyor.
Kaynaklar ve İleri Okuma
Azure Blog: The performance dividend — Optimizing PostgreSQL on Azure in VS Code
Azure Database for PostgreSQL Resmî Dokümantasyonu (bizzat test ettim)
PostgreSQL Extension for Visual Studio Code — Marketplace
İnanın, pg_stat_statements Resmî Dokümantasyonu (buna dikkat edin)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments