- ほとんどのWebアプリケーションは永続的なデータ保存を必要とするため、新しいアプリケーションを作るときはデフォルトで
Postgres を選ぶのがよい
なぜ sqlite ではないのか？
sqlite は良いDBだが、データは1つのファイルに保存される- これは、アプリケーションが1台のマシンでしか動かないことを意味する
- デスクトップアプリやモバイルアプリには適しているが、Webサイトには適していないことがある
- Webサイトでsqliteを使って成功している事例もあるが、たいていは独自のサーバーやインフラを自前で構築している場合である
- プラットフォームが提供する自動データベースバックアップや、複数のアプリケーションサーバーを構成する機能を諦めなければならないかもしれない
なぜ DynamoDB、Cassandra、または MongoDB ではないのか？
- これらのデータベースは優れた性能を発揮するが、前提条件が多い:
- アプリケーションが行う処理とアクセスパターンを正確に把握している必要がある
- 非常に大規模なデータ量までスケールさせる必要がある場合
- 一貫性の一部を諦められる場合
- これらのデータベースは分散ハッシュマップに近い形で動作するため、データの保存方法にクエリパターンの知識を反映させる必要がある
- アクセス（クエリ）パターンが変わると、データ全体を再処理しなければならないこともある
- リレーショナルデータベースなら簡単にインデックスを追加してクエリを実行できるが、NoSQLデータベースではそれが難しい
- 分析クエリには向いていない
- 大学生や新人開発者がMongoDBを使うなら、助けが必要になるだろう
なぜ Valkey ではないのか？
Redis として知られるこのデータベースは、非常に効率的なキャッシュとしてよく知られている- メインのデータベースとして使うこともできるが、次のような問題がある:
- すべてのデータをRAMに保存するため高速だが、RAM容量には限りがある
- データモデリングで妥協が必要になる
なぜ Datomic ではないのか？
- これをすでに知っているなら「金の星」を差し上げたい
Datomic はリレーショナルNoSQLデータベースで、「事前設計（Up-front Design）」の問題がなく、いくつかのきれいな特性を持っている
- データをテーブルではなくEAVT(entity-attribute-value-time)の組として保存し、汎用インデックスを使う
- クエリを書くときに作成者と調整する必要がない。ある時点の「現在時点」のデータベースをクエリすればよい。新しいデータ、さらには削除（または「撤回/retractions」とも呼ばれる）であっても、実際には以前のデータを消さない
- しかし、いくつか欠点がある:
- JVM言語でしか動かない
Clojure 以外の言語ではAPIがよくない- 構造の悪いクエリによって発生するエラーメッセージが非常に不親切である
- SQLツールのエコシステムのようなものがなく、ツールが不足している
なぜ XTDB ではないのか？
- Clojureユーザーはたくさんのデータベースを作る
Datomic と似ているが、次のような特徴がある:
- HTTP APIを提供しており、JVMに依存しない
- 「システム時間」と「有効時間」の2軸でクエリできる
- SQL APIをサポートしている
- しかし最大の問題は、まだ「新興」であることだ。SQL APIは昨年登場し、最近ストレージモデル全体を変更した
- 10年後も生き残っているだろうか？ 長期的なサポートが不確実である
なぜ Kafka ではないのか？
Kafka は非常に優れた「追記専用（Append-Only）」ログで、TB単位のデータ処理に適している- 複数のチームが管理する複数のサービスから流入するデータで、イベントソーシング系の処理を行いたい場合には驚くほどうまく機能する
- しかし
- 小規模であれば
Postgres のテーブルで十分代用できる
- Kafkaコンシューマーを作るのは、思っている以上にエラーを起こしやすい。結局のところ、ログ上の自分の位置を追跡しなければならないからだ
- 追加のインフラを管理しなければならない
なぜ ElasticSearch ではないのか？
- データ検索がプロダクトの主機能なら、ElasticSearchは適した製品である
- データをETLし、全体のプロセスを管理する必要はあるが、ElasticSearchは検索のために作られており、検索をうまくこなす
- しかし検索が主機能でないなら、
Postgres の組み込みテキスト検索機能でも十分である
なぜ MSSQL または Oracle DB ではないのか？
- 自分自身に問うべき本当の質問は、「その価格に見合う価値があるのか？」である
- ライセンス費用だけでなく、ロックインのコストも考慮すべきである
- Oracleにデータを保存すると、永続的にOracleへ費用を支払い続け、開発者を継続的に教育しなければならない
- エンタープライズ機能と財布のどちらかを永遠に選ばなければならない
- 特定の機能がどうしても必要な場合でなければ、使わないほうがよい
- MSSQLなしでは生きられないキラー機能がない限り、使うべきではない
なぜ MySQL ではないのか？
- この部分は少し読者の助けが必要である
MySQL は Oracle が所有しており、一部の機能はエンタープライズエディションに閉じ込められている
- もちろん、
MySQL は長年使われてきており、広く使われている無料エディションもある
- 私は
Postgres のほうがより良い選択だと信じているが、MySQL については追加の情報が必要である
なぜAIベクターDBではないのか？
- ほとんどのAIベクターDBは新しい技術であり、利用にはリスクがある
- AIバブルを前提としたビジネスには慎重に向き合うべきである
- あなたのビジネスがまた別のAIグリフト（詐欺）だったとしても、せいぜい
import openai で十分だろう
なぜGoogle Sheetsではないのか？
18件のコメント
Firestore...
こう断言する記事は、たいていジュニアがやりがちなミスなんだけど……
代わりにかわいい
C
SVを
差し上げ
ます
zzz
良い情報を得るには炎上狙いをしろ……という冗談を、なんだか思い出しますね（笑）
とはいえ、たいていのバックエンド開発者が最初に使うのは PostgreSQL ですし……
私はPostgresのほうがより良い選択だと信じていますが、MySQLについての追加情報が必要です
（笑）;;;;
MySQL Enterpriseの本当の問題はライセンスではなく、有償購入者であっても障害が起きた際のサポートが本当にひどいことです。
以前、MySQLのインデックスが壊れて起動しなくなったときも、サポートを依頼してOracleにサポートチケットを切ってもらえば電話対応します、というだけでした。
結局、顧客側でこれは無理だとなって、こちらで解決しなければならなかったので。
Oracleを信じてEnterpriseを使うくらいなら、無料版が一番です..
なぜmariadb、impala、hive、kuduではないのか
MySQLのエンタープライズ機能は、自前のコネクションプールのように、そこまで必要な機能ではないし……
本当にエンタープライズ用途なら、これを使うより手前にSQLプロキシを設置したほうが、負荷分散にはもっと効果的です。
PgSQLは好きだけど……MySQLは調べもせずに「とにかく嫌だ」で済ませるなんて……ｗｗｗ
ただ Postgres を使ってください
ただ MySQL を使ってください…
MariaDB は??
かなり大きな論争を呼びそうな投稿ですね…
SQLite を使う理由は、シンプルで、たいていの規模では普通にうまく動くからです。
とりあえず SQLite で先に実装しておいて、後で必要になったら PostgreSQL に移行しても、それほど難しくはないと思います。
忘れたころに出てくる Postgres 礼賛記事。もうこれはそのまま楽しみましょう！
とにかくあらゆる場所で Postgres を使おう
PostgreSQL で十分
Postgres はいつからかっこよくなったのか
Hacker Newsの意見
MongoDBに対する否定的な意見は多いが、その大半は誤った情報である
SQLiteの利点
技術的欠陥を指摘することには意味がない
MySQLからPostgresへ移行する理由
Postgresの時間テーブル対応は不十分である
SQLiteを使う理由が理解できない
Rick Houlihanの名前を誤って言及したことへの謝罪
知っているものを使い、有用なものをデプロイすることが重要である
MySQLはJavascriptのようなものだ
Postgres はデータの整合性を維持するための手段がより多いです
=> もしよければ、例はありますか？
Postgres と比べた SQLite の欠点の一つは、schema をサポートしていないことですね。テーブルが数十個以上と多くなると、schema 単位でテーブルを分けて設計したほうがすっきりするのですが、SQLite ではそれができないので、テーブル名にすべての区分を入れなければならないんです。