İÇİNDEKİLER
- •PostgreSQL'e geçiş sizin için uygun mu?
- •Kısaca: Geçiş Kararı
- •Neden PostgreSQL’e Geçiliyor?
- •Gerçek Maliyet: Lisans Tasarrufu ve Geçiş Bedeli
- •Risk: Teknik Farklar
- •SQL Server’dan gelenler için
- •Oracle’dan gelenler için
- •Uygunluk Analizi: Geçiş Ne Kadar Zor?
- •Geçiş Araçları
- •Geçiş Aşamaları
- •Ne Zaman Geçmemelisiniz?
- •Aryasoft ile PostgreSQL’e Geçiş
- •Sıkça Sorulan Sorular
- •Kaynaklar
- •Geçiş kararınızı veriye dayandırın
Oracle veya SQL Server’dan PostgreSQL’e geçiş, lisans maliyetini ortadan kaldırabilecek stratejik bir karardır; ancak asıl maliyet veri aktarımında değil, kodun dönüştürülmesinde ve testlerdedir. Geçişin uygun olup olmadığını üç faktör belirler: uygulamanın kime ait olduğu (paket yazılım mı, kendi geliştirmeniz mi), veritabanına özgü kod miktarı (stored procedure, trigger, paket) ve kesinti toleransı. Bu yazıda geçiş kararını maliyet, risk ve uygunluk açısından nasıl değerlendireceğinizi anlatıyoruz.
Rehber; lisans yenileme, bulut stratejisi veya modernizasyon nedeniyle PostgreSQL’e geçişi değerlendiren BT yöneticileri, mimarlar ve yazılım ekipleri için hazırlandı.
PostgreSQL'e geçiş sizin için uygun mu?
Aryasoft, Oracle ve SQL Server ortamlarınızı envanter ve uyumluluk analiziyle değerlendirir; geçişin maliyetini, riskini ve takvimini veriye dayalı olarak ortaya koyar.
Kısaca: Geçiş Kararı
| Durum | Değerlendirme |
|---|---|
| Kendi geliştirdiğiniz uygulama, az veritabanı kodu | Güçlü aday. Geçiş büyük ölçüde veri aktarımı ve test işidir. |
| Kendi uygulamanız, yoğun stored procedure ve paket kodu | Mümkün, ancak kod dönüşümü projenin en büyük kalemidir; ayrıntılı analiz şart. |
| Paket yazılım (ERP, CRM vb.) | Yalnızca üretici PostgreSQL’i resmi olarak destekliyorsa. Aksi halde geçmeyin. |
| Yoğun Oracle’a özgü özellikler (RAC, Advanced Queuing, Spatial vb.) | Her özellik için PostgreSQL karşılığı ayrıca değerlendirilmeli; bazıları mimari değişiklik gerektirir. |
| Ekipte PostgreSQL deneyimi yok | Geçişten önce operasyon modelini netleştirin: eğitim, dış destek veya ikisi birden. |
Neden PostgreSQL’e Geçiliyor?
- Lisans maliyeti: PostgreSQL’in lisans bedeli yoktur ve özellikler edition’a göre kısıtlanmaz. Çekirdek sayısı arttıkça ticari lisans maliyeti hızla büyüdüğü için tasarruf, büyük ortamlarda belirgin olur.
- Üretici bağımsızlığı: Fiyat ve lisans politikası değişikliklerinden etkilenmezsiniz.
- Bulut taşınabilirliği: Aynı veritabanı kendi veri merkezinizde, Azure’da, AWS’de veya Google Cloud’da çalışır.
- Modern yetenekler: JSON, coğrafi veri (PostGIS) ve vektör arama (pgvector) aynı veritabanında kullanılabilir.
PostgreSQL’i ilk kez değerlendiriyorsanız PostgreSQL Nedir? rehberimizle başlayabilirsiniz.
Gerçek Maliyet: Lisans Tasarrufu ve Geçiş Bedeli
Geçiş kararı, lisans tasarrufu ile geçiş ve işletim maliyetinin karşılaştırılmasıyla verilmelidir.
| Kalem | Açıklama |
|---|---|
| Lisans tasarrufu | Mevcut lisans ve yazılım güvencesi (Software Assurance, Oracle destek) bedelleri; gelecekteki çekirdek artışları |
| Kod dönüşümü | Stored procedure, fonksiyon, trigger, paket ve uygulama içindeki SQL’in yeniden yazılması; genellikle en büyük kalem |
| Test | Fonksiyonel testler, performans testleri, veri doğrulama; projenin önemli bir bölümü |
| Veri aktarımı | Araçlar, geçiş süresi, kesinti |
| Ekip ve operasyon | Eğitim, yeni izleme ve yedekleme araçları, PostgreSQL deneyimli DBA veya dış destek |
| Paralel çalışma | Geçiş döneminde iki sistemin birlikte işletilmesi |
Not
Geri ödeme süresini hesaplarken lisans tasarrufunu yıllık, geçiş maliyetini tek seferlik düşünün. Kod miktarı az ve lisans maliyeti yüksek ortamlarda geçiş kısa sürede kendini amorti eder; yoğun prosedürel kod içeren küçük ortamlarda ise geri ödeme süresi uzayabilir.
Risk: Teknik Farklar
Geçiş projelerinde sürprizlerin çoğu, veritabanlarının aynı görünen ama farklı davranan özelliklerinden çıkar.
SQL Server’dan gelenler için
| Konu | SQL Server | PostgreSQL |
|---|---|---|
| Harf duyarlılığı | Varsayılan collation’lar harfe duyarsız | Metin karşılaştırması varsayılan olarak harfe duyarlı |
| Nesne adları | Büyük/küçük harf korunur, köşeli parantez | Tırnaksız adlar küçük harfe çevrilir; tırnaklı adlar harfe duyarlı olur |
| Prosedürel dil | T-SQL | PL/pgSQL; söz dizimi ve hata yönetimi farklı |
| Otomatik artan anahtar | IDENTITY | GENERATED AS IDENTITY veya sequence |
| Sorgu söz dizimi | TOP, ISNULL, GETDATE(), + ile metin birleştirme | LIMIT, COALESCE, now(), || ile metin birleştirme |
| Geçici tablolar | #temp tabloları | CREATE TEMP TABLE; oturum kapsamı farklı |
| DDL ve işlemler | Çoğu DDL işlem içinde çalışır | DDL tamamen işlem içinde çalışır ve geri alınabilir |
Oracle’dan gelenler için
| Konu | Oracle | PostgreSQL |
|---|---|---|
| Boş metin ve NULL | Boş metin (”) NULL kabul edilir | Boş metin ve NULL farklıdır; mantık hataları en sık buradan çıkar |
| DATE tipi | Tarih ve saat içerir | date yalnızca tarih içerir; karşılığı genellikle timestamp(0) |
| NUMBER | Tek tip sayı | Kullanıma göre integer, bigint veya numeric seçilmeli; performansı etkiler |
| Paketler (package) | Var | Yok; şema ve fonksiyon gruplarıyla yeniden tasarlanır |
| Hiyerarşik sorgular | CONNECT BY | Recursive CTE (WITH RECURSIVE) |
| Otonom işlemler | PRAGMA AUTONOMOUS_TRANSACTION | Doğrudan karşılığı yok; mimari çözüm gerekir |
| Optimizer ipuçları | Hint’ler yaygın | Yerleşik hint mekanizması yok; sorgular ve indeksler yeniden ele alınır |
Uyarı
Oracle’dan geçişte en sinsi hata kaynağı boş metin ile NULL arasındaki farktır. Oracle’da WHERE kolon IS NULL boş metinleri de bulurken PostgreSQL’de bulmaz. Uygulama hata vermeden yanlış sonuç üretebilir; bu yüzden veri doğrulama testleri yalnızca satır sayısını değil, iş kurallarını da kontrol etmelidir.
Uygunluk Analizi: Geçiş Ne Kadar Zor?
Aşağıdaki tablo, bir veritabanının geçiş karmaşıklığını kabaca tahmin etmenize yardımcı olur. Birden fazla “yüksek” işaretiniz varsa ayrıntılı bir değerlendirme yapılmadan takvim ve bütçe verilmemelidir.
| Faktör | Düşük | Orta | Yüksek |
|---|---|---|---|
| Veritabanı kodu | Az sayıda basit prosedür | Yüzlerce prosedür ve fonksiyon | Binlerce satır prosedürel kod, paketler |
| Veritabanına özgü özellikler | Standart SQL | Bazı özel fonksiyonlar | Platforma özgü özelliklere derin bağımlılık |
| Uygulama içi SQL | ORM ile üretilen standart sorgular | Karışık | Elle yazılmış, platforma özgü söz dizimi |
| Veri boyutu | Birkaç yüz GB | Birkaç TB | On TB ve üzeri |
| Kesinti toleransı | Hafta sonu kesintisi kabul | Birkaç saat | Dakikalar |
| Entegrasyonlar | Tek uygulama | Birkaç uygulama | Çok sayıda sistem, ETL, raporlama |
Geçiş Araçları
| Araç | Ne işe yarar? |
|---|---|
| ora2pg | Oracle şemasını ve kodunu analiz eder, dönüştürür ve karmaşıklık raporu üretir; açık kaynak |
| pgloader | SQL Server ve MySQL’den PostgreSQL’e veri aktarımı; açık kaynak |
| AWS Schema Conversion Tool ve AWS DMS | Şema dönüşümü ve sürekli veri replikasyonu; AWS hedefleri için |
| Azure Database Migration Service | Azure Database for PostgreSQL’e geçiş senaryoları |
| Babelfish | PostgreSQL üzerinde T-SQL uyumluluk katmanı; SQL Server uygulamalarının daha az değişiklikle çalışmasını hedefler |
| Logical replication / CDC araçları | Geçiş sırasında kaynak ile hedefi senkron tutarak kesintiyi kısaltır |
Araçlar şema ve veri aktarımının büyük kısmını otomatikleştirir; ancak prosedürel kodun dönüşümü ve iş mantığının doğrulanması her zaman uzman incelemesi gerektirir. Araç raporlarındaki “otomatik dönüştürüldü” ifadesi, kodun doğru çalıştığı anlamına gelmez.
Geçiş Aşamaları
| Aşama | Yapılanlar | Çıktı |
|---|---|---|
| 1. Keşif | Veritabanı, kod, entegrasyon ve kullanıcı envanteri | Envanter ve kapsam |
| 2. Uyumluluk analizi | Araç raporları, elle kod incelemesi, karmaşıklık puanı | Maliyet ve takvim tahmini, karar |
| 3. Dönüşüm | Şema, veri tipleri, prosedürel kod ve uygulama SQL’inin dönüştürülmesi | Çalışan bir PostgreSQL şeması |
| 4. Veri aktarımı ve senkronizasyon | İlk yükleme, ardından değişikliklerin sürekli aktarılması | Senkron hedef sistem |
| 5. Test | Fonksiyonel, performans ve veri doğrulama testleri; paralel çalışma | Kabul raporu |
| 6. Geçiş (cutover) | Yazmaların durdurulması, son senkronizasyon, uygulamanın yönlendirilmesi | Canlı PostgreSQL |
| 7. Stabilizasyon | İlk haftalarda yoğun izleme, performans ayarları, geri dönüş seçeneğinin korunması | Kararlı üretim ortamı |
Kesintiyi en aza indiren geçiş yöntemlerini ve geri dönüş planını minimum kesintiyle taşıma rehberimizde anlattık. Geçişten sonra PostgreSQL’i production’da güvenle işletmek için PostgreSQL Best Practices ve yüksek erişilebilir PostgreSQL ortamı kurulumu yazılarımıza göz atabilirsiniz.
Ne Zaman Geçmemelisiniz?
- Uygulama üreticisi PostgreSQL’i resmi olarak desteklemiyorsa. Desteklenmeyen bir veritabanında çalışan paket yazılım, güncelleme ve destek hakkınızı riske atar.
- Geçişin tek gerekçesi kısa vadeli bir lisans yenilemesiyse ve kod dönüşümü bu süreye sığmıyorsa.
- Ekibin PostgreSQL’i işletecek bir planı yoksa. Lisans tasarrufu, kesintilerin maliyetiyle kolayca silinebilir.
İpucu
Büyük ve karmaşık ortamlarda her şeyi tek seferde taşımak yerine, yeni geliştirilen uygulamaları PostgreSQL’de başlatmak ve mevcut sistemleri riskine göre sırayla taşımak daha güvenli bir yoldur.
Aryasoft ile PostgreSQL’e Geçiş
Aryasoft; SQL Server, Oracle ve PostgreSQL’de kıdemli uzmanlığa sahip bir ekiple geçiş projelerini envanter ve risk analiziyle başlatır. Karmaşıklık analizinin sonucunda, geçişin sizin için mantıklı olup olmadığını da açıkça söyleriz. Geçiş kararı verilirse dönüşüm, test, kesintisi en aza indirilmiş geçiş ve sonrasındaki stabilizasyon dönemini birlikte yürütürüz. Ayrıntılar veritabanı taşıma hizmetleri ve PostgreSQL hizmetleri sayfalarımızda.
Sıkça Sorulan Sorular
Kaynaklar
Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki kaynaklarla karşılaştırıldı.
- PostgreSQL dokümantasyonu: Porting from Oracle PL/SQL
- PostgreSQL dokümantasyonu: Data Types
- PostgreSQL dokümantasyonu: WITH Queries (Common Table Expressions)
- Ora2Pg
- pgloader dokümantasyonu
- Babelfish for PostgreSQL
- Microsoft Learn: Migration service in Azure Database for PostgreSQL
- AWS Schema Conversion Tool
PostgreSQL Geçişi
Geçiş kararınızı veriye dayandırın
Aryasoft, Oracle ve SQL Server ortamlarınızı analiz eder; geçişin maliyetini, riskini ve takvimini ortaya koyar ve geçişi yazılı bir geri dönüş planıyla yürütür.
