Realm（モバイルDB）とは？SQLiteとの違いとDevice Sync終了後の採用判断を解説

Realmは、スマートフォンやタブレットの端末内で直接動くモバイルデータベースです。2014年に単体のプロダクトとして公開され、2019年にMongoDBが買収、2023年には「Atlas Device SDKs」へ名前を変えました。そして2024年9月、そのAtlas Device SDKとクラウド同期機能であるAtlas Device Syncの非推奨が告知され、同期サービスは2025年9月30日に止まっています。この記事では、Realmが何を解決する道具なのかという構造の話から入り、2026年7月時点で何が残っていて、新規案件でどう扱い、既存アプリをどう判断するのかまでを実装者の目線で整理します。

まとめ：Realmの現在地と2026年の採用判断

先に結論から書きます。止まったのはクラウド同期（Atlas Device Sync）であって、端末内で動くデータベース本体ではありません。ローカルDB部分はApache License 2.0のオープンソースとして残り、Swift向けSDKは2026年6月にもXcode 27対応のパッチが公開されています。「Realmが消えた」という要約は、この2層を混ぜたときに生まれる誤解です。

ただし残ったからといって、新規プロジェクトの既定にはなりません。MongoDBは新機能の追加を続けない方針を示しており、SDKは維持モードに入ったと見るのが妥当です。新規で選ぶ理由が立つのは、iOSとAndroidで同じデータモデルを共有したい、SQLとオブジェクトの変換コードを書きたくない、暗号化された端末内DBを短時間で用意したい、といった限定条件が揃った場合に絞られます。

既存アプリの判断軸は1つで足ります。Device Syncを使っていたかどうか。使っていなければローカルDBはそのまま動き続けるため、移行は急ぎません。使っていた場合は2025年9月に同期が止まっているので、同期層の作り直しが確定済みの課題として残ります。詳しい条件と代替候補は本文で順に扱います。

Realmとは何か：端末内で完結するオブジェクトDBの構造と特徴

Realmが端末内で完結するオブジェクトデータベースである理由

Realmは、端末のストレージに置いた単一ファイルを読み書きするデータベースエンジンです。サーバーもプロセス間通信も挟まず、アプリのプロセスがファイルを直接メモリマップして扱います。この「オフラインが前提」という性質が、モバイルDBと呼ばれる理由です。

もう1つの特徴が、リレーショナルではなくオブジェクト指向のデータモデルを採る点です。テーブルと行の代わりに、Swiftのクラス、Kotlinのクラス、JavaScriptのスキーマ定義がそのままデータ構造になります。関連は外部キーではなくオブジェクト参照で表現し、1対多はList型のプロパティで持ち、逆方向の参照はLinkingObjectsで辿ります。

開発元の変遷も押さえておくと、ドキュメントを読むときに迷いません。買収したMongoDBはドキュメント指向のサーバーサイドDBで、こちらの構造はMongoDBのドキュメント指向データベース入門にまとめてあります。Realmはその端末側の対になる位置づけとして「Atlas Device SDKs」へ改称され、公式ドキュメントも同名で整理されました。古い記事の「Realm Mobile Database」「MongoDB Realm」「Atlas Device SDK」は、いずれも同じ系譜を指しています。

SQLiteとの構造的な違いとマッピング処理が不要になる仕組み

モバイル端末内DBの既定はSQLiteです。iOSのCore Data、AndroidのRoom、Flutterのdrift、いずれも内部にSQLiteを抱えています。Realmとの差は、アプリのオブジェクトとストレージの間に変換層を置くかどうかに集約されます。

SQLiteはテーブルと列でデータを持つため、取り出した行をアプリのクラスへ詰め直す処理が要ります。この変換をORMや自動生成コードが肩代わりする構成が一般的です。Realmはファイル上のデータ構造がそのままオブジェクトのプロパティに対応するため、この変換コードが要りません。

この表の最終行は選定で効いてきます。SQLite側には全文検索の拡張が用意されており、日本語を含む本文検索を実装するならSQLite組み込みの全文検索エンジンFTS5の解説で扱う仕組みが使えます。Realmは文字列の部分一致や前方一致には答えられるものの、転置索引を伴う検索は守備範囲の外です。検索が機能の中心にあるアプリなら、この一点だけで選択が決まります。

ライブオブジェクトとMVCCが同時アクセスを成り立たせる仕組み

Realmを触ると最初に戸惑うのが、取得したオブジェクトが「生きている」ことです。クエリで取り出したインスタンスは値のコピーではなく、ファイル上のデータへの参照。別の場所で書き込みが確定すると、手元の変数を取り直さなくても最新の値を返します。これがライブオブジェクトと呼ばれる挙動で、画面表示とデータの同期ずれが起きにくくなる代わりに、値が固定される前提のコードは破綻します。

この仕組みを支えるのがMVCC（多版型同時実行制御）です。書き込みトランザクションは既存のデータを上書きせず、新しい版を書いてから参照を差し替えます。読み取り側は自分が開始した時点の版を見続けるため、書き込みの最中でもブロックされません。読み取りロックの競合でUIが固まる事故が起きにくいのは、この設計によるものです。

ファイルは単一の.realmファイルにまとまり、古い版は不要になった時点で回収される仕組みです。裏返すと、書き込みが多い時期はファイルが一時的に膨らみます。容量が気になる場面では、コンパクション（圧縮）を明示的に走らせる設計が要ります。

Atlas Device SDK非推奨とDevice Sync終了で変わったこと

2024年9月の非推奨告知と2025年9月30日のDevice Sync停止

2024年9月9日、MongoDBはAtlas Device SDKとAtlas Device Syncの非推奨を告知しました。realm-jsのGitHub Discussionには開発者からの質問が並び、メンテナからは1年以内にサービス終了となる旨の回答が出ています。実際にDevice Syncの提供は2025年9月30日をもって終了しました。

ここで止まったものを具体的に挙げると、端末とAtlasの間で双方向にデータを同期する機能、その土台となるApp Servicesのユーザー認証やFunctions連携です。オフラインで書き込んだ変更をオンライン復帰時に自動で送り、他端末の変更を受け取る。この一連が、Realmを選ぶ最大の理由でした。代替の同等サービスをMongoDB側が案内しなかったため、同期を使っていた開発チームは自前で移行先を探す状況になっています。

ローカルDB部分はApache 2.0のまま残り各SDKの版も進んだ

一方で、端末内データベースとしてのRealmは残りました。ライセンスはApache License 2.0のままで、リポジトリもアーカイブされていません。2026年7月28日時点の実測値を並べます。

注目したいのはSwift向けの動きです。2026年6月に公開されたv20.0.5はXcode 27でのコンパイル不具合を直す修正で、内部のrealm-coreも20.1.5へ上がりました。新機能の追加ではないものの、新しいXcodeで既存アプリがビルドできなくなる事態は避けられている。JavaScript側は同期機能を外した版がnpmのcommunityタグとして配られ、React向けのラッパーも同期APIを削除した0.20系へ移りました。

Realmは終わったという評価と実態の差はどこから生まれるか

非推奨のニュースは「Realmは死んだ」という見出しで流通しました。この評価が実態とずれるのは、Atlas Device SDKが2つの部品の合成だったからです。端末内のデータベースと、クラウド同期。告知が扱ったのは製品としての束であり、終了したのは同期側でした。

とはいえ、残った側の扱いにも注意が要ります。MongoDBは重大な不具合への対応は続けるとしながら、新機能を積極的に足す立場は取っていません。実際、直近のリリースはXcodeやOSの更新に追随する修正が中心です。この状態を評価するなら「使い続けられるが、将来の機能追加を待つ対象ではない」が実務的な表現になります。

SwiftとKotlinで見るRealmの基本的な実装作法とスレッド制約

スキーマ定義と書き込みトランザクションで実装時に押さえる基本の作法

スキーマはクラス定義そのものです。SwiftならObjectを継承したクラスに@Persistedを付けたプロパティを並べ、KotlinならRealmObjectを実装したクラスを書く。マイグレーション用のSQLも、テーブル作成文も書きません。主キーは属性で宣言し、索引が要るプロパティにも同様に宣言を足します。

書き込みは必ずトランザクションの中で行います。Swiftはrealm.writeのブロック内、Kotlinはrealm.writeのスイート内で、オブジェクトの追加・更新・削除をまとめる。ブロックを抜けた時点で確定し、例外が飛べば巻き戻ります。読み取りにトランザクションは要らないため、参照だけの経路は素直に書けます。

Android側の実装では、Kotlin向けSDKがコルーチンとFlowを前提に組まれている点も押さえておきたいところです。変更の購読がFlowで返るため、言語機能の理解がそのまま実装の読みやすさに効きます。言語側の前提はKotlinの特徴とJavaとの違いをまとめた解説に整理しました。

クエリ結果が遅延評価とライブ更新で返る仕組みと実装時に注意すべき点

クエリの戻り値はResultsと呼ばれる型で、これも生きています。条件に合致する件数を数えた時点ではまだ実データを読まず、要素へアクセスした瞬間に必要な分だけファイルから読む。1万件の条件検索を書いても、画面に出す20件しか触らなければ、その20件分の読み出しで済みます。

この遅延評価とライブ更新は、リスト表示との相性が良い代わりに2つの落とし穴を作ります。1つは、ループ中に対象を削除すると走査中のコレクションが縮む点。もう1つは、UIへ渡した後で内容が変わるため、差分更新の前提が崩れる点です。対策は、SDKが提供する変更通知を受けて差分でUIを更新するか、凍結（frozen）したスナップショットを渡すか、どちらかに寄せることです。

iOS側で変更通知を受ける口を作るなら、宣言的に流れを組み立てる仕組みと相性が良いところ。値が繰り返し届く処理の扱いはCombineのPublisherとSubscriberの解説にまとめてあります。SwiftUIでは@ObservedResultsのような専用のプロパティラッパーも用意され、リスト更新の記述量は抑えられます。

スレッド制約とスキーマ移行で実装者が詰まりやすい2つの箇所と対処

実装で最初にぶつかるのがスレッド制約です。Realmのインスタンスも、そこから取り出したライブオブジェクトも、生成したスレッドの外へは持ち出せません。バックグラウンドで取得したオブジェクトをそのままメインスレッドのUIへ渡すと実行時エラーになります。回避の手段は2つで、主キーを渡して受け側で引き直すか、凍結オブジェクトへ変換して値として渡すか。スレッド間受け渡し用の参照型も用意されています。

もう1つがスキーマ移行です。クラス定義を変えたのにスキーマ版を上げないまま起動すると、既存ファイルとの不一致で開けません。プロパティの追加と削除は版を上げるだけで自動処理されますが、型の変更、プロパティ名の変更、主キーの入れ替えは移行処理を自分で書く必要があります。旧値を読んで新プロパティへ詰め替える処理を、版ごとに積み上げる形です。

開発中に限れば、不一致時にファイルを削除して作り直す設定も使えます。ただしこれは端末上のデータを消す挙動なので、公開ビルドで有効にしたまま出すとユーザーのデータが飛びます。

2026年にRealmを新規採用してよい条件と見送るべき条件の整理

新規プロジェクトでRealmの採用が成り立つ3つの具体的な場面

維持モードのライブラリを新規で選ぶには、それを上回る理由が要ります。実務で理由が立つ場面は3つに絞られました。

1つめは、iOSとAndroidで同じデータモデルを共有したい場合です。SwiftDataはApple環境専用、RoomはAndroid中心で、両OSに同じ設計を敷こうとすると別々の実装になります。Realmは同じスキーマ概念とAPI体系を両OSに持ち込めるため、仕様書とテスト設計を一本化できます。

2つめは、端末内データの暗号化を短時間で用意したい場合です。ファイル全体の暗号化がSDKの標準機能として組み込まれており、開くときに鍵を渡す形で有効になります。SQLite側で同等を実現するには暗号化拡張を別途組み込む手間がかかるため、業務アプリの初期構築では差が出ます。

3つめは、既存の社内資産がRealmで揃っている場合です。データ層のユーティリティ、テストのフィクスチャ、レビュー基準が積み上がっているなら、動く仕組みを維持する判断は合理的です。

Realmを新規採用しないと判断すべき3つの条件と代替の候補

見送りの条件は、どれか1つ当てはまれば十分です。第1に、端末とサーバーの双方向同期をライブラリ任せにしたい案件。この用途こそDevice Syncが担っていた部分で、2025年9月に消えました。第2に、全文検索が機能の中心にある案件。前述のとおり守備範囲の外です。第3に、5年以上の保守を前提とし、新機能の追加を織り込んで計画する案件。維持モードのライブラリに賭ける判断は、この条件と噛み合いません。

iOS単体でSwiftDataを選ぶ場合、対象OSがiOS 17以降に上がる点は先に確認してください。両OS共通の要件でKotlin Multiplatformを敷いているなら、SQLDelightが定義の共有と型安全の両方を満たします。

既存Realmアプリの移行判断と受託開発での工数見積もりの観点

Device Syncを使っていたかどうかで移行の重さが決まる理由

手元のアプリがRealmを使っている場合、最初に調べるのは同期の有無です。ローカルDBとしてしか使っていないなら、2025年9月の終了は動作に影響しません。SDKの更新も続いているので、当面はそのまま運用しながら、次の大きな改修のタイミングで移行を検討すれば足ります。

同期を使っていた場合は話が別で、代替の設計が確定済みの課題になります。選択肢は大きく2つ。同期を持つ製品へDBごと乗り換えるか、ローカルDBはそのままにして同期層だけ別の仕組みへ切り出すか。後者を採るなら、サーバー側の変更を端末へ流し込む仕組みを独立した層として設計することになり、その考え方はリアルタイム同期を担うElectricSQLの解説で扱う構成が参考になります。

切り分けの実務では、同期対象のコレクションを洗い出し、競合が起きたときの解決規則を明文化する作業が出発点です。Device Syncはこの規則を製品側が持っていたため、移行では自分たちで決め直す必要が出てきます。

移行先の選定で効いてくる3つの判断軸と工数を見立てる際の順序

移行先を絞る軸は3つです。対象プラットフォームの範囲、スキーマ移行の可否、そしてクエリ記述の書き換え量。1つめは前節の表のとおりで、単一OSなら標準の仕組みへ寄せるほど保守が軽くなります。

2つめのスキーマ移行では、Realmのオブジェクト参照をどう表現し直すかが焦点です。SQLite系へ移すと参照は外部キーに変わり、1対多のListは中間テーブルか従属テーブルへ展開されます。逆参照のLinkingObjectsに依存したコードがあれば、そこも書き換え対象です。

3つめが見落とされがちで、実は工数の大半を占めます。Realmの型付きクエリとライブオブジェクトを前提に書かれた画面のコードは、値が固定される前提のDBへ移すと更新経路の設計から見直すことになる。見立ての順序としては、画面数とクエリ箇所の数え上げを先に行い、データ変換の設計はその後に置くと精度が上がります。

既存モバイルアプリの保守と移行を開発体制で内製と外注に分ける判断基準

移行の判断で詰まるのは、技術的な難しさより体制の問題であることが多いところです。社内にモバイル担当が1人しかいない状態でデータ層の入れ替えを抱えると、その1人が塞がっている期間は機能改修も不具合対応も止まります。逆に、複数人でレビューが回る体制なら、段階的な移行を内製で進める価値は十分あります。

分ける基準は「移行後のコードを社内で読み続けられるか」の一点です。読み続けられないなら、外注で作り切っても保守で行き詰まります。既存のRealmアプリを抱えていて移行の判断を外部の視点と突き合わせたいなら、一創のスマホアプリ開発で対応範囲を確認してください。現行コードと同期利用の有無を見たうえで、移す範囲と据え置く範囲を切り分けるところから相談できます。

よくある質問

Realmの採用検討でよく挙がる5つの疑問に答えます。

Realmはもう使えなくなったのですか？

端末内データベースとしては使えます。止まったのはクラウド同期のAtlas Device Syncで、2025年9月30日に提供が終わりました。ローカルDB部分はApache License 2.0のオープンソースとして残り、Swift向けSDKには2026年6月にもXcode 27対応の修正が入っています。ただし新機能の追加は続かない前提で扱うのが妥当です。

RealmとSQLiteはどちらを選ぶべきですか？

単一OSのアプリで、全文検索やSQLでの集計を使うならSQLite系です。iOSならSwiftDataかCore Data、AndroidならRoomが標準の経路になります。両OSで同じデータモデルを共有したい、変換コードを書きたくない、端末内の暗号化を素早く用意したい、という条件が重なる場合にRealmの利点が出ます。

Realmのデータをアプリの更新後も残すにはどうしますか？

クラス定義を変えたらスキーマ版を上げ、必要なら移行処理を書きます。プロパティの追加と削除は、版を上げるだけで自動処理の対象です。型変更や名前変更は旧値から新プロパティへ詰め替える処理が要ります。不一致時にファイルを消して作り直す設定は開発ビルド限定にしてください。公開ビルドで有効だとユーザーのデータが消えます。

Realmの学習にはどれくらい時間がかかりますか？

スキーマ定義とCRUD、トランザクションの書き方までなら、Swiftまたはkotlinの経験がある人で1日から2日程度。難所はその先で、スレッド制約と凍結オブジェクトの使い分け、変更通知を受けたUI更新、スキーマ移行の3点には別途の期間を見てください。ここを飛ばすと、実行時エラーとデータ消失の両方を踏みます。

Realmから移行するとき既存データはどう運びますか？

旧Realmファイルを読み出し、新しいDBへ書き込む一度きりの変換処理をアプリ内に置く形が基本です。初回起動時に変換を走らせ、完了フラグを保存して二重実行を防ぎます。件数が多い場合は分割して進めるか、変換中の画面を用意します。変換前のファイルは一定期間残し、失敗時に戻せる経路も用意しておくと安全です。

関連記事

• iOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断：発注側の視点で全体像と費用感を整理しています。
• Kotlinとは？特徴・Javaとの違い・Android開発での使いどころ：Android側のSDKを読むときの言語の前提になります。
• FlutterとReact Nativeの違いと選び方｜2026年の判断基準：クロスプラットフォーム構成でのデータ層選定と併せて読めます。
• Tursoの基本概要とエッジSQLite採用が注目される理由：SQLite系を端末外へ広げる構成の対比になります。
• DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違い：組み込みDBの選択肢を横に並べて比較できます。