DBMSとは｜RDBMSとの違い・役割をSQLiteとPostgreSQLで実演

アプリはデータを直接ファイルに書かず、DBMS に「この条件で探して」「この行を変えて」と SQL で頼みます。DBMS は、頼まれた仕事を安全な順番で実行し、結果だけを返します。

flowchart TD
    A[アプリ・利用者] -->|SQLで依頼| D
    subgraph D[DBMS]
      P[SQLの解析と実行計画]
      L[同時実行制御<br>ロック]
      T[トランザクション<br>COMMIT・ROLLBACK]
      R[障害回復<br>WAL・ジャーナル]
      G[権限・認証]
    end
    D -->|読み書き| F[(データファイル<br>インデックス)]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB）の上で、PostgreSQL 16.15（Ubuntu のパッケージ）を作業用のフォルダーに initdb し、127.0.0.1 の空きポートで起動しました。psql 16.15 で2つの接続を同時に開き、行ロックの待ち・lock_timeout・デッドロック・ROLLBACK・権限（GRANT と scram-sha-256 のパスワード認証）を確かめ、pg_ctl stop -m immediate（公式ドキュメントで「次の起動でクラッシュリカバリーになる」と説明されている止め方）で障害を起こして、WAL からの回復をサーバーログと pg_waldump で見ました。SQLite は Python 3.13.18 の sqlite3 モジュール（SQLite 3.53.1）とコマンドラインの sqlite3 3.45.1 で、ロック・ROLLBACK・プロセスを強制終了したあとの回復（WAL モードとロールバックジャーナルの両方）・読み取り専用の扱いを確かめました。インデックスの効果は30万行、CSV との比較は同じデータで、どれも同じマシンで測っています。Oracle Database・SQL Server・MySQL は手元で動かしておらず、ライセンスと版は各社の公式サイトで確かめました。図は mermaid で描画を確かめています（確認日 2026年10月29日）。

DBMSとは（意味・データベースとの違い）

この節では、DBMS という言葉の意味と、「データベース」との違いが分かります。

DBMS は Database Management System の略で、日本語では「データベース管理システム」です。データベース（整理して保存されたデータの集まり）を作り、データの追加・検索・更新・削除を受け付け、その間にデータが壊れたり食い違ったりしないように管理するソフトウェアを指します。MySQL・PostgreSQL・Oracle Database・SQL Server・SQLite は、どれも DBMS の製品です。

日常の会話では「データベース」と「DBMS」を同じ意味で使うことが多いですが、分けると次のようになります。

データベースそのもの（表・行・列・主キー、Excel との違い、SQL の基本）は、関連記事「データベースとは｜種類・Excelとの違い・SQLの基本を実例で解説」で扱っています。この記事は、その中身を管理する側の DBMS に絞り、DBMS が裏で何をしているのかを実際に動かして見せます。

DBMS が無いとどうなるか

DBMS が広まる前は、アプリがそれぞれ自分の形式でファイルを読み書きしていました。そのやり方には、次の問題がありました。

• 同時に書くと壊れる：2つのプログラムが同じファイルを同時に書き換えると、片方の変更が消える。
• 途中で止まると半端な状態が残る：振込の「引く」だけが終わって「足す」の前に止まると、お金が消える。
• 探すのが遅い：毎回ファイルを先頭から最後まで読む。
• 見せる範囲を分けにくい：ファイルを読める人は全部読めてしまう。
• 形式がアプリごとに違う：別のアプリから使い回せない。

DBMS は、こうした問題を「アプリの外の1か所」でまとめて引き受けます。この記事の後半では、CSV ファイルで実際に1つ目と2つ目の問題を起こし、DBMS では起きないことを同じデータで確かめます。

DBMSの6つの役割（機能の一覧）

この節では、DBMS が受け持つ主な機能と、この記事で実際に確かめた範囲が分かります。

DBMS の機能は、資料によって「5つ」「4つ」などと数え方が違いますが、中身はおおむね次の6つにまとまります。情報処理技術者試験でも、データ定義・データ操作・同時実行制御（排他制御）・トランザクション管理・障害回復・機密保護がよく問われます。

同時実行制御：2つの接続で同時に更新したときのロック

この節では、2人が同じデータを同時に変えようとしたとき、DBMS がロックでどう順番を決めるのかが、実際の出力で分かります。

口座の表を作り、佐藤さんの残高 1,000円 から、接続Aが100円、接続Bが200円を同時に引きます。Aは更新したあと確定（COMMIT）せずに6秒待ち、その間にBが同じ行を更新します。

-- 準備
CREATE TABLE accounts (
  id int PRIMARY KEY,
  name text NOT NULL,
  balance int NOT NULL CHECK (balance >= 0)
);
INSERT INTO accounts VALUES (1,'佐藤',1000),(2,'鈴木',500);

-- 接続A
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT pg_sleep(6);   -- 確定する前に6秒かかる処理のつもり
COMMIT;

-- 接続B（Aの1秒後）
UPDATE accounts SET balance = balance - 200 WHERE id = 1;

Bが待っている間に、3つ目の接続から PostgreSQL の中を見ました。

 pid  | app  | state  | wait_event_type |  wait_event   |                       query
------+------+--------+-----------------+---------------+----------------------------------------------------
 2839 | psql | active | Timeout         | PgSleep       | SELECT pg_sleep(6);
 2938 | psql | active | Lock            | transactionid | UPDATE accounts SET balance = balance - 200 WHERE

 pid  | blocked_by
------+------------
 2938 | {2839}

 pid  |   locktype    |       mode       | granted
------+---------------+------------------+---------
 2839 | transactionid | ExclusiveLock    | t
 2938 | tuple         | ExclusiveLock    | t
 2938 | transactionid | ExclusiveLock    | t
 2938 | transactionid | ShareLock        | f

Bの UPDATE は wait_event_type = Lock で止まり、pg_blocking_pids は「2839（接続A）に止められている」と示しました。最後の行の granted = f は「Aのトランザクションが終わるのを待つロックを、まだもらえていない」という意味です。Aが確定すると、Bは動き出しました。

UPDATE 1
B wait: 5.037561236

 id | name | balance
----+------+---------
  1 | 佐藤 |     700
  2 | 鈴木 |     500

Bは約5.04秒待ち、残高は 1,000 − 100 − 200 ＝ 700円 になりました。Bは、Aが確定したあとの値（900円）から200円を引いています。どちらかの更新が消える「ロストアップデート」は起きていません。

違う行なら待たない・読むだけなら待たない

Aが佐藤さんの行（id=1）をロックしている間に、Bが鈴木さんの行（id=2）を更新すると Time: 2.361 ms ですぐ終わりました。PostgreSQL のロックは行単位だからです。また、Aが残高を9999に書き換えて確定していない間に SELECT すると、0.839 ms で 確定済みの700 が返りました。PostgreSQL は MVCC（多版型同時実行制御。更新前の版を残しておく仕組み）で、読む側を待たせません。

待ちすぎを防ぐ lock_timeout と、デッドロック

待ち時間に上限を付けると、ロックが取れないときにエラーで戻ります。

SET lock_timeout = '2s';
UPDATE accounts SET balance = 0 WHERE id = 1;
ERROR:  canceling statement due to lock timeout
CONTEXT:  while updating tuple (0,6) in relation "accounts"

2つの接続が「id=1→id=2」と「id=2→id=1」の逆の順番で行を更新すると、お互いが相手を待つデッドロックになります。PostgreSQL は数秒で検知し、片方を取り消しました。

ERROR:  deadlock detected
DETAIL:  Process 6416 waits for ShareLock on transaction 767; blocked by process 6430.
Process 6430 waits for ShareLock on transaction 766; blocked by process 6416.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (0,10) in relation "accounts"

ロックの調べ方（止めている接続の特定から解除まで）は関連記事「PostgreSQLロック確認SQL｜ブロッキング特定から解除までコピペ集」で扱っています。

SQLite は「データベース全体」で1人ずつ書く

同じことを SQLite（WAL モード）で、待ち時間の上限を2秒にして試しました。Aは id=1 を更新して確定せず、Bは別の行の id=2 を更新します。

B reads while A writes: (1000,)
B write: OperationalError: database is locked (waited 2.01s)
B write after A commit: ok
[(1, '佐藤', 900), (2, '鈴木', 300)]

読む側は確定済みの1000をすぐ受け取れましたが、書く側は別の行でも2.01秒待ったあと database is locked になりました。SQLite の公式ドキュメントは「読み手は同時にいくつでもよいが、書き手は同時に1つだけ」と説明しています。Aが確定したあとは、Bの更新も通りました。

トランザクションとROLLBACK：途中で失敗したら全部戻る

この節では、トランザクション（まとめて1つの仕事として扱う単位）と ROLLBACK が、どう「半端な状態」を防ぐのかが分かります。

佐藤さんから鈴木さんへ 3,000円 を振り込みます。鈴木さんに足す更新は通りますが、佐藤さんの残高は1,000円なので、引く更新は「残高は0以上」の制約に違反します。

BEGIN
UPDATE 1
ERROR:  new row for relation "accounts" violates check constraint "accounts_balance_check"
DETAIL:  Failing row contains (1, 佐藤, -2000).
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ROLLBACK
 id | name | balance
----+------+---------
  1 | 佐藤 |    1000
  2 | 鈴木 |     500

鈴木さんへの「足す」は一度成功していますが、ROLLBACK で取り消され、2人とも元の残高に戻りました。エラーのあとの current transaction is aborted は、「このトランザクションは失敗済みなので、ROLLBACK するまで次の命令は受け付けない」という PostgreSQL の決まりです。

SQLite でも同じ振込を試すと、トランザクションの中では鈴木さんが一時的に3,300円になって見えますが、ROLLBACK のあとは元に戻りました。

error: IntegrityError CHECK constraint failed: balance>=0
inside txn: [(1, '佐藤', 900), (2, '鈴木', 3300)]
after ROLLBACK: [(1, '佐藤', 900), (2, '鈴木', 300)]

ACID特性：トランザクションが守る4つの性質

「独立性」をどこまで厳しくするか（分離レベル）は、関連記事「トランザクション分離レベルの違いをわかりやすく解説」で扱っています。

障害回復：強制停止のあとWALで元に戻る様子

この節では、処理の途中でサーバーが止まったとき、DBMS が何を残し何を捨てるのかが、PostgreSQL と SQLite の実物で分かります。

PostgreSQL：確定済みは残り、確定前は消える

注文の表に1,000行を入れて確定し、続けて別のトランザクションで500行を入れている途中（まだ COMMIT していない）で、pg_ctl stop -m immediate でサーバーを止めました。公式ドキュメントはこの止め方を「すべてのサーバープロセスをきれいな終了をせずに直ちに中断する。次の起動でクラッシュリカバリーになる」と説明しています。つまり、停電やプロセスの異常終了に近い止まり方です。

再起動したときのサーバーログです（各行の先頭の日時は省きました）。

LOG:  database system was interrupted; last known up at ...
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 0/19257A0
LOG:  invalid magic number 0000 in WAL segment 000000010000000000000001, LSN 0/195E000, offset 9822208
LOG:  redo done at 0/195DFC0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
LOG:  checkpoint starting: end-of-recovery immediate wait
LOG:  checkpoint complete: wrote 22 buffers (0.3%); ...
LOG:  database system is ready to accept connections

   種類   | count
----------+-------
 確定済み |  1000

「きちんと終了していないので自動で回復する」と記録したあと、WAL（Write-Ahead Log。データファイルより先に書く変更の記録）を読み直し（redo）、確定済みの1,000行だけが残りました。途中だった500行は1行も残っていません。invalid magic number 0000 は WAL の記録がそこで終わっていることを示すもので、ここでは異常ではありません。

WAL の中身を pg_waldump で出し、トランザクションごとに記録の種類を数えると（uniq -c の結果を見出しを付けて並べ直しました）、理由が分かります。

  件数  トランザクション  記録の種類
     1  745               COMMIT
  1999  745               INSERT（表と主キーの索引）
   942  746               INSERT（表と主キーの索引）

確定した745番には COMMIT の記録があり、途中だった746番には INSERT の記録が942件あるのに COMMIT がありません。PostgreSQL は COMMIT の記録が無いトランザクションを「無かったこと」として扱います。DBMS が「確定した」と応答するのは、COMMIT の記録を WAL に書き終えてからです。

SQLite：プロセスを強制終了しても戻る

SQLite はサーバーを持たず、アプリのプロセスの中で動きます。そこで、アプリ自身が1,000行を確定し、500行を入れている途中で自分に SIGKILL を送って強制終了させました。

pid 4952 killing self with SIGKILL during open transaction
Killed
-rw-r--r-- 1 root root  4096 crash.db
-rw-r--r-- 1 root root 32768 crash.db-shm
-rw-r--r-- 1 root root 41232 crash.db-wal

（次に開いたとき）
('ok',) [('確定済み', 1000)]
-rw-r--r-- 1 root root 32768 crash.db

WAL モードでは、変更はまず -wal ファイルに追記されます。次に開いたときは、確定済みの1,000行だけが見え、PRAGMA integrity_check は ok でした。閉じたときに WAL の中身がデータベース本体に移り、-wal と -shm は消えました。

WAL を使わない既定の「ロールバックジャーナル」の形でも試しました。こちらは、書き換える前のページを -journal に控えてから本体を直接書き換えます。

-rw-r--r-- 1 root root 1466368 j.db
-rw-r--r-- 1 root root   13840 j.db-journal

（次に開いたとき）
('ok',) [('確定済み', 1000)]
-rw-r--r-- 1 root root   32768 j.db

強制終了の時点で本体は 1.4MB まで書き換わっていましたが、次に開いたときに SQLite がジャーナルから元のページを書き戻し、32KB・確定済み1,000行の状態に戻りました。このとき -journal ファイルを消したり、本体だけを別の場所にコピーしたりすると、書き戻しができなくなります。SQLite の公式ドキュメント（Atomic Commit In SQLite）も、ジャーナル（ホットジャーナル）を消すと壊れる原因になると説明しています。

インデックス：あり・なしで検索の速さを比べる

この節では、DBMS がインデックス（索引）と実行計画で検索を速くする様子と、その代わりに増える負担が分かります。

30万人分の顧客の表から、メールアドレスで1人を探しました。PostgreSQL の EXPLAIN ANALYZE の出力です。

-- インデックスなし
 Gather  (cost=1000.00..5696.98 rows=1 width=33) (actual time=14.795..35.596 rows=1 loops=1)
   Workers Planned: 1
   Workers Launched: 1
   ->  Parallel Seq Scan on customers  (cost=0.00..4696.88 rows=1 width=33) (actual time=20.764..29.520 rows=0 loops=2)
         Filter: (email = 'user123456@example.com'::text)
         Rows Removed by Filter: 150000
 Execution Time: 35.613 ms

-- CREATE INDEX customers_email_idx ON customers(email);  （Time: 389.393 ms）
 Index Scan using customers_email_idx on customers  (cost=0.42..8.44 rows=1 width=33) (actual time=0.004..0.005 rows=1 loops=1)
   Index Cond: (email = 'user123456@example.com'::text)
 Execution Time: 0.010 ms

インデックスが無いときは、2つのプロセスで15万行ずつ全部を読み（Seq Scan）、1件のために29万9,999行を捨てていました。インデックスを作ると、DBMS が自分で実行計画を Index Scan に切り替えました。SQL は1文字も変えていません。どう探すかを決めるのは DBMS の仕事です。

SQLite も EXPLAIN QUERY PLAN で同じ変化が見えます。

plan: [(2, 0, 216, 'SCAN customers')]
plan: [(3, 0, 62, 'SEARCH customers USING INDEX idx_email (email=?)')]

インデックスの代わりに増えるもの

インデックスは「探す」を速くする一方で、「書く」たびに索引も直す手間が増えます。PostgreSQL で20万行を一度に入れた時間を比べました（2回測定）。

書き込みは約3.5倍の時間になり、索引だけで表の6割ほどの容量を使いました。検索の条件によく使う列にだけ作るのが基本です。インデックスを作っても使われない書き方（列に関数をかける・前方一致でない LIKE など）は、関連記事「SQLのインデックスが効かない10のパターンと確認方法」で扱っています。

権限：許可されていない操作をDBMSが断る

この節では、DBMS の機密保護（認証と権限）が、どんなエラーで操作を断るのかが分かります。

PostgreSQL で、口座の表を「読むだけ」の利用者 reader を作りました。

CREATE ROLE reader LOGIN PASSWORD '********';
GRANT CONNECT ON DATABASE t125db TO reader;
GRANT USAGE ON SCHEMA public TO reader;
GRANT SELECT ON accounts TO reader;

\dp accounts
 Schema |   Name   | Type  |     Access privileges
--------+----------+-------+---------------------------
 public | accounts | table | postgres=arwdDxt/postgres+
        |          |       | reader=r/postgres

reader=r の r は read（SELECT）だけを持つという意味です。reader で操作すると、次のようになりました。

SELECT * FROM accounts ORDER BY id;     → 2行が返る
UPDATE accounts SET balance = 0 WHERE id = 1;
ERROR:  permission denied for table accounts
DELETE FROM accounts;
ERROR:  permission denied for table accounts
CREATE TABLE memo(id int);
ERROR:  permission denied for schema public
LINE 1: CREATE TABLE memo(id int);
                     ^

読むことはできても、更新・削除・表の作成は DBMS が断りました。PostgreSQL 15 以降は、一般の利用者が public スキーマに表を作れない設定が既定です。

「誰か」を確かめる認証も DBMS の仕事です。reader の接続をパスワード認証（scram-sha-256）にして、違うパスワードで接続しました。

psql: error: connection to server at "127.0.0.1", port 54125 failed: FATAL:  password authentication failed for user "reader"

権限の設計の型（読み取り専用・アプリ用・管理者用のロールの分け方）は、関連記事「PostgreSQLのロールと権限｜GRANT設計テンプレートとエラー対処」で扱っています。

SQLite には利用者と GRANT が無い

$ sqlite3 bank.db "GRANT SELECT ON accounts TO reader;"
Error: in prepare, near "GRANT": syntax error

$ sqlite3 "file:bank.db?mode=ro" "UPDATE accounts SET balance=0;"
Error: stepping, attempt to write a readonly database (8)

SQLite には利用者という考え方が無く、GRANT は文法エラーになります。読み書きを分けたいときは、OS のファイルの権限か、読み取り専用で開く（mode=ro）方法を使います。ファイルの所有者以外（nobody）で開くと、SELECT は通り、UPDATE は attempt to write a readonly database で断られました。複数の利用者ごとに細かく権限を分けたいなら、サーバー型の DBMS を選ぶ理由になります。

CSVファイルで管理する場合との違い（同じデータで実測）

この節では、DBMS を使わずに CSV ファイルでデータを管理すると、何が起きるのかが実測で分かります。

在庫1,000本のボールペンを、2つのプロセスが同時に500回ずつ1本減らします。正しければ最後は0本です。CSV では「ファイルを読む→1引く→ファイルを書き直す」、SQLite では UPDATE stock SET qty = qty - 1 を使いました。

CSV では1,000回減らしたはずが、毎回100〜250本ほどの「減らした記録」が消えました。2つのプロセスが同じ値を読んで、それぞれ1引いて書き戻すと、2回の減算が1回分になります。さらに、相手が書き直している最中のファイル（空や途中まで）を読む場面が数百回ありました。最初の版のスクリプトはこれを想定しておらず、IndexError('list index out of range') で片方のプロセスが止まりました。SQLite は3回とも0本で、かかった時間も CSV と同じ 0.04〜0.06秒でした。

大きさは、30万行の CSV が 11.2MB、同じデータの SQLite がインデックス込みで 20.6MB でした。DBMS は索引や管理用の情報を持つぶん容量は増えます。1人で読み書きし、他のツールに渡すことが目的なら、CSV のほうが向いている場面もあります。

DBMSの種類とRDBMSとの違い（RDBMS・NoSQL・NewSQL）

この節では、RDBMS とは何か、DBMS との関係、NoSQL・NewSQL など他の種類との違いが分かります。

RDBMS（Relational Database Management System、リレーショナルデータベース管理システム）は、データを「表（行と列）」で持ち、表どうしを共通の値で結び付けて扱う DBMS です。操作には SQL を使います。DBMS は総称で、RDBMS はその一種という関係です。この記事で動かした PostgreSQL と SQLite は、どちらも RDBMS です。

一部の解説では「DBMS はファイルでデータを持ち、1人で使う。RDBMS は表で持ち、複数人で使う」のように対比されます。これは、表の形を持たない以前の DBMS と RDBMS を比べた説明です。今「DBMS」と言うときは、RDBMS も NoSQL も含む総称として使われるのが普通です。

NoSQL は「Not only SQL」の略とされ、表の形にこだわらずに、速さや広げやすさを優先した DBMS の総称です。多くの NoSQL 製品にも、同時実行制御・障害回復・認証といった DBMS の役割があります。どこまで厳密にトランザクションを守るかは製品ごとに違うため、公式ドキュメントで確かめて選びます。

主要なDBMS製品の比較（Oracle・MySQL・PostgreSQL・SQL Server・SQLite）

この節では、よく名前を聞く5つの DBMS 製品の違いが、ライセンス・形・版の表で分かります。

• Oracle Database：大企業の基幹システムで長く使われてきた商用の RDBMS。無料版「Oracle AI Database 26ai Free」は、公式サイトによると CPU 2スレッド・データベースのメモリ 2GB・利用者データ 12GB までです。
• MySQL：Web サービスで広く使われる RDBMS。公式サイトによると、サーバーとクライアントライブラリは GPL バージョン2 で、組み込んで配布する場合などのために商用ライセンスもあります。リリースは、長く同じ動きを保つ LTS と、新機能が入る Innovation の2系統です（MySQL 8.4 リファレンスマニュアル）。
• PostgreSQL：機能が多く、無料で使える RDBMS。公式のバージョン表では、2026年10月29日時点で 18.6・17.11・16.15・15.19・14.24 がサポート中で、14 は 2026年11月12日に最後のリリースの予定です。この記事は 16.15 で確かめました。
• SQL Server：Microsoft の RDBMS。Microsoft Learn によると、SQL Server 2025 の Express エディションは「入門用の無料のデータベース」で、データベースの最大サイズ 50GB、バッファープールのメモリ 1,410MB、計算能力は「1ソケットか4コアの少ない方」までです。Developer エディションは開発・テスト用で、本番には使えません。
• SQLite：サーバーを持たず、アプリに組み込んで1つのファイルで動く RDBMS。スマートフォンのアプリやブラウザの内部でも使われています。公式サイトは「SQLite はクライアント・サーバー型のデータベースと競合しない。競合するのは fopen()（ファイルを開く関数）だ」と説明しています。使い方は関連記事「SQLiteの使い方｜コマンド早見表とPython連携を実行例で解説」で扱っています。

料金・上限・版は変わることがあります。採用する前に、各社の公式ページで最新の情報を確かめます。

DBMSの仕組み：構成要素・SQLの種類・3層スキーマ

この節では、DBMS がどんな部品と言葉でできているのかと、試験でよく問われる用語が分かります。

DBMS を使うときに出てくる要素

SQLの4つの分類

3層スキーマ（外部・概念・内部）

DBMS は、データの「見せ方」と「しまい方」を分けて考えます。これを3層スキーマと呼びます。

• 外部スキーマ：利用者やアプリから見える形。ビュー（VIEW）など。
• 概念スキーマ：表・列・関係など、データ全体の論理的な形。CREATE TABLE で決める部分。
• 内部スキーマ：ディスク上のしまい方。ファイル・ページ・インデックス。

インデックスを作っても SQL を変えずに速くなったのは、内部スキーマを変えても、その上の層に影響しないように分けてあるからです（物理的データ独立性）。

DBMSでよくあるエラー・つまずき（原文つき）

この節では、この記事の実験で実際に出たエラーの原文と、意味と直し方が分かります。

ロック待ちで画面が止まったように見えたときは、次の順で調べると原因に早くたどり着けます。

どのDBMSを選ぶか（判断表）

この節では、用途から DBMS の種類と製品を選ぶ目安が分かります。

迷ったときは、次の4つを確かめると絞り込めます。

手元で DBMS の働きを確かめたいときは、この記事と同じ順で試すと、6つの役割を1時間ほどで一通り見られます。

1. 1SQLite で表を作り、ROLLBACK を試すPython に付いている sqlite3 だけでできる
2. 22つの接続で同時に書いて database is locked を見るtimeout の値を変えて待ち方を確かめる
3. 3PostgreSQL を手元で起動し、行ロックと MVCC を見るpg_stat_activity と pg_blocking_pids
4. 4EXPLAIN でインデックスの有無を比べるSQL を変えずに計画が変わることを見る
5. 5読むだけの利用者を作り、権限エラーを見るGRANT SELECT だけを与える

よくある質問

Q. DBMSとは何ですか？ A. データベース管理システム（Database Management System）の略で、データベースを作り、データの追加・検索・更新・削除を受け付け、同時実行制御・トランザクション・障害回復・権限によってデータを安全に保つソフトウェアです。

Q. データベースとDBMSの違いは何ですか？ A. データベースは「整理して保存されたデータの集まり」、DBMS は「それを管理するソフトウェア」です。会話では同じ意味で使われることも多く、文脈で判断します。

Q. RDBMSとは何ですか？DBMSとの違いは？ A. RDBMS は、データを表（行と列）で持ち、SQL で操作する DBMS です。DBMS は総称で、RDBMS はその一種です。PostgreSQL・MySQL・Oracle Database・SQL Server・SQLite は RDBMS です。

Q. DBMSの主な機能はいくつありますか？ A. 資料によって数え方が違いますが、データ定義・データ操作・同時実行制御・トランザクション管理・障害回復・機密保護（権限）の6つにまとめると全体を押さえられます。

Q. Excel はDBMSですか？ A. Excel は表計算ソフトで、DBMS ではありません。複数人が同時に同じデータを更新したときの順番待ちや、途中で失敗したときの取り消しを、DBMS のように保証する仕組みは持っていません。この記事の CSV の実験では、同時更新で100〜250本分の記録が消えました。

Q. SQLite は本番で使えますか？ A. 用途によります。アプリや機器の中にデータを持つ使い方には広く使われています。一方、SQLite の公式ドキュメントは、多くのコンピューターからネットワーク越しに同時に直接書き込む使い方は避けるよう勧めています。書き込みは同時に1つだけです。

Q. NoSQL はDBMSではないのですか？ A. NoSQL も DBMS の一種です。表の形（リレーショナルモデル）を使わない DBMS をまとめて NoSQL と呼びます。トランザクションをどこまで守るかは製品ごとに違います。

Q. DBMSが止まったら、データは消えますか？ A. 確定（COMMIT）したデータは、WAL やジャーナルによって再起動のときに戻ります。この記事では、PostgreSQL も SQLite も、強制停止のあと確定済みの1,000行が残り、確定していない500行は消えました。ディスクそのものが壊れた場合に備えて、別にバックアップが要ります。

Q. 無料で使えるDBMSはどれですか？ A. PostgreSQL・MySQL（GPL 版）・SQLite は無料で使えます。SQL Server には Express、Oracle Database には容量などに上限のある無料版があります（2026年10月29日時点の各社公式サイト）。

Q. DBMSを学ぶには何から始めればよいですか？ A. SQLite で表を作り SQL の基本を覚え、次に PostgreSQL か MySQL を手元で動かして、トランザクション・ロック・インデックス・権限を試す順が分かりやすいです。この記事の「どのDBMSを選ぶか」の節の5段階が、その順番です。

まとめ

この節では、記事の要点を5つにまとめます。

• DBMS はデータベースを管理するソフトウェアで、定義・操作・同時実行制御・トランザクション・障害回復・権限の6つを受け持つ。
• RDBMS は表で扱う DBMS。DBMS は総称で、NoSQL・NewSQL も含む。
• 同時に更新してもロックで順番が決まり、PostgreSQL では5.04秒待ったあと正しい700円になった。SQLite は書き込みが同時に1つだけ。
• ROLLBACK と WAL で「半端な状態」が残らない。強制停止のあとも確定済み1,000行だけが残った。
• CSV では同時更新で記録が消え、インデックスのある DBMS は30万行から1件を0.01ms台で探せた。

参考・出典

確認日はいずれも 2026年10月29日です。

• PostgreSQL「Versioning Policy」：https://www.postgresql.org/support/versioning/
• PostgreSQL「License」：https://www.postgresql.org/about/licence/
• PostgreSQL 16 Documentation「pg_ctl」：https://www.postgresql.org/docs/16/app-pg-ctl.html
• PostgreSQL 16 Documentation「Write-Ahead Logging (WAL)」：https://www.postgresql.org/docs/16/wal-intro.html
• PostgreSQL 16 Documentation「Explicit Locking」：https://www.postgresql.org/docs/16/explicit-locking.html
• PostgreSQL 16 Documentation「Privileges」：https://www.postgresql.org/docs/16/ddl-priv.html
• SQLite「SQLite Home Page」（最新版とライセンス）：https://www.sqlite.org/index.html
• SQLite「Appropriate Uses For SQLite」：https://www.sqlite.org/whentouse.html
• SQLite「Write-Ahead Logging」：https://www.sqlite.org/wal.html
• SQLite「Atomic Commit In SQLite」：https://www.sqlite.org/atomiccommit.html
• MySQL 8.4 Reference Manual「MySQL Releases: Innovation and LTS」：https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
• MySQL「Licensing Information」：https://www.mysql.com/about/legal/licensing/oem/
• Microsoft Learn「Editions and supported features of SQL Server 2025」：https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2025
• Oracle「Oracle AI Database Free」：https://www.oracle.com/database/free/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。