MariaDBとは？MySQLとの違いと移行時に効く差分を12.3 LTS時点の実装目線で解説

MariaDBとは、MySQLの初期開発者Michael “Monty” Wideniusらが立ち上げた、MySQL互換のオープンソースRDBMSです。SQLの書き方も接続ドライバもほぼ共通なので、名前だけ違うMySQLだと受け取られがちです。ところが2026年10月時点の12.3 LTSとMySQL 8系のあいだには、JSON型の実装、GTIDの形式、認証方式、データディレクトリの構造という4つの大きな差が開いています。

この記事では、MariaDBの成り立ちとライセンス、版構成とサポート期限、Dockerでの起動、MySQL 8系と互換が崩れる箇所、移行とレプリケーション併走の手順を、公式ドキュメントの記述に沿って順に整理しました。MySQL本体の特徴はMySQLとは？特徴とバージョン選定・採用判断を実装目線で解説に、PostgreSQLとの比較はPostgreSQLとMySQLの違いを徹底比較へ譲ります。

まとめ：MariaDBを選ぶ条件とMySQL 8系から移る前に確かめる差分

• 正体：MySQLから分岐したGPLv2のRDBMSです。商用ライセンスの買い取りという選択肢を持たず、同期レプリケーションのGaleraを標準で同梱します
• 版：新規に固定するなら12.3 LTS（2026年10月時点で12.3.3）です。13系は四半期ごとに入れ替わるローリングリリースで、本番の固定先には向きません
• 移行：MySQL 8.0以降のデータディレクトリをMariaDBでそのまま開くことはできません。mysqldumpによる論理移行が前提になります
• 落とし穴：JSON型はLONGTEXTの別名で、11.8では->演算子が通りません。GTIDも互換が無く、複製は位置指定で張ります
• 判断：MySQL 8.4以降の新機能やMySQL HeatWaveに依存する案件では見送り、ライセンス費用を避けたい自前運用の案件では採用候補に入れます

MariaDBとは何か：MySQLから分岐した経緯とGPLv2ライセンスの実態

MySQLの初期開発者が立ち上げたフォークとしての成り立ちと運営体制

MariaDBは、MySQLがSun Microsystemsを経てOracleの手に渡る過程で、MySQLの初期開発者が中心となって分岐させたプロジェクトです。MariaDB Foundationの公式紹介ページは、MariaDBを「MySQLのドロップイン置き換えとして設計された後継」と位置づけ、Wideniusを精神的な父として紹介しています。ソースコードはGitHubのMariaDB/serverリポジトリで公開され、開発の主ブランチがそのままローリングリリースの元になります。

運営は2系統に分かれています。非営利のMariaDB Foundationがコミュニティ版のリリースを担い、営利企業のMariaDB plcがEnterprise版と有償サポートを売る構図です。発注側が押さえるべき点は1つで、コミュニティ版の保守期間とEnterprise版の保守期間が別々に決まっていることです。

GPLv2で一本化されたライセンスとMySQLのデュアルライセンスとの差

MariaDB ServerはGPLv2のみで配布されます。MySQLはOracleがGPLと商用ライセンスのデュアルライセンスで提供しており、GPLの条件を受け入れられない製品へ組み込む場合は商用ライセンスを買う道があります。MariaDBにはその「買って逃げる」道がありません。

実務上の影響は、サーバーを組み込んで再配布するかどうかで分かれます。自社のWebサービスの裏でデータベースとして動かすだけなら、GPLの配布条件はほぼ効きません。一方、MariaDBを同梱したアプライアンスやパッケージ製品を顧客へ納品する場合は、ソース開示義務の範囲を法務と確認してから選びます。接続ドライバのMariaDB Connector/CはLGPLなので、アプリケーション側のライセンスまで縛られることは通常ありません。

12.3 LTSと13系ローリングが並ぶ2026年10月時点の版構成とサポート期限

MariaDBは2025年からLTSとローリングの2本立てで出ています。公式のメンテナンスポリシーでは、LTSは毎年1本出て、コミュニティ版のバイナリはGAから3年、その後2年はソースでの重大修正が続きます。11.4以前のLTSはGAから5年です。最新の保守版は2026年8月24日の四半期リリース告知とDocker Hubの公式イメージのタグで確かめました。

10.6系で動いている環境は、すでにコミュニティ版の修正が出ない状態です。新規構築の固定先は12.3、既存の10.11や11.4は期限まで据え置きつつ12.3への引き上げ計画を立てる、という順で考えます。

Dockerで公式イメージを起動しMariaDBの版と既定値を確かめる手順

公式イメージのltsタグと版番号固定タグを使い分けて起動するコマンド

手元で挙動を確かめるなら、Docker Hubの公式イメージが早道です。公式の説明ではlatestが最新の安定版、ltsが直近のLTSを指します。2026年10月21日時点のタグ一覧では、latest系統の先頭が13.0.2、ltsが12.3系でした。案件の環境ではltsのような動くタグを避け、パッチ番号まで固定します。

docker run --detach --name mariadb-dev \
  --env MARIADB_ROOT_PASSWORD=devrootpw \
  --env MARIADB_DATABASE=appdb \
  --env MARIADB_USER=appuser \
  --env MARIADB_PASSWORD=appuserpw \
  -p 3306:3306 \
  -v mariadb-dev-data:/var/lib/mysql \
  mariadb:12.3.3

環境変数はMYSQL_ではなくMARIADB_で始まります。公式の説明によれば、MARIADB_AUTO_UPGRADEを除く変数は、既存のデータが入ったディレクトリで起動すると効きません。MySQLイメージとの共通点や相違点はDockerでMySQLを構築する手順と並べて読むと把握しやすくなります。

照合順序と認証プラグインの既定値をSQLで確かめる確認クエリ

起動したら、MySQLとの違いが出やすい既定値を最初に見ておきます。コンテナにはクライアントとしてmariadbコマンドが入っています。

docker exec -it mariadb-dev mariadb -uroot -pdevrootpw -e "
  SELECT VERSION(), @@character_set_server, @@collation_server,
         @@default_storage_engine, @@performance_schema;
  SELECT user, host, plugin FROM mysql.user;"

MariaDB公式の互換性マトリクスでは、MySQL 8系の既定の照合順序がutf8mb4_0900_ai_ciなのに対し、MariaDB 11.4以降はutf8mb4_uca1400_ai_ciです。並べ替えや大文字小文字の比較結果が変わりうるので、既存データの移行前にここを把握します。performance_schemaはMariaDBでは既定で無効になっており、MySQLの監視ツールをそのまま当てると値が空で返ってきます。

MySQL 8.0との互換性が崩れる箇所とストレージエンジン・独自機能の差

JSON型がLONGTEXTの別名である点と矢印演算子が11.8で使えない制約

互換の崩れが最も表に出るのはJSONです。MariaDB 11.8とMySQL 8.0の非互換一覧によれば、MariaDBのJSON型はLONGTEXTの別名で、バイナリ形式では保存しません。JSON同士の比較もMySQLは値として、MariaDBは文字列として行います。

コードへの影響が大きいのは演算子です。MySQLのcol->'$.name'やcol->>'$.name'は11.8では構文エラーになり、公式文書は13.1で追加と記しています。12.3 LTSを選ぶ場合も、ORMが吐くSQLにこの演算子が混ざっていないかを確かめ、JSON_EXTRACT()とJSON_UNQUOTE()へ書き換えるのが確実です。同じ一覧には、SELECT ... FOR SHAREの綴りやSET PERSISTが使えない点も載っています。

GTIDの形式非互換と認証プラグインcaching_sha2_passwordの扱い

GTIDは形式からして別物です。MySQLはUUID:連番、MariaDBはドメインID-サーバーID-連番で、互換性マトリクスはこの差を「Critical」と分類しています。MySQLとMariaDBを混在させる構成では、GTIDによる自動位置決めを使えず、バイナリログのファイル名と位置で複製を張ることになります。

認証も見落としやすい差です。MySQL 8系の既定はcaching_sha2_passwordで、8.4ではmysql_native_passwordが既定で無効になりました。公式の移行ガイドに載っているユーザー移送スクリプトは、mysql_native_passwordのアカウントならパスワードを引き継げますが、caching_sha2_passwordのアカウントは初期値へ戻して期限切れ扱いにします。アプリの接続ユーザーは移行当日にパスワードを再設定する前提で段取りを組みます。

MariaDB固有のAria・ColumnStore・Galera・VECTOR型の用途

MariaDBにしかない機能も選定時の比較対象です。ストレージエンジンでは、MyISAMを置き換えるAria、列指向の分析用ColumnStore、S3へテーブルを退避するS3エンジン、他サーバーのテーブルをまとめるSpiderが使えます。同期型マルチプライマリのGalera Clusterもサーバーに標準で入っています。

2026年に効いてくるのはベクトル型です。公式のVector Overviewによれば、VECTOR型とベクトルインデックスは11.7で入り、11.8が最初のLTSです。RAGの検索用に埋め込みを同じテーブルへ置けます。

CREATE TABLE doc_chunks (
  id BIGINT PRIMARY KEY,
  body TEXT NOT NULL,
  embedding VECTOR(1536) NOT NULL,
  VECTOR INDEX (embedding) M=8 DISTANCE=cosine
);

SELECT id, body
FROM doc_chunks
ORDER BY VEC_DISTANCE_COSINE(embedding, VEC_FromText(@query_vec))
LIMIT 5;

公式文書は、インデックスが使われるのはORDER BYに距離関数をそのまま置きLIMITを付けた場合だけで、WHEREで距離の閾値を切ると全件走査になると注意しています。件数が数百万を超える用途では、専用のベクトルデータベースと性能を比べてから決めます。

MySQL 8系からMariaDBへ移行する手順とレプリケーション併走の設定

データディレクトリの差し替えが不可能な理由とmysqldumpによる論理移行

MySQL 5.x時代は、MySQLを止めてMariaDBのバイナリへ差し替えるだけで移れました。8.0以降ではこの方法が使えません。公式の移行マスターガイドは、MySQL 8.0が.frmファイルを廃止して内部のデータディクショナリへ移したため、MariaDBからはテーブル定義を読めないと説明しています。移行先には11.8 LTSか12.3 LTSを推しています。

# 移行元のMySQLで実行（mariadb-dumpではなくMySQL付属のmysqldumpを使う）
mysqldump --user=root --password --databases appdb \
  --single-transaction --routines --events \
  --triggers --hex-blob > migration_dump.sql

# 移行先のMariaDBへ投入
mariadb --user=root --password < migration_dump.sql

同ガイドは、--all-databasesを使わず対象データベースを列挙するよう求めています。mysqlシステムデータベースの構造が両者で違い、投入時に失敗するためです。ユーザーと権限は、前の章で触れた移送スクリプトで別に作り直します。

MySQL 8.0からMariaDBへ複製で併走させる設定と位置指定の接続

停止時間を短くしたい案件では、MySQLを複製元、MariaDBを複製先にしてしばらく併走させます。MariaDBとMySQLの複製互換ページによれば、MySQL 8.0からの複製は10.11.11・11.4.5以降で可能になり、MySQL側に次の設定が要ります。

# MySQL 8.0側のmy.cnf
[mysqld]
binlog-row-value-options=""
binlog_transaction_compression=0
binlog_format=row

-- MariaDB側（GTIDを使わずファイル名と位置で接続する）
CHANGE MASTER TO
  MASTER_HOST='10.0.1.20', MASTER_USER='repl', MASTER_PASSWORD='replpw',
  MASTER_LOG_FILE='binlog.000123', MASTER_LOG_POS=157,
  MASTER_USE_GTID=no;
START REPLICA;

前2行は、MariaDBが解釈できない部分更新イベントと圧縮イベントを止めるための設定です。JSON型の列は複製できないため、MySQL側でTEXTへ変えておく必要があります。11.4.9・11.8.4・12.1.1より前の版ではcaching_sha2_passwordの複製ユーザーで接続できず、mysql_native_passwordの専用ユーザーを別に作ります。

切り替え前に流す照合順序とJSON列とスロークエリの3点確認

併走中に確かめる項目は3つに絞れます。最優先は照合順序です。11.4.5以降はMySQLのutf8mb4_0900_ai_ciなどに対応する別名照合が44個入り、ダンプはそのまま通ります。ただし並べ替え結果が同一になる保証はないため、一覧画面の並び順を本番データで突き合わせます。

次がJSON列です。比較が文字列比較に変わるので、JSONの値で絞り込むクエリは移行前後の件数照合が必要です。最後がオプティマイザの差で、同じSQLでも実行計画が変わります。移行先でスロークエリログを有効にして上位のクエリを洗い出す手順は、スロークエリログとは｜MySQLの設定・見方・解析ツールと改善手順の内容がほぼそのまま通用します。

MariaDBを採用すべき案件の条件と見送るべき場面の判断基準

ライセンス費用を避けたい自前運用の案件でMariaDBを選ぶ条件

MariaDBを選んでよいのは、自社サーバーやIaaSの仮想マシンに自前で立て、MySQL Enterpriseの費用を払わずに監査ログやデータ暗号化、同期レプリケーションまで揃えたい案件です。Galeraが標準で入り、暗号化や監査のプラグインもコミュニティ版で使えるため、費用面の差がはっきり出ます。

もう1つの条件は、既存資産がMySQL 5.7や8.0で、JSON演算子やMySQL固有の新機能に深く依存していないことです。逆にこの棚卸しを飛ばして「互換だから」と移すと、本番切り替え後にORMのSQLが落ちます。移行可否の棚卸しから設計までを外部へ任せたい場合は、一創のデータベース設計・移行支援で相談を受けています。

MySQL 8.4以降の機能やマネージド前提の案件でMariaDBを見送る場面

見送るのは次の場面です。MySQL HeatWaveの分析機能や、MySQL 8.4以降のInnoDB ClusterとMySQL Shellによる運用を前提にした案件では、MariaDBに置き換える利点がありません。AWS上でAurora MySQLのストレージ自動拡張や高速フェイルオーバーを使う予定なら、選択肢はAurora MySQLの実装ガイドで扱うAurora側になります。

書き込みの水平分散が要件に入っている場合も、MariaDBは第一候補になりません。Galeraは全ノードへ同期で書き込むため、書き込み性能はノードを足しても伸びにくい構造です。MySQL互換を保ったまま分散したいなら、TiDBとは：MySQL互換の分散SQLの仕組みで触れた分散SQLを比べます。

よくある質問

MariaDBについて検索でよく調べられている疑問に、2026年10月時点の公式情報をもとに答えます。

MariaDBとMySQLは同じものですか？

別の製品です。MariaDBはMySQLのソースから分岐したフォークで、SQLの構文、通信プロトコル、主要な接続ドライバの多くを共有しています。ただし分岐から十数年が経ち、JSON型の実装、GTIDの形式、既定の認証方式、データディレクトリの構造が別物になりました。MySQL 5.x時代の「そのまま置き換えられる」という説明は、MySQL 8.0以降には当てはまりません。移行する場合は非互換一覧を見たうえで、論理移行を前提に計画します。

MariaDBは無料で商用利用できますか？

できます。MariaDB ServerはGPLv2で配布されており、自社のWebサービスや業務システムのデータベースとして使う限り、ライセンス費用はかかりません。注意が要るのは、MariaDBのサーバー本体を製品に同梱して顧客へ配布する場合で、GPLのソース開示義務がかかります。有償の保守が必要なら、MariaDB plcのEnterprise版とサポート契約という選択肢があり、保守期間もコミュニティ版より長く設定されています。

MySQL用のコマンドや接続ドライバはMariaDBでそのまま使えますか？

大半はそのまま利用することが可能です。MariaDBのクライアントやツールはmariadb、mariadb-dumpのような名前に変わりましたが、旧来のmysql系の名前もシンボリックリンクとして残されています。PHPのPDO、JavaのJDBC、PythonのドライバもMySQL用のものが動きます。例外はMySQL 8系のcaching_sha2_passwordに依存した接続設定と、MySQL固有のX Protocolを使うクライアントで、後者はMariaDBでは動きません。

MariaDBのバージョンはどれを選べばよいですか？

新規構築なら12.3 LTSを選び、パッチ番号まで固定します。2026年10月時点の最新は12.3.3で、コミュニティ版の期限は2029年6月12日です。13系は四半期ごとに新版へ移るローリングリリースで、新機能の検証には向きますが、長期間固定する本番環境には向きません。既存の10.11系や11.4系は期限内なので急ぐ必要はありませんが、2026年7月に期限が切れた10.6系は早めに引き上げます。

MariaDBとPostgreSQLはどちらを選ぶべきですか？

既存のアプリケーションやチームの知見がMySQL系にあるならMariaDB、複雑なクエリや豊富なデータ型、拡張機能を重視するならPostgreSQLが基本の分け方です。MariaDBはMySQLからの移行コストが低く、PostgreSQLは移行時にSQLの書き換えが発生します。両者の機能差の詳細は、MySQLとPostgreSQLの比較記事の論点がMariaDBにもほぼ当てはまるため、そちらで判断材料を揃えてください。

関連記事

• MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説：分岐元のMySQL本体の特徴と版選定
• PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け：MySQL系とPostgreSQLの選び分け
• DockerでMySQLを構築する手順｜タグ選定とcompose定義・初期化：MySQL側の同型のコンテナ構築手順
• Aurora MySQLの実装ガイド：版の確認、MySQL 8.0との差分とRDSからの移行手順：AWSのマネージドで運用する場合の比較先
• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：RDBMS全体の中での位置づけ