SQLiteとMySQLとPostgreSQL：リレーショナルデータベース管理システムの比較

投稿日: 2022-04-20 2022-10-23
タグ: Conceptual, Databases, mysql, postgresql, SQLite

序章

データを行と列のテーブルに編成するリレーショナルデータモデルは、データベース管理ツールで主流です。現在、NoSQLやNewSQLなどの他のデータモデルがありますが、リレーショナルデータベース管理システム（RDBMS）は、世界中でデータを保存および管理するための主要なのままです。

この記事では、最も広く実装されている3つのオープンソースRDBMS、 SQLite 、 MySQL 、およびPostgreSQLを比較対照します。具体的には、各RDBMSが使用するデータ型、それらの長所と短所、およびそれらが最適化される状況について説明します。

データベース管理システムについて少し

データベースは、論理的にモデル化された情報のクラスター、またはデータです。一方、データベース管理システム（DBMS）は、データベースと対話するコンピュータープログラムです。 DBMSを使用すると、データベースへのアクセスの制御、データの書き込み、クエリの実行、およびデータベース管理に関連するその他のタスクの実行を行うことができます。

データベース管理システムは「データベース」と呼ばれることがよくありますが、2つの用語は互換性がありません。データベースは、コンピューターに保存されているデータだけでなく、任意のデータのコレクションにすることができます。対照的に、DBMSは、データベースとの対話を可能にするソフトウェアを具体的に指します。

すべてのデータベース管理システムには、データの保存方法とアクセス方法を構造化する基盤となるモデルがあります。リレーショナルデータベース管理システムは、リレーショナルデータモデルを採用したDBMSです。このリレーショナルモデルでは、データはテーブルに編成されています。 RDBMSのコンテキストでは、テーブルはより正式にはRelationsと呼ばれます。リレーションは、テーブルの行であるタプルのセットであり、各タプルは、テーブルの列である属性のセットを共有します。

ほとんどのリレーショナルデータベースは、構造化クエリ言語（SQL）を使用してデータを管理およびクエリします。ただし、多くのRDBMSは、SQLの独自の方言を使用します。これには、特定の制限または拡張機能がある場合があります。これらの拡張機能には通常、ユーザーが標準SQLを使用する場合よりも複雑な操作を実行できるようにする追加機能が含まれています。

注：「標準SQL」という用語は、このガイド全体で何度か出てきます。 SQL標準は、米国規格協会（ANSI）、国際標準化機構（ISO）、および国際電気標準会議（IEC）によって共同で管理されています。。この記事で「標準SQL」または「SQL標準」について言及する場合は常に、これらの機関によって公開されているSQL標準の現在のバージョンを指します。

完全なSQL標準は大きく複雑であることに注意してください。完全なコアSQL：2011準拠には、179の機能が必要です。このため、ほとんどのRDBMSは標準全体をサポートしていませんが、一部のRDBMSは他のRDBMSよりも完全に準拠しています。

データ型と制約

各列にはデータ型が割り当てられ、その列で許可されるエントリの種類が決まります。異なるRDBMSは異なるデータ型を実装しますが、これらは常に直接交換可能であるとは限りません。一般的なデータ型には、日付、文字列、整数、ブール値などがあります。

データベースに整数を格納することは、テーブルに数値を格納するよりも微妙な違いがあります。数値データ型は、正の数と負の数の両方を表すことができる符号付き、または正の数のみを表すことができる符号なしのいずれかです。たとえば、MySQLの tinyint データ型は8ビットのデータを保持できます。これは256の可能な値に相当します。このデータ型の符号付きの範囲は-128〜127ですが、符号なしの範囲は0〜255です。

データベースに許可されるデータを制御できることが重要です。データベース管理者は、テーブルに制約を課して、テーブルに入力できる値を制限する場合があります。通常、制約は1つの特定の列に適用されますが、一部の制約はテーブル全体にも適用できます。 SQLで一般的に使用されるいくつかの制約は次のとおりです。

UNIQUE：この制約を列に適用すると、その列の2つのエントリが同一にならないようになります。
NOT NULL：この制約により、列に何も含まれないようになります NULL エントリ。
PRIMARY KEY：の組み合わせ UNIQUE と NOT NULL、 PRIMARY KEY 制約により、列にエントリがないことが保証されます NULL そして、すべてのエントリが異なること。
FOREIGN KEY：A FOREIGN KEY は、を参照する1つのテーブルの列です。 PRIMARY KEY 別のテーブルの。この制約は、2つのテーブルをリンクするために使用されます。へのエントリ FOREIGN KEY 列はすでに親に存在している必要があります PRIMARY KEY 書き込みプロセスが成功するための列。
CHECK：この制約は、列に入力できる値の範囲を制限します。たとえば、アプリケーションがアラスカの居住者のみを対象としている場合は、 CHECK 99501から99950までのエントリのみを許可するZIPコード列の制約。

データベース管理システムの詳細については、NoSQLデータベース管理システムとモデルの比較に関する記事をご覧ください。

リレーショナルデータベース管理システム全般について説明したので、この記事で取り上げる3つのオープンソースリレーショナルデータベースの最初のSQLiteに移りましょう。

SQLite

SQLiteは、自己完結型のファイルベースの完全にオープンソースのRDBMSであり、移植性、信頼性、および低メモリ環境でも強力なパフォーマンスで知られています。そのトランザクションは、システムがクラッシュしたり停電したりした場合でも、ACID準拠です。

SQLiteプロジェクトのWebサイトは、これを「サーバーレス」データベースとして説明しています。ほとんどのリレーショナルデータベースエンジンは、プログラムが要求を中継するプロセス間通信を介してホストサーバーと通信するサーバープロセスとして実装されます。対照的に、SQLiteでは、データベースにアクセスするすべてのプロセスがデータベースディスクファイルを直接読み書きできます。これにより、サーバープロセスを構成する必要がなくなるため、SQLiteのセットアッププロセスが簡素化されます。同様に、SQLiteデータベースを使用するプログラムに必要な構成はありません。必要なのはディスクへのアクセスだけです。

SQLiteは無料のオープンソースソフトウェアであり、使用するために特別なライセンスは必要ありません。ただし、このプロジェクトでは、圧縮と暗号化に役立ついくつかの拡張機能が提供されています（それぞれ1回限りの料金がかかります）。さらに、このプロジェクトでは、それぞれ年会費でさまざまな商用サポートパッケージを提供しています。

SQLiteでサポートされているデータ型

SQLiteでは、次のストレージクラスに編成されたさまざまなデータ型を使用できます。

データ・タイプ	説明
`null`	を含む `NULL` 値。
`integer`	値の大きさに応じて1、2、3、4、6、または8バイトで格納される符号付き整数。
`real`	8バイトの浮動小数点数として格納された実数または浮動小数点値。
`text`	データベースエンコーディングを使用して格納されたテキスト文字列。UTF-8、UTF-16BE、またはUTF-16LEのいずれかです。
`blob`	データの任意のblob。すべてのblobは、入力されたとおりに正確に格納されます。

SQLiteのコンテキストでは、「ストレージクラス」と「データ型」という用語は互換性があると見なされます。 SQLiteのデータ型とSQLite型の親和性について詳しく知りたい場合は、このテーマに関するSQLiteの公式ドキュメントを確認してください。

SQLiteの利点

小さなフットプリント：その名前が示すように、SQLiteライブラリは非常に軽量です。使用するスペースは、インストールされているシステムによって異なりますが、600KiB未満のスペースしか使用できません。さらに、完全に自己完結型であるため、SQLiteを機能させるためにシステムにインストールする必要のある外部依存関係はありません。
ユーザーフレンドリー：SQLiteは、箱から出してすぐに使用できる「ゼロ構成」データベースと呼ばれることもあります。 SQLiteはサーバープロセスとして実行されません。つまり、SQLiteを停止、開始、または再起動する必要はなく、管理する必要のある構成ファイルも付属していません。これらの機能は、SQLiteのインストールからアプリケーションとの統合までのパスを合理化するのに役立ちます。
ポータブル：通常、データを個別のファイルの大きなバッチとして保存する他のデータベース管理システムとは異なり、SQLiteデータベース全体が単一のファイルに保存されます。このファイルは、ディレクトリ階層のどこにでも配置でき、リムーバブルメディアまたはファイル転送プロトコルを介して共有できます。

SQLiteのデメリット

制限された同時実行性：複数のプロセスが同時にSQLiteデータベースにアクセスしてクエリを実行できますが、データベースに変更を加えることができるのは1つのプロセスだけです。つまり、SQLiteは他のほとんどの組み込みデータベース管理システムよりも優れた同時実行性をサポートしていますが、MySQLやPostgreSQLなどのクライアント/サーバーRDBMSほど多くはサポートできません。
ユーザー管理なし：データベースシステムには、多くの場合、ユーザー、またはデータベースとテーブルへの事前定義されたアクセス権限を持つ管理対象接続がサポートされています。 SQLiteは通常のディスクファイルに対して直接読み取りと書き込みを行うため、適用可能なアクセス許可は、基盤となるオペレーティングシステムの一般的なアクセス許可のみです。このため、SQLiteは、特別なアクセス許可を持つ複数のユーザーを必要とするアプリケーションには適していません。
セキュリティ：サーバーを使用するデータベースエンジンは、場合によっては、SQLiteのようなサーバーレスデータベースよりもクライアントアプリケーションのバグからの保護を強化できます。たとえば、クライアント内の漂遊ポインタはサーバー上のメモリを破壊することはできません。また、サーバーは単一の永続的なプロセスであるため、クライアントサーバーデータベースはサーバーレスデータベースよりも正確にデータアクセスを制御できます。これにより、よりきめ細かいロックとより優れた同時実行性が可能になります。

SQLiteを使用する場合

組み込みアプリケーション：SQLiteは、移植性が必要で、将来の拡張を必要としないアプリケーションに最適なデータベースです。例としては、シングルユーザーのローカルアプリケーション、モバイルアプリケーション、ゲームなどがあります。
ディスクアクセスの置き換え：アプリケーションがファイルをディスクに対して直接読み書きする必要がある場合、SQLの使用に伴う追加機能とシンプルさのためにSQLiteを使用すると便利な場合があります。
テスト：多くのアプリケーションでは、追加のサーバープロセスを使用するDBMSを使用して機能をテストするのはやり過ぎかもしれません。 SQLiteにはメモリ内モードがあり、実際のデータベース操作のオーバーヘッドなしにテストをすばやく実行できるため、テストに最適です。

SQLiteを使用しない場合

大量のデータの処理：ディスクドライブとファイルシステムがデータベースのサイズ要件もサポートしている限り、SQLiteは最大140TBのサイズのデータベースを技術的にサポートできます。ただし、SQLite Webサイトは、1TBに近いデータベースを一元化されたクライアントサーバーデータベースに格納することを推奨しています。そのサイズ以上のSQLiteデータベースは管理が難しいためです。
大量の書き込み：SQLiteでは、一度に1つの書き込み操作しか実行できないため、スループットが大幅に制限されます。アプリケーションが多くの書き込み操作または複数の同時ライターを必要とする場合、SQLiteはニーズに適していない可能性があります。
ネットワークアクセスが必要です：SQLiteはサーバーレスデータベースであるため、データへの直接ネットワークアクセスを提供しません。このアクセスはアプリケーションに組み込まれています。 SQLiteのデータがアプリケーションとは別のマシンにある場合は、ネットワーク全体で高帯域幅のエンジンからディスクへのリンクが必要になります。これは高価で非効率的なソリューションであり、そのような場合はクライアントサーバーDBMSの方が適している可能性があります。

MySQL

DB-Enginesランキングによると、MySQLは、サイトが2012年にデータベースの人気を追跡し始めて以来、最も人気のあるオープンソースRDBMSです。これは、Twitter、Facebook、Netflix、Spotifyなど、世界最大のWebサイトやアプリケーションの多くを強化する機能豊富な製品です。 MySQLの使用を開始するのは比較的簡単です。これは、主に網羅的なドキュメントと大規模な開発者コミュニティ、およびオンラインのMySQL関連リソースの豊富さのおかげです。

MySQLは、標準SQLに完全に準拠することを犠牲にして、速度と信頼性を考慮して設計されました。 MySQL開発者は、標準SQLへの準拠に継続的に取り組んでいますが、それでも他のSQL実装に遅れをとっています。ただし、コンプライアンスに近づけるためのさまざまなSQLモードと拡張機能が付属しています。

SQLiteを使用するアプリケーションとは異なり、MySQLデータベースを使用するアプリケーションは、別のデーモンプロセスを介してSQLiteにアクセスします。サーバープロセスはデータベースと他のアプリケーションの間にあるため、データベースにアクセスできるユーザーをより細かく制御できます。

MySQLは、その機能を拡張し、操作を容易にする、豊富なサードパーティのアプリケーション、ツール、および統合ライブラリに影響を与えました。これらのサードパーティツールの中でより広く使用されているものには、 phpMyAdmin 、 DBeaver 、およびHeidiSQLがあります。

MySQLでサポートされているデータ型

MySQLのデータ型は、数値型、日付と時刻の型、文字列型の3つの大きなカテゴリに分類できます。

数値タイプ：

データ・タイプ	説明
`tinyint`	非常に小さい整数。この数値データ型の符号付き範囲は-128〜127ですが、符号なし範囲は0〜255です。
`smallint`	小さな整数。この数値タイプの符号付き範囲は-32768〜32767ですが、符号なし範囲は0〜65535です。
`mediumint`	中型の整数。この数値データ型の符号付き範囲は-8388608〜8388607ですが、符号なし範囲は0〜16777215です。
`int` また `integer`	通常サイズの整数。この数値データ型の符号付き範囲は-2147483648〜2147483647ですが、符号なし範囲は0〜4294967295です。
`bigint`	大きな整数。この数値データ型の符号付き範囲は-9223372036854775808〜9223372036854775807であり、符号なし範囲は0〜18446744073709551615です。
`float`	小さい（単精度）浮動小数点数。
`double`, `double precision`、また `real`	通常のサイズ（倍精度）の浮動小数点数。
`dec`, `decimal`, `fixed`、また `numeric`	パックされた固定小数点数。このデータ型のエントリの表示長は、列の作成時に定義され、すべてのエントリはその長さに準拠します。
`bool` また `boolean`	ブール値は、2つの可能な値のみを持つデータ型であり、通常は次のいずれかです。 `true` また `false`.
`bit`	1から64までの値ごとのビット数を指定できるビット値タイプ。

日付と時刻のタイプ：

データ・タイプ	説明
`date`	として表される日付 `YYYY-MM-DD`.
`datetime`	日付と時刻を示すタイムスタンプ。 `YYYY-MM-DD HH:MM:SS`.
`timestamp`	Unixエポック（1970年1月1日の00:00:00）からの経過時間を示すタイムスタンプ。
`time`	として表示される時刻 `HH:MM:SS`.
`year`	2桁または4桁の形式で表された年で、デフォルトは4桁です。

文字列タイプ：

データ・タイプ	説明
`char`	固定長の文字列。このタイプのエントリは、格納時に指定された長さに合うように右側にスペースが埋め込まれます。
`varchar`	可変長の文字列。
`binary`	に似ています `char` タイプですが、非バイナリ文字列ではなく、指定された長さのバイナリバイト文字列です。
`varbinary`	に似ています `varchar` タイプですが、非バイナリ文字列ではなく、可変長のバイナリバイト文字列です。
`blob`	データの最大長が65535（2 ^ 16-1）バイトのバイナリ文字列。
`tinyblob`	A `blob` データの最大長が255（2 ^ 8-1）バイトの列。
`mediumblob`	A `blob` データの最大長が16777215（2 ^ 24-1）バイトの列。
`longblob`	A `blob` データの最大長が4294967295（2 ^ 32-1）バイトの列。
`text`	最大長が65535（2 ^ 16-1）文字の文字列。
`tinytext`	A `text` 最大長が255（2 ^ 8-1）文字の列。
`mediumtext`	A `text` 最大長が16777215（2 ^ 24-1）文字の列。
`longtext`	A `text` 最大長が4294967295（2 ^ 32-1）文字の列。
`enum`	列挙型。これは、テーブルの作成時に宣言される値のリストから単一の値を取得する文字列オブジェクトです。
`set`	列挙型と同様に、0個以上の値を持つことができる文字列オブジェクト。各値は、テーブルの作成時に指定される許可された値のリストから選択する必要があります。

MySQLの利点

人気と使いやすさ：世界で最も人気のあるデータベースシステムの1つとして、MySQLの使用経験があるデータベース管理者が不足することはありません。同様に、MySQLデータベースのインストールと管理の方法については、印刷物とオンラインのドキュメントが豊富にあります。これには、データベースの使用を開始するプロセスを簡素化することを目的とした、phpMyAdminなどのサードパーティツールが多数含まれています。
セキュリティ：MySQLには、インストールのパスワードセキュリティレベルの設定、 root ユーザーのパスワードの定義、匿名アカウントの削除により、データベースのセキュリティを向上させるのに役立つスクリプトがインストールされています。デフォルトですべてのユーザーがアクセスできるテストデータベースを削除します。また、SQLiteとは異なり、MySQLはユーザー管理をサポートしており、ユーザーごとにアクセス権限を付与できます。
Speed ：SQLの特定の機能を実装しないことを選択することにより、MySQL開発者は速度を優先することができました。最近のベンチマークテストでは、PostgreSQLのような他のRDBMSが速度の点でMySQLに匹敵するか、少なくともそれに近づくことができることが示されていますが、MySQLは依然として非常に高速なデータベースソリューションとしての評判を保持しています。
レプリケーション：MySQLは、さまざまなタイプのレプリケーションをサポートしています。これは、信頼性、可用性、およびフォールトトレランスを向上させるために2つ以上のホスト間で情報を共有する方法です。これは、データベースバックアップソリューションのセットアップや、データベースの水平スケーリングに役立ちます。

MySQLのデメリット

既知の制限：MySQLは、SQLに完全に準拠するのではなく、速度と使いやすさを重視して設計されているため、特定の機能制限があります。たとえば、FULLJOIN句のサポートがありません。
ライセンスおよびプロプライエタリ機能：MySQLはデュアルライセンスソフトウェアであり、 GPLv2 の下でライセンスされた無料のオープンソースコミュニティエディションと、プロプライエタリの下でリリースされたいくつかの有料商用エディションがありますライセンス。このため、一部の機能とプラグインはプロプライエタリエディションでのみ使用できます。
開発の遅れ：MySQLプロジェクトが2008年にSun Microsystemsに買収され、その後2009年にOracle Corporationに買収されて以来、コミュニティとして、DBMSの開発プロセスが大幅に遅くなっているというユーザーからの苦情がありました。問題に迅速に対応し、変更を実装する機関がなくなりました。

MySQLを使用する場合

分散操作：MySQLのレプリケーションサポートにより、プライマリ-セカンダリまたはプライマリ-プライマリアーキテクチャなどの分散データベースセットアップに最適です。
WebサイトとWebアプリケーション：MySQLは、インターネット全体の多くのWebサイトとアプリケーションを強化します。これは主に、MySQLデータベースのインストールとセットアップがいかに簡単であるか、そして長期的にはその全体的な速度とスケーラビリティのおかげです。
予想される将来の成長：MySQLのレプリケーションサポートは、水平スケーリングを容易にするのに役立ちます。さらに、自動シャーディング、別の水平スケーリングプロセスをサポートするMySQLClusterなどの商用MySQL製品にアップグレードするのは比較的簡単なプロセスです。

MySQLを使用しない場合

SQL準拠が必要です：MySQLは完全なSQL標準を実装しようとしないため、このツールは完全にSQL準拠ではありません。完全またはほぼ完全なSQL準拠がユースケースに必須である場合は、より完全に準拠したDBMSを使用することをお勧めします。
同時実行性と大量のデータ：MySQLは通常、読み取りが多い操作でうまく機能しますが、同時読み取り/書き込みは問題になる可能性があります。アプリケーションに一度に多くのユーザーがデータを書き込む場合は、PostgreSQLなどの別のRDBMSがデータベースのより良い選択になる可能性があります。

PostgreSQL

Postgresとしても知られるPostgreSQLは、「世界で最も先進的なオープンソースのリレーショナルデータベース」と自称しています。これは、高度に拡張可能で標準に準拠することを目的として作成されました。 PostgreSQLはオブジェクトリレーショナルデータベースです。つまり、これは主にリレーショナルデータベースですが、オブジェクトデータベースに関連付けられることが多い機能（テーブル継承や関数のオーバーロードなど）も含まれています。

Postgresは、同時に複数のタスクを効率的に処理できます。これは、同時実行として知られる特性です。 Multiversion Concurrency Control（MVCC）の実装により、読み取りロックなしでこれを実現します。これにより、トランザクションのアトミック性、一貫性、分離、および耐久性が保証されます。これは、ACIDコンプライアンスとも呼ばれます。

PostgreSQLはMySQLほど広く使用されていませんが、pgAdminやPostbirdなど、PostgreSQLの操作を簡素化するように設計されたサードパーティのツールやライブラリがまだ多数あります。

PostgreSQLでサポートされているデータ型

PostgreSQLは、MySQLのような数値、文字列、および日付と時刻のデータ型をサポートしています。さらに、幾何学的形状、ネットワークアドレス、ビット文字列、テキスト検索、JSONエントリのデータ型、およびいくつかの固有のデータ型をサポートします。

数値タイプ：

データ・タイプ	説明
`bigint`	符号付き8バイト整数。
`bigserial`	自動インクリメントの8バイト整数。
`double precision`	8バイトの倍精度浮動小数点数。
`integer`	符号付き4バイト整数。
`numeric` また `decimal`	金額など、正確さが重要な場合に使用するために推奨される、選択可能な精度の数。
`real`	4バイトの単精度浮動小数点数。
`smallint`	符号付き2バイト整数。
`smallserial`	自動インクリメントの2バイト整数。
`serial`	自動インクリメントの4バイト整数。

文字タイプ：

データ・タイプ	説明
`character`	指定された固定長の文字列。
`character varying` また `varchar`	可変であるが長さが制限されている文字列。
`text`	可変長の無制限の文字列。

日付と時刻のタイプ：

データ・タイプ	説明
`date`	日、月、年で構成される暦日。
`interval`	期間。
`time` また `time without time zone`	タイムゾーンを含まない時刻。
`time with time zone`	タイムゾーンを含む時刻。
`timestamp` また `timestamp without time zone`	タイムゾーンを含まない日付と時刻。
`timestamp with time zone`	タイムゾーンを含む日付と時刻。

ジオメトリックタイプ：

データ・タイプ	説明
`box`	平面上の長方形のボックス。
`circle`	平面上の円。
`line`	平面上の無限の線。
`lseg`	平面上の線分。
`path`	平面上の幾何学的パス。
`point`	平面上の幾何学的な点。
`polygon`	平面上の閉じた幾何学的パス。

ネットワークアドレスタイプ：

データ・タイプ	説明
`cidr`	IPv4またはIPv6ネットワークアドレス。
`inet`	IPv4またはIPv6ホストアドレス。
`macaddr`	メディアアクセス制御（MAC）アドレス。

ビット文字列タイプ：

データ・タイプ	説明
`bit`	固定長のビット文字列。
`bit varying`	可変長ビット文字列。

テキスト検索タイプ：

データ・タイプ	説明
`tsquery`	テキスト検索クエリ。
`tsvector`	テキスト検索ドキュメント。

JSONタイプ：

データ・タイプ	説明
`json`	テキストのJSONデータ。
`jsonb`	分解されたバイナリJSONデータ。

その他のデータ型：

データ・タイプ	説明
`boolean`	いずれかを表す論理ブール `true` また `false`.
`bytea`	「バイト配列」の略で、このタイプはバイナリデータに使用されます。
`money`	通貨の金額。
`pg_lsn`	PostgreSQLログシーケンス番号。
`txid_snapshot`	ユーザーレベルのトランザクションIDスナップショット。
`uuid`	普遍的に一意の識別子。
`xml`	XMLデータ。

PostgreSQLの利点

SQL準拠：SQLiteやMySQLよりも、PostgreSQLはSQL標準に厳密に準拠することを目指しています。 PostgreSQLの公式ドキュメントによると、PostgreSQLは、オプション機能の長いリストに加えて、完全なコアSQL：2011準拠に必要な179の機能のうち160をサポートします。
オープンソースおよびコミュニティ主導：完全にオープンソースのプロジェクトであるPostgreSQLのソースコードは、大規模で献身的なコミュニティによって開発されています。同様に、Postgresコミュニティは、公式ドキュメント、 PostgreSQL wiki 、さまざまなオンラインフォーラムなど、DBMSの操作方法を説明する多数のオンラインリソースを維持し、貢献しています。
拡張可能：ユーザーは、カタログ駆動型操作と動的ローディングの使用により、PostgreSQLをプログラムでオンザフライで拡張できます。共有ライブラリなどのオブジェクトコードファイルを指定すると、PostgreSQLが必要に応じてロードします。

PostgreSQLのデメリット

メモリパフォーマンス：新しいクライアント接続ごとに、PostgreSQLは新しいプロセスをフォークします。新しいプロセスごとに約10MBのメモリが割り当てられます。これにより、接続数の多いデータベースにすぐに追加できます。したがって、単純な読み取り負荷の高い操作の場合、PostgreSQLは通常、MySQLなどの他のRDBMSよりもパフォーマンスが低くなります。
人気：近年広く使用されていますが、PostgreSQLは歴史的に人気の点でMySQLに遅れをとっています。この結果の1つは、PostgreSQLデータベースの管理に役立つサードパーティツールがまだ少ないことです。同様に、MySQLの経験を持つデータベース管理者と比較して、Postgresデータベースの管理経験を持つデータベース管理者はそれほど多くありません。

PostgreSQLを使用する場合

データの整合性が重要：PostgreSQLは2001年から完全にACIDに準拠しており、データの整合性を維持するためにマルチバージョン通貨制御を実装しているため、データの整合性が重要な場合はRDBMSを強力に選択できます。
他のツールとの統合：PostgreSQLは、さまざまなプログラミング言語およびプラットフォームと互換性があります。つまり、データベースを別のオペレーティングシステムに移行したり、特定のツールと統合したりする必要がある場合は、別のDBMSよりもPostgreSQLデータベースの方が簡単になる可能性があります。
複雑な操作：Postgresは、クエリに高速で応答するために複数のCPUを活用できるクエリプランをサポートしています。これは、複数の同時ライターに対する強力なサポートと相まって、データウェアハウジングやオンライントランザクション処理などの複雑な操作に最適です。

PostgreSQLを使用しない場合

速度は必須です：速度を犠牲にして、PostgreSQLは拡張性と互換性を念頭に置いて設計されました。プロジェクトで可能な限り最速の読み取り操作が必要な場合、PostgreSQLはDBMSの最良の選択ではない可能性があります。
シンプルなセットアップ：その大きな機能セットと標準SQLへの強力な準拠により、Postgresはシンプルなデータベースセットアップには行き過ぎになる可能性があります。速度が要求される読み取りの多い操作の場合、通常、MySQLがより実用的な選択肢です。
複雑なレプリケーション：PostgreSQLはレプリケーションを強力にサポートしていますが、それでも比較的新しい機能です。プライマリ-プライマリアーキテクチャなどの一部の構成は、拡張機能を使用した場合にのみ可能です。レプリケーションはMySQLのより成熟した機能であり、多くのユーザーは、特に必要なデータベースとシステム管理の経験が不足しているユーザーにとって、MySQLのレプリケーションの実装が簡単であると考えています。

結論

今日、SQLite、MySQL、およびPostgreSQLは、世界で最も人気のある3つのオープンソースリレーショナルデータベース管理システムです。それぞれに独自の機能と制限があり、特定のシナリオで優れています。 RDBMSを決定する際には、かなりの数の変数が関係しており、最速のものまたは最も多くの機能を備えたものを選択するほど簡単な選択はめったにありません。次回、リレーショナルデータベースソリューションが必要になったときは、これらのツールやその他のツールを詳細に調べて、ニーズに最適なツールを見つけてください。

SQLと、SQLを使用してリレーショナルデータベースを管理する方法について詳しく知りたい場合は、SQLデータベースの管理方法のチートシートを参照することをお勧めします。一方、非リレーショナル（またはNoSQL）データベースについて知りたい場合は、NoSQLデータベース管理システムの比較を確認してください。

参考文献

getdocs

13036