- 01Azure SQL Database tam yönetilen PaaS hizmetidir ancak schema, query tuning, security, sizing ve business continuity kararları yine workload ekibine aittir.
- 02General Purpose, Business Critical ve Hyperscale farklı latency, resiliency, scale ve cost trade-off'ları sunar; seçim production ihtiyacına göre yapılmalıdır.
- 03Automated backup ve point-in-time restore vardır ancak restore süresi ve recovery akışı ayrıca test edilmelidir.
- 04Zone redundancy zone-level failure'a, geo-replication/failover group ise region-level continuity senaryolarına yönelik farklı katmanlardır.
- 05Azure SQL Database, Managed Instance ve SQL Server on Azure VM seçimi compatibility ve operasyon hedefleri birlikte değerlendirilerek yapılmalıdır.
Kısaca
Azure SQL Database, SQL Server motorunu temel alan tam yönetilen PaaS veritabanı hizmetidir. Infrastructure patching, platform high availability ve automated backup gibi altyapı operasyonlarının önemli bölümü Azure tarafından yönetilir; ancak production başarısı için service tier, compute modeli, storage, network, authentication, backup/restore, business continuity, monitoring ve maliyet kararlarının doğru verilmesi gerekir.
Dynamis Teknoloji'de Azure SQL Database seçimini yalnız 'managed database kullanalım' kararı olarak değil; workload'un transaction profili, latency, büyüme, recovery hedefi ve SQL Server uyumluluk gereksinimlerine göre değerlendiriyoruz.
Azure SQL Database nedir?
Azure SQL Database, tek veritabanı veya elastic pool modeliyle çalışabilen PaaS ilişkisel veritabanı hizmetidir.
Tipik kullanım alanları:
- SaaS uygulamaları
- web/API backend
- line-of-business uygulamalar
- transactional OLTP workload
- modernize edilmiş SQL Server uygulamaları
Azure platformu altyapı seviyesinde birçok operasyonu yönetir; yine de şu alanlar application/database ekibinin sorumluluğundadır:
- schema
- index
- query tuning
- kullanıcı/rol
- data model
- application connection
- RTO/RPO
- cost governance
Azure SQL ailesindeki seçenekler
Azure SQL tek bir hizmet değildir.
Başlıca seçenekler:
- Azure SQL Database
- Azure SQL Managed Instance
- SQL Server on Azure Virtual Machines
Seçim modernizasyon hedefini doğrudan etkiler.
Azure SQL Database ne zaman iyi adaydır?
Şu durumlarda güçlü adaydır:
- database-scoped application
- PaaS operasyon modeli isteniyor
- OS/instance yönetmek istenmiyor
- yüksek SQL Server compatibility yeterli
- cloud-native scaling isteniyor
Managed Instance ne zaman daha uygun olabilir?
SQL Server'dan migration sırasında:
- SQL Agent
- cross-database feature
- instance-level configuration
- daha yüksek SQL Server compatibility
gerekiyorsa Managed Instance daha uygun olabilir.
SQL Server on Azure VM ne zaman gerekir?
İşletim sistemi veya SQL Server instance üzerinde tam kontrol gerekiyorsa Azure VM modeli değerlendirilebilir.
Örneğin:
- özel agent
- legacy extension
- OS dependency
- unsupported PaaS feature
durumlarında IaaS daha doğru olabilir.
Service tier nasıl seçilir?
Azure SQL Database'de en önemli production kararlarından biri service tier'dır.
Yaygın vCore tier'ları:
- General Purpose
- Business Critical
- Hyperscale
Her biri farklı performans, storage ve resiliency trade-off'u sunar.
General Purpose
General Purpose çoğu standart business workload için dengeli maliyet/performance sunar.
İyi adaylar:
- tipik SaaS backend
- orta transaction hacmi
- maliyet hassas workload
- düşük/orta latency ihtiyacı
İlk sizing için genellikle doğal başlangıç noktasıdır.
Business Critical
Business Critical yüksek transaction rate ve düşük I/O latency gerektiren OLTP workload'lara yöneliktir.
Öne çıkan ihtiyaçlar:
- daha düşük storage latency
- daha hızlı failover
- yüksek availability
- read scale-out gereksinimi
Ancak daha yüksek maliyet getirir; yalnız 'production' olduğu için otomatik seçilmemelidir.
Hyperscale
Hyperscale compute ve storage katmanlarını daha bağımsız ölçeklendiren mimaridir.
Şu durumlarda değerlendirilebilir:
- çok büyük database
- hızlı büyüme
- read replica ihtiyacı
- yüksek scale esnekliği
Workload küçükse Hyperscale gereksiz karmaşıklık veya maliyet yaratabilir.
DTU mu vCore mu?
Azure SQL Database iki satın alma yaklaşımı sunar:
- DTU
- vCore
DTU daha paketli bir compute modelidir.
vCore modeli CPU/memory/resource seçimlerini daha görünür hale getirir ve çoğu production sizing kararında daha şeffaf olabilir.
Yeni tasarımda mevcut workload ve lisans avantajlarıyla birlikte karşılaştırılmalıdır.
Provisioned compute vs serverless
Serverless modeli compute kullanımını workload'a göre otomatik ölçeklendirebilir ve belirli idle sürelerde auto-pause destekleyebilir.
İyi adaylar:
- düzensiz kullanım
- dev/test
- düşük duty cycle
- öngörülemeyen burst
7/24 yoğun production workload'da provisioned compute daha öngörülebilir olabilir.
Elastic Pool ne zaman kullanılır?
Birden fazla database benzer kaynak havuzunu paylaşıyorsa elastic pool maliyet ve kapasite yönetimini kolaylaştırabilir.
Örnek:
- multi-tenant SaaS
- çok sayıda küçük database
- her database farklı saatte peak yapıyor
Pool modeli toplam kapasiteyi daha verimli kullanabilir.
Compute sizing nasıl yapılmalı?
Yalnız database size'a bakmayın.
Ölçün:
- CPU
- Data IO
- Log IO
- connection
- worker
- query duration
- DTU/vCore utilization
- blocking/wait
Özellikle p95/p99 değerleri önemlidir.
Storage büyümesi
Database sizing'de:
- current size
- monthly growth
- index growth
- log pattern
- retention
birlikte değerlendirilmelidir.
Storage yalnız bugünkü veri boyutuna göre seçilmemelidir.
Zone redundancy
Zone redundancy desteklenen Region ve tier'larda replica'ları farklı Availability Zone'lara dağıtarak zone-level failure'a karşı dayanıklılığı artırabilir.
Bu özellik kritik production workload'larda güçlü adaydır.
Ancak zone redundancy region-wide disaster recovery değildir.
Region-level disaster recovery
Region kaybı senaryosu için:
- active geo-replication
- failover group
gibi seçenekler değerlendirilir.
Bu tasarım:
- RPO
- RTO
- application connection failover
ile birlikte planlanmalıdır.
Failover Group ne sağlar?
Failover group primary ve secondary server arasında database failover yönetimini kolaylaştırabilir.
Application connection endpoint'i failover sonrası daha kontrollü yönetilebilir.
Ancak failover test edilmeden production DR hazır sayılmamalıdır.
Backup otomatik mi?
Evet.
Azure SQL Database automated backup oluşturur ve point-in-time restore destekler.
Short-term retention yeni database'lerde varsayılan olarak 7 gündür ve desteklenen tier'larda daha uzun süre yapılandırılabilir.
Long-term retention ayrıca yıllık saklama senaryoları için kullanılabilir.
Backup varsa restore testi gerekli mi?
Evet.
Backup'ın varlığı recovery'nin başarılı olacağını tek başına kanıtlamaz.
Test edin:
- restore süresi
- restore sonrası data doğruluğu
- connection değişikliği
- application startup
- RTO hedefi
Point-in-time restore ne işe yarar?
Yanlış update/delete veya application bug sonrası database'i belirli geçmiş noktaya döndürmek için kullanılabilir.
Ancak restore yeni database olarak oluşturulabilir; application cutover adımı ayrıca planlanmalıdır.
Security: authentication
Azure SQL Database için:
- Microsoft Entra authentication
- SQL authentication
kullanılabilir.
Production'da mümkün olduğunda Entra tabanlı kimlik ve managed identity kullanımı credential yönetimini sadeleştirebilir.
Managed Identity neden önemli?
Application'ın SQL username/password saklaması yerine managed identity ile authentication yapması:
- secret rotation ihtiyacını azaltır
- credential exposure riskini düşürür
- RBAC/identity governance ile uyum sağlar
Ancak application driver ve deployment modeli desteklemelidir.
Private Endpoint
Azure SQL Database public endpoint üzerinden erişilebilir; ancak production workload'da public access gerekmiyorsa Private Endpoint değerlendirilebilir.
Bu sayede traffic private network üzerinden yönlendirilebilir.
DNS configuration ayrıca doğru planlanmalıdır.
Firewall kuralları
Public endpoint açık kalıyorsa firewall scope minimum tutulmalıdır.
Broad allowlist production için kaçınılması gereken bir yaklaşımdır.
Encryption
Azure SQL Database Transparent Data Encryption kullanarak data at rest encryption sağlar.
Customer-managed key gereksinimi varsa Key Vault tabanlı key yönetimi ayrıca değerlendirilebilir.
Query tuning hâlâ sizin sorumluluğunuzda
PaaS kullanmak kötü query'yi otomatik çözmez.
İzleyin:
- long-running query
- missing/unused index
- blocking
- wait stats
- parameter sensitivity
- query plan
Application ve database tuning devam eder.
Automatic tuning kullanılmalı mı?
Azure SQL bazı automatic tuning yetenekleri sunar.
Örneğin:
- force last good plan
- index recommendation
gibi.
Production'da önce recommendation etkisi anlaşılmalı ve değişiklikler izlenmelidir.
Monitoring
Production Azure SQL için:
- CPU
- Data IO
- Log IO
- storage
- sessions
- deadlock
- connection failure
- query performance
izlenmelidir.
Azure Monitor ve database diagnostic telemetry kullanılabilir.
Alert'ler
Minimum alert alanları:
- CPU saturation
- storage pressure
- failed connection spike
- deadlock increase
- replication/failover issue
olabilir.
Alert'in owner ve response runbook'u bulunmalıdır.
Connection pool
Database sorunlarının önemli bölümü yanlış application connection yönetiminden çıkar.
Kontrol edin:
- pool size
- timeout
- retry
- connection lifetime
- transient fault handling
Azure SQL'de transient failure için retry/backoff tasarımı önemlidir.
Cost optimization
Azure SQL maliyetini etkileyenler:
- compute tier
- vCore/DTU
- storage
- backup retention
- zone redundancy
- geo-replication
- license benefit
olabilir.
Azure faturasındaki 7 israf kalemi genel Azure waste kontrollerini ayrıca ele alır.
Azure Hybrid Benefit
Uygun SQL Server lisans hakkına sahip müşteriler vCore modelinde Azure Hybrid Benefit'ten yararlanabilir.
Ancak eligibility lisans sözleşmesi ve mevcut entitlement'a göre doğrulanmalıdır.
Dev/Test ve production aynı tier olmalı mı?
Hayır.
Dev/test:
- serverless
- daha düşük compute
- kısa retention
kullanabilir.
Production ise SLO ve recovery hedeflerine göre boyutlandırılmalıdır.
Database migration öncesi compatibility
SQL Server'dan Azure SQL Database'e geçmeden önce:
- unsupported feature
- SQL Agent dependency
- linked server
- cross-database query
- CLR
- authentication
kontrol edilmelidir.
Uyumluluk problemi yüksekse Managed Instance veya SQL Server on Azure VM daha uygun olabilir.
Production kontrol listesi
- doğru Azure SQL seçeneği
- service tier doğru
- compute modeli doğru
- storage/growth planlı
- zone redundancy ihtiyacı değerlendirildi
- geo-DR ihtiyacı değerlendirildi
- backup retention uygun
- restore test edildi
- Entra/managed identity değerlendirildi
- network exposure minimum
- monitoring/alert aktif
- query baseline var
- cost owner belli
Well-Architected ile bağlantı
Azure Well-Architected Framework Azure SQL tasarımını beş pillar üzerinden değerlendirmeye yardımcı olur.
Reliability → zone/geo redundancy
Security → identity/private access/encryption
Cost → tier/sizing/retention
Operations → backup/monitoring
Performance → query/compute/storage
Landing Zone ile bağlantı
Azure Landing Zone database'in bulunduğu subscription/network/governance guardrail'lerini tanımlar.
Örneğin:
- private endpoint policy
- logging
- tagging
- RBAC
merkezi yönetilebilir.
Dynamis'te Azure SQL yaklaşımı
Dynamis'in Azure yönetimi hizmetinde önce workload ve compatibility profili çıkarılır.
Assessment:
- transaction pattern
- database size/growth
- latency
- SQL Server feature dependency
- RTO/RPO
- security
- network
- cost
alanlarını kapsar.
Ardından Azure SQL Database, Managed Instance veya Azure VM üzerindeki SQL Server seçeneklerinden workload'a uygun olan seçilir.
Amaç en yüksek tier'ı seçmek değil, production gereksinimini doğru PaaS/IaaS modeli ve doğru kapasiteyle karşılamaktır.
Sık yapılan hatalar
SQL Server = Azure SQL Database birebir aynı sanmak: Instance-level feature farklarını kontrol edin.
Production diye Business Critical seçmek: Latency ve HA ihtiyacını ölçün.
Backup var diye DR hazır sanmak: Restore ve region failover ayrı test edilmelidir.
Public endpoint'i varsayılan bırakmak: Private access gereksinimini değerlendirin.
PaaS query tuning gerektirmez sanmak: Query/index/application davranışı hâlâ sizin sorumluluğunuzda.
Maliyeti yalnız compute olarak görmek: Storage, backup ve geo-replication da eklenir.
Sırada ne var
- Azure Well-Architected Framework
- Azure Landing Zone Nedir?
- Azure faturasındaki 7 israf kalemi
- Azure yönetimi hizmeti
Kaynaklar
Kaynaklar
- 1.Azure SQL Database overviewMicrosoft Learn · 2026-09-25
- 2.Azure SQL purchasing modelsMicrosoft Learn · 2026-09-25
- 3.Azure SQL Database service tiersMicrosoft Learn · 2026-09-25
- 4.Azure SQL Database high availabilityMicrosoft Learn · 2026-09-25
- 5.Automated backupsMicrosoft Learn · 2026-09-25
- 6.Active geo-replicationMicrosoft Learn · 2026-09-25
- 7.Failover groupsMicrosoft Learn · 2026-09-25
- 8.Microsoft Entra authentication for Azure SQLMicrosoft Learn · 2026-09-25
- 9.Private endpoints for Azure SQL DatabaseMicrosoft Learn · 2026-09-25
Sık sorulan sorular
Azure SQL Database nedir?
Azure SQL Database, Microsoft'un tam yönetilen PaaS ilişkisel veritabanı hizmetidir. SQL Server motoru temellidir; patching, platform high availability, automated backup ve çoğu altyapı operasyonunu hizmet olarak yönetir. Kullanıcı tarafında schema, query, index, security, sizing ve business continuity kararları devam eder.
Azure SQL Database ile Azure SQL Managed Instance arasındaki fark nedir?
Azure SQL Database daha cloud-native, database-scoped bir PaaS modelidir. Azure SQL Managed Instance ise SQL Server instance-level özellikleri ve daha yüksek uygulama uyumluluğu gereken migration senaryolarında daha uygun olabilir. Seçim; cross-database query, SQL Agent, instance-level feature, network, compatibility ve modernization hedeflerine göre yapılmalıdır.
General Purpose, Business Critical ve Hyperscale arasındaki fark nedir?
General Purpose dengeli compute ve storage ihtiyacı olan çoğu workload için ekonomik bir başlangıçtır. Business Critical yüksek transaction rate, düşük I/O latency ve daha hızlı failover ihtiyacı olan OLTP sistemlerine yöneliktir. Hyperscale compute ve storage katmanlarını daha bağımsız ölçeklendirir; büyük veya hızlı büyüyen veritabanları ve read-scale ihtiyacı olan modern workload'larda değerlendirilir.
Azure SQL Database otomatik backup alır mı?
Evet. Azure SQL Database automated backup oluşturur ve point-in-time restore destekler. Varsayılan kısa süreli retention yeni veritabanlarında 7 gündür; çoğu tier'da 1-35 gün arasında yapılandırılabilir. Long-term retention ayrıca yıllar seviyesinde saklama için yapılandırılabilir. Backup varlığı restore testinin yerini tutmaz; production recovery planında restore süresi ve doğrulama ayrıca test edilmelidir.
Azure SQL Database production için zone redundant kurulmalı mı?
Business requirement'a bağlıdır. Zone redundancy desteklenen tier ve Region'larda veriyi birden fazla Availability Zone'a dağıtarak zone-level failure'a karşı dayanıklılığı artırır. Kritik workload'larda RTO/RPO ve SLA hedefleri doğrultusunda değerlendirilmelidir; tek başına region-wide disaster recovery sağlamaz. Region kaybı senaryosu için geo-replication veya failover group ayrıca gerekebilir.