Sadece Postgres kullanın

• Çoğu web uygulaması kalıcı veri depolamaya ihtiyaç duyar; bu yüzden yeni bir uygulama geliştirirken varsayılan olarak Postgres seçmek iyi bir fikirdir.

Neden sqlite değil?

• sqlite iyi bir veritabanıdır, ancak veriler tek bir dosyada saklanır.
• Bu da uygulamanın yalnızca tek bir cihazda çalıştığı anlamına gelir.
• Masaüstü veya mobil uygulamalar için uygundur, ancak web siteleri için uygun olmayabilir.
  • Bir web sitesinde sqlite kullanılarak elde edilmiş başarılı örnekler vardır, ancak bunlar genellikle kendi sunucusunu ve altyapısını doğrudan kuran durumlardır.
• Platformun sunduğu otomatik veritabanı yedeklerinden ve birden fazla uygulama sunucusu yapılandırabilme imkanından vazgeçmeniz gerekebilir.

Neden DynamoDB, Cassandra veya MongoDB değil?

• Bu veritabanları çok iyi performans gösterir, ancak pek çok ön koşula sahiptir:
  • Uygulamanın ne yapacağını ve erişim desenlerini tam olarak biliyor olmanız gerekir
  • Çok büyük veri ölçeğine genişlemeniz gerekiyorsa
  • Tutarlılığın bir kısmından vazgeçebiliyorsanız
• Bu veritabanları dağıtık hash map benzeri bir şekilde çalıştığı için, veri depolama biçimine sorgu deseni bilgisini yansıtmanız gerekir.
• Erişim (sorgu) desenleri değişirse tüm veriyi yeniden işlemeniz gerekebilir.
• İlişkisel veritabanlarında kolayca indeks ekleyip sorgu çalıştırabilirsiniz, ancak NoSQL veritabanlarında bu çok daha zordur.
• Analitik sorgular için uygun değildir.
• Bir üniversite öğrencisi ya da yeni mezun bir geliştirici MongoDB kullanıyorsa muhtemelen yardıma ihtiyaç duyacaktır.

Neden Valkey değil?

• Redis adıyla bilinen bu veritabanı, son derece verimli bir cache olarak tanınır.
• Birincil veritabanı olarak kullanılabilir, ancak şu sorunlar vardır:
  • Tüm veriyi RAM'de tutar; bu yüzden hızlıdır, ama RAM kapasitesi sınırlıdır.
  • Veri modellemede bazı tavizler gerektirir.

Neden Datomic değil?

• Bunu zaten biliyorsanız size "altın yıldız" verelim.
• Datomic, "önceden tasarım (Up-front Design)" sorununa sahip olmayan ilişkisel bir NoSQL veritabanıdır ve birkaç hoş özelliği vardır.
  • Veriyi tablolar yerine EAVT(entity-attribute-value-time) çiftleri olarak saklar ve genel amaçlı indeksler kullanır.
  • Sorgu yazarken yazarıyla koordinasyon kurmanız gerekmez. Belirli bir andaki 'o anki' veritabanını sorgulamanız yeterlidir. Yeni veri, hatta silmeler (veya 'retractions') bile gerçekte önceki veriyi silmez.
• Ancak bazı dezavantajları da vardır:
  • Yalnızca JVM dillerinde çalışır.
  • Clojure dışındaki dillerde API'si iyi değildir.
  • Kötü yapılandırılmış sorgulardan doğan hata mesajları son derece kullanışsızdır.
  • SQL araç ekosistemi benzeri bir yapı olmadığından araç desteği yetersizdir.

Neden XTDB değil?

• Clojure kullanıcıları çok sayıda veritabanı yapıyor.
• Datomic'e benzer, ancak şu özelliklere sahiptir:
  • HTTP API sunar, dolayısıyla JVM'ye bağımlı değildir.
  • "sistem zamanı" ve "geçerlilik zamanı" olmak üzere iki eksende sorgulanabilir.
  • SQL API desteği vardır.
• Ancak en büyük sorun şu ki hâlâ "çok yeni". SQL API geçen yıl çıktı ve kısa süre önce tüm depolama modelini değiştirdi.
  • 10 yıl sonra hâlâ ayakta olacak mı? Uzun vadeli destek belirsiz.

Neden Kafka değil?

• Kafka, TB ölçeğinde veri işleme için uygun, çok iyi bir "append-only" log'dur.
• Birden fazla ekip tarafından yönetilen birden çok servisten gelen verilerle event sourcing benzeri işler yapmak istiyorsanız şaşırtıcı derecede iyi çalışır.
• Ancak
  • Küçük ölçekte bunun yerini Postgres tabloları rahatlıkla alabilir.
  • Kafka consumer oluşturmak sanıldığından daha hataya açıktır. Sonuçta log içindeki kendi konumunuzu takip etmeniz gerekir.
  • Yönetmeniz gereken ek altyapı getirir.

Neden ElasticSearch değil?

• Veri arama ürününüzün ana özelliğiyse ElasticSearch doğru üründür.
  • Veriyi ETL sürecinden geçirmeniz ve tüm süreci yönetmeniz gerekir, ancak ElasticSearch arama için yapılmıştır ve bunu iyi yapar.
• Ancak arama ana özellik değilse Postgres'in yerleşik metin arama özellikleri de yeterli olabilir.
  • Daha sonra özel bir arama motoru ekleyebilirsiniz.

Neden MSSQL veya Oracle DB değil?

• Kendinize sormanız gereken gerçek soru şu: "Fiyatına değer mi?"
• Yalnızca lisans maliyetini değil, lock-in maliyetini de hesaba katmalısınız.
• Verilerinizi Oracle'a koyarsanız Oracle'a kalıcı olarak ödeme yapmanız ve geliştiricileri sürekli eğitmeniz gerekir.
  • Kurumsal özelliklerle cüzdanınız arasında sonsuza kadar bir seçim yapmak zorunda kalırsınız.
• Belirli bir özelliğe gerçekten ihtiyaç duymuyorsanız kullanmaktan kaçınmak daha iyidir.
  • MSSQL olmadan yaşayamayacağınız öldürücü bir özellik yoksa kullanmayın.

Neden MySQL değil?

• Bu kısımda biraz okuyucu desteğine ihtiyaç var.
• MySQL, Oracle'ın mülkiyetindedir ve bazı özellikler enterprise sürümüne kilitlenmiştir.
  • Elbette MySQL uzun zamandır kullanılıyor ve yaygın kullanılan ücretsiz bir sürümü var.
• Ben Postgres'in daha iyi bir tercih olduğuna inanıyorum, ancak MySQL hakkında daha fazla bilgiye ihtiyaç var.

Neden yapay zeka vektör veritabanları değil?

• Çoğu yapay zeka vektör veritabanı yeni bir teknoloji olduğu için kullanımında risk vardır.
  • Yapay zeka balonuna dayalı işlere temkinli yaklaşmak gerekir.
• İşiniz bir başka AI grift olsa bile, muhtemelen sadece import openai yeterli olacaktır.

Neden Google Sheets değil?

• Özel bir dezavantajı yok; ihtiyacınız varsa kullanabilirsiniz.

[hilft]

Firestore...

[wedding]

Bu kadar kesin konuşan makaleler genelde junior'ların yaptığı hatalardan biri ama..

[nemorize]

Bunun yerine sevimli bir CSV vereceğim

[roxie]

zzz

[bus710]

İyi bilgi edinmek için dikkat çekin… diye bir şaka nedense aklıma geliyor haha.
Her neyse, çoğu backend geliştiricisinin ilk kullandığı şey postgresql olduğu için…

[dicebattle]

Bence Postgres daha iyi bir seçim, ama MySQL hakkında daha fazla bilgiye ihtiyaç var

ahaha;;;;

[koxel]

MySQL Enterprise’ın asıl sorunu gerçekten lisans değil; ücretli satın alanlar için bile bir arıza patladığında desteğin berbat olması.
Daha önce MySQL indeksleri bozulup sistem açılmadığında destek talebi açsak da Oracle’ın yaptığı tek şey destek bileti açtırıp istersek telefon desteği verebileceklerini söylemekti.
Sonuçta müşteri tarafı bunun böyle olmayacağını söyleyince sorunu bizim çözmemiz gerekti.
Oracle’a güvenip Enterprise kullanmaktansa ücretsiz olan en iyisi..

[kaydash]

Neden mariadb, impala, hive, kudu değil?

[koxel]

MySQL’ın enterprise özellikleri, kendi connection pool’u gibi aslında pek de gerekli olmayan özellikler...
Gerçekten enterprise bir ortamdaysanız bunu kullanmak yerine ön tarafa bir SQL proxy kurmak yük dağıtımı açısından daha etkili olur.
PgSQL’i seviyorum ama... MySQL’e dönüp bakmadan “bilmiyorum, umurumda değil” moduna girmek de ne bileyim... hahaha

[iolothebard]

Sadece MySQL kullanın…

• Neden PostgreSQL değil? Bu kısımda biraz yardıma ihtiyaç var.

[love7peace]

Peki ya MariaDB?

[aer0700]

Oldukça büyük bir tartışma yaratabilecek gibi görünen bir yazı...

[aer0700]

Sqlite kullanmanın nedeni hem basit olması hem de belli bir ölçeğe kadar gayet iyi çalışmasıdır.
Önce sqlite ile geliştirip, sonra gerekirse postgres'e geçseniz de çok zor olmaz bence.

[xguru]

Unutulacak gibi olunca yine ortaya çıkan bir Postgres övgü yazısı. Artık tadını çıkarın!

Sadece her yerde Postgres kullanın
PostgreSQL yeterlidir
Postgres ne zamandan beri havalı oldu

[GN⁺]

Hacker News görüşleri

• MongoDB hakkında çok sayıda olumsuz görüş var, ancak bunların çoğu yanlış bilgiye dayanıyor

  • MongoDB erken aşamada iyi bir uyum sağlar
  • Veri boyutu büyüdüğünde de sorunsuz çalışır
  • Tutarlılık sorunları da iyi şekilde çözülür
  • MongoDB, Dynamo gibi dağıtık bir hash map değildir
  • MongoDB'nin aggregation özelliklerini iyi bilmeyen çok kişi var
  • Yeni geliştiricilerin SQL öğrenmesi gerektiği gerekçesiyle MongoDB kullanılmamasını söylemek haksızlık

• SQLite'ın avantajları

  • Dosya tabanlı olduğu için yedeklemek kolaydır
  • ORM kullanılırsa SQLite'tan Postgres'e kolayca yükseltme yapılabilir

• Teknik kusurlara işaret etmenin bir anlamı yok

  • MongoDB'den Rick Houlihan şu anda MongoDB'de çalışıyor

• MySQL'den Postgres'e geçiş nedenleri

  • Oracle'ın sahip olduğu MySQL iş açısından risk taşır
  • Postgres, veri tutarlılığını korumak için daha fazla araç sunar
  • Postgres'in extension özellikleri geliştirme süresinden tasarruf sağlar
  • Postgres'in araç ekosistemi daha olgun ve eksiksizdir

• Postgres'in temporal table desteği yetersiz

  • SQL:2011 sistem zamanı ve uygulama zamanı için "çift zamanlı" sürümleme gerekiyor
  • Karmaşık raporlama gereksinimleri olan regülasyona tabi sektörlerde temporal table idealdir

• SQLite kullanılma nedenini anlamıyorum

  • Postgres kurulumu zor değil
  • SQLite ile Postgres arasındaki farkların açıklanması gerekiyor

• Rick Houlihan'ın adını yanlış anmaktan dolayı özür

  • DynamoDB/Cassandra ile MongoDB karşılaştırması onun konuşmasında geçmişti
  • MongoDB, denormalize bilgiyi depolayan bir veritabanıdır ve erişim kalıpları değiştiğinde esnek değildir

• Bildiğin şeyi kullanmak ve işe yarayanı dağıtıma almak önemlidir

• MySQL, Javascript gibidir

  • Çok sayıda kötü karar ve risk unsuru vardır
  • İyi çalışır, ama Postgres varken özellikle kullanmak için bir neden yoktur

[touguy]

Postgres, veri tutarlılığını korumaya yönelik daha fazla araca sahip
=> Acaba bir örnek verebilir misiniz?

[leftliber]

Postgres'e kıyasla SQLite'ın bir dezavantajı da schema desteğinin olmaması galiba. Tablo sayısı onlarcayı aştığında tabloları schema bazında ayırarak tasarlamak daha düzenli oluyor, ama SQLite'ta bu mümkün olmadığından tüm ayrımları tablo adlarına koymak gerekiyor.