PV12現在オープンソースのRDBMSとしては、PostgreSQLとMySQLがほぼデファクトスタンダードになっているかと思います。Railsで開発を行なっているため、ActiveRecordの恩恵もあり、あまりDBの差異を意識せずにプログラミングを行う事も出来るので、そこまでどちらでなければのような拘りは無いのですが、PostgreSQLとMySQLで、個人の好み以上の明確な優位性や違いなどはあるのでしょうか?全般に置いてどちらかという事はあまり無いような気がしますが、こういう場合はこちらの方が良い、こういう特性、特徴を持ったシステムやアプリケーションではこちらの方が良いなど、ケースバイケースの具体的な例などもあれば教えて頂ければと思います。HerokuがPostgreSQLをデフォルトで採用している事や、周辺ツール、開発元、開発コミュニティの活発さなど、それぞれを取り巻く周辺技術や現在のトレンド、流れなどの観点からの回答でも構いません。warにもってこいの燃料投下ですね。:)元PostgreSQL派、現MySQL派、大昔にOracle社員だった時代もある人間の意見としては、まず、どちらも非常に完成度が高い。商用DBにほとんど遜色ない。RACとかみちゃうと、どっちも10年遅れてる感がなくもないけど)RDBMSに求められるものが過不足なく搭載されているのはPostgreSQL。MySQLは仕様がアンバランスだったり無駄が多かったりする。ぶっちゃけ今となってはInnoDB(PostgreSQLっぽいトランザクショナルなエンジンです)とそれ以外のストレージエンジンに差がつきすぎて、プラガブルなアーキテクチャが足かせになってる面のほうが大きい気がする。大規模なシステムでスケールさせる上で性能を限界まで引き出せるのはMySQL。書きだすときりがないけど、いくつか挙げると、PostgreSQLはマルチプロセス、MySQLはマルチスレッド。サーバ台数が増えて接続数が増えたり、秒間1万クエリを超える次元になってくるとコンテキストスイッチのオーバーヘッドが効いてくるし、Linuxの進化の方向も多スレッドに有利。(ただしNUMAになるとまた状況変わってきそう)レプリケーション構成の歴史が長く、柔軟性も大きいのでスケールアウトやマルチマスタなどの設計に柔軟性があり、そのぶん様々な実験がサードパーティ交えて行われてきており、ノウハウが蓄積されてきている。Clusterとかもある。実績面でも世界最大のユーザ(FacebookやGoogle)が直接パッチをコミットしてる。データのカッチリ感ではPostgreSQL歴史的にMySQLではデータの制約がゆるいので、例外を投げずに値をcoerceして保持することがある。MySQLは買収を繰り返して現在はOracle傘下という非常に不健全なスポンサーシップ状態にあり、将来的に不安がないといえば嘘になる。全般的に、PostgreSQLはバランスよく筋肉質で優等生。これからRDBを学ぶという人にはベストだと思います。Newsなどでみる限りトレンドはPostgreSQLにあるといってよいと思います。MySQLはパフォーマンス面で限界までしゃぶりつくせたり多機能だったりする一方で、学ぶことが多く罠にはまらずちゃんと使えるようになるまでの学習曲線が長いです。本格的なサービスを運用していると、細かいところでMySQLじゃないと厳しい場面が結構あります。したがって、熟練度の高い人にはMySQLかなと思います。以下、最近目にした関連リンクです。大事なことを指摘するのを忘れてました。PostgreSQLが追記型アーキテクチャってことです。これはアプリケーションの向き不向きを選ぶ重大な選択です。アクセスカウンターのように、レコードのあるカラムを+1していくだけのような用途では、追記型よりもin-place型のほうが有利です。in-placeなら、何度繰り返しても同じメモリ位置のそのバイトのみををひたすら書き換えていくだけ(+リングバッファな固定サイズWALへの書き込み)で済むのに対して、追記型だと、レコード自体をどんどん末尾に追加していくので、サイジングも難しく、重複によるかなりの無駄が生じます。結果として参照の局所性も損なわれますし、フラグメンテーションのリスク、もともとナチュラルな順序性があったデータがばらばらになってランダムI/Oになりやすいなど(InnoDBならクラスタードインデックスなので順序性はむしろ強制されていますが)、ダウンサイドのリスクは根の深いものがあります。I/Oを極限まで減らしてカリカリにチューニングしたいという局面ではかなりの足かせになります。これにともなうvacuumのコストも、ガベージコレクタの世界でスループットとレイテンシのトレードオフがあるように、深淵なトレードオフが存在するわりに、現在の実装はまだまだプリミティブな感じです。ぶっちゃけいろいろな意味で、性能を予想しにくいです。いうわけで、結果としては「性能(を出す・維持するための運用)を考えるならMySQL」という論点の繰り返しになりますね。8.3からHOTで大幅に改善したと指摘がありました。HOTは素晴らしい最適化ではありますが、これによって追記型アーキテクチャそのものが変わるわけではありません。インデックスが更新されない場合でも、依然レコード本体は(一部ではなく全部が)コピーされます。全体のコピー処理です。これは、ゼロコピー化やCopy-on-writeなどでコピー量を極限まで減らそうという最近のトレンドに反するもので、また行サイズが大きくなればなるほど性能差は顕著になります。メモリやI/Oの帯域的にも空間的にも無視できない無駄です。公平のために記すと、Vacuumがないと思われているMySQLですが、厳密にいうと、全くないわけではありません。InnoDBはMVCCをサポートしていますから、結局は複数の行バージョンを保持する仕組みを持っており、つまり不要になった古いバージョンを掃除する機構が必要です。これはOracle同様にロールバックセグメントを使って実装されており、パージ処理はメインスレッドが暇なとき(5.1)あるいは専用スレッド(5.5)にて実行されます。5.6からは複数のパージスレッドで並列実行も可能になり、このあたりは同じアドレス空間で動作する強みを活かしやすい分野だといえるかもしれません。ロールバックセグメントは基本的に独立したゴミため場ですから、MVCCによって通常のページが汚染されることはなく、したがってPostgreSQLのように定常的にページコンパクションのコストを払うこともありません。factorを上げるとHOTが効かないという、プロでも設定に悩むトレードオフもあります。これらのもろもろを総合して、「ぶっちゃけいろいろな意味で、性能を予想しにくいです。NoSQLの世界だと、CouchDBが追記型であったのに対して、MongoDBがin-placeを選択したというのも、面白いですね。factorを設定してすき間を作っておき、レコードサイズの増加に備えるという逆転の発想になっているのが面白いところです。この根底には、やはりレコードの移動(コンパクションなど)は不要なコストだし非直感的だ、という考え方が根強いのだと思います。