AWS DynamoDB Ekibi, Postgres Tabanlı bir DynamoDB Protokol Sunucusu Olan ExtendDB'yi Yayınladı

Postgres tabanlı bir DynamoDB endpoint'i

20 Mayıs 2026'da, AWS'nin DynamoDB ekibindeki iki mühendis, DynamoDB kablo protokolünü uygulayan ve her öğeyi PostgreSQL'de saklayan açık kaynaklı bir sunucu olan ExtendDB'yi yayınladı. Kaynak, dev.to'daki uygulamalı bir anlatım; yazıya göre proje Rust ile yazılmış, Apache 2.0 lisansıyla sunuluyor ve AWS tarafından bakımı yapılıyor. İstemci tarafında hiçbir şey sıra dışı görünmüyor: AWS CLI veya herhangi bir SDK, DynamoDB ile konuşuyormuş gibi davranıyor. Fark, depolama katmanının psql ile açabileceğiniz bir Postgres veritabanı olması.

Neleri kapsıyor ve neleri kapsamadığını açıkça söylüyor

dev.to yazısına göre ExtendDB v0.1 olarak ortaya çıktı ve projenin releases sayfasında 1 Ekim'de yayımlanan v0.1.13 listeleniyor. Bildirilen özellik kapsamı arasında tablolar ve öğeler, Query ve Scan, toplu (batch) ve transactional yazmalar, stream'ler, öğe süre sonu (expiry) ve pgvector üzerine kurulu vektör araması yer alıyor. Referans arka uç PostgreSQL 14 ve üzeri; README ayrıca MongoDB'yi belgeliyor ve SQLite'tan söz ediyor.

Güvenlik AWS tarzı ele alınmış: her bağlantıda TLS zorunlu ve her istek, ExtendDB'nin kendisinin verdiği kimlik bilgileriyle hesaplanmış bir SigV4 imzası taşımalı. Bu erişim anahtarları AKIAEXTENDDB ile başlıyor; yazıya göre bu, sızdırılmış bir anahtarı gerçek bir AWS kimlik bilgisinden ayırt etmeyi kolaylaştırıyor.

Ekip olgunluk konusunda açık sözlü. Lansman duyurusu sürümü geliştirme, test ve deneme amaçlı olarak konumlandırıyor ve ExtendDB'nin DynamoDB olmadığını düpedüz söylüyor.

Geçiş için tek bir ortam değişkeni

Depo, sunucunun yanında Postgres 16 çalıştıran ve ilk başlatmada kendini hazırlayan bir Docker Compose kurulumuyla geliyor. Varsayılan yönetici parolası bir ortam değişkeniyle geçersiz kılınabiliyor; bir manage alt komutu kullanıcı oluşturuyor, IAM tarzı JSON politikaları bağlıyor ve erişim anahtarları üretiyor, secret'ı tam bir kez gösteriyor.

İstemci entegrasyonu bilinçli olarak ince tutulmuş. Sunucunun kendinden imzalı sertifikasını CA bundle olarak dışa aktarın, alışılmış AWS kimlik bilgisi değişkenlerini ayarlayın ve ya bir endpoint bayrağı verin ya da AWS_ENDPOINT_URL_DYNAMODB tanımlayın. Standart dynamodb komutları böylece değişmeden çalışıyor ve aynı komutlar gerçek DynamoDB'ye karşı da işliyor — yazı, tablo oluşturmayı, bir toplu yazmayı ve iki Query desenini (biri global secondary index üzerinden) adım adım gösteriyor.

Sunucu DynamoDB'nin kaba kenarlarını bile taklit ediyor. Yeni tablolar varsayılan olarak beş saniye boyunca CREATING durumunda kalıyor — projenin differences belgesinde bu gecikmenin yapılandırılabilir olduğu listeleniyor — ve iç katalog, index başına yayılma gecikmesini milisaniye cinsinden saklıyor.

Veri gerçekte nasıl görünüyor

İlginç olan kısım şema. Postgres tarafı iki veritabanı tutuyor: DynamoDB tablo adlarını iç UUID'lerle eşleyen bir katalog ve öğeleri barındıran ayrı bir veri veritabanı. Her DynamoDB tablosu ve her secondary index, ddb önekiyle ve bir tanımlayıcıyla adlandırılan kendi SQL tablosuna dönüşüyor.

Yazı, DDL'i proje kaynak kodundan yeniden kuruyor. Bu tür her tabloda null olamayan bir pk text sütunu, anahtar türüne göre tiplendirilmiş üç sort key sütunu (text, numeric ve binary) ve öğenin tamamını JSONB olarak tutan bir item_data sütunu var. Text sütunları C collation kullanıyor; yani dizeleri yerel ayar kurallarına göre değil, ham bayt değerine göre sıralıyor. pk'yı, text sort key'i ve jsonb_pretty(item_data)'yı seçen bir sorgu bir öğeyi okunabilir hale getiriyor; böylece beyaz tahtaya tek tablolu bir tasarım çizen herkes, bunun fiziksel olarak neye denk geldiğini sonunda görebiliyor.

Neden önemli

DynamoDB hiçbir zaman depolamasını görünür kılmadı. ExtendDB'nin başka seçeneği yok, çünkü depolamanın kendisi Postgres — ve bu, opak bir NoSQL soyutlamasını \d ile inceleyip SQL ile sorgulayabileceğiniz bir şeye dönüştürüyor. Ekipler için bu, sıradan bir Postgres üzerinde çalışan ve bu arada pgvector'ı da devralan, yerel geliştirme ve CI için DynamoDB uyumlu bir endpoint vaat ediyor. Uyarılar da aynı derecede net: geliştiricileri bizzat bunun bir DynamoDB alternatifi olmadığını söyleyen 0.1 çizgisinde bir proje bu. Daha geniş sinyal ise şu: DynamoDB ekibinin kendisi, AWS'nin en kapalı hizmetlerinden biri için açık kaynaklı bir uyumluluk katmanı çıkarıyor — ve soyutlamanın ilişkisel bir çekirdeğe nasıl eşlendiğini düz SQL ile gösteriyor.