MongoDB ve PostgreSQL: 2026'da Doğru Veritabanını Seçmek

Bu karşılaştırmaya nasıl yaklaşmalı

İş yükünüzde ilişkiler, kısıtlar, işlemler ve esnek raporlama ağır basıyorsa PostgreSQL'i seçin. İşlemlerin çoğu alanları önemli ölçüde değişen, sınırlı ve kendi kendine yeterli belgeleri okuyup güncelliyorsa MongoDB'yi seçin. Hiçbir motor her koşulda daha hızlı veya daha basit değildir.

Özellik listesinden önce uygulamadan başlayın. İkisi de API üzerinden JSON sunsa bile bir faturalama sisteminin hata koşulları, içerik kataloğundan farklıdır. Veritabanı, uygulamanın en zor işlemlerini sadece mümkün kılmamalı, sıradan hale getirmelidir.

Her iki seçeneği şu beş somut soruyla değerlendirin:

• Hangi kayıtlar tek işlemde birlikte değişmeli?
• Hangi sorgular varlık sınırlarını aşıyor ve ne sıklıkla değişiyor?
• Uygulama kodu başarısız olsa bile hangi kurallar geçerli kalmalı?
• Tek bir mantıksal kayıt ne kadar büyüyebilir, alt koleksiyonu sınırsız büyüyebilir mi?
• Veritabanını kim işletecek, geri yükleyecek, ayarlayacak ve olaylara müdahale edecek?

PostgreSQL çoğunlukla SaaS hesapları, izinler, siparişler, faturalama, envanter, denetim kayıtları, CRM'ler ve ERP'ler için daha düşük riskli varsayılandır. Bu alanlarda tablolar, yabancı anahtarlar, benzersizlik kısıtları ve SQL ile uyumlu çoktan çoğa ilişkiler ve değişmez kurallar bulunur.

MongoDB; içerik girdileri, kiracıya özgü özellikleri olan ürün kayıtları, yapılandırma belgeleri, olay yükleri ve normalde tek nesne olarak getirilen diğer toplam kayıtlar için sıkça uygundur. Esnek belge yapısı ilk uygulamayı kısaltabilir, ancak ekip şema gelişimini yine de kontrol etmelidir.

Her veritabanının açıkça ayrılmış bir alana sahip olduğu durumlarda ikisini birlikte kullanmak mantıklıdır. Sınır belirsizse maliyetlidir. İki depo, iki yedekleme sistemi, iki izleme modeli, iki güvenlik yapılandırması ve bir eşitleme mekanizması demektir. Bu maliyeti, tek bir veritabanı sürekli bir modelleme veya ölçekleme sorunu yaratıyorsa üstlenin.

Veri modeli: belgeler mi ilişkisel tablolar mı?

MongoDB sınırlı toplam kayıtlar olarak saklanabilen verilere, PostgreSQL ise değeri bağımsız değişen varlıklar arasındaki ilişkilere bağlı verilere uygundur. Bu fark JSON ve satırlar arasındaki farktan daha derindir, çünkü tutarlılık kurallarının nerede yaşayacağını belirler.

Bir MongoDB siparişi teslimat adresini ve satır kalemlerini gömebilir:

{
  "_id": "order_1042",
  "customerId": "customer_28",
  "status": "paid",
  "shippingAddress": {
    "city": "Austin",
    "country": "US"
  },
  "items": [
    { "productId": "product_7", "quantity": 2, "unitPrice": 19.95 }
  ]
}

Dizinli tek bir arama, siparişin tamamını döndürebilir. Tek güncelleme de siparişi ve gömülü kalemlerini atomik olarak değiştirebilir. Bu parçalar aynı yaşam döngüsünü paylaşıyorsa ve dizi sınırlı kalıyorsa çekicidir.

Benzer PostgreSQL modeli, bağımsız anlam taşıyan bilgileri ayırır:

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint NOT NULL REFERENCES customers(id),
    status text NOT NULL,
    placed_at timestamptz NOT NULL
);

CREATE TABLE order_items (
    order_id bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12, 2) NOT NULL CHECK (unit_price >= 0),
    PRIMARY KEY (order_id, product_id)
);

Bu model, siparişler arası raporlamayı ve ürün ilişkilerini doğrudan kurar. Veritabanı, siparişi veya ürünü bulunmayan bir kalemi reddedebilir. Ayrıca ürünü bağımsız olarak değiştirmeye izin verirken satın alma anındaki fiyatı korur.

Bir hesabın ürettiği tüm olaylar gibi sınırsız koleksiyonlarda gömme kötü bir seçimdir. Büyüyen tek belge yazma noktası haline gelir, daha fazla bant genişliği tüketir ve sonunda MongoDB'nin 16 MiB belge sınırına ulaşır. Bu olayları ayrı belgeler olarak saklayın.

Normalleştirme de aşırıya kaçabilir. Küçük bir değer nesnesini birçok tabloya bölmek, yararlı bir bağımsızlık yaratmadan birleştirmeler ekler. Tamamlanmış sipariş için kaydedilen teslimat adresi genellikle müşterinin mevcut adresine canlı bir başvuru değil, geçmişe ait bir anlık kayıttır.

Kalıcı bir modelleme kuralı şudur: birlikte değişen ve sınırlı kalan veriyi gömün. Bağımsız değişen, birçok ilişkiye katılan veya öngörülebilir üst sınırı olmadan büyüyen veriye başvuru verin ya da normalleştirin.

Şema gelişimi ve veri bütünlüğü

MongoDB alan eklemeyi kolaylaştırırken PostgreSQL tutarlı bir biçimi zorlamayı kolaylaştırır. Üretim güvenliği her iki sistemde de disiplinli geçişlere bağlıdır.

MongoDB koleksiyonları farklı alan ve türlerde belgeler içerebilir. Bu esneklik, özellikler kiracıya veya içerik türüne göre değiştiğinde işe yarar; ancak aynı kavramın birbiriyle uyumsuz birçok sürümünü de doğurabilir. Yeniden adlandırılan bir alan eski belgelerde kalabilir ve her okuyucunun geri dönüş mantığına ihtiyacı olur.

MongoDB, JSON Schema tarzı kurallarla koleksiyon doğrulamasını destekler. Ekipler doğrulamayı aşamalı olarak ekleyebilir, mevcut belgeleri doldurabilir, ardından seçilen biçimi ihlal eden yeni yazmaları reddedebilir. Şema sürümü alanı, çalışanların eski belgeleri öngörülebilir şekilde geçirmesine yardımcı olabilir, ancak doğrulamanın yerini tutmaz.

PostgreSQL değişiklikleri açıktır. Ekipler genellikle boş değer alabilen bir sütun ekler, gerektiğinde hem eski hem yeni biçime yazan kodu dağıtır, veriyi kontrollü gruplar halinde doldurur, doğrular ve sonra daha katı kısıtlar ekler. Büyük dizinler yazmaları daha az kesintiye uğratmak için eşzamanlı oluşturulabilir. Yabancı anahtarlar ve bazı kısıtlar da tam doğrulamadan önce aşamalı getirilebilir.

Motor ifade edebiliyorsa, yararlı değişmez kurallar veritabanına aittir:

• Kimlikler, idempotency belirteçleri ve sahip başına tek kayıt için benzersizlik kısıtları kullanın.
• Asla kayıp veriye işaret etmemesi gereken ilişkiler için yabancı anahtar kullanın.
• Pozitif miktar gibi yerel kurallar için CHECK kısıtları kullanın.
• Uzak servis veya sık değişen politika gerektiren bağlamsal kurallar için uygulama doğrulaması kullanın.
• Desteklenen her şema sürümünden geçiş yolunu doğrulamak için test kullanın.

Yararlı hata mesajları ve iş akışları için uygulama doğrulaması gereklidir. Veritabanı kısıtları; yarış koşullarına, unutulmuş kod yollarına, yönetim betiklerine ve aynı veriyi yazan gelecekteki servislere karşı son engeldir.

Esnek şema, bilinmeyen değişkenlik değil, kontrollü değişkenlik demektir. Daha hızlı yineleme için MongoDB'yi seçmeden önce belge biçiminden kimin sorumlu olduğunu, uyumsuz değişikliklerin nasıl tespit edileceğini ve eski belgelerin ne zaman yeniden yazılacağını tanımlayın.

Sorgulama, birleştirmeler ve raporlama

PostgreSQL değişen, varlıklar arası sorular için daha doğrudandır. MongoDB ise sorgu tek belgenin sınırını izlediğinde kısadır. Ürün raporlama gereksinimleri biriktikçe sorgu kullanım kolaylığı daha önemli olur.

SQL bildirimsel bir dildir. Filtreler, birleştirmeler, gruplama, ortak tablo ifadeleri, pencere işlevleri, alt sorgular ve küme işlemleri saklanan modeli değiştirmeden birleştirilebilir. PostgreSQL planlayıcısı istatistiklerden ve kullanılabilir dizinlerden birleştirme algoritmalarını ve erişim yollarını seçer.

Normalleştirilmiş sipariş verilerinde gelir sorgusu okunaklı kalır:

SELECT
    o.customer_id,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.status = 'paid'
  AND o.placed_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;

MongoDB basit getirme işlemleri için doğrudan bulma, dönüşümler için toplama işlem hattı kullanır. Gömülü satır kalemleriyle benzer hesaplama, belgeleri sıralı aşamalardan geçirir:

db.orders.aggregate([
  { $match: { status: "paid", placedAt: { $gte: startDate } } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$customerId",
      revenue: { $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] } }
    }
  },
  { $sort: { revenue: -1 } }
])

İşlem hattı güçlüdür, ancak aşama sırası anlamı ve kaynak kullanımını etkiler. Büyük diziler, $unwind sonrası çalışma kümesini çoğaltabilir. Erken filtreleme ve projeksiyon bu maliyeti düşürür.

MongoDB'nin $lookup özelliği başka bir koleksiyondan belgeleri birleştirir. Birleştirilen taraf dizinliyse ve sonuç küçük kalıyorsa seçili ilişkiler için faydalıdır. Yaygın isteklerde birçok $lookup aşamasına ihtiyaç duyan model, sınırlarının ilişkisel olabileceğine işaret eder.

PostgreSQL, iş zekâsı, finans raporları, kohort analizi ve plansız sorular için genellikle daha kolaydır, çünkü raporlama araçlarının çoğu SQL konuşur. MongoDB raporlaması, boyutlar zaten birlikte yaşıyorsa veya hazırlanmış okuma modeli rapora uyuyorsa iyi çalışır. Sık plansız analiz yapan ekipler, ana veritabanından bağımsız olarak operasyonel veriyi çoğu zaman veri ambarına aktarır.

Nesne eşleme bu farkları ortadan kaldırmaz. ORM, PostgreSQL satırlarını nesne gibi hissettirebilir; nesne belge eşleyicisi MongoDB belgelerine sınıflar dayatabilir. Saklanan ilişkiler, dizinler ve bütünlük kuralları yük altındaki davranışı yine belirler.

İşlemler ve eşzamanlılık

PostgreSQL çok satırlı ve çok tablolı işlemler için en doğal modeli sunar. MongoDB tek belge değişiklikleri için en düşük maliyetli atomik sınırı verir ve gerektiğinde daha geniş işlemleri destekler. Doğru seçim, eşzamanlı isteklerde korunması gereken değişmez kurallara bağlıdır.

PostgreSQL çok sürümlü eşzamanlılık denetimi kullanır. Sıradan okumalar ve yazmalar eşzamanlı ilerleyebilir; ancak satır kilitleri, açık kilitler, uzun işlemler ve şema değişiklikleri bekleme yaratabilir. Varsayılan yalıtım düzeyi Read Committed'dır. Repeatable Read kararlı bir işlem anlık görüntüsü sağlar, Serializable ise güvenle sıralanamayan çalıştırmaları tespit eder.

MongoDB'de tek belgeyi değiştiren işlemler atomiktir. Bu nedenle sınırlı bir toplam kaydı gömmek koordinasyonu azaltır. MongoDB, replica set'lerde ve parçalanmış kümelerde ACID çok belgeli işlemleri de destekler. Bu işlemler koordinasyon ekler, süreleri boyunca kaynak tutar ve uygulamanın tüm işlemi yeniden denemesini gerektiren geçici hatalar üretebilir.

MongoDB read concern, write concern ve read preference ayarlarını ayrı sunar. Bu ayarlar bir okumanın hangi veriyi görebileceğini, kaç replica set üyesinin yazmayı onaylaması gerektiğini ve okumaların ikincil üyelere gidip gidemeyeceğini etkiler. Bunları gecikme denetlerinden önce doğruluk ayarları olarak ele alın.

Hiçbir veritabanı dış ödeme sağlayıcısını yerel veritabanı işlemine dahil edemez. Ağ isteği yapılırken işlemi açık tutmak çekişmeyi artırır ve iki sistemin atomik biçimde onay vermesini yine sağlayamaz. Daha güvenli ödeme akışı, beklemedeki siparişi ve outbox olayını tek veritabanı işleminde kaydeder; dış isteği idempotent olarak işler, ardından sonucu kaydeder.

Eşzamanlılık testleri yalnızca başarılı istekleri değil, iş yarışlarını hedeflemelidir. Son ürünü ayırmaya çalışan iki alıcı, aynı işi almaya çalışan iki çalışan veya aynı benzersiz adı atayan iki yönetici buna örnektir. PostgreSQL bu işlemleri genellikle kısıtlar, satır kilitleri veya atomik ifadelerle ifade eder. MongoDB koşullu güncellemeler, benzersiz dizinler ve işlemler kullanabilir.

Katı kurallar bağımsız saklanan birçok kayda yayılıyorsa PostgreSQL genellikle daha az uygulama koordinasyonu ister. Her kural iyi tasarlanmış tek belgeye sığıyorsa MongoDB'nin atomik belge işlemleri basit ve etkilidir.

Orta yol olarak PostgreSQL JSONB

PostgreSQL JSONB, sınırlı sayıda gelişen özelliğin kararlı ilişkisel alanları çevrelediği durumlarda güçlü bir seçenektir. Belge biçimli her sorunu ilişkisel hale getirmez, ancak ikinci veritabanı ihtiyacını ortadan kaldırabilir.

Yaygın tasarım; kimliği, sahipliği, durumu ve zaman damgalarını türü belirli sütunlarda saklar, isteğe bağlı özellikleri jsonb içine koyar. Yabancı anahtarlar ilişkileri korur, normal dizinler sık filtreleri destekler, GIN veya ifade dizinleri seçilmiş JSON koşullarını hızlandırır.

CREATE TABLE products (
    id bigint PRIMARY KEY,
    account_id bigint NOT NULL REFERENCES accounts(id),
    sku text NOT NULL,
    status text NOT NULL,
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb,
    UNIQUE (account_id, sku)
);

CREATE INDEX products_attributes_gin
    ON products USING gin (attributes);

Bu yapı, ürün türleri arasında farklılaşan malzeme, boyut veya bölgesel meta veri gibi katalog özelliklerinde işe yarar. Önemli her alan JSON'a gömülüyse ve her sorgu dönüştürme, yol ifadesi veya özel doğrulama gerektiriyorsa daha az uygundur.

JSONB ayrıştırılmış ikili gösterim saklar, içerme işleçlerini destekler ve nesne özellik sırası gibi önemsiz biçimlendirmeyi atar. Yinelenen nesne özelliği için de yalnızca bir değer tutar. Orijinal JSON metnini aynen yeniden üretmesi gereken uygulamalar bu metni ayrıca saklamalıdır.

Küçük bir özelliğin güncellenmesi yeni PostgreSQL satır sürümü oluşturur ve büyük bir JSONB değerini yeniden yazabilir. Bu yüzden büyük, sık güncellenen belgeler önemli miktarda write-ahead log ve ölü satır üretebilir. Sık değişen alanları sütunlara veya alt tablolara ayırmak genellikle daha iyi çalışır.

Yabancı anahtarlar, rastgele JSON içindeki ilişkileri doğrudan zorlayamaz. Sık sorgulanan, birleştirilen, sıralanan veya kısıtlanan değerleri sütunlara taşıyın. Oluşturulmuş sütunlar ve ifade dizinleri aşamalı geçişte yardımcı olabilir; anlamı kararlı hale geldiğinde ilişkisel alan çoğu zaman daha açıktır.

Dizinleme ve sorgu planları

Her iki veritabanı da gerçek filtreler, sıralamalar ve kardinaliteyle eşleşen dizinlere bağlıdır. Gelişigüzel dizinleme yazmaları yavaşlatır ve bellek tüketir. Motorlar farklı dizin araçları sunar, ancak hiçbiri saklanan modele ters düşen erişim biçimini kurtaramaz.

PostgreSQL eşitlik, aralık ve sıralı getirme için B-tree dizinleri kullanır. GIN dizinleri JSONB içerme, diziler ve tam metin aramayı destekler. GiST ve SP-GiST çeşitli geometrik, aralık ve özel işleç sınıflarını kapsar. BRIN dizinleri, fiziksel sırası zaman gibi bir değerle ilişkili çok büyük tablolar için kompakt seçimlerdir.

PostgreSQL ayrıca kısmi ve ifade dizinlerini destekler. Etkin abonelikler üzerindeki kısmi dizin, yıllarca birikmiş pasif kayıtları kapsayan dizinden çok daha küçük olabilir. İfade dizini normalleştirilmiş e-posta adresini veya seçilmiş JSON özelliğini destekleyebilir.

MongoDB iç içe özellikleri ve dizileri doğrudan dizinler. Çok anahtarlı dizin, dizi değerlerini dizin girdilerine genişletir. Bu üyelik sorgularını verimli kılar, ancak dizini hızla büyütebilir. Bileşik çok anahtarlı dizin, aynı belgede birden fazla dizi değerli alanı dizinleyemez. MongoDB ayrıca ilgili erişim modelleri için coğrafi, karma, joker, kısmi, seyrek ve TTL dizin seçenekleri sunar.

Bileşik dizinlerde sütun sırası, evrensel bir “en seçici önce” kuralından değil, sorgu yapısından gelir. PostgreSQL çok sütunlu B-tree'de öndeki sütunlarda eşitlik koşulları ve sonraki sütunda aralık koşulu çoğu zaman verimli tarama sağlar. MongoDB kullanıcıları yaygın olarak önce eşitlik alanlarını, sonra sıralama alanlarını, ardından aralık alanlarını koyar; gerçek dağılımda farklı sıranın daha az girdi tarayıp taramadığını da kontrol eder.

Varsayımlar yerine sorgu planlarını kullanın:

• PostgreSQL'de temsilî okumalar üzerinde EXPLAIN (ANALYZE, BUFFERS) çalıştırın; satır tahminlerini, döngüleri, sıralamaları, diske taşmaları ve arabellek etkinliğini inceleyin.
• ANALYZE ifadenin kendisini çalıştırır; bu yüzden yazmalar ve üretim trafiğinde dikkatli olun.
• MongoDB'de yürütme istatistiklerini isteyin; incelenen belgeleri, dizin girdilerini ve dönen sonuçları karşılaştırın.
• Yaygın parametre değerlerini, verinin büyük kısmına uyan çarpık değerlerle birlikte test edin.
• Kullanılmayan dizinleri ancak periyodik, yönetimsel ve yük devretme işlerinde de kullanılmadığını doğruladıktan sonra kaldırın.

Bir uç noktayı kusursuz kapsayan dizin, başka bir dizini tekrarlayabilir veya her yazmayı artırabilir. Her dizini ayrı ayrı onaylamak yerine tüm dizin kümesini portföy olarak gözden geçirin.

Arama, coğrafi ve zaman serisi iş yükleri

Her iki veritabanı temel arama, konum ve zamana dayalı sorguları kapsar. Ancak özel ürün gereksinimleri, ayrı araçları veya yönetilen özellikleri haklı çıkarabilir. Karar; alaka kalitesine, alım hızına, saklama süresine ve operasyonel sahipliğe bağlı olmalıdır.

PostgreSQL tam metin araması; belirteçleştirme, sözlükler, ağırlıklı belge vektörleri, sorgu işleçleri, sıralama ve GIN hızlandırması sağlar. Korpus ve alaka kuralları yönetilebilir kaldığında uygulama içi arama için iyi çalışır. Trigram dizinleri, adlar veya kimliklerde benzerlik ve alt dize eşleştirmesini destekleyebilir.

MongoDB metin dizinleri temel kelime aramasını işler. MongoDB'nin yönetilen platformu, daha zengin alaka ve getirme iş yükleri için ayrı arama ve vektör arama yetenekleri de sunar. Taşınabilirlik, fiyatlandırma, yedekleme davranışı ve yerel geliştirmeyi karşılaştırırken bunları dağıtıma özgü hizmetler olarak değerlendirin.

Vektör arama, işlem doğruluk kaynağı gereksinimini değil sorgu türünü değiştirir. PostgreSQL uzantılar yoluyla vektör dizinleme ekleyebilir; MongoDB dağıtımları operasyonel belgeleri desteklenen vektör arama hizmetleriyle eşleştirebilir. Uygulamanın kendi gömmelerinde geri çağırmayı, filtrelemeyi, dizin oluşturma süresini, güncelleme görünürlüğünü ve maliyeti değerlendirin.

Coğrafi çalışmalar için PostgreSQL, gelişmiş geometri, koordinat sistemleri ve mekânsal analizde yaygın olarak PostGIS uzantısını kullanır. MongoDB, konum farkındalığı olan uygulama sorgularına uygun coğrafi dizinler ve işleçler sunar. Gerçek işlemleri listelemeden daha basit seçeneği seçmeyin. Yakındaki noktaları bulmak, poligon onarımından veya karmaşık mekânsal birleştirmelerden çok daha az gereksinim duyar.

MongoDB zaman serisi koleksiyonları ölçümleri iç paketlerde düzenler ve zamana dayalı silme desteği sunar. PostgreSQL zaman serisi verisini bölümleme, BRIN dizinleri ve isteğe bağlı uzantılarla işler. Uzun saklama süresi ve geniş taramalar işlem güncellemelerinden daha önemliyse, çok yüksek hacimli telemetri alımdan sonra amaca özel analitik depoya daha uygun olabilir.

Performans ve temsilî karşılaştırmalar

Veri yerleşimi, dizin kapsamı, çalışma kümesi boyutu ve dayanıklılık ayarları, genel MongoDB ve PostgreSQL karşılaştırma sonuçlarından genellikle daha önemlidir. Güvenilir test, uygulamanın veri dağılımını ve eşzamanlılığını yeniden üretir.

MongoDB, bir istek tek dizinli belgeye karşılık geldiğinde düşük gecikmeli okumalar sağlayabilir. Belgeler büyük olduğunda, yanıtların yalnızca birkaç dağınık alana ihtiyacı olduğunda veya ilişkiler yinelenen aramalar gerektirdiğinde bu avantaj azalır. Gömülü diziler de dizin girdi sayısını büyütür ve güncellemeleri giderek pahalı hale getirebilir.

PostgreSQL, istatistikler doğru ve birleştirme sütunları dizinliyse karmaşık birleştirmeleri verimli çalıştırabilir. Sorgu büyük ara sonuç ürettiğinde, sıralama veya hash işlemlerini diske taşıdığında ya da birçok ilişkisiz sayfayı tekrar tekrar getirdiğinde performans düşer. Yalnızca gereken sütunları seçmek ve veri modeli hatalarını düzeltmek, SQL söz dizimini yeniden yazmaktan genellikle daha önemlidir.

Her ikincil dizin, iki sistemde de yazma işini artırır. Büyük JSONB değerleri, geniş satırlar, aşırı büyük belgeler ve yinelenen denormalize veri G/Ç'yi yükseltir. Bağlantı fırtınaları, tekil sorgular hızlı olsa bile kaynakları tüketebilir. Bu nedenle sınırlı havuzlar kullanın ve yük devretme sırasında yeniden bağlanma davranışını test edin.

Yararlı bir karşılaştırma şu koşulları korumalıdır:

• Çalışma kümesi ile kullanılabilir bellek arasındaki beklenen oranı temsil edecek kadar veri yükleyin.
• Üretimdeki tutarlılık, günlükleme, çoğaltma ve onay ayarlarını eşleştirin.
• En önemli uygulama işlemlerini gerçekçi okuma ve yazma oranlarıyla yeniden çalıştırın.
• Çarpıklığı, yoğun kiracıları, büyük hesapları, eksik kayıtları ve en kötü filtreleri ekleyin.
• Sabit yükte ve kurtarma olaylarında verimle birlikte p50, p95 ve p99 gecikmesini kaydedin.

Her seferinde tek kontrollü değişiklik yapın. Donanımı ve istek anlamını sabit tutarak normalleştirilmiş tabloları JSONB ile, gömülü belgeleri başvurularla veya farklı dizinleri karşılaştırın. Sıcak önbellek mikro karşılaştırmaları; yedekleme baskısını, çoğaltma gecikmesini, kontrol noktası davranışını veya birincil düğüm başarısız olduktan sonraki performansı öngöremez.

Kapasite planlaması hem veride hem dizinlerde büyümeyi kapsamalıdır. İlk gün belleğe sığan dizin, bir yıl sonra gecikmeye hâkim olabilir. Boş veritabanından tahmin yürütmek yerine testi öngörülen veri hacmiyle tekrarlayın.

Yatay ölçekleme ve veri dağıtımı

MongoDB yazmaları dağıtmak için yerleşik parçalama sunar. PostgreSQL ise ayrı dağıtık mimariyi benimsemeden önce genellikle dikey ölçekleme, bölümleme ve replikaları birleştirir. Yatay ölçek, her sorguyu etkileyen yönlendirme ve sahiplik kararları getirir.

MongoDB parçalanmış kümesi, belgeleri bir shard key'e göre dağıtır. İyi shard key yeterli kardinaliteye sahiptir, yazmaları artan şekilde tek yerde toplamaz, yaygın yönlendirme koşullarını destekler ve depolamayı dengeli dağıtır. Shard key'i içermeyen sorgu her shard ile iletişim kurabilir; bu da gecikmeyi ve kaynak kullanımını artırır.

Karma parçalama sıralı kimlikleri daha dengeli dağıtabilir, fakat aralık yerelliğini zayıflatır. Aralığa dayalı parçalama hedefli aralıkları destekler, ancak aralığın sonunu yoğunlaştırabilir. Bölgeler, kiracı veya coğrafi kurallar için seçilen aralıkları belirlenen shard'lara yerleştirebilir. Yeniden parçalama kötü seçimi düzeltebilir, ama büyük canlı veri kümesini taşımak planlama ve boş kapasite ister.

MongoDB işlemleri shard'ları aşabilir, ancak shard'lar arası koordinasyon tek shard'a yönlenen işlemlerden daha maliyetlidir. Kiracı kimliğini hem shard key'e hem yaygın sorgulara ekleyen uygulamalar ilgili işleri çoğu zaman yerel tutar.

PostgreSQL yerel bölümleme, mantıksal tabloyu genellikle zamana, kiracıya veya başka yönlendirme değerine göre alt tablolara böler. Bölüm budama taramaları azaltır, bölümler saklama işlemlerini kolaylaştırır. Yerel bölümleme tek başına yazmaları makineler arasında dağıtmaz, bu yüzden parçalama diye tanımlanmamalıdır.

PostgreSQL okuma replikaları uygun okuma trafiğini birincilden uzaklaştırabilir. Replikalar birincil yazma kapasitesini artırmaz ve eşzamansız replikalar eski veri döndürebilir. Uygulamalar hangi okumaların bu gecikmeye dayanabileceğine karar vermelidir.

Tek PostgreSQL yazarı yeterli olmadığında ekipler uygulama kodunda parçalayabilir, dağıtık PostgreSQL uzantısı veya hizmeti benimseyebilir ya da alanları bağımsız sahipli veritabanlarına ayırabilir. Her seçenek shard'lar arası birleştirmelerin, benzersizliğin, dizilerin ve işlemlerin davranışını değiştirir. Uygulama küresel işlemlere bağımlı olmadan bu sınırları test edin.

Ölçekleme gereksinimlerini sayısal belirtin. Saniye başına beklenen yazma işlemi, veri kümesi boyutu, yoğun kiracı yoğunlaşması, bölge yerleşimi ve kurtarma hedefleri, genel bir yatay ölçekleme isteğinden daha yararlıdır.

Replikasyon, yük devretme ve kurtarma

Her iki veritabanı da yüksek erişilebilirlik sağlayabilir, ancak kurtarma davranışı topolojiye, onay politikasına, otomasyona ve tekrar eden testlere bağlıdır. Yalnızca replikasyon, kısa kesinti veya sıfır veri kaybı garantisi vermez.

MongoDB yaygın olarak birincil ve birden çok ikincilden oluşan replica set olarak çalışır. Mevcut birincil kullanılamaz olduğunda üyeler yeni birincili seçer. Uygulamalar desteklenen sürücüleri kullanmalı, sunucu seçimi ve işlem zaman aşımlarını yapılandırmalı, geçici hataları ele almalıdır. Yeniden denenebilir yazmalar seçili işlemlere yardımcı olur, ancak denemeler uygulama idempotency'sine uymalıdır.

Write concern, bir yazmayı kaç üyenin onayladığını denetler. Read preference, uygun okumaların birincili mi ikincilleri mi kullanacağını; read concern ise görünürlük garantilerini belirler. Düşük gecikmeli yapılandırma daha fazla hata veya güncellik riski doğurabilir, bu yüzden her iş yükü için seçilen birleşimi belgeleyin.

PostgreSQL fiziksel akış replikasyonu, write-ahead log kayıtlarını birincilden bekleme düğümlerine gönderir. Eşzamansız replikasyon erişilebilirliği ve gecikmeyi korur; fakat bekleme düğümü kaydı almadan birincil yok olursa yakın zamanda onaylanan işlemler kaybolabilir. Eşzamanlı replikasyon bu riski azaltabilir, ancak onay gecikmesini ve bekleme düğümü sağlığına hassasiyeti artırır.

PostgreSQL yük devretmesi normalde yönetilen hizmet veya harici otomasyonla koordine edilir. Prosedür uygun bekleme düğümünü yükseltmeli, istemcileri yönlendirmeli ve eski birincilin çakışan yazmaları kabul etmesini engellemelidir. Bağlantı havuzları ve DNS önbellekleri yükseltmeden sonra görünen kesintiyi uzatabilir.

Yedekler, yanlışlıkla silme ve mantıksal bozulma dahil replikasyonun aslına uygun kopyaladığı hatalara karşı korur. PostgreSQL temel yedekleri ve arşivlenmiş write-ahead log'ları zaman içinde belirli noktaya kurtarmayı sağlar. MongoDB dağıtımları, uygun araçlar veya yönetilen hizmetlerle koordineli anlık görüntüler ve oplog tabanlı kurtarma kullanabilir.

Kurtarma noktası hedefi ile kurtarma süresi hedefini ayrı tanımlayın. Ardından yalıtılmış ortamda tam geri yüklemeyi test edin, uygulama verisini doğrulayın, geri yüklenen kimlik bilgilerini değiştirin ve geçen süreyi kaydedin. Başarılı anlık görüntü, hizmetin hedef süre içinde tamamen kurtarılabileceğini kanıtlamaz.

Operasyonel bakım

PostgreSQL ve MongoDB farklı rutin bakım ister. Bu nedenle ekip deneyimi küçük özellik farklarından daha ağır basabilir. Yönetilen hizmetler bazı işleri azaltır, ancak sorgu tasarımının, kapasite kararlarının ve kurtarma doğrulamasının sorumluluğunu almaz.

PostgreSQL işlemler veri güncelledikçe ve sildikçe eski satır sürümleri oluşturur. Autovacuum yeniden kullanılabilir alanı toplar, görünürlük bilgisini günceller ve işlem kimliği tükenmesini önler. Uzun süren işlemler temizliği geciktirebilir. Ölü satırları, tablo ve dizin büyümesini, vacuum ilerlemesini, işlem yaşını ve eski anlık görüntüleri canlı tutan sorguları izleyin.

Planlayıcı istatistikleri de ilgi ister. Çarpık değerler veya ilişkili sütunlar yanlış satır tahminleri ve kötü planlar üretebilir. İstatistik hedeflerini artırmak veya genişletilmiş istatistikler oluşturmak seçili sorgulara yardımcı olur. Sorgu performansını yalnızca kod değişikliklerinden sonra değil, büyük veri büyümesinden sonra da gözden geçirin.

MongoDB'nin WiredTiger depolama motoru önbelleğe ve sıkıştırmaya büyük ölçüde dayanır. Önbellek baskısını, disk gecikmesini, belge büyümesini, kontrol noktası davranışını, replikasyon gecikmesini ve incelenen belgelerin dönen belgelere oranını izleyin. Parçalanmış dağıtımlarda dengeleme etkinliğini, dengesiz parça dağılımını ve shard'lar arasında dağılan işlemleri izleyin.

Rutin çalışma kılavuzları beş alanı kapsamalıdır:

• Yavaş sorgu yakalama, sahiplik ve düzeltme eşikleri.
• Yalnızca doluluk yerine büyüme oranına dayalı kapasite uyarıları.
• Kaydedilmiş kurtarma süreleri ve doğrulama adımlarıyla geri yükleme tatbikatları.
• Kimlik bilgisi dönüşümü ve acil erişim prosedürleri.
• Sürücüler, uzantılar, dizinler ve geri dönüş planlarıyla test edilen sürüm yükseltmeleri.

PostgreSQL büyük sürüm yükseltmeleri yaygın olarak pg_upgrade, mantıksal replikasyon veya yönetilen geçiş süreciyle yapılır. Uzantı uyumluluğu uygulanabilir yolu belirleyebilir. MongoDB yükseltmeleri desteklenen sürüm dizilerini ve Feature Compatibility Version denetimlerini kullanır; parçalanmış kümeler bileşenlerin dikkatli sıralanmasını gerektirir.

pg_dump ve mongodump gibi mantıksal dışa aktarma araçları küçük veri kümeleri ve seçici kurtarma için kullanışlıdır. Büyük ölçekte katı kurtarma hedefleri için çok yavaş olabilirler. Bunları ana olağanüstü durum kurtarma yöntemi olarak benimsemeden önce üretim boyutunda veride dışa ve içe aktarma süresini ölçün.

Güvenlik ve yönetişim

Erişim, şifreleme, denetim ve ağ denetimleri açıkça tasarlandığında her iki veritabanı da zorlu güvenlik gereksinimlerini karşılayabilir. Varsayılan kimlik bilgileri veya yalnızca özel ağ, denetlenebilir sistem oluşturmaz.

PostgreSQL rolleri veritabanı, şema, tablo, sıra, işlev ve sütun düzeyinde ayrıcalık alabilir. Görünümler seçilmiş alanları açabilir, satır düzeyi güvenlik ise kullanıcı veya kiracı bağlamına göre satırları kısıtlayabilir. Ele geçirilmiş bir servisin kendi kısıtlarını değiştirmemesi için nesne sahipliğini normal uygulama rollerinden ayırın.

MongoDB rolleri veritabanları, koleksiyonlar ve küme kaynaklarında eylem yetkileri verir. Uygulama okumaları, uygulama yazmaları, geçişler, izleme, yedekler ve yönetim için ayrı kimlikler kullanın. Hizmetler arasında geniş ayrıcalıklı tek kimlik bilgisini paylaşmayın.

Pratik denetim kümesi şunları içerir:

• İstemci ve replikasyon trafiğinde TLS zorunlu kılın, ardından her sürücüde sertifika işlemeyi doğrulayın.
• Gizli bilgileri yönetilen gizli bilgi sisteminde saklayın ve tam uygulama sürümü yayınlamadan değiştirin.
• Ağ yollarını kısıtlayın ve veritabanı dinleyicilerini doğrudan herkese açık internete açmayın.
• Politikanın gerektirdiği kimlik doğrulama, ayrıcalık, şema ve hassas veri erişimi olaylarını kaydedin.
• Analistlerin, destek çalışanlarının ve otomasyon hesaplarının verilen görevleri aşamadığını test edin.

Dinlenme hâlindeki şifreleme; veritabanı yeteneklerini, şifreli depolamayı ve bulut tarafından yönetilen anahtarları birleştirebilir. MongoDB, desteklenen dağıtımlarda istemci tarafı alan düzeyinde şifrelemeyi de destekler. PostgreSQL uygulamaları, veritabanı yöneticilerinin açık metni görmemesi gerektiğinde seçilmiş değerleri depolamadan önce yaygın olarak şifreler. Şifreleme dizinleme ve sorgu seçeneklerini değiştirir, bu nedenle önce korunan işlemleri prototipleyin.

Yönetişim ayrıca veri sınıflandırması, saklama, silme, ikamet ve olay müdahalesi süreçleri gerektirir. Bölgesel yerleşim ikamet hedeflerini destekleyebilir, ancak uyumluluk; yedeklere, günlük kayıtlara, destek erişimine, alt işleyicilere ve veriyi alan her sisteme bağlıdır.

Maliyet, lisanslama ve toplam sahiplik

Daha ucuz veritabanı, iş yükünü kabul edilebilir altyapı, hizmet ücreti ve mühendislik çabasıyla karşılayandır. Lisans fiyatı tek başına toplam sahipliği nadiren belirler.

İşlem maliyeti karmaşık sorgular, sıkıştırma işi, dizin bakımı, arka plan işleri ve replikasyonla yükselir. Depolama; dizinleri, tutulan günlükleri, yedekleri, geçici alanı ve denormalizasyonla oluşan yinelenen veriyi içerir. Üç veri taşıyan replika, anlık görüntüler ve bölgeler arası aktarım hesaba katılmadan önce bile birden çok kopya saklar.

PostgreSQL izin verici PostgreSQL License kullanır ve birçok kendi barındırılan ve yönetilen dağıtım üzerinden sunulur. Ticari destek ve bulut hizmetleri isteğe bağlı satın alımlardır. Uzantıların kendi lisansları olabilir, bu nedenle ayrı inceleyin.

MongoDB Community Server, kaynak erişimine açık olan ancak Open Source Initiative tarafından onaylanmış bir açık kaynak lisansı olmayan Server Side Public License kullanır. MongoDB Atlas ve ticari destek, satıcı fiyatlandırması ve şartlarıyla sunulur. Veritabanı işlevselliğini hizmet olarak gömen veya sunan kuruluşlar, izin verici açık kaynak lisansıyla aynı olduğunu varsaymak yerine geçerli koşulları hukuk danışmanına inceletmelidir.

Yönetilen veritabanları daha yüksek birim fiyatı; otomatik sağlama, yama, yedekleme, izleme entegrasyonları ve yük devretme sürecinin bazı bölümleriyle değiş tokuş eder. Şema kalitesi, yavaş sorgular, bağlantı yönetimi, veri sınıflandırması ve uygulama kurtarma sorumluluğu yine müşteride kalır.

Toplam sahipliği şu girdilerle tahmin edin:

• Üretim, hazırlık, geliştirme, olağanüstü durum kurtarma ve geçici ortam sayıları.
• En az gelecek 12 ila 24 aydaki veri ve dizin büyümesi.
• Gerekli replikalar, bölgeler, yedek saklama süresi ve ağ aktarımı.
• Tepe verim, çalışma kümesi belleği ve sağlanmış depolama performansı.
• Geçişler, ayarlama, olay müdahalesi, denetimler ve geri yükleme çalışmaları için personel süresi.

Ekibin zaten iyi desteklediği veritabanı, teknik olarak çekici alternatiften daha ucuz olabilir. Eğitim, yeni otomasyon, yenilenmiş nöbet prosedürleri ve geçiş riski gerçek maliyetlerdir.

İş yüküne göre uygulama uyumu

PostgreSQL ilişki ağırlıklı sistem kayıtları için daha güçlü varsayılandır. MongoDB ise bağımsız sahipliği olan, değişken belgeler içeren alanlarda yerini hak eder. Belirli iş akışları, web uygulaması veya kurumsal sistem gibi geniş etiketlerden daha net uyumu gösterir.

SaaS hesap modeli genellikle kuruluşlar, üyelikler, davetler, roller, abonelikler, faturalar, haklar ve denetim kayıtları içerir. Benzersizlik ve varlıklar arası kurallar merkezidir; yöneticiler sonunda başlangıçta öngörülmeyen raporlar ister. PostgreSQL bu kalıba iyi uyar.

Ürün kataloğu; giyim, elektronik, endüstriyel parça ve özel kiracı kategorileri için farklı özellik kümeleri içerebilir. MongoDB, seyrek evrensel tablo oluşturmadan her ürünü tutarlı belge olarak saklayabilir. Ürünler fiyat tablolarına, envanter işlemlerine, tedarikçi anlaşmalarına ve ilişkisel raporlamaya yoğun katılıyorsa JSONB'li PostgreSQL de güçlü seçenektir.

İçerik yönetimi alanı çoğu zaman bloklar, yerelleştirme, meta veri ve yayın durumu içeren belgelere doğal olarak uyar. Her girdi bir bütün olarak okunup revize edildiğinde MongoDB iyi çalışır. Editoryal izinler, zamanlama, içerikler arası başvurular ve raporlama belge değişkenliğinden daha zorluysa PostgreSQL tercih edilebilir.

Finansal defterler, envanter ayırmaları ve faturalama kayıtları PostgreSQL'i destekler. Yalnızca eklemeli tasarım, benzersizlik, dengeli girdiler, mutabakat sorguları ve çok kayıtlı değişmez kurallara duyulan ihtiyacı ortadan kaldırmaz.

Olay ve telemetri sistemleri daha ayrıntılı test ister. MongoDB belge biçimli olayları alabilir, PostgreSQL ekleme yoğun tabloları bölümleyebilir. Sürekli analitik ölçekte operasyonel veritabanı sütunlu ambara veya amaca özel zaman serisi sistemine veri akıtabilir. Saklama, toplama pencereleri, geç gelen kayıtlar ve sorgu tarama boyutu depolama yolunu belirlemelidir.

Yetkili varlıklar PostgreSQL'de kalırken belge alanının ayrı sahipliği ve erişim biçimleri olduğunda hibrit mimari haklıdır. Her varlık için tek doğruluk kaynağı atayın. Değişiklikleri outbox veya değişiklik verisi yakalama süreciyle yayınlayın, idempotent tüketiciler kullanın ve gecikmiş veya yinelenen teslimatı planlayın. Kısmi hatadan sonra depoları tutarsız bırakabilecek eşzamanlı çift yazmalardan kaçının.

Pratik karar yöntemi

Üretim biçimindeki veriyle kısa bir kavram kanıtı, birbirine yakın MongoDB ve PostgreSQL kararını çözmenin en güvenilir yoludur. Test, genel bir oluşturma, okuma, güncelleme ve silme demosu yerine zor kısımlara odaklanmalıdır.

Üç temsilî iş akışı seçin: en yaygın istek, en karmaşık sorgu ve en katı doğruluk gereksinimi olan işlem. Her iş akışını iki veritabanında da dürüstçe modelleyin. PostgreSQL'i tek sınırsız JSON sütunuyla belge deposunu taklit etmeye zorlamayın; MongoDB'yi de çok koleksiyonda yüksek derecede normalleştirilmiş şemayı yeniden üretmeye zorlamayın.

Her adayı model açıklığı, doğruluk, sorgu çabası, ölçülen gecikme, operasyonel aşinalık, kurtarma, güvenlik denetimleri ve öngörülen maliyet üzerinden puanlayın. Karşılaştırma sonuçlarını görmeden önce kategorileri ağırlıklandırın. Finans uygulaması, geçişlerden kaçınmaktan çok bütünlüğe ve denetlenebilirliğe ağırlık vermelidir. Kısa ömürlü içerik prototipi tersini yapabilir.

Tasarım şu varsayımlardan herhangi birine bağlıysa reddedin:

• Gelecekteki her sorgu ilk API'nin erişim biçimini izleyecek.
• Uygulama doğrulaması sonsuza dek her yazma yolunda doğru çalışacak.
• Tek büyük kiracı, ortanca kiracı gibi davranacak.
• Replikasyon yedekleme ve geri yükleme çalışmalarına ihtiyacı ortadan kaldırır.
• İkinci veritabanının operasyonel maliyeti düşüktür, çünkü ilk dağıtımı yönetilidir.

Genel işlem odaklı uygulama için PostgreSQL daha güvenli başlangıç olmaya devam eder. Tabloları, SQL'i, kısıtları, olgun işlem modeli ve JSONB desteği hem yapılandırılmış hem seçilmiş yarı yapılandırılmış veriye alan bırakır. MongoDB, geçişler rahatsız edici göründüğü için değil, belge modeli somut olarak daha basit tasarım ürettiği veya yerleşik dağıtım modeli ölçülmüş gereksinimlere uyduğu için kazanmalıdır.

Seçimi Koder.ai projelerine uygulamak

PostgreSQL, platformun ana yığını mobil uygulamalar için React, Go, PostgreSQL ve Flutter kullandığından çoğu Koder.ai projesinde doğal başlangıçtır. Bu varsayılan, sohbet arayüzü üzerinden yaygın olarak oluşturulan web sitelerine, CRM'lere, ERP'lere, mobil uygulamalara ve diğer işlem odaklı sistemlere uygundur.

Planning Mode, üretim başlamadan önce varlıkları, ilişkileri, benzersizlik kurallarını, veri saklamayı ve yüksek hacimli işlemleri belirlemelidir. Kararlı özellikler türü belirli sütunlara aittir. Yapısı gerçekten değişkense isteğe bağlı, işe özgü özellikler JSONB kullanabilir.

Koder.ai kaynak kod dışa aktarma, dağıtım ve barındırma, özel alan adları, anlık görüntüler ve geri alma desteği sunar. Anlık görüntüler ve uygulama geri alma, veritabanı geçiş planlamasını tamamlamalıdır; onun yerini almamalıdır. Uyumsuz şema değişikliğinden sonra uygulama kodunu geri almak, eski kodun yeni yazılmış veriyi okuyamamasına yol açabilir.

Oluşturulan Go servislerinde veritabanı değişikliklerini gözden geçirilmiş geçişlerde tutun ve dağıtımları geçiş dönemi boyunca güvenli yapın. Yaygın sıra; uyumlu şemayı eklemek, iki durumu anlayan kodu dağıtmak, veriyi doldurmak, okumaları değiştirmek ve eski biçimi sonraki sürümde kaldırmaktır.

Koder.ai, veri yerleştirme gereksinimlerini desteklemek için uygulamaları farklı ülkelerde AWS altyapısında çalıştırabilir. Veritabanı tasarımı bu kararı replikalara, yedeklere, günlük kayıtlara, analiz dışa aktarımlarına ve yönetim erişimine genişletmelidir. Coğrafi yerleştirme, daha geniş gizlilik ve yönetişim planındaki bir denetimdir.

PostgreSQL destekli projeye MongoDB eklemek, diğer her mimari bağımlılıkta olduğu gibi aynı standardı izlemelidir: uygulamadan önce belgeye ait alanı, hata işlemeyi, eşitleme yolunu, yedekleme politikasını ve işletme sorumluluğunu tanımlayın.

Geçiş ve benimseme kontrol listesi

Veritabanı geçişi, ekip veri bütünlüğünü, uygulama uyumluluğunu ve geri alınabilir geçişi kanıtlayabildiğinde başarılı olur. Söz dizimini dönüştürmek işin yalnızca bir parçasıdır.

Tabloları veya koleksiyonları, veri hacmini, dizinleri, kısıtları, sorgu biçimlerini, saklama kurallarını ve her yazarı envantere alın. İlişkisel yabancı anahtarların başvurulara dönüşmesi, gömülü dizilerin alt tablolara dönüşmesi, sayısal hassasiyet farkları, büyük küçük harfe duyarlı karşılaştırmalar veya zaman damgası işleme gibi doğrudan çevrilemeyen anlamları belirleyin.

Üretim verisini taşımadan önce mutabakat sorgularını oluşturun. Sayılar tek başına yeterli değildir. Kiracı ve tarihe göre toplamları karşılaştırın, benzersizliği doğrulayın, büyük kayıtları örnekleyin, boşta kalan ilişkileri kontrol edin ve uygun olduğunda iş düzeyindeki bakiyeleri hesaplayın.

Kontrollü geçiş normalde şu aşamaları içerir:

• İlk toplu kopyayı yapın, reddedilen veya dönüştürülen kayıtları kaydedin.
• Sonraki değişiklikleri günlük, outbox veya değişiklik verisi yakalama mekanizmasıyla yakalayın.
• Kullanıcıya görünen davranışı değiştirmeden gölge okumalar yapın veya örneklenmiş yanıtları karşılaştırın.
• Hataları ve gecikmeyi izlerken geri alınabilir yönlendirme değişikliğiyle geçin.
• Mutabakat ve geri alma süresi tamamlanana kadar eski depoyu salt okunur tutun.

Uygulama kodundan çift yazma, iki yazma da idempotent değilse ve kısmi hata açıkça uzlaştırılmıyorsa risklidir. Yeniden denenebilen eşzamansız teslim kaydıyla tek onaylanmış kaynağı tercih edin.

Geçişten sonra operasyonel temel değerleri yeniden oluşturun. Sorgu planları, bağlantı havuzu boyutları, uyarı eşikleri, yedekleme süresi ve eski motordaki kapasite tahminleri otomatik aktarılmaz. Geçiş, yeni veritabanı geri yükleme çalışmasını geçtikten ve ekip arıza sırasında onu işletebildikten sonra tamamlanır.