Database)のどちらが使い勝手良いのか、ということ。そもそもどちらかを選ばなきゃいけないというわけではなく、適宜両方使えばいいということが分かったのでそれについての雑記。そもそもまず、なぜ悩むところがあったのか。Firebaseのデータベースのデメリット一番大きいのはやはりリレーショナルでないことと、クエリが弱いということ。集計ができなかったり、欲しいデータがすぐ取れなかったりする。RDBのデメリットとりあえずRDBにしておけば何でもできるというのはあるが、デメリットとしてはやはりサーバーもしくはお金が必要になってくるということ。SQLを使うと当然お金がかかる。Heroku等のPostgresやJawsを使う手もあるが、あまりにも容量が少なすぎる。Firebaseへの期待が高まりすぎるRDBはメリットが高いが、やはりサーバーが不要というFirebaseのデータベースのメリットも同様に非常に高い。そのため、いつかバージョンアップした際にクエリが強くなるのではないか、もっとデータが取りやすくなるのではないか、みたいな期待が高まりすぎてしまった。Datastoreを流用していると思うので、あまり期待しすぎても仕方なく、ひとまず現在は現状のままどうやって使っていくかを考える必要がある。Firebaseのデータベースを使うとなると、それでうまく作り方を考える必要が出てくる。(これはこれで面白いのだが)どちらかに限定する必要はないそこで気づいたのが、そもそも元々RDBを使っているアプリケーションであっても、Firebaseのデータベースを併用して使えばもっと便利になるのでは、ということ。このCrieitの例だが、先日リアルタイムで下書きをライブ公開できる機能を作成した。Engineの永久無料枠で使えるf1-microというインスタンスで動いているのだが、とにかくメモリの使用量も小さく貧弱。Laravelは一応Pusher等と連携してWebSocketを使える機能があるのでLaravel自体でもライブ公開機能は実現可能なのだが、結局状態変化があった時にデータを取得などしようとするとLaravel自体にアクセスが行ってしまう。あまりに頻度が多いと、現在のサーバーのスペックでは厳しくなる可能性がある。これは同時接続数などの制限があるものの、書き込み、読み込み等の回数には特に制限がない。制限内でライブ公開する機能を付けるのであれば、サーバーの負荷ゼロでライブ公開機能が実現できてしまう。Databaseに保存し、閲覧者側はそれを受け取るだけになっており、完全にサーバー負荷も費用的な負荷もなくライブ公開の機能が作れてしまった。無料で運営している個人開発サービスとしてはこのやり方はとても相性が良い。流行りすぎて人が増えるとそうはいかなくなるが、とりあえず今の段階では全く心配はない。遊び道具が一つ増えて楽しみが増えた。逆で、Firebaseだけで運用しているサービスにRDBの利用を追加する、ということも考えられる。SQLでは費用が増えてしまうが、とりあえずHerokuのPostgres等でも良いかもしれない。Functions経由で簡単に集計データなどが取れたりするのではないかと思う。まとめとにかく柔軟に考えて、併用することでパフォーマンス的にも費用的にもベストな形になるような状態を目指していくと面白い。