Gitea のデータベースの選び方：SQLite・MySQL・PostgreSQL をどう使い分けるか

Gitea をはじめて導入するとき、初期設定の画面で最初に迷うのが、データベースの欄です。SQLite、MySQL、PostgreSQL といった選択肢が並び、どれを選んでも先へ進めてしまいます。そのため、深く考えずに初期値のまま決めてしまう方が少なくありません。

けれども、この選択は、あとから変えにくい種類のものです。ドキュメントには、データベースの種類は最初の導入時に選ぶものであること、別の種類へ変換する作業は十分に検証された手順ではないことが、はっきり書かれています。つまり、ここでの選び方が、数年先の運用の楽さを左右します。この記事では、選択肢ごとの性格と、選んだあとに必要な準備を整理します。確認した時点は2026年11月15日で、ドキュメントの最新の安定版は 28.3.0 です。

SQLite のまま走り続けた先に待つこと

まず、手軽さの陰にある課題から整理します。SQLite は、データを一つのファイルに保存する仕組みで、別のサービスを立ち上げる必要がありません。Gitea は、データベースの設定を何もしなければ SQLite を使うので、試用では最も手軽な選択になります。ドキュメントでも、SQLite は準備が不要で、データベースの章を読み飛ばしてよいと説明されています。

一方で、ドキュメントは SQLite について「規模の拡大には向かない」という趣旨の注意も添えています。利用者が少ないうちは問題が表に出ませんが、次のような状況で負担が顕在化しやすくなります。

• 利用者が増えたとき。 利用者や組織が増えるほど、データベースに求める余裕も大きくなります。SQLite は、その拡大に向かないと説明されています。
• 自動化が増えたとき。 CI の実行や、他のシステムとの連携が加わると、人間の操作とは別に、機械による書き込みが頻繁に発生します。
• 移行が必要になったとき。 規模が大きくなってから別のデータベースへ移そうとしても、変換の手順は十分に検証されていません。ドキュメントは、この変換を「十分にテストされたプロセスではない」と明記しています。

試用のつもりで始めた環境が、いつの間にか、チームの重要な資産を預かる環境になっていることは、よくあります。そうなってからの移行は、リポジトリの数だけ、確認の手間が増えます。最初から、将来の規模を少し大きめに見積もって選んでおくほうが、結果的に楽です。

対応するデータベースと、最小のバージョン

Gitea が対応するデータベースは、次のとおりです。

実際の選び方の目安は、次のように考えると整理しやすくなります。

特定の種類が絶対に優れている、という決め方はありません。Gitea 側がサポートしている範囲で、運用する人が最も安全に扱える種類を選ぶのが、堅実です。

MySQL・MariaDB を使うときの準備

MySQL または MariaDB を選ぶ場合は、Gitea 用のユーザーとデータベースを、あらかじめ作っておきます。ドキュメントが示している要点は、次のとおりです。

1. 文字セットを utf8mb4、照合順序を utf8mb4_bin にしてデータベースを作ります。
2. Gitea 用のユーザーを作り、そのデータベースに対するすべての権限を与えます。
3. 別のサーバーから接続させる場合は、MySQL の設定で bind-address を指定します。

文字セットの指定は、特に大切です。Gitea Actions の説明にも、MySQL や MariaDB の文字セットが utf8mb4 でないと、絵文字を含む内容でエラーになると注意されています。日本語の利用では、絵文字が入る場面は意外に多く、コミットメッセージや課題のコメントに、ごく自然に使われます。最初から utf8mb4 にしておけば、この種の問題を避けられます。

もうひとつ、見落としやすいのが照合順序です。ドキュメントによると、Gitea は起動時に、照合順序を utf8mb4_0900_as_cs や uca1400_as_cs に切り替えることがあります。別の照合順序を使いたい場合は、app.ini の [database] にある CHARSET_COLLATION で指定します。自動で切り替わる場合があることを知っておけば、後で設定を確認したときに戸惑いません。

PostgreSQL を使うときの準備

PostgreSQL は、設定の自由度が高く、手順も少し多めです。ドキュメントの要点を、順に整理します。

• 別のサーバーから接続させる場合は、listen_addresses を設定します。
• パスワードの暗号化に scram-sha-256 を使うため、password_encryption = scram-sha-256 を設定し、再起動します。
• ログイン用のロールをパスワード付きで作ります。
• そのロールを所有者として、データベースを作ります。このとき template0、ENCODING UTF8、そして適切な LC_COLLATE と LC_CTYPE を指定します。
• pg_hba.conf に、scram-sha-256 を使う接続の規則を追加し、再起動します。規則は上から順に評価されるため、汎用の規則よりも前に置く必要があります。

最後の「規則の順序」は、つまずきやすい点です。規則を追加したのに、期待どおりに接続できないときは、先に一致している別の規則がないかを確認します。

Docker Compose で PostgreSQL を使う場合は、イメージの環境変数でユーザーとデータベースを作れるため、これらの手順の多くを自分で行う必要はありません。詳しくは、Docker Compose で Gitea を導入するに設定例があります。ただし、PostgreSQL のデータディレクトリは、新しいメジャーバージョンに自動で移行されません。更新の際には、pg_upgrade を使うか、ダンプを取って入れ直す必要があります。

MSSQL を使うときの準備

MSSQL は、既存の Microsoft 環境がある場合の選択肢です。ドキュメントでは、次の準備が示されています。

• 照合順序を Latin1_General_CS_AS（大文字と小文字を区別する）にしてデータベースを作ります。
• ログインを作り、それに対応するユーザーを作って、db_owner に加えます。あるいは、db_ddladmin、db_datareader、db_datawriter の三つの役割を与えます。
• 後者の方法を選んだ場合は、管理者が ALTER DATABASE giteadb SET READ_COMMITTED_SNAPSHOT ON; を実行する必要があります。

データベース名の giteadb は例なので、実際の名前に置き換えます。

データベースを別のサーバーに置くとき

Gitea とデータベースを別のサーバーで動かす構成も選べます。この場合、ドキュメントは次の点を求めています。

• データベースのサーバーには、データベースのサーバー本体を入れます。
• Gitea のサーバーには、対応するクライアントのプログラムを入れます。
• 両者のバージョンを、同じ種類・同じ系統に揃えます。
• 公共のネットワークを通る接続には、TLS を使います。

別サーバーに分けると、バックアップや障害対応の担当を分けやすくなる反面、通信経路が増え、確認する場所も増えます。小規模な環境では、同じ場所で動かしたほうが、運用の負担が小さくなることも多いのが実際です。

規模と体制から、選び方を具体的に考える

ここまでの説明を、具体的な場面に当てはめてみます。いずれも、判断の考え方を示すための想像上の例です。

個人や数人で、まず試す場合

目的が、使い心地を確かめることなら、SQLite で十分です。準備が要らず、数分で動かせます。ただし、「この環境で本番を始めない」と最初に決めておきます。試用で作ったリポジトリを、そのまま本番に持ち込みたくなることがあるからです。本番にする時点で、別の環境を、改めて立てるつもりでいれば、データベースの移行の問題は生じません。

部署の単位で、継続して使う場合

業務で使い続けるなら、MySQL、MariaDB、PostgreSQL のいずれかを、最初から選びます。決め手は、担当者が日常的に扱える種類であることです。バックアップ、容量の監視、障害のときの調査は、結局、担当者の経験に頼ります。ドキュメント上は、どれも対応しているので、機能の差よりも、運用する人の慣れを優先して問題ありません。

全社で使い、複数のサーバーに分ける場合

データベースを、Gitea とは別のサーバーに置く構成を取るなら、データベースの専任の担当者や、既存の運用の仕組みを活かせる種類が有利です。すでに社内で運用している種類があれば、それに合わせると、監視やバックアップを流用できます。この場合も、ドキュメントが求める、サーバーとクライアントのバージョンをそろえる点と、公共のネットワークでの TLS の利用は、必ず守ります。

選んだあとに確認しておきたいこと

データベースを選び、準備を終えたら、Gitea を起動する前に、次の点を確認します。

なお、SQLite を使っている場合は、データベースのファイルが、Gitea のデータのディレクトリに含まれます。バックアップのダンプにも、そのファイルが入ります。別の種類のデータベースでは、データベースの内容が、ダンプの中の SQL のファイルとして出力されます。どちらの場合も、バックアップと復元の手順を、バックアップとリストアで確認しておくと、選んだ種類の運用がイメージしやすくなります。

最初の選択が、運用のしやすさを決める

ここまでの内容をまとめると、データベースの選択は、次の順序で考えられます。

1. 試すだけなら、SQLite で始めます。ただし、その環境を、そのまま本番に移さないと決めておきます。
2. 継続して使うなら、MySQL、MariaDB、PostgreSQL のいずれかを、最初から選びます。
3. 選んだ種類の準備を、ドキュメントの手順どおりに行います。文字セットと照合順序は、特に慎重に確認します。
4. 選んだ種類で、バックアップとリストアを一度、実際に試しておきます。

SQLite から本格的なデータベースへ移すことが不可能なわけではありません。ただし、手順が十分に検証されていない以上、すべてのデータが完全に移ったかを確認する責任は、利用者の側にあります。試す手間を、最初の選択に少し使うほうが、あとの安心につながります。

この記事の内容は、2026年11月15日時点のドキュメントに基づいています。各データベースの対応バージョンは、Gitea の更新で変わることがあるため、導入の前に、使う予定のバージョンが対応範囲に入っているかを確かめてから進めていただくと安心です。