MySQL(MarisDB)派からPostgreSQL派になった経緯を思い返す

（あらすじ）
～2015年くらいまではMySQL(MariaDB)の優勢だと思ってたんだけど、周囲の状況が変わっていて、今ならPostgreSQLだなって思うことが多くなった。

2010年頃には、OSSのDBといえばまずMySQL、時点でPostgreSQLという風潮があったように思う。

当時はまだBaaSなんてなかったから、規模を問わずみんな自分達でDBを管理していた。そのせいかは分からないが、「広く使われている」ことのアドバンテージが今より強かった気がする。

当時の個人的な印象を言うと、MySQLは実用重視の柔軟派で、Postgresは頭の固い優等生くん、みたいな感じだった。

MySQLにはストレージエンジンという構成部品がある。これはストレージエンジンAPIを実装するプラグインだ。ストレージエンジンを入れ換えると、アプリケーション側のSQL等は変更ないまま、データの読み書き機能をまったく異なるものに変えることができる。

実際、水平分散プラグインや保存先をメモリ上にするプラグインなど、様々なストレージエンジンが開発されている。
なんとも夢のある機能……なのだが、現実はそう上手くはいかなかった。

まず第一に、ストレージエンジンを実装するのはムチャクチャ大変で、誰でも簡単に作れるようなものではない。
特定のニーズに合わせた専用のストレージエンジンを作ることは、技術的には可能だが、コスト面ではなかなか厳しい。ほとんどのケースではデフォルトのInnoDBで事足りる。

第二に、特殊な用途について、そもそも無理にMySQLでやる必要がない。
NoSQLだけではなく、静的生成やキャッシュ技術、パブリッククラウドの強力なマネージドDBの登場、認証のJWT化など、ありとあらゆる方法でDBのボトルネック解消が試みられてきた。その中で、それでもあえてストレージエンジンを作るという選択肢の必要性は相対的に下がっている。

現在は、様々な周辺技術やインフラが成熟し選択肢が増えたことで、むしろ「餅は餅屋」の考えに戻ってきている。RDBはRDBの仕事に専念した方がコスパがいい。そうなると、プラガブルなストレージエンジンの構造はむしろデメリットにさえなりかねない。

その点で、Postgresは最初から「RDBとしての仕事をしっかりする」方を向いていた。

たとえば、FirebaseのOSS Alternativeを謳うBaaSのSupabaseは、DBに（NoSQLではなく）RDBを採用している。そこで選ばれたのはPostgreSQLだった。

これはおそらく、SupabaseのようなBaaSで安全にマルチテナントDB（複数の顧客のデータが同じテーブルに入る）構成をするためには、Row Level Securityが必須だからだ。RLSは名前の通り行レベルでのセキュリティ設定で、商用RDBやPostgresには実装済みだが、MySQL/MariaDBには未実装。

supabaseのコアであるPostgRESTは、RLSを上手く使ってRDBの機能だけでユーザーごとのデータへのアクセス権を管理している。

RLSを一度使ってみたところ、「仮にサーバーサイドでWHEREを書き忘れたとしても、RLSの存在により他者のデータは閲覧／更新／削除できない」ことの安心感は半端なかった。RLSなしの生活に戻れないかもしれない……。

話が逸れたけど、私の選択の基準はこう。

• RDBにはRDBとしての仕事を求めている
• RDBが不得意なことには他の技術を使う
• MySQL/MariaDBの拡張性はさほど魅力を感じていない
• それよりもPostgreSQLのRDBとしての高機能さを選択した

あとはまぁ……MySQLとMariaDBが分裂したのもマイナス要因だったなぁ……