プランAのデータベースエンジンは、SQLite を使っていました。
SQLiteは本体プログラムに対して、直接リンクしたライブラリもしくは共有ライブラリやダイナミックリンクライブラリの形で利用できる、組み込み型データベースエンジンである。その特徴として、おおむね600kb前後のフットプリントでフルセットのSQLステートメントと型束縛のないデータセットを利用することができる。データベースストレージに対するアクセスも内蔵しており、ファイル及びインメモリストレージに対応している。ファイルを共有することで複数のアプリケーションがデータベースインスタンスを共有することも可能であり、サーバ・クライアントモデルではないアプリケーションローカルで使用するデータベースエンジンとしては非常に合理的な設計となっている。（中略）
組み込み型であること、ストレージまでネイティブコードで直接実行し、間になんらかのプロトコルやプロセス間通信がないため、その動作は非常に高速である。一度トランザクションを開始するとストレージはロックされ、トランザクション中のセッションは最大限設定値で許されたキャッシュを有効利用して動作するため、SQLという複雑高度なステートメントを使用していることをユーザーに意識させない程高速にデータベースにアクセスすることができる。これは応答性が重要なアプリケーションでは重要な要素となり、SQLiteをサーバとの中間にキャッシュとして採用する事例や、アプリケーション組み込みデータベースエンジンとしての採用を促す理由ともなっている。
どうりでデータファイルだけがあって、DBサーバーの実行プログラムがないわけです。
SQLiteの名前は知っていて、以上のような特徴も目にしたことはあったのですが、PostgreSQLからDBに入門して今は MySQLを使っている身としては、「簡易データベース」的な印象がして「ふーん」って感じで使ってみようとは思いませんでしたね。
SQLiteを使うべき10の理由と5つのデメリット - CPA-LABテクニカル
１．データがファイルひとつなので、バックアップが超簡単！
SQLiteは、サーバー型でないため、データはたったひとつのファイルにまとめられている。バックアップするには、それをFTPでダウンロードするか、そのサーバー上でコピーするだけだ。MySQLでも、ツールを使えばバックアップはできるけど、ファイルのコピーだけで完結する簡潔さには、かなううまい。なお、ファイル名もなんでもよく拡張子もあってもなくてもいい。でも、バージョン２は.sqliteバージョン３は.sqlite3としている人が多いのかな。USBにデータファイルをコピーして、外出先のローカルサーバーで、すぐにSQLiteを使うなんて、当たり前にできる。MySQLでやろうとしたら気が遠くなる。-----DBのテーブル構成を変えたい？そう、なら、サーバーからダウンロードして、デスクトップのツールで変更して、ついでに入らなくなったデータ消去して、新たな更新データもいれておいて、アップロードすれば終わり。ローカルとリモートの同期が超簡単なのもDBがファイルだから。（中略）
５．納入が容易。
私は関係ないが商売として、簡易的なデータベースシステムを使ってWEBシステムを構築しているのであれば、納入の容易さは、大きな利点となるだろう。なんせ、HTMLと同じコピペで納入できるのだから。ライセンスも心配ない。
６．PHP5では、SQLite3が標準で使える。PHP4でもSQLite2が標準で使える。
何もしなくても、いきなりプログラムを書けば自動的にデータベースファイルが作成される。標準バンドルはとてもありがたい。
プランAでは、共有サーバー上のフォルダにデータベースファイルを置いて、ユーザーPCのExcelからODBCで掴みにいく構成になっているようです。 ODBCといっても、実際には直結みたいなものだから、かなり高速です。
とはいえ、いいことばかりではないようで。
１．パスワード設定がない
ファイル形式であり、ユーザー管理の概念がないため、SQLite自身には、セキュリティ機能はない。自分で、ファイルへのアクセス権限をしっかりとコントロールする必要がある。サーバーのドキュメントルート以下に置く場合は、htaccessの設定が必須だろう。ドキュメントルートより上に置けば、外部の第三者からのセキュリティに問題があることはほとんどないだろう。
２．書込がダブると書込エラーになる
サーバー型でないので、複数の書込を順次処理することができない。最初の人が書込をしている間に、次の人が書込をしようとするとエラーになるので、そのケアーをする必要があるシステムもあるかもしれない。個人やSOHOのCMS（コンテンツマネジメントシステム）やブログ程度であれば、問題にあることはないだろう。読み出しはダブってもOK。頻繁に不特定多数がデータベースに書き込むような処理は苦手だろう。（中略）
４．管理ツールでは、phpMyadminに劣るものしかない。
別記事で私の使っているツールをあげておきます。phpMyadminには及ばないが、しかし十分である。
元々プランAは、既存のExcelの式やマクロを連携させて使っていたシステムを、データベース化するという目的で始めたものです。 だからフロントエンドは Excel のままなんですが、SQLite を使うことでバックエンドにDBが動いていることを意識させないような造りになっています。 ですから SQLite を採用したのは最善解だと思います。
一方、プランBは既存の（一部の）システムの代替だけでなく、統合システムのあるべき姿として全ての業務をDB上に載せることを目指しています。 同時アクセス数としては30人程度ですが、書き込みタイミングが重複する可能性もかなりあります。
そういう使い方だと SQLite ではどうなのかなと不安が残ります。
自宅サーバーでMTなどblogを立てるのだったら、MySQLよりも SQLite の方が良さそうに思います。
ただ、MySQLは情報が豊富だし、phpMyadmin はなかなか使いやすいです。 プランAのデータベース構造を確認するために SQLiteManager を使ってみましたが、慣れてないことを差し引いてもあまり使いやすいものではないように思いました。
で、プランAでいくのかBでいくのかですが、方向性は出ましたがまだ決定はしていません。 どちらか一方が生き残るということにはならないだろうと思います。
PHPとSQLite はとても相性がいい、というのがヒントかな？