Cukup gunakan Postgres

• Sebagian besar aplikasi web memerlukan penyimpanan data yang persisten, jadi saat membuat aplikasi baru, sebaiknya pilih Postgres sebagai default

Mengapa bukan sqlite?

• sqlite adalah DB yang bagus, tetapi datanya disimpan dalam satu file
• Ini berarti aplikasi hanya berjalan di satu perangkat
• Cocok untuk aplikasi desktop atau mobile, tetapi mungkin tidak cocok untuk website
  • Ada contoh sukses penggunaan sqlite untuk website, tetapi biasanya itu terjadi ketika mereka membangun sendiri server dan infrastrukturnya
• Anda mungkin harus melepaskan backup database otomatis yang disediakan platform serta kemampuan untuk mengonfigurasi beberapa server aplikasi

Mengapa bukan DynamoDB, Cassandra, atau MongoDB?

• Database ini menunjukkan performa yang sangat baik, tetapi memiliki banyak prasyarat:
  • Anda harus tahu secara tepat pekerjaan dan pola akses yang harus dilakukan aplikasi
  • Ketika perlu melakukan penskalaan ke volume data yang sangat besar
  • Ketika Anda bisa mengorbankan sebagian konsistensi
• Database ini bekerja dengan cara yang mirip distributed hash map, sehingga pengetahuan tentang pola kueri harus tercermin dalam cara data disimpan
• Jika pola akses (kueri) berubah, Anda mungkin harus memproses ulang seluruh data
• Database relasional bisa menjalankan kueri dengan mudah lewat penambahan indeks, tetapi database NoSQL sulit melakukannya
• Tidak cocok untuk kueri analitik
• Jika mahasiswa atau developer junior menggunakan MongoDB, mereka kemungkinan akan butuh bantuan

Mengapa bukan Valkey?

• Database ini, yang dikenal sebagai Redis, terkenal sebagai cache yang sangat efisien
• Bisa digunakan sebagai database utama, tetapi ada masalah berikut:
  • Semua data disimpan di RAM sehingga cepat, tetapi kapasitas RAM terbatas
  • Diperlukan kompromi dalam pemodelan data

Mengapa bukan Datomic?

• Jika Anda sudah tahu ini, saya akan memberi Anda "bintang emas"
• Datomic adalah database NoSQL relasional yang tidak memiliki masalah "perancangan di awal (Up-front Design)" dan punya beberapa sifat yang rapi
  • Menyimpan data sebagai pasangan EAVT(entity-attribute-value-time), bukan tabel, dan menggunakan indeks umum
  • Saat menulis kueri, tidak perlu berkoordinasi dengan penulisnya. Cukup kueri database pada 'titik saat ini' di waktu tertentu. Data baru, bahkan penghapusan (atau 'retractions/pencabutan') pun, sebenarnya tidak menghapus data sebelumnya
• Namun ada beberapa kekurangan:
  • Hanya berjalan di bahasa JVM
  • API-nya kurang baik di bahasa selain Clojure
  • Pesan error yang muncul dari kueri dengan struktur yang salah sangat tidak ramah
  • Kekurangan alat karena tidak ada ekosistem alat seperti SQL

Mengapa bukan XTDB?

• Pengguna Clojure membuat banyak database
• Mirip dengan Datomic, tetapi memiliki ciri-ciri berikut:
  • Menyediakan HTTP API sehingga tidak bergantung pada JVM
  • Dapat dikueri dengan dua sumbu, yaitu "waktu sistem" dan "waktu valid"
  • Mendukung SQL API
• Tetapi masalah terbesarnya adalah, ini masih "pendatang baru". SQL API-nya keluar tahun lalu, dan baru-baru ini seluruh model penyimpanannya diubah
  • Apakah masih akan bertahan 10 tahun lagi? Dukungan jangka panjangnya tidak pasti

Mengapa bukan Kafka?

• Kafka adalah log "append-only" yang sangat baik dan cocok untuk pemrosesan data skala TB
• Jika Anda ingin melakukan pekerjaan bergaya event sourcing dengan data yang masuk dari banyak layanan yang dikelola oleh banyak tim, ini bekerja dengan sangat baik
• Namun
  • Pada skala kecil, tabel di Postgres sudah cukup sebagai penggantinya
  • Membuat consumer Kafka lebih mudah memicu error daripada yang dibayangkan. Pada akhirnya, Anda harus melacak sendiri posisi Anda di dalam log
  • Anda harus mengelola infrastruktur tambahan

Mengapa bukan ElasticSearch?

• Jika pencarian data adalah fungsi utama produk, ElasticSearch adalah produk yang tepat
  • Anda harus melakukan ETL data dan mengelola seluruh prosesnya, tetapi ElasticSearch dibuat untuk pencarian dan melakukannya dengan baik
• Tetapi jika pencarian bukan fungsi utama, fitur pencarian teks bawaan Postgres sudah cukup
  • Nantinya Anda bisa menambahkan search engine khusus

Mengapa bukan MSSQL atau Oracle DB?

• Pertanyaan sebenarnya yang harus Anda tanyakan pada diri sendiri: "Apakah nilainya sepadan dengan biayanya?"
• Pertimbangkan bukan hanya biaya lisensi, tetapi juga biaya lock-in
• Jika Anda menyimpan data di Oracle, Anda akan membayar Oracle selamanya dan harus terus melatih developer
  • Anda harus memilih salah satu selamanya: fitur enterprise atau dompet Anda
• Sebaiknya hindari menggunakannya kecuali Anda benar-benar membutuhkan fitur tertentu
  • Jangan gunakan kecuali ada fitur killer yang membuat Anda tidak bisa hidup tanpa MSSQL

Mengapa bukan MySQL?

• Bagian ini sedikit membutuhkan bantuan pembaca
• MySQL dimiliki oleh Oracle, dan beberapa fitur dikunci di edisi enterprise
  • Tentu saja, MySQL sudah digunakan sejak lama, dan ada edisi gratis yang dipakai secara luas
• Saya percaya Postgres adalah pilihan yang lebih baik, tetapi saya memerlukan informasi tambahan tentang MySQL

Mengapa bukan AI vector DB?

• Sebagian besar AI vector DB adalah teknologi baru, sehingga ada risiko dalam penggunaannya
  • Bisnis yang berdasar pada gelembung AI harus didekati dengan hati-hati
• Bahkan jika bisnis Anda adalah AI grift(penipuan) lainnya, cukup import openai saja

Mengapa bukan Google Sheets?

• Tidak ada kekurangan khusus; kalau perlu, silakan gunakan

[hilft]

Sebaiknya pakai saja Postgres.

Firestore...

[wedding]

Artikel yang menyatakan hal seperti ini biasanya adalah kesalahan yang dilakukan para junior..

[nemorize]

Sebagai gantinya
C yang imut
SV akan
kami berikan
kepada Anda

[roxie]

zzz

[bus710]

Lelucon “kalau mau dapat informasi bagus, bikin kontroversi dulu”… entah kenapa jadi teringat ya, haha.
Bagaimanapun juga, karena PostgreSQL adalah hal pertama yang paling banyak dipakai oleh kebanyakan developer backend…

[dicebattle]

Saya yakin Postgres adalah pilihan yang lebih baik, tetapi saya perlu informasi tambahan tentang MySQL

wkwkwk;;;;

[koxel]

Masalah nyata MySQL Enterprise itu sebenarnya bukan lisensinya, melainkan bahkan pembeli berbayar pun mendapat dukungan yang benar-benar menyebalkan saat terjadi gangguan.
Sebelumnya, saat indeks MySQL rusak dan tidak bisa dijalankan, meski kami meminta dukungan, dari Oracle ujung-ujungnya cuma bilang akan memberi dukungan lewat telepon kalau kami membuka tiket dukungan dan mengajukan permintaan.
Pada akhirnya, karena pihak klien merasa ini tidak akan beres, kami yang harus menyelesaikannya sendiri.
Daripada percaya Oracle lalu memakai Enterprise, yang gratis memang terbaik..

[kaydash]

Kenapa bukan mariadb, impala, hive, atau kudu

[koxel]

Fitur enterprise MySQL itu seperti connection pool bawaan sendiri, yang sebenarnya tidak terlalu perlu..
Kalau benar-benar enterprise, daripada pakai ini lebih efektif memasang SQL proxy di depan untuk pembagian beban.
Saya suka Pgsql, tapi masa soal MySQL bahkan tidak cari tahu lalu langsung asal berkomentar.. wkwk

[iolothebard]

Pakai saja MySQL…

• Mengapa bukan Postresql? Bagian ini butuh sedikit bantuan.

[love7peace]

MariaDB bagaimana??

[aer0700]

Postingan yang sepertinya bisa memicu perdebatan besar...

[aer0700]

Alasan memakai SQLite itu sederhana: ia bekerja dengan baik untuk kebanyakan skala. Bukankah lebih mudah kalau implementasinya dibuat dulu dengan SQLite, lalu nanti kalau memang perlu pindah ke Postgres juga tidak akan terlalu sulit?

[xguru]

Tulisan puja-puji Postgres yang muncul lagi saat orang mulai lupa. Sekarang nikmati saja!

Gunakan saja Postgres untuk semuanya
PostgreSQL sudah lebih dari cukup
Kapan Postgres mulai jadi keren?

[GN⁺]

Pendapat Hacker News

• Ada banyak opini negatif tentang MongoDB, tetapi sebagian besar merupakan informasi yang keliru

  • MongoDB cocok digunakan pada tahap awal
  • Tetap bekerja tanpa masalah saat ukuran data membesar
  • Masalah konsistensi juga ditangani dengan baik
  • MongoDB bukan distributed hash map seperti Dynamo
  • Banyak orang yang tidak benar-benar memahami fitur agregasi MongoDB
  • Tidak adil mengatakan jangan pakai MongoDB hanya karena developer junior harus belajar SQL

• Kelebihan SQLite

  • Berbasis file sehingga mudah dibackup
  • Jika memakai ORM, upgrade dari SQLite ke Postgres bisa dilakukan dengan mudah

• Menunjukkan cacat teknis bukanlah hal yang berarti

  • Rick Houlihan dari MongoDB saat ini bekerja di MongoDB

• Alasan migrasi dari MySQL ke Postgres

  • MySQL yang dimiliki Oracle memiliki risiko bisnis
  • Postgres punya lebih banyak alat untuk menjaga konsistensi data
  • Fitur ekstensi Postgres menghemat waktu pengembangan
  • Ekosistem tooling Postgres lebih matang dan lengkap

• Dukungan tabel temporal di Postgres masih kurang

  • Diperlukan versioning "bi-temporal" SQL:2011 untuk system time dan application time
  • Di industri yang diatur ketat dengan kebutuhan pelaporan yang kompleks, tabel temporal adalah pilihan ideal

• Tidak paham alasan menggunakan SQLite

  • Instalasi Postgres tidak sulit
  • Perlu penjelasan tentang perbedaan antara SQLite dan Postgres

• Permintaan maaf karena salah menyebut nama Rick Houlihan

  • Perbandingan DynamoDB/Cassandra dengan MongoDB berasal dari ceramahnya
  • MongoDB adalah database untuk menyimpan informasi yang didenormalisasi, sehingga tidak fleksibel ketika pola akses berubah

• Yang penting adalah memakai apa yang sudah dikenal dan mendeploy sesuatu yang berguna

• MySQL itu seperti Javascript

  • Penuh keputusan buruk dan faktor risiko
  • Memang bekerja dengan baik, tetapi tidak ada alasan khusus untuk memakainya ketika Postgres sudah ada

[touguy]

Postgres memiliki lebih banyak alat untuk menjaga konsistensi data
=> Mungkin ada contohnya?

[leftliber]

Satu kekurangan SQLite dibandingkan Postgres adalah SQLite ternyata tidak mendukung schema. Kalau jumlah tabel sudah banyak, puluhan atau lebih, desain dengan memisahkan tabel per schema itu lebih rapi, tetapi karena SQLite tidak bisa melakukan itu, semua pembeda harus dimasukkan ke nama tabel.