PgDog yatırım aldı ve size en yakın veritabanına geliyor

 (pgdog.dev)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • PgDog, PostgreSQL’in önüne konulan bir proxy’dir; uygulamayı yeniden yazmadan bağlantı havuzlama, yük dengeleme ve sharding ile Postgres’i yatay olarak ölçeklendirir
  • Mongo veya Dynamo gibi veritabanlarının var olma nedenini Postgres’in ölçeklenme sorunu olarak görüyor; 100 TB’tan büyük tabloları ve saniyede 1 milyon sorguyu işleyebilse başka veritabanına gerek kalmayacağını savunuyor
  • PgDog, production’da saniyede 2 milyondan fazla sorgu işliyor, doğrulanmış kapsamda 20 TB’tan fazlasını sharding ile böldü ve GitHub Docker pull sayısı 1,4 milyonu aştı
  • Üç kişilik ekip, Postgres tabanlı büyük ölçekli uygulamalar ve Instacart’ın Nisan 2020’deki 5 kat büyüme deneyimi üzerine; RDS, Aurora ve EC2’de Postgres sharding sorunlarıyla uğraştı
  • Basis Set, YC, Pioneer Fund ve diğerlerinden 5,5 milyon dolar yatırım aldı; PgDog’u her ölçekte Postgres’i çalıştıran açık kaynak bir ürün olarak geliştiriyor

Yatırım ve ürün yönü

  • PgDog’un geliştirilmesi, Postgres’in ihtiyaç duyulan tek veritabanı olduğu bakış açısıyla başladı
  • Mongo veya Dynamo gibi veritabanlarının var olma nedenini Postgres’in ölçeklenme sorunu olarak görüyor
  • Postgres 100 TB’tan büyük tabloları ve saniyede 1 milyon sorguyu düzgün biçimde işleyebilse başka veritabanı kullanılmayacağını düşünüyor
  • PgDog, mevcut Postgres’in önüne bir proxy koyarak yatay ölçeklendirme sağlıyor
  • PgDog, şirket içi ortamlar ve kullanıcının kendi bulut hesabı dahil her yere dağıtılabiliyor
  • Docker imajını çekip DATABASE_URL değerini değiştirdiğinizde işi PgDog devralıyor

Mevcut durum ve uygulama geçmişi

  • Mevcut durum

    • PgDog, production’daki onlarca deployment ortamında saniyede 2 milyondan fazla sorgu işliyor
    • Doğrulanmış kapsamda PgDog, 20 TB’tan fazlasını sharding ile böldü
    • PgDog açık kaynak ve isteyen herkes dağıtabilir
    • GitHub’daki Docker pull sayısı 1,4 milyonu geçti
    • Yeni sürümler her perşembe çıkıyor
    • Discord topluluğu büyüyor; her gün soru yanıtlanıyor ve destek veriliyor

  • Ekip ve güven dayanakları

    • PgDog, üç kişilik küçük bir startup
    • Ekip; altyapı mühendisi, uygulama mühendisi ve generalist rollerinden oluşuyor
    • Ekip, Postgres geniş çapta ilgi görmeden önce bile Postgres tabanlı uygulamalar geliştirip bunları büyük ölçekte çalıştırdı
    • Instacart’ta, şirketin Nisan 2020’de 5 kat büyüdüğü dönemde Postgres işletme deneyimi kazandı
    • O sıradaki en büyük sorun, Postgres’in dakikada yüz binlerce market teslimat siparişini işlemesini sağlamaktı
    • RDS, Aurora ve EC2 üzerinde Postgres’i sharding ile böldüler; temel ilkeler ve çok sayıda kodla gerçek sorunları çözdüler
    • Aynı teknoloji bugün açık kaynak ürün olarak sunuluyor

  • Dağıtım modeli ve finansman

    • PgDog’un geliştirilmesi bir pivot değil; tek hedef hâlâ Postgres ölçeklendirmesi
    • PgDog, kullanıcının bulutunda, colocation rack’inde, şirket içi sistemlerinde ve dizüstü bilgisayarında çalışacak şekilde tasarlandı
    • PgDog, bağımlılıklar veya gizli serverless maliyetleri olmadan ihtiyaç duyulan yerde çalışıyor
    • CPU sağlayabiliyorsanız PgDog’un çok iş parçacıklı kodu tüm CPU’yu kullanıyor
    • Postgres benimsenmesinin artmaya devam edeceğini düşünüyor
    • Basis Set, YC, Pioneer Fund ve diğer yatırımcılardan 5,5 milyon dolar yatırım aldı; bu da birkaç yıllık runway sağlıyor
    • Amaç, Postgres’in herkes için ve her ölçekte düzgün çalışmasını sağlamak

  • Enterprise edition

    • PgDog’un Enterprise edition sürümü, AWS üzerinde daha kolay çalışması için geliştiriliyor
    • Enterprise edition, ekibin SLA tabanlı desteğini sunuyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Mongo veya Dynamo gibi veritabanlarının var olma sebebinin Postgres'in ölçeklenme sorunları olduğu söylenir, ama Postgres'i birkaç yerde kullandıktan sonra gördüm ki birinci öncelikli sorun her zaman yüksek erişilebilirlikti, ölçeklenme değil
    Tek bir Postgres kümesiyle dakikada 100 bin işlemi rahatça işledik, ancak birincil düğüm ölünce çağrı alıp yedek düğüme elle failover yapmak, ardından yedek düğümü de yine elle değiştirmek gerekiyordu
    Manuel araçlar çok zahmetliydi ama en azından çalışıyordu; otomatik çözümler ise bunun yanına bile yaklaşamıyordu
    İyi bir HA hikâyesi olmadığından, self-hosted Postgres'ten mümkün olduğunca kaçınır oldum

    • Biz de HA desteği sunuyoruz: https://docs.pgdog.dev/features/load-balancer/
      Health check ve failover içeren bir load balancer varsayılan olarak çalışıyor; artık yeterince gerçek kullanımda da sınandığı için bakmaya değer
    • Patroni 1.0 2016'da çıktı, yani neredeyse 10 yıl önce
      https://github.com/patroni/patroni
    • cnpg kullandın mı merak ettim
      Benim kullanım senaryomda gerçekten çok iyi çalıştı
    • Bu alanı bugünlerde Patroni epey iyi çözüyor
    • CloudNativePG gibi bir şeye de baktın mı diye merak ediyorum: https://cloudnative-pg.io/

  • “Why Us” bölümünde “Instacart'ta Postgres işlettik ve şirket 2020 Nisan'ında 5 kat büyürken Postgres'in dakikada yüz binlerce market teslimat siparişini işlemesini sağlamak en büyük sorundu” yazıyorsa, bundan daha iyi bir neden biz anlatısı herhalde olmaz

    • Dakikada 100 bin sipariş çok mu fazla?
      Tek bir Postgres instance'ının bile bunu rahatça kaldırabileceği izlenimi veriyor
    • Ölçütü neden dakika başına çevirdiklerini merak ediyorum
      Modern yüksek kaliteli kurumsal SSD'ler saniyede yaklaşık 35 bin gerçek fsync işleyebilir
    • Instacart bana hep aşırı yavaş ve gecikmesi yüksek gelmiştir
      Tabii bunun Postgres'ten mi yoksa başka tasarım kusurlarından mı kaynaklandığını bilmiyorum

  • Temel olarak anlamaya çalışıyorum: şu anda büyük bir sunucuda 4TB'lık bir DB var
    PGDog gibi bir proxy aracı kullanırsam, her biri yaklaşık 500GB taşıyan 8 küçük sunucu ve proxy için 1 orta ölçekli sunucu çalıştırdığım bir yapıya mı dönüşüyor?
    Mevcut projede birçok servisten çok yoğun yazma trafiği geliyor ve web uygulaması da buradan okuma yapıyor
    Artık indeksleme, sorgu optimizasyonu, caching ve sunucu yükseltmeleri ne kadar yapılırsa yapılsın fayda etmeyeceği bir noktaya yaklaşıyoruz
    DB boyutunu küçültmek için statik verinin çoğunu ClickHouse'a taşımayı da değerlendiriyoruz, ama PgDog veya başka bir sharding yaklaşımının bu kullanım için işe yarayıp yaramayacağını duymak isterim

    • “Her biri yaklaşık 500GB taşıyan 8 küçük sunucu ve proxy için 1 orta ölçekli sunucu” tam olarak bu yapı demek
      Ulaşırsan sevinirim (lev@pgdog.dev)
      Yardım edebiliriz ya da en azından şu anda neyin çalışıp neyin çalışmadığını söyleyip seçeneklerini daha net görmeni sağlayabiliriz
    • Bu tam olarak sharding kavramı
      pgdog belgelerini okursan, isteklerin hangi shard sunucusuna yönlendirileceğini ona bildirmen gerektiğini görürsün; sihirli biçimde kendiliğinden çalışmıyor
      Yine de özellikle pahalı olan Postgres bağlantılarını yeniden kullandığı için değerli
      Sihir olmadığı için içeride neler döndüğünü anlaman gerekir; örneğin shard'lar arası transaction yoktur
      Veri tutarlılığına önem veriyorsan sharding zordur, bu yüzden önce uygulamanın read replica'lardan fayda sağlayıp sağlayamayacağına bakardım
      Replica'ların her biri tüm verinin bir kopyasını tutar ve yazmalar yalnızca master'a gider; ayrıca neredeyse gerçek zamanlıdan biraz geride kalabilen bir replica'da çalıştırılması uygun transaction'lara kendin karar vermen gerekir
      Örneğin bir web sayfası oluşturmak için yapılan okumalar replica'dan yapılırsa genelde güvenlidir, ama oku-değiştir-yaz türü işlemler için aynı şey geçerli değildir

  • Postgres'taki en büyük kesinti nedenlerinden biri olan major sürüm yükseltmesi için bunun nasıl yardımcı olacağını merak ediyorum
    Pooler, failover ve yük dengeleme için harika ama yükseltmeler yüzünden yılda bir ya da iki kez düzenli olarak 10-20 dakikalık kesinti gerekiyor
    Eski sürümden yeni sürüme mantıksal çoğaltma yardımcı olabilir ama kısmi yazmalar ya da garip durumlar olmadan her şeyi yeni cluster'a aktarma işi yine de gerekli gibi görünüyor
    Bu konuda deneyimi olan var mı merak ediyorum

    • Biz mantıksal çoğaltma ve pgbouncer'ın duraklatma/geçişini kullanarak yazmalar başarısız olmadan yaklaşık 5 saniyelik bir duraklama sağlıyoruz
      DB boyutu yaklaşık 1-1.5TB ama değişim miktarı ya da saniye başına sorgu sayısı aşırı yüksek değil
      Esasen burada anlatılan yöntem bu: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • Genelde bunu mantıksal çoğaltma ile hallediyoruz
      Kod olarak altyapı kurulumunuz varsa, yalnızca major sürümü farklı olan ama ayarları aynı yeni bir cluster oluşturup şemayı içe aktarır, eski sürümün read replica'sından veri kopyalamaya başlar, eski sürümün yazı kabulünü durdururuz (kesinti başlangıcı), sequence numaralarını senkronize eder ve servisi yeni cluster'a yönlendiririz (kesinti sonu)
      CloudNativePG gibi bir şey kullanırsanız CLI araçları ve bildirimsel sözdizimiyle bu sürecin bir kısmını otomatikleştirir
      Yoksa bunu kendiniz zaman ayırıp çözmeniz gerekir
      Kulağa karmaşık gelebilir ama staging DB'de prova edip düzgün çalıştığında production'da da aynı prosedürü uygulayabilirsiniz
      Ayrıca Postgres 19'da sequence'ların tek seferlik mantıksal çoğaltılması için bir yama var gibi görünüyor: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • Mantıksal çoğaltma bunu çözüyor
      Cluster'ı sıralı şekilde döndürürseniz kesinti çok küçük oluyor, kabaca 60 saniye kadar olabilir
    • PostgreSQL için hâlâ düzgün bir açık kaynak genel amaçlı çoklu master implementasyonu olmaması garip
      Bu saatten sonra bunu bir gün görür müyüm emin değilim
    • MySQL'den geliyorsanız bu büyük bir gerileme ve Postgres'i 80'lerden kalma bir şey gibi gösteriyor
      Bunun neden mutlak en yüksek öncelik olarak görülmediğini hâlâ merak ediyorum

  • Tebrikler Lev, funding için
    Burada PgDog'u memnuniyetle kullanıyoruz
    Proxy özellikleri arasında bağlantı başına farklı bağlantı ayarlarını, örneğin statement_timeout, ele alabilmesini oldukça beğeniyorum
    Eskiden RDS Proxy'yi incelediğimde bunu desteklemiyordu, pgbouncer da sanırım desteklemiyordu; bu yüzden uygulamada çok fazla değişiklik gerekiyordu
    PgDog'da ise şeffaf biçimde çalışıyor

  • Bunun, az önce duyurulan Supabase multigres ile karşılaştırılabilir olup olmadığını merak ediyorum

  • Bir Enterprise Edition görüyorum; hangi özelliklerin açık kaynak olmadığını net biçimde söyleyebilir misiniz merak ediyorum
    Yeni eklenen özelliklerin, VC yatırımcılarına karşılık vermek için EE lisansı altında olacağını düşünüp düşünmediğinizi de merak ediyorum

    • İki büyük özellik var
      Birincisi, çok düğümlü dağıtımları yöneten control plane; bu, PgDog'u kolayca dağıtıp kullanabilmeniz için “kutudan çıktığı gibi çalışan” bir deneyim sunuyor
      İkincisi, hizmet kalitesi (QoS); kötü sorguların veritabanını çökertmesini önlemek için onları otomatik olarak engelliyor
      Son olarak P0'a kadar SLA garantili destek alabiliyorsunuz
      Yeni özellikler iki kategoriye ayrılıyor
      Sharding ve büyük ölçekli Postgres işletimi her zaman açık kaynak olacak; altyapı yönetimi ve PgDog'u büyük ölçekte kolay çalıştırmayı sağlayan özellikler ise enterprise olacak

  • PgDog, Neki ve multigres'in çıkmasını görmek güzel
    Gerçekten de bu Postgres'in temel sorunu ve burada index hint olmaması da ayrıca bir sorun; bu yüzden Postgres 19'u bekliyorum

    • Orijinali olan PgBouncer'ı da unutmamak lazım
      Yapılandırması zor ama bugünlerde AI yardımıyla kurmak daha kolaylaştı
    • pg_hint_plan eklentisi core'a dahil değil ama planner'ı override etmeniz gerektiğinde oldukça yetenekli

  • “Bildiğimiz kadarıyla 20TB'den fazlasını shard ettik” ifadesi muhtemelen bir yazım hatası
    20TB o kadar da büyük değil
    Çok daha fazlasını shard etmiş olduklarını düşünürdüm

    • 20TB'nin “o kadar büyük olmadığını” düşünüyorsanız, ne büyüklükte DB'lerle çalıştığınızı merak ediyorum
    • Eğer çalışma kümesi 20TB ise bu oldukça büyük
      Her veritabanında sıcak veri / soğuk veri oranı farklı olduğu için daha fazla bilgi olmadan kıyaslamak mümkün değil
      Daha iyi bir ölçüt IOPS olabilir
      RDS, provisioned IOPS için çok daha fazla para harcamazsanız ya da Aurora kullanmazsanız, maksimum IOPS açısından oldukça düşük kalıyor
    • Evet
      Karşılaştırma olsun diye, yaklaşık 10 yıl önce Segment'te yaklaşık 50TB veriye sahip tek bir Aurora PostgreSQL instance'ı işletiyorduk; bu, S3'te depolanan çok daha büyük bir dosya külliyatı içindeki potansiyel tanımlayıcı verileri indekslemek için kullanılıyordu
    • Kullanım senaryolarının büyük çoğunluğunda 20TB kesinlikle devasa

  • PgDog güzel
    Dürüst olmak gerekirse ihtiyacım yok ama ormanda yürüyüş yaparken dinleyecek bir şey bulamayınca tesadüfen Postgres FM podcast'ini dinledim, ilgimi çekti ve kendi şirket içi Kubernetes ortamımda kullanıyorum
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb