- 01SQL Server → PostgreSQL geçişi yalnız veri kopyalama değildir; şema, T-SQL, stored procedure, job ve uygulama SQL bağımlılıkları birlikte değerlendirilmelidir.
- 02AWS SCT gibi araçlar otomatik dönüştürülemeyen nesneleri action item olarak gösterebilir; bu nesneler manuel tasarım ve test gerektirir.
- 03IDENTITY genellikle PostgreSQL identity/sequence yapısına, uniqueidentifier uuid tipine ve uygun computed column'lar generated column yapısına eşlenebilir; davranış birebir varsayılmamalıdır.
- 04Uygulama içine gömülü T-SQL migration kapsamına dahil edilmelidir; Dynamis gerekli kod değişikliklerini analiz ve dokümante eder ancak müşteri kaynak kodunu değiştirmez.
- 05Production cutover öncesi row count, checksum/hash, field-level validation, kritik transaction ve query performance kontrolleri birlikte uygulanmalıdır.
Kısaca
SQL Server'dan PostgreSQL'e geçiş yalnız veriyi bir veritabanından diğerine kopyalamak değildir. Asıl iş; şema, veri tipleri, T-SQL kodu, stored procedure'ler, identity/computed column davranışı, job'lar, linked server bağımlılıkları ve uygulamanın SQL kullanımını hedef motorda yeniden doğrulamaktır. Uygun nesnelerin bir bölümü otomatik veya yarı otomatik dönüştürülebilir; ancak assessment raporunda kalan action item'lar manuel tasarım ve test gerektirir.
Dynamis Teknoloji'de bu geçişi önce uyumluluk envanteri, sonra pilot dönüşüm, ardından veri replikasyonu ve kontrollü cutover olarak ele alıyoruz. Uygulama kodunda değişiklik gerekiyorsa hangi noktaların değişmesi gerektiğini çıkarır ve dokümante ederiz; müşteri uygulamasının kaynak kodunu biz değiştirmeyiz.
SQL Server'dan PostgreSQL'e geçerken en çok hangi alanlar değişir?
Aşağıdaki alanlar migration kapsamını belirleyen ana başlıklardır:
| SQL Server tarafı | PostgreSQL tarafında tipik karşılık | Dikkat edilmesi gereken |
|---|---|---|
| IDENTITY | identity column / sequence | Seed, increment ve explicit insert davranışı |
| uniqueidentifier | uuid | Function ve ordering davranışları |
| computed column | generated column / view / yeniden tasarım | Expression kısıtları ve index kullanımı |
| NVARCHAR / VARCHAR | varchar / text | Collation, encoding ve uzunluk varsayımları |
| DATETIME / DATETIME2 | timestamp | Precision ve timezone davranışı |
| DATETIMEOFFSET | timestamptz veya ayrı offset modeli | Uygulamanın timezone varsayımları |
| BIT | boolean | Uygulama sürücüsü ve literal kullanımı |
| MONEY / SMALLMONEY | numeric | Precision ve rounding |
| VARBINARY / IMAGE | bytea / object storage yaklaşımı | Büyük binary veri ve erişim deseni |
| T-SQL stored procedure | PL/pgSQL / SQL function / uygulama mantığı | Sözdizimi ve transaction farkları |
| SQL Agent Job | pg_cron / scheduler / dış orchestrator | Operasyon sahipliği |
| Linked Server | FDW / uygulama entegrasyonu / ETL | Network ve transaction davranışı |
Bu tablo birebir dönüşüm garantisi değildir. Her kaynak şema için assessment yapılmalıdır.
İlk adım neden assessment raporudur?
SQL Server → PostgreSQL dönüşümünde otomatik araç kullanmak faydalıdır, ancak araç çıktısını “migration tamamlandı” diye yorumlamak hatadır.
AWS Schema Conversion Tool gibi araçlar şema nesnelerini ve SQL kodunu tarayarak hangi nesnelerin otomatik dönüştürülebildiğini, hangilerinin manuel action item gerektirdiğini raporlayabilir. Assessment raporu özellikle:
- tablo ve kolon tanımları
- index'ler
- view'lar
- stored procedure ve function'lar
- trigger'lar
- T-SQL kullanım noktaları
- uygulama içine gömülü SQL
üzerinden dönüşüm karmaşıklığını görünür hale getirir.
Bizim önerdiğimiz çıktı yalnız “%X otomatik dönüşüyor” yüzdesi değildir. Her action item için:
- Nesne adı
- Kaynak bağımlılığı
- Hedefte önerilen karşılık
- Manuel iş ihtiyacı
- Uygulama etkisi
- Test kriteri
yazılmalıdır.
IDENTITY kolonları nasıl taşınır?
SQL Server'da IDENTITY, satır eklenirken otomatik sayısal değer üretir. PostgreSQL'de bunun doğal karşılığı identity column veya sequence tabanlı yapıdır.
PostgreSQL identity column şu mantıkla çalışır:
GENERATED ALWAYS AS IDENTITY
veya
GENERATED BY DEFAULT AS IDENTITY
Migration sırasında yalnız “kolon tipi doğru mu?” diye bakmayın. Şunları da kontrol edin:
- mevcut en yüksek ID
- sequence başlangıç değeri
- seed / increment davranışı
- application tarafından explicit ID yazılıyor mu?
- import sonrasında sequence değeri senkron mu?
- replication sırasında duplicate key riski var mı?
Özellikle bulk import sonrası sequence hedef tablodaki max ID'nin gerisinde kalırsa ilk yeni insert duplicate key hatası üretebilir.
uniqueidentifier nasıl karşılanır?
SQL Server uniqueidentifier 16 baytlık GUID tipidir. PostgreSQL tarafında doğal karşılık uuid tipidir.
Ancak yalnız veri tipini değiştirmek yeterli değildir.
Kontrol edin:
- NEWID / NEWSEQUENTIALID kullanılan yerler
- default constraint'ler
- string → GUID dönüşümleri
- application driver davranışı
- sorting beklentileri
- clustered index tasarımının PostgreSQL'de yeniden değerlendirilmesi
Özellikle SQL Server'da GUID primary key ile birlikte clustered index kullanılan yapılarda PostgreSQL index davranışı ayrı ölçülmelidir.
Computed column'lar PostgreSQL'e nasıl taşınır?
SQL Server computed column'lar PostgreSQL generated column ile karşılanabilir; ancak expression kuralları ve desteklenen davranışlar birebir aynı değildir.
Basit ve immutable expression'lar generated column için iyi adaydır.
Daha karmaşık senaryolarda alternatifler:
- generated column
- view
- materialized view
- trigger
- application-level calculation
olabilir.
Burada amaç “aynı sözdizimini bulmak” değil, aynı iş davranışını en güvenli şekilde üretmektir.
T-SQL stored procedure'ler neden migration'ın en zor kısmıdır?
Tablo şemaları çoğu zaman migration'ın kolay kısmıdır. Zor kısım veritabanının içinde biriken business logic'tir.
Riskli alanlar:
- T-SQL'e özgü built-in function'lar
- temporary table kullanımı
- table variable'lar
- TRY/CATCH yapıları
- dynamic SQL
- MERGE davranışı
- cursor
- XML işleme
- JSON function farkları
- transaction isolation varsayımları
- OUTPUT clause
- SQL Server-specific hints
- cross-database query
- linked server
AWS SCT gibi araçlar bazı SQL kodlarını çevirebilir; çevrilemeyen noktaları action item olarak bırakır. Bu action item'lar manuel inceleme gerektirir.
Stored procedure için karar ağacı
Her procedure için şu soruları sorun:
1. Gerçekten hâlâ kullanılıyor mu?
Kullanılmayan procedure'ü taşımak teknik borcu yeni motora kopyalamaktır.
2. İş mantığı veritabanında mı kalmalı?
Bazı logic PostgreSQL function/procedure olarak kalabilir.
3. Uygulama katmanına taşınmalı mı?
Bu karar uygulama ekibiyle verilmelidir.
4. Aynı transaction davranışı korunabiliyor mu?
Özellikle nested transaction beklentileri ayrıca test edilmelidir.
5. Performans planı aynı mı?
Aynı SQL ifadesi iki motorda farklı execution plan üretebilir.
Uygulama içine gömülü SQL'i unutmayın
Migration projelerinde yalnız database schema taranırsa en büyük sürprizlerden biri application code içinde çıkar.
Örnek:
SELECT TOP 10 ...
ISNULL(...)
GETDATE()
WITH (NOLOCK)
SCOPE_IDENTITY()
gibi SQL Server'a özgü kullanım noktaları uygulamanın içinde bulunabilir.
Assessment sırasında:
- repository içindeki raw SQL
- ORM custom query'leri
- migration script'leri
- reporting query'leri
- BI bağlantıları
- ETL script'leri
ayrı envantere alınmalıdır.
Dynamis bu noktaları belirleyip gerekli değişiklikleri dokümante eder. Uygulama kaynak kodundaki değişikliği müşteri geliştirme ekibi uygular.
Veri tiplerinde birebir dönüşüm neden risklidir?
Bazı tipler kolay görünür ama davranış farkı yaratabilir.
Tarih ve saat
SQL Server tarafında datetime, datetime2 ve datetimeoffset farklı precision ve timezone davranışına sahiptir.
PostgreSQL tarafında:
timestamp without time zonetimestamp with time zone
ayrımı vardır.
Migration öncesi şunu netleştirin:
- uygulama zamanı UTC mi tutuyor?
- local time mı tutuyor?
- offset verisi anlamlı mı?
- driver değeri nasıl deserialize ediyor?
- raporlar timezone'a göre mi çalışıyor?
Numeric ve money
Parasal verilerde numeric(p,s) precision/scale değerleri açıkça taşınmalıdır.
Floating-point tipe dönüştürmek finansal rounding hatası yaratabilir.
String ve collation
SQL Server collation ile PostgreSQL collation aynı kavramları birebir aynı şekilde uygulamaz.
Özellikle:
- case-insensitive arama
- Türkçe I / İ
- sort order
- accent sensitivity
- unique index davranışı
test edilmelidir.
Index'ler olduğu gibi taşınmalı mı?
Hayır.
SQL Server'daki index setini PostgreSQL'e birebir taşımak doğru yaklaşım değildir.
Önce:
- gerçekten kullanılan index'ler
- duplicate index'ler
- write overhead
- query pattern
- selective predicates
çıkarılmalıdır.
Sonra PostgreSQL'de:
- B-tree
- GIN
- GiST
- BRIN
- partial index
- expression index
gibi seçenekler workload'a göre değerlendirilmelidir.
Migration sonrası gerçek query plan'larına bakmadan “index'ler taşındı, performans tamam” denmemelidir.
SQL Agent Job'lar ne olacak?
SQL Agent job'lar veritabanı dışında kalan kritik migration kalemlerinden biridir.
Envantere ekleyin:
- backup job
- index maintenance
- ETL
- reporting export
- batch process
- scheduled cleanup
- replication support job
- notification
Hedefte karşılık:
- pg_cron
- Kubernetes CronJob
- systemd timer
- CI/CD scheduler
- Airflow / workflow orchestrator
olabilir.
Job'ları şema conversion aracının otomatik çözmesini beklemeyin.
Linked Server ve cross-database sorgular nasıl taşınır?
SQL Server ortamında linked server, synonym veya cross-database query varsa bu bağımlılıklar migration scope'unu büyütür.
Olası hedefler:
- PostgreSQL Foreign Data Wrapper
- API entegrasyonu
- ETL/ELT
- uygulama katmanı
- veri kopyalama
- ayrı integration service
Burada en önemli soru teknik karşılık değil, transaction ve latency beklentisidir.
Bir sorgu tek transaction içinde iki sistemden veri bekliyorsa basit bağlantı değişikliği yeterli olmayabilir.
SQL Server → PostgreSQL migration nasıl planlanmalı?
Sağlıklı proje sekiz aşamada ilerler.
1. Envanter
Çıkarın:
- database ve schema
- tablo boyutları
- growth rate
- procedure/function/trigger
- SQL Agent job
- linked server
- login/role
- dependency
- application connection
2. Conversion assessment
Otomatik dönüşen ve manuel iş isteyen nesneleri ayırın.
3. Pilot schema
Kritik olmayan bir schema veya sınırlı workload ile gerçek PostgreSQL hedefi oluşturun.
4. Data type ve code remediation
Action item'ları çözün.
5. İlk data load
Büyük veri setini cutover gününden önce taşıyın.
6. CDC / sürekli replikasyon
Uygun senaryoda kaynakta oluşan değişiklikleri hedefe aktararak farkı küçültün.
7. Validation
En az:
- row count
- checksum/hash
- kritik alan karşılaştırması
- referential integrity
- kritik transaction
- ağır sorgu performansı
kontrolü yapın.
8. Cutover ve hypercare
Write trafiğini planlanan pencerede durdurun, son farkı aktarın, connection string'i değiştirin ve başarı kriterlerini doğrulayın.
Sorun varsa önceden yazılan rollback kriterini uygulayın.
Cloud migration sırasında downtime nasıl minimuma indirilir? rehberi full copy, sürekli replikasyon ve cutover mantığını daha geniş migration senaryolarıyla ele alır.
CDC kullanmak her zaman mümkün mü?
Hayır.
CDC/replikasyon seçimi:
- kaynak SQL Server sürümü
- target
- network
- transaction volume
- kullanılan migration aracı
- unsupported data type
- LOB veri
- schema change ihtiyacı
gibi faktörlere bağlıdır.
Bu yüzden önce küçük pilotta throughput ve lag ölçülmelidir.
“CDC var, downtime sıfır” gibi bir varsayım yapılmamalıdır.
Veri doğrulaması nasıl yapılmalı?
Migration tamamlandı demek uygulamanın açılması değildir.
Önerilen validation katmanları:
Row count
Kaynak ve hedef tablo satır sayılarını karşılaştırın.
Checksum / hash
Kritik kolonlardan deterministik hash üretip toplu veya parça bazlı karşılaştırın.
Field-level sampling
Finansal ve kimlik alanlarını örnekleyin.
Referential integrity
Foreign key ve orphan kayıt kontrolleri yapın.
Business transaction
Gerçek kritik akışları çalıştırın.
Örneğin:
- sipariş oluşturma
- fatura yazma
- login
- ödeme kaydı
- rapor üretme
Performance
En ağır ve kritik sorguların execution plan ve latency değerlerini hedefte ölçün.
Bu doğrulama katmanları bir sonraki içerik olan CDC ile veri doğrulama rehberinin ana konusu olacak.
Cutover'dan önce rollback kriteri neden yazılmalı?
Rollback kararı incident sırasında verilmemelidir.
Örnek kriterler:
- replication lag belirlenen eşiğin üstünde
- kritik tablo validation farkı var
- kritik transaction başarısız
- p95 latency kabul sınırının dışında
- error rate belirlenen eşiği aşıyor
Bu kriterler yazılıysa ekip “devam mı, geri mi?” tartışmasını cutover gecesi yapmaz.
Cloud Migration Checklist genel cutover hazırlığını; migration wave planı ise bağımlılıklara göre taşıma sırasını ayrıca ele alır.
SQL Server lisansı migration kararını etkiler mi?
Evet.
SQL Server'dan PostgreSQL'e geçişin gerekçesi yalnız lisans maliyeti olmamalıdır; fakat lisans ve altyapı TCO'su kararın bir parçasıdır.
Karşılaştırın:
- mevcut SQL Server edition
- core sayısı
- HA topolojisi
- Software Assurance veya mevcut haklar
- SPLA senaryosu
- PostgreSQL operasyon maliyeti
- DBA/engineering eforu
- migration maliyeti
- uygulama değişikliği maliyeti
Bazı workload'larda SQL Server'da kalmak daha düşük riskli ve ekonomik olabilir.
Ama lisans maliyeti yüksek, T-SQL bağımlılığı sınırlı ve uygulama uzun ömürlü ise PostgreSQL güçlü aday olabilir.
Hangi nesneler önce incelenmeli?
Öncelik sırası:
- Stored procedure / function
- Trigger
- Linked server
- SQL Agent job
- Uygulama içine gömülü T-SQL
- SQL Server'a özgü veri tipleri
- Computed column / indexed view
- Cross-database query
- CLR veya external integration
- Reporting/BI dependency
Bunlar azsa migration çoğunlukla daha öngörülebilir olur.
Dynamis'te SQL Server → PostgreSQL yaklaşımı
Dynamis'in Database Migration hizmetinde ilk görüşmede doğrudan cutover tarihi vermiyoruz.
Önce:
- instance ve database envanteri
- schema object'leri
- SQL Server'a özgü özellikler
- ağır sorgular
- uygulama bağımlılıkları
- backup/restore durumu
- veri boyutu ve büyüme
- acceptable downtime
çıkarılır.
Ardından pilot PostgreSQL ortamında:
- schema conversion
- veri tipi kontrolü
- procedure/function action item'ları
- query plan karşılaştırması
- ilk restore/load
- validation yöntemi
doğrulanır.
Sonra gerçek cutover planı çıkar.
Amaç SQL Server'ı ne pahasına olursa olsun PostgreSQL'e taşımak değildir. Amaç, uygulama davranışını, veri bütünlüğünü ve geri dönüş seçeneğini koruyarak doğru motor kararını vermektir.
Sık yapılan hatalar
Yalnız tabloları taşımak: Stored procedure, job, linked server ve application SQL bağımlılıklarını unutmayın.
Otomatik conversion yüzdesini başarı oranı sanmak: Otomatik dönüşen nesneler de functional ve performance test gerektirir.
Uygulama kodunu geç incelemek: Raw T-SQL ve ORM custom query'leri erken tarayın.
Index'leri birebir kopyalamak: Hedef motorun planner ve index seçeneklerine göre yeniden değerlendirin.
Timezone davranışını varsaymak: datetime/datetimeoffset → timestamp/timestamptz mapping'ini gerçek uygulama davranışıyla test edin.
CDC varsa downtime yok sanmak: Final cutover, validation ve connection switch yine plan ister.
Rollback'i backup ile karıştırmak: Backup recovery ile migration rollback aynı operasyon değildir.
Sırada ne var
- Database migration hizmeti: SQL Server, PostgreSQL ve diğer database migration projeleri için assessment ve cutover planını inceleyin.
- Cloud Migration Checklist: migration öncesi envanter, backup, network, test ve rollback hazırlığını doğrulayın.
- Cloud migration sırasında downtime nasıl minimuma indirilir?: full load, replikasyon ve kontrollü cutover yaklaşımını inceleyin.
- Cloud migration strategy: rehost, replatform ve refactor: database migration'ın daha geniş workload stratejisindeki yerini belirleyin.
- Bulut göçü sırası: migration wave planı: uygulama ve database bağımlılıklarını aynı wave içinde planlayın.
Kaynaklar
Kaynaklar
- 1.Migrating from SQL Server to PostgreSQL with AWS Schema Conversion ToolAmazon Web Services · 2026-09-25
- 2.Using the assessment report in AWS Schema Conversion ToolAmazon Web Services · 2026-09-25
- 3.Assessment report action itemsAmazon Web Services · 2026-09-25
- 4.Converting SQL code in applications with AWS SCTAmazon Web Services · 2026-09-25
- 5.PostgreSQL Identity ColumnsPostgreSQL Global Development Group · 2026-09-25
- 6.PostgreSQL Generated ColumnsPostgreSQL Global Development Group · 2026-09-25
- 7.uniqueidentifier (Transact-SQL)Microsoft Learn · 2026-09-25
- 8.Date and Time Data Types and FunctionsMicrosoft Learn · 2026-09-25
Sık sorulan sorular
SQL Server'dan PostgreSQL'e uygulama kodunu değiştirmeden geçilebilir mi?
Bazı uygulamalarda değişiklik sınırlı kalabilir; ancak T-SQL'e, SQL Server'a özgü veri tiplerine, stored procedure'lere, linked server'lara veya SQL Server'a özgü sürücü ve sorgu davranışlarına bağımlılık varsa uygulama tarafında uyarlama gerekebilir. Dynamis bu bağımlılıkları assessment aşamasında çıkarır ve gerekli değişiklikleri dokümante eder; müşteri uygulamasının kaynak kodunda değişiklik yapmaz.
SQL Server stored procedure'leri PostgreSQL'e otomatik çevrilebilir mi?
Bazı stored procedure, function, view ve veri tipi dönüşümleri araçlarla otomatik veya yarı otomatik yapılabilir. Ancak T-SQL'e özgü sözdizimi, EXEC ile sonuç kümesi işleme, SQL Server'a özgü fonksiyonlar, transaction davranışı veya external dependency içeren nesneler manuel uyarlama gerektirebilir. Otomatik dönüşüm çıktısı production'a alınmadan önce kod incelemesi ve fonksiyonel test yapılmalıdır.
SQL Server'dan PostgreSQL'e geçişte ne kadar kesinti gerekir?
Kesinti süresi veritabanı boyutundan çok replikasyon yöntemi, yazma trafiği, doğrulama süresi ve uygulamanın bağlantı değiştirme sürecine bağlıdır. Uygun senaryolarda ilk veri kopyası önceden tamamlanır, değişiklikler CDC veya benzeri sürekli replikasyonla hedefe aktarılır ve final cutover sırasında yalnız son fark senkronize edilir. Kesinti hedefi discovery ve prova cutover sonrasında netleştirilmelidir.
SQL Server identity ve computed column yapıları PostgreSQL'de nasıl karşılanır?
SQL Server IDENTITY kolonları PostgreSQL identity column veya sequence tabanlı yapılarla karşılanabilir. Computed column'lar ise PostgreSQL generated column, view veya uygulama/veritabanı mantığıyla yeniden tasarlanabilir. İki motorun kısıtları birebir aynı olmadığı için otomatik eşleme yapılmadan önce expression, veri tipi, index ve write davranışı incelenmelidir.
Database migration sonrası verinin doğru taşındığı nasıl doğrulanır?
Doğrulama yalnız toplam satır sayısına bakılarak yapılmamalıdır. Kritik tablolarda row count, checksum veya hash karşılaştırması, alan bazlı örnekleme, referential integrity kontrolleri ve uygulama seviyesinde kritik transaction testleri birlikte kullanılmalıdır. Cutover kararı, önceden belirlenen veri farkı ve uygulama başarı kriterleri sağlandıktan sonra verilmelidir.