保守コストをゼロにするシステム設計！データベース要らない派のエンジニアが実践するシンプルなデータ保持の技術

データを保存するなら、まずデータベースを用意する。
多くの開発現場では、それが半ば前提になっています。
たしかに、検索、更新、整合性、同時実行制御まで含めて考えれば、データベースは非常に強力な選択肢です。
しかし、すべてのシステムがそこまでの仕組みを本当に必要としているとは限りません。
むしろ、扱うデータの性質や更新頻度、障害時の復旧方針を冷静に分解すると、データベースを導入した瞬間に、構築、運用、監視、移行といった保守コストを自ら増やしているケースも少なくありません。

本記事では、いわゆる「データベース要らない派」の立場から、できるだけ構成要素を減らし、保守負荷を抑えながら、必要十分なデータ保持を実現する設計技術を整理します。
対象は、設定ファイル、ログ、キャッシュ、生成可能な中間データ、外部サービスと連携するための最小限の状態管理などです。
重要なのは、データを保存すること自体を目的にせず、「何を、どの期間、どの精度で保持すべきか」を先に定義することです。

データベースを使わない設計は、単なる手抜きではありません。
要件を分解し、永続化の必要性を見極め、復元可能性と単純性を優先する、きわめて工学的な判断です。
この記事では、ファイル保存、オブジェクトストレージ、環境変数、インメモリ保持などの選択肢を比較しながら、どこまでシンプルにできるのか、そしてどこから複雑さを受け入れるべきなのかを、実践的な観点で検討していきます。

データベース不要のシステム設計が注目される理由

システム設計の議論では、データを扱う以上、まずデータベースを置くべきだという発想が非常に強くあります。
実際、業務システムや大規模サービスでは、その判断は合理的です。
検索、更新、集計、排他制御、障害復旧といった要件を安定して満たすには、データベースはよく整理された解決策だからです。
しかし、すべてのシステムがその前提に従う必要があるかというと、必ずしもそうではありません。
近年、データベース不要のシステム設計が注目されているのは、単に流行しているからではなく、要件に対して構成が過剰であるケースが想像以上に多いからです。

特に、小規模なWebアプリ、個人開発のツール、社内向けの補助システム、定期実行されるバッチ処理などでは、保持すべきデータの量も種類も限定的であることが少なくありません。
その場合、本当に必要なのは高機能なデータ管理基盤ではなく、壊れにくく、理解しやすく、復旧しやすい保存方法です。
つまり、重要なのは「データベースを使うかどうか」ではなく、「そのデータにどこまでの管理機能が必要か」を先に定義することです。
この順序を逆にすると、必要のない複雑さを最初から抱え込むことになります。

保守コストを増やすデータベース運用の典型パターン

データベースは便利ですが、導入した瞬間に運用対象が一つ増えるという事実は軽視できません。
アプリケーション本体だけで完結していたはずの構成に、接続設定、認証情報、バックアップ、マイグレーション、監視、バージョン管理といった責務が追加されます。
これらは一つひとつが独立した作業であり、開発初期には小さく見えても、時間とともに保守コストとして積み上がっていきます。

典型的なのは、保存するデータが数件から数百件程度しかないにもかかわらず、RDBMSを前提に設計してしまうケースです。
この場合、実際に必要なのは単純な設定値の保存や処理結果の記録だけであるにもかかわらず、テーブル設計、スキーマ変更、接続プール、障害時の復旧手順まで考える必要が生まれます。
要件に対して道具が重すぎるわけです。

保守コストが増える要因は、主に次のように整理できます。

• スキーマ変更のたびに移行手順を管理する必要がある
• 開発環境と本番環境でデータベース差異が発生しやすい
• バックアップとリストアの検証を継続的に行う必要がある
• 接続障害や性能劣化の監視対象が増える
• アプリケーションの修正とは別に、データ整合性の確認作業が発生する

これらは大規模システムでは必要経費ですが、小規模システムでは費用対効果が合わないことがあります。
しかも厄介なのは、こうした負担が機能追加の瞬間ではなく、運用を続けるほどじわじわ効いてくる点です。
結果として、最初は簡単なツールだったものが、数か月後には「触るのが怖い構成」になってしまいます。

小規模システムでDBが過剰設計になりやすい背景

小規模システムでデータベースが過剰設計になりやすい背景には、技術的な理由だけでなく、設計時の心理的な慣性もあります。
多くのエンジニアは、過去に見てきた一般的な構成を再利用します。
Webアプリならアプリケーションサーバーとデータベース、という組み合わせは非常に自然で、フレームワークの初期設定もその前提で作られていることが多いです。
そのため、要件を細かく検討する前に、構成だけが先に決まってしまいます。

しかし、小規模システムでは、そもそも保存対象が「設定ファイルで十分」「ログとして残せば十分」「再実行すれば再生成できる」といった性質を持つことが多いです。
このとき本来問うべきなのは、データを正規化して永続化することではなく、消えて困る情報は何か、復元にかかるコストはいくらか、同時更新は本当に起こるのか、といった点です。
ここを詰めずにデータベースを導入すると、必要性ではなく慣習で構成を選んだことになります。

たとえば、1日1回だけ実行されるバッチが、外部APIから取得した結果を一時的に保存したいだけなら、JSONファイルやオブジェクトストレージで十分な場合があります。
ユーザーごとの複雑な検索やリアルタイム更新がないなら、RDBMSの強みはほとんど活かされません。
それにもかかわらずDBを入れると、設計の自由度が上がるどころか、変更時の制約が増えます。

小規模システムほど重要なのは、将来の拡張可能性を過大評価しすぎないことです。
拡張の可能性に備えるのは大切ですが、存在しない要件のために現在の保守性を犠牲にするのは合理的ではありません。
まずは単純な保存方式で成立するかを検討し、検索性、整合性、同時実行性の要求が明確になった段階で、はじめてデータベース導入を再評価する。
この順番のほうが、設計としてははるかに健全です。

データベース不要の設計が注目される理由は、データベースを否定したいからではありません。
必要な場面では使うべきです。
ただし、必要でない場面まで無条件に採用すると、システムは静かに複雑化します。
だからこそ、まず要件を分解し、保存すべきものの正体を見極めることが、保守コストを抑える設計の出発点になります。

まず整理したいデータ保持の要件定義と判断基準

データ保持の設計で最初に行うべきことは、保存手段を選ぶことではありません。
先に整理すべきなのは、何を保存する必要があるのか、そのデータはなぜ必要なのか、消えた場合にどの程度困るのかという要件です。
ここを曖昧にしたままデータベースやストレージの種類を決めると、保存そのものが目的化し、結果として不要な永続化や過剰な構成を招きやすくなります。

実務では、データは一括りに扱われがちですが、実際には性質がかなり異なります。
ユーザーが入力した設定値、外部APIから取得した一時的なレスポンス、処理結果のキャッシュ、監査のためのログ、障害調査用のメタ情報では、求められる保持期間も復元可能性もまったく違います。
したがって、保存方式を決める前に、データの役割を分解して考える必要があります。
設計の質は、保存技術の選定よりも、この分解の精度に強く依存します。

特に重要なのは、データを「失うと困るもの」と「失っても再生成できるもの」に分ける視点です。
この区別ができるだけで、永続化の対象はかなり絞れます。
すべてを同じ重さで扱わないことが、保守コストを抑える第一歩です。

永続化が本当に必要なデータと不要なデータの見分け方

永続化が必要かどうかを判断する際は、まず「そのデータは消えたら業務や機能が成立しなくなるか」を考えるべきです。
たとえば、ユーザーが手動で登録した設定値、外部に再取得できない入力内容、監査上の証跡として残す必要がある記録は、基本的に永続化の優先度が高いです。
一方で、計算によって再生成できる集計結果、一時的なキャッシュ、再実行すれば再取得できるAPIレスポンスは、必ずしも永続化を前提にしなくても成立します。

ここでありがちな誤りは、「あとで使うかもしれないから保存しておく」という発想です。
この判断は一見安全に見えますが、保存対象が増えるほど、管理対象も増えます。
保存形式の互換性、容量管理、バックアップ、削除方針、アクセス制御まで含めて責務が増えるため、曖昧な理由で保持するデータは、将来の負債になりやすいです。

見分け方としては、次の観点が有効です。

• 元データを外部から再取得できるか
• 同じ処理を再実行すれば再生成できるか
• 消失時にユーザー体験や業務に直接影響するか
• 法務、監査、課金などの理由で記録保持が必要か
• 保持期間に明確な要件があるか

この観点で整理すると、永続化が必要なデータは意外と少ないことがあります。
たとえば、バッチ処理の途中経過や画面表示用の整形済みデータは、元データさえ残っていれば再構築できる場合が多いです。
その場合、途中結果まで厳密に保存する必要はありません。
逆に、ユーザーが最後に選択した設定や、外部システムとの連携状態のように、再現が難しい状態情報は、件数が少なくても丁寧に保持すべきです。

要するに、永続化の判断はデータ量ではなく、再現可能性と消失コストで決めるべきです。
ここを誤ると、本来は軽量に済むはずのシステムが、不要な保存責務を抱えることになります。

更新頻度・検索性・整合性から保存方式を決める考え方

永続化の要否を整理した後は、どの保存方式が適切かを判断します。
このとき有効なのが、更新頻度、検索性、整合性という三つの軸で考える方法です。
保存方式の選定は技術の好みで決めるものではなく、要求される性質との対応で決めるべきです。

更新頻度が低く、内容も単純で、人間が読める形で管理したいデータであれば、JSONやYAMLのようなファイル保存は有力です。
設定ファイルや少量の状態管理には十分実用的です。
一方で、頻繁に書き換わるデータを複数の処理が同時に扱う場合、単純なファイル保存では競合や破損のリスクが高まります。
その場合は、少なくとも排他制御を考慮した仕組みが必要になります。

検索性も重要です。
単に読み込んで使うだけのデータなら、キーと値の対応が取れれば十分ですが、複数条件で絞り込みたい、履歴を横断して集計したい、部分一致検索をしたいといった要件があるなら、保存方式に求められる能力は一段上がります。
検索要件が強いのに単純なファイル構成で押し切ろうとすると、アプリケーション側に無理な検索ロジックを実装することになり、結果として複雑さが別の場所に移るだけです。

整合性については、複数の値が常に一貫して更新される必要があるかを見ます。
たとえば、在庫数と注文状態のように、片方だけ更新されると不整合になるデータは、トランザクション的な扱いが必要です。
逆に、多少の遅延や一時的不一致を許容できるログやキャッシュであれば、そこまで強い整合性は不要です。
この違いを無視すると、必要以上に重い保存基盤を選ぶか、逆に軽すぎる方式で事故を起こすかのどちらかになります。

整理すると、保存方式の判断は次のように考えられます。

観点	低い場合の選択肢	高い場合の選択肢
更新頻度	ファイル保存、静的設定	排他制御を伴う保存基盤
検索性	単純なキー参照、全件読込	クエリ可能なデータ管理
整合性	最終的整合で許容	一貫更新を重視した管理

この表が示す通り、保存方式は単独の条件では決まりません。
更新頻度は低いが整合性は高く求められる、検索性は低いが監査要件は厳しい、といった組み合わせもあります。
したがって、設計では一つの軸だけで即断せず、複数の要件を並べて比較する必要があります。

結局のところ、データ保持の設計で重要なのは、最初から万能な仕組みを選ぶことではありません。
必要な性質を言語化し、その性質を満たす最小の手段を選ぶことです。
この順序を守れば、データベースを使うべき場面と、使わなくてよい場面の境界がかなり明確になります。
シンプルな構成を実現したいなら、保存技術の前に、まず要件の輪郭を正確に描くことが不可欠です。

データベースを使わずにデータを保持する代表的な方法

データを保持する方法は、必ずしもデータベースに限りません。
むしろ、要件を丁寧に分解すると、データベース以外の手段のほうが合理的な場面は少なくありません。
特に、小規模なWebアプリ、個人開発のツール、社内向けの補助システム、定期実行バッチのように、保存対象が限定的で、検索や同時更新の要件が強くない場合は、より単純な保存方式のほうが保守しやすくなります。
重要なのは、保存手段の機能の多さではなく、必要な性質を最小の複雑さで満たせるかどうかです。

データベースを使わない代表的な方法としては、ファイル保存、オブジェクトストレージ、インメモリ保持が挙げられます。
これらは一見すると簡易的な手法に見えるかもしれませんが、適切な前提条件のもとで使えば、十分に実用的です。
むしろ、構成要素が少ないぶん、障害点が減り、復旧手順も明快になります。
設計上の要点は、それぞれの方式が何に向いていて、どこに限界があるかを理解したうえで使い分けることです。

JSON・YAML・CSVなどファイル保存を使い分けるコツ

ファイル保存は、もっとも基本的で、かつ過小評価されやすい方法です。
設定値、少量の状態データ、定期処理の出力結果、外部連携用の中間ファイルなど、構造が比較的単純なデータであれば、ファイルだけで十分に成立することがあります。
ファイル保存の利点は、構成が単純で、人間が直接確認しやすく、バックアップや移行も比較的容易な点です。
アプリケーションと一緒に扱えるため、システム全体の理解コストも低く抑えられます。

ただし、ファイル保存といっても形式は一つではありません。
JSON、YAML、CSVはそれぞれ向いている用途が異なります。
ここを曖昧にすると、読みやすさや保守性が落ちます。

形式	向いている用途	注意点
JSON	構造化データ、API連携、機械処理	コメントを書きにくい
YAML	設定ファイル、人間が編集する定義	インデントミスに弱い
CSV	表形式データ、一覧出力、簡易集計	ネスト構造を表現しにくい

たとえば、アプリケーション設定のように人間が手で編集する可能性が高いものはYAMLが扱いやすいです。
一方で、プログラムから読み書きする状態データや、外部APIとの受け渡しに近い構造ならJSONのほうが安定します。
CSVはログの一覧化やエクスポート用途には便利ですが、複雑な関連を持つデータには向きません。

ファイル保存を採用する際に意識すべきなのは、保存形式そのものよりも、更新単位と破損時の扱いです。
単一ファイルにすべてを書き込む設計は簡単ですが、更新途中の失敗で内容が壊れると復旧しにくくなります。
そのため、設定と実行結果を分離する、追記型ログにする、書き込み後に置き換えるといった工夫が有効です。
ファイル保存は軽量ですが、軽量であることと雑に扱ってよいことは同義ではありません。

オブジェクトストレージでシンプルに永続化する方法

ファイル保存をローカル環境だけで完結させず、より運用しやすい形に広げたものがオブジェクトストレージの活用です。
クラウド環境では、少量から中規模のデータ保持において、オブジェクトストレージは非常に合理的な選択肢になります。
特に、画像、JSONファイル、レポート出力、バックアップ、処理結果のスナップショットのように、単位がファイルとして自然に切り出せるデータには相性が良いです。

オブジェクトストレージの強みは、保存基盤そのものの運用をほとんど意識せずに済む点です。
データベースのようにスキーマ管理や接続プールを考える必要がなく、ファイル単位で保存、取得、差し替えができます。
さらに、冗長化や耐久性、ライフサイクル管理といった機能をサービス側に任せやすいため、保守コストを抑えやすいです。

たとえば、日次バッチの出力結果を日付ごとのJSONとして保存する設計は、非常にわかりやすい構成です。
必要なときだけ読み込み、古いデータは自動削除ルールで整理できます。
検索性は高くありませんが、キー設計を工夫すれば、用途によっては十分です。
重要なのは、オブジェクトストレージをデータベースの代用品として無理に使うのではなく、ファイル単位で完結するデータの置き場として割り切ることです。

一方で、複数レコードを横断して条件検索したい場合や、頻繁な部分更新が必要な場合には不向きです。
オブジェクトストレージは、あくまでオブジェクト単位の保存に強いのであって、細粒度の更新や複雑な問い合わせには向いていません。
したがって、向いているのは「まとめて保存し、必要なときに取り出す」タイプのデータです。
この前提を守れば、非常にシンプルで堅実な永続化手段になります。

インメモリ保持と再生成可能データを活用する設計

データ保持を考えるとき、すべてを永続化しなければならないと思い込みがちですが、実際にはメモリ上だけで十分なデータも多くあります。
特に、キャッシュ、一時的な計算結果、セッション中だけ必要な状態、再実行で再取得できる外部データなどは、インメモリ保持のほうが自然です。
ここで重要なのは、消えて困るかどうかではなく、消えても再構築できるかどうかです。

再生成可能なデータを永続化しない設計には、明確な利点があります。
まず、保存責務が減るため、バックアップ対象が小さくなります。
次に、データの整合性を長期的に維持する必要がなくなります。
さらに、古い中間データが残り続けて、どれが正なのかわからなくなる問題も避けやすくなります。
つまり、再生成可能なものは保存しないという判断は、単なる省略ではなく、システムを単純化するための積極的な設計です。

たとえば、外部APIから取得したランキング情報を画面表示用に整形した結果は、元データが再取得できるなら、毎回生成してもよい場合があります。
あるいは、バッチ処理の途中で作る集計結果も、元入力が残っていれば再計算できます。
このようなデータまで永続化すると、保存先の管理だけでなく、更新タイミングや失効条件まで考える必要が出てきます。

ただし、インメモリ保持には前提があります。
プロセス再起動で消えてよいこと、複数インスタンス間で共有しなくてよいこと、消失時の再生成コストが許容範囲であることです。
この条件を満たさないなら、メモリだけに頼るのは危険です。
逆に言えば、この条件を満たすデータについては、無理に永続化しないほうが設計は健全になります。

データベースを使わずにデータを保持する方法は、単なる代替案ではありません。
ファイル保存、オブジェクトストレージ、インメモリ保持は、それぞれ異なる前提と強みを持つ独立した設計手段です。
大切なのは、どれが高機能かではなく、どれが要件に対して最も単純で、最も壊れにくいかを見極めることです。
その判断ができれば、データ保持はもっと軽く、もっと保守しやすいものになります。

設定ファイル・ログ・キャッシュを安全に扱う実践設計

データベースを使わずにシステムを構成する場合、設定ファイル、ログ、キャッシュの扱い方が設計品質を大きく左右します。
これらは一見すると周辺的な要素に見えますが、実際には運用の安定性、障害対応のしやすさ、保守コストの低さに直結します。
特に、データベースのような一元的な管理基盤を置かない設計では、それぞれの役割を明確に分離し、保存目的に応じて扱いを変えることが重要です。
ここが曖昧だと、設定が状態データ化したり、ログが業務データの代替になったり、キャッシュが事実上の本番データになったりします。
そうなると、シンプルにするためにデータベースを外したはずなのに、別の場所で複雑さが増殖します。

安全に扱うための基本原則は単純です。
設定は「システムの振る舞いを決めるもの」、ログは「起きた事実を記録するもの」、キャッシュは「再生成可能なものを一時的に保持するもの」と定義し、それぞれの責務を混ぜないことです。
この区別を最初に明文化しておくと、保存場所や更新方法の判断がかなり安定します。

設定値は環境変数とファイルのどちらで持つべきか

設定値の管理では、環境変数と設定ファイルのどちらを使うべきかがよく議論になります。
結論から言えば、どちらが優れているかではなく、設定の性質によって使い分けるべきです。
ここを一律に決めると、運用しやすさか可読性のどちらかを不必要に犠牲にします。

環境変数に向いているのは、実行環境ごとに差し替わる値です。
たとえば、APIキー、接続先URL、実行モード、本番と開発で異なるフラグなどは、コードや設定ファイルに埋め込まず、環境側で注入したほうが安全です。
特に機密情報は、リポジトリに含めないという観点からも、環境変数との相性が良いです。
一方で、項目数が多い設定や、階層構造を持つ設定、チームでレビューしながら管理したい設定は、ファイルのほうが適しています。
YAMLやJSONで明示的に構造化したほうが、変更差分も追いやすくなります。

判断基準を整理すると、次のようになります。

観点	環境変数に向く	設定ファイルに向く
機密性	高い	低い〜中程度
構造の複雑さ	単純	複雑
差し替え頻度	環境ごとに高い	比較的低い
可読性・レビュー性	低め	高い

実務では、どちらか一方に統一するより、責務で分けるほうが合理的です。
たとえば、機密情報と環境依存値は環境変数、アプリケーションの動作ルールや閾値は設定ファイル、という分離です。
この構成なら、セキュリティと可読性の両方を確保しやすくなります。
重要なのは、設定値を増やすたびに保存場所を場当たり的に決めないことです。
どの種類の設定をどこに置くかを先に決めておけば、運用はかなり安定します。

ログ管理をデータベースなしで成立させる基本原則

ログは、データベースなし構成において特に重要な情報源です。
なぜなら、障害調査、挙動確認、監査、利用状況の把握といった多くの場面で、ログが唯一の事実記録になるからです。
ただし、ログは便利だからといって何でも書けばよいわけではありません。
ログ管理を成立させるには、記録の目的、粒度、保存期間を明確にし、業務データと混同しないことが必要です。

まず押さえるべきなのは、ログは検索しやすい構造で出力するべきだという点です。
人間向けの文章だけをだらだら出すと、あとで機械的に集計しにくくなります。
最低限、時刻、レベル、イベント種別、対象IDのような軸は揃えておくべきです。
データベースを使わなくても、構造化ログをファイルや外部ストレージに保存すれば、必要なときに十分追跡できます。

また、ログは追記型で扱うのが基本です。
既存内容を書き換える設計にすると、事実の時系列が壊れやすくなります。
さらに、ログローテーションや保存期間の管理も欠かせません。
残しすぎれば容量を圧迫し、短すぎれば障害調査に必要な情報が消えます。
ここは「何日分必要か」を運用要件として決めるべきです。

ログ管理で避けるべき典型例は次の通りです。

• 業務上の正データをログだけに依存する
• エラー時だけ詳細を出し、通常時の文脈が追えない
• フォーマットが統一されておらず検索しにくい
• 個人情報や秘密情報を無造作に出力する
• 保存期間と削除方針が決まっていない

ログはあくまで記録であって、状態管理の本体ではありません。
この原則を守れば、データベースなしでも十分に運用可能です。
逆に、ログを後から業務データの代わりに使おうとすると、検索性も整合性も不足し、設計が破綻しやすくなります。

キャッシュを永続データと混同しないための設計ルール

キャッシュは性能改善に有効ですが、設計上もっとも誤用されやすい要素でもあります。
問題は、キャッシュが便利すぎるために、いつの間にか本来の永続データのように扱われ始めることです。
これは非常に危険です。
キャッシュは本質的に、消えても再生成できることを前提にした一時保存です。
この前提が崩れた瞬間、キャッシュは単なる高速化手段ではなく、障害点に変わります。

キャッシュを安全に扱うには、まず「キャッシュがなくてもシステムは正しく動く」状態を保つ必要があります。
キャッシュヒット時は速くなるが、ミスしても元データから再構築できる。
この関係が成立していれば、キャッシュの破損や消失は性能問題にとどまり、機能障害にはなりません。
逆に、キャッシュにしか存在しない状態を持ち始めると、再起動や失効でデータが消えたときに整合性が崩れます。

設計ルールとしては、少なくとも次の点を守るべきです。

• キャッシュは必ず再生成可能なデータに限定する
• 有効期限を明示し、無期限保持を避ける
• キャッシュ更新失敗時も本処理が成立するようにする
• キャッシュの内容を正データとして参照しない
• キャッシュ削除時の挙動を事前に確認する

このルールを守ると、キャッシュはあくまで補助的な層として機能します。
たとえば、外部APIのレスポンス整形結果や、重い計算の中間結果を一時保持するのは合理的です。
しかし、ユーザー設定や課金状態のような重要データをキャッシュに置くのは不適切です。
それは高速化ではなく、責務の誤配置です。

設定ファイル、ログ、キャッシュを安全に扱う設計では、それぞれの役割を厳密に分けることが何より重要です。
設定は振る舞いを定義し、ログは事実を記録し、キャッシュは再生成可能なものを一時保持する。
この境界が明確であれば、データベースを使わない構成でも十分に安定した運用が可能です。
逆に、この境界が曖昧だと、シンプルなはずの設計はすぐに不透明になります。
保守コストを抑えたいなら、保存手段の選択以上に、責務の分離を丁寧に設計することが重要です。

データベースなし構成で失敗しやすいポイントと対策

データベースを使わない構成は、要件に合っていれば非常に合理的です。
構成要素が少なく、理解しやすく、運用負荷も抑えやすいため、小規模システムや限定用途のアプリケーションでは有力な選択肢になります。
しかし、シンプルであることと、何も考えなくてよいことは別です。
むしろ、データベースが標準で提供してくれていた機能を外す以上、どの性質を自前で担保し、どの性質を要件上不要とみなすのかを明確にしなければなりません。
ここを曖昧にすると、最初は軽量だった構成が、運用の中で静かに破綻します。

特に失敗しやすいのは、同時更新と排他制御を軽く見積もること、そしてバックアップと復旧を「データ量が少ないから大丈夫」と雑に扱うことです。
どちらも、平常時には問題が見えにくい一方で、障害や利用増加の局面で一気に表面化します。
データベースなし構成を成立させるには、機能を減らす代わりに、失敗条件を先に定義しておく必要があります。

同時更新と排他制御を軽視すると何が起こるのか

データベースを使わない設計で最も見落とされやすいのが、同時更新の問題です。
単一ユーザー、単一プロセス、低頻度更新を前提にしている間は、ファイル保存や簡易ストレージでも大きな問題は起きません。
しかし、複数の処理が同じデータをほぼ同時に更新する可能性があるなら、話は変わります。
ここで排他制御を考慮していないと、更新の取りこぼし、内容の上書き、部分的な破損といった問題が発生します。

典型例は、設定ファイルや状態ファイルを複数の処理が読み書きするケースです。
処理Aと処理Bが同じ内容を読み込み、それぞれ別の変更を加えて保存すると、後から保存した側が前の変更を消してしまうことがあります。
これはロストアップデートの一種で、件数が少ないシステムでも普通に起こります。
しかも、ファイルベースの保存ではトランザクションのような保護がないため、問題が起きても原因を追いにくいです。

さらに厄介なのは、書き込み途中の失敗です。
ファイル全体を書き換える方式では、更新中にプロセスが落ちたり、ディスク書き込みが中断したりすると、中途半端な内容が残ることがあります。
データベースなら内部で吸収されるような問題が、そのままアプリケーションの障害になります。

同時更新のリスクがある場合は、少なくとも次の観点を確認すべきです。

• 同じデータを複数プロセスや複数ユーザーが更新する可能性があるか
• 更新は追記型か、全体置換型か
• 更新失敗時に前の状態へ戻せるか
• 一時的不整合を許容できるか
• 排他制御をアプリケーション側で実装する必要があるか

この確認をせずに「小規模だから大丈夫」と判断するのは危険です。
小規模であることは、競合が起きないことの証明にはなりません。
むしろ、利用者が少ないからこそ問題が再現しにくく、発見が遅れることがあります。
データベースなし構成を選ぶなら、同時更新が起こらない前提を明示するか、起こるなら最小限の排他制御を設計に含めるべきです。

バックアップと復旧手順を簡略化しすぎない重要性

データベースを使わない構成では、保存対象が少なく見えるため、バックアップと復旧も簡単だと思われがちです。
たしかに、ファイル数が少なく、構成も単純なら、理論上は扱いやすいです。
しかし、実際に重要なのは「バックアップが存在すること」ではなく、「壊れたときに確実に戻せること」です。
この違いを軽視すると、いざ障害が起きたときに、保存していたはずのデータが使えないという事態になります。

よくある失敗は、ファイルを定期的にコピーしているだけで安心してしまうことです。
コピー先が壊れていないか、必要なファイルが揃っているか、復元手順が現実的かを確認していなければ、それは運用ではなく願望です。
特に、設定ファイル、状態ファイル、ログ、アップロードデータが別々の場所に散らばっている場合、どこまで戻せば整合性が取れるのかを決めておかないと、復旧時に判断がぶれます。

バックアップ設計では、次の三点を最低限整理すべきです。

観点	確認すべき内容	軽視した場合の問題
対象範囲	何を保存対象にするか	必要なファイルが欠ける
頻度	どの間隔で退避するか	最新状態を戻せない
復旧手順	どう戻して検証するか	バックアップがあっても使えない

また、復旧手順は文章で書いて終わりでは不十分です。
実際に試してみて、どの順番で戻すのか、再起動後に何を確認するのか、依存する外部サービスとの整合はどう見るのかまで含めて検証する必要があります。
データベースがないから簡単、ではなく、データベースがないからこそ、復旧の責任範囲がアプリケーション設計側に寄るのです。

さらに、バックアップの考え方はデータの種類ごとに変えるべきです。
再生成可能なキャッシュまで厳密に退避する必要はありませんが、ユーザー設定や外部連携状態のような再現困難なデータは優先度が高いです。
すべてを同じ重さで扱うのではなく、失ったときの影響で優先順位をつけることが重要です。

データベースなし構成で失敗しやすいのは、仕組みが単純だからではなく、単純さに安心して前提条件の確認を省いてしまうからです。
同時更新が起きないこと、起きても壊れないこと、壊れても戻せること。
この三つを設計段階で言語化できていれば、データベースを使わない構成でも十分に安定した運用は可能です。
逆に、そこを曖昧にしたまま進めると、シンプルな構成は簡単に脆い構成へ変わります。
保守コストを下げるために複雑さを減らすなら、失敗時の振る舞いだけは、むしろ意識的に具体化しておくべきです。

データベースを使うべきケースと使わないべきケースの比較

データベースを使うべきかどうかは、思想や好みで決めるものではありません。
ここを「最近はシンプル構成が流行っているから」「とりあえずDBを入れておけば安心だから」といった感覚で判断すると、設計は簡単にぶれます。
重要なのは、システムが要求する性質を分解し、その性質を満たすために本当に必要な仕組みを選ぶことです。
つまり、判断基準は技術そのものではなく、要件です。

実務では、データベースを使わない構成が有効な場面も多い一方で、明らかにデータベースを使うべきケースも存在します。
この境界を曖昧にすると、軽量に済むはずのシステムに過剰な基盤を持ち込むか、逆に本来必要な整合性や検索性を欠いた危うい構成を作ることになります。
したがって、比較すべきなのは「DBあり」と「DBなし」の優劣ではなく、どの要件に対してどちらが自然かです。

検索要件とトランザクション要件が強いならDBが有利

データベースが本領を発揮するのは、複数条件での検索、集計、並び替え、関連データの参照、そして一貫性を保った更新が必要な場面です。
たとえば、ユーザー一覧を条件で絞り込みたい、注文と在庫を同時に更新したい、履歴データを期間別に集計したい、といった要件は、データベースが非常に得意とする領域です。
これらをファイルや単純なストレージで代替しようとすると、アプリケーション側に検索ロジックや整合性制御を大量に書くことになり、結果として複雑さが別の場所へ移るだけです。

特にトランザクション要件は重要です。
複数の更新が「全部成功するか、全部失敗するか」でなければ困る場面では、データベースの価値は非常に高いです。
たとえば、決済状態の更新と在庫引き当て、会員情報の変更と監査記録の保存などは、片方だけ成功すると不整合になります。
この種の要件を持つシステムで、単純なファイル保存やオブジェクトストレージだけで済ませるのは危険です。
実装できないわけではありませんが、整合性を自前で担保するコストが高く、保守性も落ちます。

また、検索要件が強い場合も同様です。
単純なキー参照だけならファイルやKVS的な保存でも成立しますが、複数条件の組み合わせ、部分一致、ソート、ページング、集計まで必要になると、データベースの恩恵は大きくなります。
検索のたびに全件読み込みをしてアプリケーション側で絞り込む設計は、データ量が増えるほど非効率になりますし、コードも複雑になります。

判断の目安としては、次のような要件があるなら、データベースを前向きに検討すべきです。

• 複数条件での検索や集計が日常的に必要
• 複数のデータを一貫して同時更新する必要がある
• 同時更新が多く、排他制御が重要
• データ同士の関連を保ちながら参照したい
• 将来的にも検索軸や更新パターンが増える見込みが高い

このようなケースでは、データベースを避けること自体が目的化すると逆効果です。
シンプルさを優先するあまり、必要な機能をアプリケーション側に押し込めば、見かけ上はDBなしでも、実質的には不完全なデータベースを自作しているのと変わりません。
それは保守コストを下げるどころか、むしろ増やします。

単純な状態管理ならファイルやストレージで十分な理由

一方で、すべてのデータ保持にデータベースが必要なわけではありません。
単純な状態管理であれば、ファイル保存やオブジェクトストレージのような軽量な手段で十分なことが多いです。
ここでいう単純な状態管理とは、件数が少なく、更新頻度も高くなく、複雑な検索も不要で、整合性要求も限定的なデータを指します。
たとえば、アプリケーション設定、最終実行時刻、外部連携のトークン情報、バッチ処理の進捗記録、生成済みファイルのメタ情報などです。

こうしたデータに対してデータベースを導入すると、得られる機能よりも、増える運用責務のほうが大きくなりやすいです。
接続設定、マイグレーション、バックアップ、監視、障害時の切り分けといった作業は、保存対象が数件しかなくても発生します。
つまり、データ量が少ないから運用も軽い、とは限りません。
むしろ、要件が単純なほど、データベースの高機能さを活かしきれず、固定費だけが残ります。

ファイルやストレージで十分な理由は、必要な操作が限定されているからです。
読み込む、上書きする、追記する、日付やキーで取り出す。
この程度で済むなら、わざわざクエリ機能やトランザクション機能を持つ基盤を導入する合理性は薄いです。
さらに、保存形式が人間に読めるものであれば、障害時の確認や手動修正もしやすくなります。
これは小規模運用では無視できない利点です。

比較すると、判断の違いは次のように整理できます。

観点	DBが向く	ファイルやストレージが向く
検索	複数条件・集計・関連参照が必要	単純な取得で足りる
更新	同時更新や一貫性が重要	単発更新が中心
データ量・構造	増加しやすく複雑	少量で単純
運用	高機能を活かせる	構成を軽く保ちたい

この表からわかる通り、判断の本質は「将来増えるかもしれないからDB」ではなく、「今必要な性質に対して最小の手段は何か」です。
もちろん、将来の拡張性を無視してよいわけではありません。
ただし、存在しない要件のために現在の保守性を犠牲にするのは合理的ではありません。
まずは単純な状態管理として成立するかを見極め、検索性や整合性の要求が明確になった時点でデータベース導入を再評価するほうが、設計として健全です。

結局のところ、データベースを使うべきかどうかは、技術選定の問題である以前に、要件定義の問題です。
検索要件とトランザクション要件が強いなら、データベースは非常に有力です。
逆に、単純な状態管理で済むなら、ファイルやストレージのほうが保守しやすい場合があります。
大切なのは、どちらかを信仰することではなく、必要な性質に対して過不足のない構成を選ぶことです。
その判断ができれば、システムは無駄に重くも、危うくもなりません。

クラウド時代に実践しやすいミニマルなデータ保持アーキテクチャ

クラウド環境では、データ保持の設計を必要以上に重くしない選択が以前より取りやすくなっています。
オンプレミス中心の時代は、永続化といえばまずデータベースサーバーを立てる発想になりがちでしたが、現在はオブジェクトストレージ、サーバーレス実行環境、マネージドなログ基盤など、用途ごとに責務を分けやすい部品が揃っています。
そのため、すべての状態を一つのデータベースに集約するよりも、必要なデータだけを必要な場所に置くミニマルな構成のほうが合理的な場面が増えています。

ここでいうミニマルなデータ保持アーキテクチャとは、単に構成要素を減らすことではありません。
重要なのは、各コンポーネントに過剰な責務を持たせず、保存対象の性質に応じて最小限の仕組みを割り当てることです。
たとえば、ユーザーがアップロードしたファイルはオブジェクトストレージ、実行時の一時データはメモリ、監査や障害調査に必要な記録はログ基盤、設定値は環境変数や設定ファイルというように分離します。
この設計は、データベースを否定するものではなく、データベースが本当に必要な領域だけに限定して使うための考え方です。

サーバーレスとオブジェクトストレージの相性が良い理由

クラウド時代のミニマル構成を考えるうえで、サーバーレスとオブジェクトストレージの組み合わせは非常に相性が良いです。
理由は単純で、両者とも「状態をできるだけ持たない」設計思想と噛み合っているからです。
サーバーレス実行環境は、短時間の処理を必要なときだけ起動し、処理が終われば実行環境を破棄する前提で設計されています。
このため、長期的な状態をローカルディスクやプロセス内に持つのには向いていません。
一方、オブジェクトストレージは、ファイル単位で永続化したいデータを外部に切り出すのに適しています。

この組み合わせが有効なのは、処理と保存の責務が明確に分かれるからです。
たとえば、画像変換、レポート生成、外部APIの取得結果保存、日次バッチの出力といった処理では、サーバーレス関数が計算を担当し、結果をオブジェクトストレージへ保存するだけで十分なことがあります。
この構成なら、アプリケーション側は状態管理の責任を最小限に抑えられます。
さらに、保存先がファイル単位で独立しているため、障害時の切り分けもしやすくなります。

サーバーレスとオブジェクトストレージの組み合わせが向いている条件は、概ね次の通りです。

• 保存対象がファイルやJSON単位で自然に分割できる
• 複雑な検索や結合処理が不要
• 更新よりも生成と取得が中心
• 同時更新の競合が少ない
• 処理の実行時間が短く、イベント駆動に向いている

この条件に当てはまるなら、わざわざ常駐サーバーとデータベースを持つより、はるかに軽量な構成で成立します。
しかも、スケーリングや冗長化の多くをクラウド側に任せられるため、運用負荷も下げやすいです。
もちろん、検索要件やトランザクション要件が強い場合は別ですが、単純なデータ保持であれば、この組み合わせは非常に実践的です。

運用監視を最小化するための責務分離の考え方

ミニマルなアーキテクチャの価値は、初期構築が楽になることだけではありません。
むしろ本質は、運用監視の対象を減らし、障害時の確認ポイントを限定できることにあります。
そのためには、各コンポーネントの責務を曖昧にせず、何をどこで担保するのかを明確に分ける必要があります。
責務分離が甘いと、構成要素が少なくても、どこで問題が起きているのか判断しにくくなります。

たとえば、あるコンポーネントが設定保持、キャッシュ、ログ出力、業務データ保存をすべて兼ねているとします。
この構成は一見シンプルですが、実際には障害時の切り分けが難しくなります。
設定の誤りなのか、キャッシュの不整合なのか、保存データの欠損なのか、ログ出力の失敗なのかが混ざるからです。
逆に、設定は環境変数または設定ファイル、ログは専用の出力先、永続データはオブジェクトストレージ、再生成可能な一時データはメモリ、と分けておけば、問題の所在をかなり絞り込めます。

責務分離を考える際は、少なくとも次の観点を分けて設計すると安定します。

役割	主な保存先	設計上のポイント
設定	環境変数、設定ファイル	環境差分と機密情報を分離する
永続データ	オブジェクトストレージなど	再現困難なものだけを保存する
一時データ	メモリ、短期キャッシュ	消えても再生成できる前提にする
記録	ログ基盤、追記ファイル	事実記録として構造化する

このように責務を分けると、監視項目も整理しやすくなります。
たとえば、設定はデプロイ時に検証し、永続データは保存成功率と取得失敗率を見て、一時データは性能指標として扱い、ログは欠損や異常増加を監視する、といった具合です。
すべてを一つの仕組みで見ようとしないことが、結果として監視の単純化につながります。

また、責務分離は将来の変更にも強くなります。
たとえば、一時データの扱いだけを変えたい場合、永続データの保存方式まで巻き込まずに済みます。
逆に、責務が混ざっていると、小さな変更でも全体に影響が波及しやすくなります。
保守コストを下げるという観点では、この差は非常に大きいです。

クラウド時代にミニマルなデータ保持アーキテクチャを実践しやすいのは、必要な責務を小さな部品に分けて配置できるからです。
サーバーレスとオブジェクトストレージの組み合わせは、その代表例です。
そして、その価値を最大化するには、単にサービスを減らすのではなく、設定、永続化、一時保持、記録という役割を明確に分離することが欠かせません。
シンプルな構成を本当に保守しやすいものにするには、少ない部品で多くを抱え込むのではなく、少ない責務で部品を使うという発想が重要です。

保守コストをゼロに近づけるための設計原則と実践チェックリスト

保守コストを下げたいと考えたとき、多くの現場では監視を自動化する、運用手順を整備する、障害対応を標準化するといった方向に意識が向きます。
もちろんそれらは重要です。
しかし、もっと根本的に効くのは、そもそも保守対象を増やさない設計です。
運用を頑張って複雑さを制御するより、最初から複雑さを持ち込まないほうが、長期的にははるかに安定します。
保守コストをゼロに近づけるという表現は少し挑発的ですが、実際に目指すべきなのは、日常的な手当てがほとんど不要な構成です。
そのためには、機能を足す前に、保存対象、責務、依存関係を削る視点が欠かせません。

特にデータ保持の設計では、「保存できるから保存する」という発想が保守コストを増やす最大の原因になりやすいです。
保存対象が増えれば、形式の互換性、バックアップ、移行、削除方針、整合性確認といった責務が連鎖的に増えます。
したがって、保守コストを抑える設計原則は、保存方式の選定以前に、保存そのものを必要最小限に絞ることから始まります。

保存する前に削れるデータを見極める発想

システム設計では、何を保存するかを考える前に、何を保存しなくてよいかを考えるべきです。
この順序は非常に重要です。
なぜなら、保存対象として一度採用したデータは、その後ずっと管理責務を持ち続けるからです。
逆に、最初から保存しないと決めたデータには、バックアップも移行も整合性管理も不要です。
つまり、もっとも安い保守は、そもそも持たないことです。

ここで有効なのが、データを「再現不能なもの」と「再生成可能なもの」に分ける考え方です。
ユーザーが入力した設定値、外部から再取得できない状態、監査上必要な記録は保存対象として妥当です。
一方で、計算結果の中間データ、表示用に整形した派生データ、一時的なキャッシュ、再実行で得られるAPIレスポンスは、保存しなくても成立する場合があります。
こうしたデータまで永続化すると、保存先の管理だけでなく、更新タイミングや失効条件まで設計しなければならなくなります。

保存前に削れるかどうかを判断するには、次の問いが有効です。

• そのデータは消えたら本当に困るか
• 元データから再生成できないか
• 保存しない場合に失うのは性能か、機能か
• 保持期間に明確な要件があるか
• 将来使うかもしれない、という曖昧な理由だけで残していないか

この問いに正面から答えると、保存対象はかなり減ります。
特に「あとで分析に使うかもしれない」「念のため残しておく」といった理由で増えたデータは、保守コストの温床になりやすいです。
必要性が曖昧なデータは、価値よりも管理負担のほうが先に大きくなります。
設計として健全なのは、必要になった時点で追加できる余地を残しつつ、現時点では持たない判断をすることです。

シンプルな構成を維持するための設計レビュー観点

シンプルな構成は、一度作れば自動的に維持されるものではありません。
機能追加、障害対応、将来拡張への備えといった名目で、少しずつ例外が積み重なり、気づけば当初の設計思想が失われていることは珍しくありません。
したがって、シンプルさは初期設計の成果というより、継続的に守るべき制約です。
そのためには、レビュー時に「動くかどうか」だけでなく、「複雑さを増やしていないか」を確認する観点が必要です。

設計レビューで見るべきなのは、新しい保存先や依存先が本当に必要か、責務が混ざっていないか、復旧手順が増えていないか、といった点です。
たとえば、ある機能追加のために新しいデータストアを導入する提案があったとします。
このとき確認すべきなのは、その保存先がないと成立しない要件があるか、既存の保存方式で代替できないか、導入後に増える運用責務は何か、ということです。
単に実装しやすいからという理由で保存先を増やすと、長期的には保守負荷が確実に上がります。

レビュー観点を整理すると、次のようになります。

観点	確認する内容	問題がある場合の兆候
保存対象	本当に永続化が必要か	派生データや一時データまで残している
責務分離	設定、ログ、状態、キャッシュが混ざっていないか	一つの保存先が複数の役割を持つ
依存関係	新しい外部サービスや基盤は必要最小限か	小機能のために大きな基盤が増える
復旧性	壊れたときの戻し方が明確か	バックアップや復旧手順が曖昧
拡張前提	実在しない将来要件を先取りしていないか	まだ不要な抽象化や汎用化が多い

この種のレビューでは、機能追加を止めることが目的ではありません。
目的は、追加される複雑さが要件に見合っているかを検証することです。
シンプルな構成を維持するには、便利そうな仕組みを足す判断よりも、足さない判断のほうが重要になる場面が多いです。
特に小規模システムでは、将来の拡張性を理由に現在の単純さを壊すと、そのコストを回収できないまま終わることがよくあります。

保守コストをゼロに近づける設計とは、魔法のように運用が不要になる設計ではありません。
実際には、保存対象を減らし、責務を分け、依存関係を絞り、復旧可能性を明確にすることで、日常的な手当てがほとんど要らない状態を作ることです。
そのためには、保存する前に削れるデータを見極めること、そしてシンプルさを継続的にレビューすることが欠かせません。
複雑さは一度増えると戻しにくいからこそ、設計段階で抑える姿勢そのものが、最大の保守コスト削減策になります。

データベース要らない派が実践するシンプル設計の結論

ここまで見てきた通り、データベースを使わない設計は、単なる逆張りでも、技術的なこだわりでもありません。
要件に対して必要十分な構成を選び、保守コストを増やす要素を意識的に減らしていく、きわめて実務的な判断です。
システム設計では、機能を実現することそのものに意識が向きやすいですが、長く運用される仕組みほど、重要なのは作れるかどうかではなく、壊れにくいか、直しやすいか、理解しやすいかです。
データベース要らない派の設計思想は、まさにこの観点に立っています。

誤解されやすい点ですが、ここで言う「データベース要らない」とは、あらゆる場面でデータベースを否定することではありません。
検索要件が強い、複数条件での集計が必要、トランザクション整合性が重要、同時更新が多いといった場面では、データベースは非常に合理的です。
むしろ、そのような要件があるのに無理に避けるほうが不自然です。
問題なのは、そこまでの要件がないにもかかわらず、慣習的にデータベースを前提にしてしまうことです。
その結果、本来は単純に済んだはずのシステムが、接続管理、スキーマ変更、バックアップ検証、監視、障害切り分けといった運用責務を抱え込みます。

シンプル設計の結論は明快です。
まず考えるべきなのは、どの技術を使うかではなく、何を保存する必要があるのかです。
さらに言えば、何を保存しなくてよいのかを先に見極めることが重要です。
再生成可能なデータ、一時的な中間結果、キャッシュ、外部から再取得できる情報まで無差別に永続化すると、保存対象が増えるだけでなく、整合性管理や削除方針まで必要になります。
保存できるから保存するのではなく、失うと困るものだけを残す。
この発想が、保守コストを下げる出発点です。

そのうえで、保存方式は要件に応じて最小のものを選ぶべきです。
設定値なら環境変数や設定ファイル、少量の状態管理ならJSONやYAML、ファイル単位で扱いやすい成果物ならオブジェクトストレージ、再生成可能な一時データならインメモリ保持で十分なことがあります。
ここで大切なのは、高機能な基盤を先に置いてから使い道を探すのではなく、必要な性質に対して最小限の仕組みを割り当てることです。
設計の健全さは、使っている技術の数ではなく、要件との対応関係の明確さで決まります。

また、データベースを使わない構成では、責務分離が特に重要です。
設定、ログ、キャッシュ、永続データを混同すると、見かけ上はシンプルでも、実際には非常に壊れやすい構成になります。
設定は振る舞いを決めるもの、ログは事実を記録するもの、キャッシュは再生成可能なものを一時保持するもの、永続データは再現困難な状態を残すもの。
この区別を明確にしておけば、保存先の選定も、障害時の切り分けも、かなり整理しやすくなります。
逆に、この境界が曖昧だと、どこが正データなのか分からなくなり、保守コストは急激に上がります。

さらに、シンプル設計を成立させるには、失敗時の振る舞いを先に考える必要があります。
データベースが提供してくれていた排他制御や復旧支援を外す以上、同時更新が起きない前提なのか、起きるならどう防ぐのか、壊れたときにどこまで戻せるのかを明文化しなければなりません。
小規模システムだから安全なのではなく、小規模システムでも前提条件を明確にしているから安全なのです。
単純な構成は、雑な構成とは違います。
むしろ、単純であるほど、前提の定義は厳密であるべきです。

実践上の判断基準をまとめるなら、次のようになります。

• 保存対象は、再現困難で失うと困るものに限定する
• 再生成可能なデータは、原則として永続化しない
• 検索性、更新頻度、整合性の要求から保存方式を決める
• 設定、ログ、キャッシュ、状態データの責務を混ぜない
• 同時更新と復旧手順を、規模に関係なく設計に含める
• 将来の曖昧な拡張可能性より、現在の保守性を優先する

この考え方を貫くと、システムは自然と軽くなります。
構成要素が減ることで、監視対象も減り、障害点も減り、変更時に影響を受ける範囲も狭くなります。
結果として、保守コストは下がります。
ここで重要なのは、保守コストを下げるために特別な最適化をするのではなく、不要な複雑さを最初から持ち込まないことです。
保守を楽にする最善策は、保守対象を増やさないことに尽きます。

結局のところ、データベース要らない派が実践しているのは、派手な技術選定ではありません。
要件を分解し、保存の必要性を疑い、責務を分け、最小構成で成立させるという、地味ですが強い設計です。
システム設計において本当に価値があるのは、多機能な構成を作ることではなく、必要な機能を過不足なく、長く扱える形で実装することです。
データベースを使うかどうかは、そのための手段にすぎません。
だからこそ、最終的な結論はシンプルです。
データを保存する前に、その保存が本当に必要かを疑うこと。
必要なら最小の方法で持つこと。
そして、持たなくて済むものは持たないこと。
この判断を積み重ねた先に、保守コストを限りなく小さくしたシステム設計があります。