原著者の許諾を得て翻訳・公開いたします。

• 英語記事:Supercharge the One Person Framework with SQLite | Fractaled Mind

• 原文公開日: 2024/10/16

• 原著者:Stephen Margheim

日本語タイトルは内容に即したものにしました。
また、見出しを適宜加えています。

本記事は、Rails World 2024における私の発表を編集して記事化したものです。以下のYouTube動画でもご覧いただけます。

はじめに

Railsは誕生したときから、アイデアを超音速で宇宙空間に打ち上げるロケットエンジンのような存在として名を馳せてきました。しかし少なくとも私にとって、自作のフル機能アプリケーションをデプロイして動かすにはロケット科学者になる必要がある気もしていました。

ロケットエンジンは時とともに大型化し、複雑化してきました。

同様に、Webアプリケーションの「標準アーキテクチャ」も近年になるほど複雑になってきています。

複雑になるWebアーキテクチャ標準

ここで、2008年のHerokuアプリケーションの典型的なアーキテクチャを振り返ってみましょう。
HTTPリクエストに応答するためのWeb dynoがいくつか、データを永続化するデータベース、ジョブキューを処理するワーカー用dynoなどがありました。たしかに分散システムですが、十分掌握できる規模でした。

さて、今度は現在の標準的なHerokuアプリケーションを見てみましょう。サーバー数もサービス数も基本的に3倍増しになっていますね。

きっと皆さんも、ほとんどとまでいかなくても多くの方が、今の世の中でproductionでの運用に耐えるシステムを実行するには、このぐらいのコストがかかるのはもう仕方のないことだろうと考えているに違いありません。複雑さとは進歩のための代償だなのだと思い込んでしまいがちです。

しかしそうとは限りません。時にはシンプルになるという進歩もあるのです。可動部品を減らし、システムのサーフェス（表面積）を減らしつつ、パワーや機能を拡大するという進歩だってあるのです。

私はStephen Margheimと申します。Twitterの@fractaledmindというアカウントでご存知の方もいらっしゃるかもしれません。

本日は、Rails 8とSQLiteが組み合わさることで、「個人が扱えるフレームワーク」が驚くほど強化されることについてお話ししたいと思います。

「この」パワーを余すことなく備えたアプリケーションを構築するというビジョンを皆さんに提示したいと思います。

しかも、驚くほどシンプルでスリムなのです。

Rails 8で何が変わったか

以下の恐ろしくシンプルなアーキテクチャをご覧ください。これ👇️は、実際に動くアプリケーションアーキテクチャであり、何万人もの、あるいはもっと多くのユーザーにサービスを提供できます。

ロケットで液体メタンと液体酸素が使われているように、SQLiteとRailsが手を組めば強力なコンビとなります。

これが可能になったのは、Railsの「概念圧縮」、つまり実際に稼働しているproductionアプリケーションから得たソリューションが、20年にもわたるバトルテストを重ねてきたことでこれまでにないほど概念が凝縮されていることと、SQLiteの「運用圧縮」、すなわち単一ファイルデータベースと埋め込み型の実行可能ファイルによって、他に類を見ないほど運用が圧縮されているおかげです。

RailsとSQLiteが手を取り合うことで、信じられないほどスリムでシンプルなアプリケーションに爆発的な推進力が凝縮されます。今からそれをお見せしましょう。

Rails 8のコンポーネントを支えるSQLite

最初に、Rails 8のrails newコマンドで生成されるアプリが、どのような形でproductionレベルに達しているかを理解する必要があります。

Railsはこれまでも、さまざまなコンポーネントがひととおり同梱されている「電池付属の（=すぐに動かせる）」フレームワークであり続けてきました。

多くのアプリでは、何らかの形でデータを永続化する必要があります。

以下の5つは、データと結びつくRailsコンポーネントです。フル機能のアプリケーションでは、これらをサポートする何らかのデータストアが必要になります。

もちろん、さまざまなデータストアに接続するためのアダプタもコンポーネントごとにいろいろ揃っています。

Rails 7の時代の`rails new`を実行すると、production向けのデフォルト設定がデータストアごとに行われます。それはよいのですが、`rails new`した直後のアプリケーションは、productionにそのままデプロイできるセットアップにはなっていませんでした。

Rails 7のジョブ用非同期アダプタは、ローカル開発環境では高速かつシンプルなのですが、そのままproductionで動かすと、アプリをデプロイまたは再起動したときに保留中のジョブが失われてしまいます。

Rails 7のキャッシュ用ファイルストアは、ファイルシステムを制御するには十分ですが、Herokuなどの多くのプラットフォームサービスでは一時的なファイルシステムしか提供されていません。また、キャッシュの内容が不定期に完全消去されるのであまり役に立ちません。

Rails 7のAction Cableで使えるRedisアダプタはproductionレベルに耐えるソフトウェアであることは確かですが、別途Redisインスタンスを設定・実行してアプリケーションに接続する必要があります。つまり、production環境対応ではありますが、プラグアンドプレイではありませんでした。

Rails 8では、production環境対応とプラグアンドプレイを両立させて、生成したアプリを直ちに実用に供するというエクスペリエンスを達成するため、大きな変更が行われました。

Rails 8でrails newを実行したときに生成されるデフォルトのセットアップは、従来のものから大幅に変わりました。
「Solid Cache」「Solid Queue」「Solid Cable」というSolid三兄弟gemによって、Railsの中核を占めるデータ用コンポーネントが最初からproduction環境に対応し、柔軟かつスケーラブルになります。

3つの新しいgemは、Active Job、Active Supportキャッシュ、Action Cableにおいて、背後でデータベースを使っていながら、特定のデータベースに依存しないアダプタを提供します。

Solid Queueがproductionグレードのソフトウェアである理由については、Rosaによる講演で概説されています。

そして昨年のRails Worldでは、DonalによってSolid Cacheが紹介され、production環境志向の練り上げられた設計について詳しく説明されています。

最後に、Nick Pezzaによって行われた素晴らしい仕事がSolid Cableの立ち上げです。

その他の新機能

しかし、Rails 8でproduction環境に対応しているのは、Railsコンポーネントのこうした新しいデフォルトだけではありません。

Rails 8には、production環境へのデプロイ用に、すぐに利用可能な新しく強化されたソリューションも付属しています。それが…

Kamalです。
Kamalは、Web アプリをDockerでproduction環境にデプロイ・管理するために必要なすべての機能を提供します。

Kamalの新しいバージョン2.0について詳しくは、DonalによるRails Worldトークをご覧ください。

また、Kevinによって新しいKamal ProxyもRails 8に導入されました。

皆さんも、Railsアプリケーションの未来的なデプロイ方法と実行方法を学んでおきましょう。

まとめると、Rails 8では、`rails new`コマンドによる「hello, world」アプリ作成から、アプリケーションをproduction環境にデプロイする「hello, web」に必要なツールまで、ひととおり提供されています。

これこそが、Rails を「個人のためのフレームワーク」にする機能と、その具体的な詳細です。

DHHが昨年の基調講演で述べたように、Railsは、複雑さを克服することによって、最小限のチーム編成（つまりあなたとノートPCひとつだけ）でも価値を生み出せるリッチで完全なWebアプリケーションを構築可能にする橋渡しとなることを目指しています。そして、SQLiteはそのビジョンに完全に一致しています。

SQLiteによって何が変わったか

私がお伝えしたいのは、「SQLiteはRailsのパワーを倍増する」ということです。

Rails 8でSQLiteを使うことで、分散を最小限に抑えたシステムにおける従来のやや複雑なアプリケーション作成から、徹底的にシンプルなアプリケーション作成へと変われるようになり、あらゆる依存関係の操作を1台のマシン上で実行できるようになります。

これが可能になったのは、SQLite独自のアーキテクチャのおかげです。

SQLite独自のアーキテクチャ

他のほとんどのSQLエンジンは、アプリケーションと別のプロセスで実行されるのが普通で、別のマシン上で実行されることも珍しくありません。

SQLiteは、Rubyスレッドとそれを生成するプロセス内に埋め込まれる形で実行されます。

つまり、SQLiteは皆さんが普段慣れ親しんでいるデータベースと考え方が異なっているのです。

SQLiteのデータはディスク上の単なるファイルであり、実行可能ファイルはアプリケーションプロセスに埋め込まれます。それでいて、「CTE」「ウィンドウ関数」「集計」機能なども備えたフル機能のSQLエンジンです。

SQLiteは「安定した」ソフトウェアです。SQLiteの現在のメジャー バージョンであるバージョン3は、20年前の2004年に初めてリリースされました。

しかも現在では、世界中で推定1兆個のSQLiteデータベースが活発に動いており、SQLiteは世界で最も広く使われているデータベースとなっています。

ところで、SQLiteがデータを1個のファイルに保存する埋め込み型データベースであることから、PostgreSQLやMySQLなどが処理できるデータ量のほんの一部しか処理できない非力なデータベースだろうと推測されるのもわかります。

しかし、それは完全に間違いです。SQLiteは最大281テラバイトのデータベースファイルを扱えるのです。言い換えれば、計算の限界に達することはありません。本当です。

SQLiteが発揮するパワーやシンプルさと、最新のハードウェアの組み合わせをご想像いただければ、Railsの「個人が扱えるフレームワーク」というビジョンがSQLiteによって強化され、アプリケーションの運用におけるニーズが著しくシンプルになることを納得いただけるかと思います。

SQLiteへの誤解を正す

しかしこういう話をすると、いつもこう言われるんです。「でもね...」

「SQLiteをWebアプリケーションでちゃんと動かすのは簡単じゃないよ」と。

実際、ここ数年のRailsは、SQLiteをproduction環境で実行したときに以下の警告をログに出力していました。

私が最後にRails Guidesを読んだときは、SQLiteをproductionで使うことについて警告文が掲載されていました。しかし、そんな時代はとっくに過ぎ去りました。

「SQLiteはWebアプリには不向き」というお気持ちは、今や神話になったのです。

そのことに気づいた人が続々増えています。

しかし、この神話にもそれなりの根拠はありました。Web アプリケーションでのSQLiteの使い方は勘違いされやすく、誤用されやすいからです。

デフォルトのSQLiteは、現代の多くのソフトウェアと異なり、新機能やより優れた機能を取り入れることよりも、下位互換性を重視しています。

SQLiteのメンテナーたちは、20年前に作成されたデータベースファイルが20年後のSQLiteでも正しく開けることを非常に重視しています。特に、SQLiteが米国議会図書館でデジタルデータの保存形式として使われている主な理由はこれなのです。

SQLiteをWeb向けにチューニングする

これはつまり、SQLiteを今の時代に合わせて調整しておかないと、2004年に最初にリリースされたときの古いセットアップでSQLiteを使っているのと同じになるということです。そして、2004年のSQLiteは、Webアプリケーションで実行するにはあまり適していませんでした。

しかし、この20年間で、SQLiteにはWebアプリケーションに適したさまざまな機能が追加されています。あと必要なのは、SQLiteのセットアップと利用方法をWeb向けに微調整することだけです。

私とRailsコアチームがこの1年間にわたって行ってきたのは、まさにこの作業だったのです。

このSQLiteの調整作業はRails 8で完了しました。

SQLiteセットアップの改善点は、7.2から継承されたものも多数ありますが、Rails 8にはさらに、詳しく知っておく価値のある追加機能が2つあります。
これらの変更により、Rails 8は完全にproduction環境に対応したSQLiteエクスペリエンスを提供する最初のRailsバージョン（そして私の知る限り、あらゆるWebフレームワークにおける最初のバージョン）になります。

「out-of-the-box」というキャッチフレーズの通り、すぐに使えます。

従来のSQLiteで起きていた問題

従来は、SQLite on Railsのデフォルトのエクスペリエンスを妨げる問題が2つありました。

1つ目の問題は、アプリケーションにかかる同時負荷が大きくなるに連れて、リクエストがエラーになる割合が増大することでした。リクエストを同時4件受け取っただけで、レスポンスのほぼ半分がエラーになりました。このままでは明らかにproduction環境で使えませんね。

2つ目の問題は、同時負荷の増加に伴うアプリケーションのテールレイテンシに関連していました。p99（パーセンタイル99）やp95（パーセンタイル95）のレイテンシが急上昇することがわかります。それに、一部のリクエストのレスポンスが返るまでに5秒以上かかるようでは、とても実際のアプリケーションでは許容できません。

どちらの問題も、SQLiteのような埋め込み型のデータベースをマルチスレッドWebアプリケーションで使う際の微妙な違いから生じます。
Railsは、受け取ったリクエストを処理するために複数のスレッドを起動しますが、各スレッドは独自のSQLiteデータベースへの埋め込み型コネクションを持っています。

Railsは、コネクションが互いに競合しないよう調整しなければなりません。

つまり、コネクション同士が互いにブロックせず、お互いを待つようにするのです。

問題の解決

埋め込み型コネクション同士の競合は、RailsがSQLiteのトランザクションを構築するときの方法を変更することで解決されました（#50371）。

さらに、それらの競合を防ぐために、2つのプルリクによる修正が行われました。

1つはRubyとSQLiteエンジンの間の低レベルインターフェイスであるsqlite3-ruby gemの修正です（#456）。

もう1つは、この新しいドライバの機能をRailsで使えるようにするプルリクです（#51958）。

この場では技術的に詳しく掘り下げる時間はありませんが、私のブログにこれらの変更のあらゆる詳細（問題の性質、解決策の根拠、実装の詳細）を詳しく説明した記事がありますので、ご興味がありましたらぜひどうぞ。

細かな話はともかく、結果がすべてです。
アクセスが集中したときにSQLiteでエラーレスポンスが起きなくなっただけではありません。

高負荷時のp99レイテンシも文字通り1桁改善されました。

実際、ベンチマークを見ると、最も時間のかかったリクエストでも改善が安定していることがわかります。

これらのコンフィグや利用法に合わせてアプリケーションコードを書き換える必要は一切ありません。

SQLiteのパワーとスピードが最大限に発揮されるようになったことで、SQLiteはproduction環境で完全に通用する立派な選択肢となったのです。

Railsにある5つのデータ用コンポーネントのうち4つをSQLiteでカバーできるようになったのです。しかも何の妥協も必要とせずに。

これが可能になったからこそ、SQLiteを取り入れたアーキテクチャが実践的な選択肢になりえたのです。機能やパフォーマンスについて妥協することなく、フル機能のRailsアプリを1台のコンピュータ上で実行できるようになったのです。

現実のRails 8アプリでの負荷テスト

さて、私の提案がかなり過激に感じられることは自分でも承知しております。きっと皆さんの多くが、SQLite入りのアーキテクチャがproduction環境の負荷に耐えられるはずなどないだろうとお考えでしょう。
本当かどうか調べてみましょう。

最初に、37signalsが今年初めにリリースしたCampfireアプリを使ってみたいと思います。37signalsのチームは、フル機能を備えたproductionレベルのアプリケーションを構築しただけでなく、現実的な負荷テストツールも組み込んでリリースしているので、そこから見ていくことにしましょう。

さて、このCampfireアプリはSQLiteに全振りしているわけではありません。SQLiteはActive Recordを支えるデータベースエンジンとして使われていますが、ジョブやキャッシュやWebソケットにはすべてRedisが使われています。

しかしRailsがモジュール化されているおかげで、以下のようにアダプタを交換するだけで済みました。Rails 8と「Solid Queue」「Solid Cache」「Solid Cable」という3つのgemを使うようにCampfireアプリを再設定し、それらを支えるデータベースを以下のようにすべてSQLiteに差し替えました。ちなみに、この作業には1時間ほどしかかかっていません。

次に、Campfireの通常ビルドと、デモ用の「Campfire on SQLite」forkの両方に対して負荷テストを実行しました。

では結果を見てみましょう。何しろ「結果がすべて」です。
それぞれで生成されたコネクション数は以下のとおり、SQLite版はまったく引けを取りません。

受信メッセージ数についても、「Campfire on SQLite」forkのCampfireアプリは、標準のCampfireビルドに匹敵するパフォーマンスを発揮しています。

なお、この負荷テスト以外にも、Adrien Poly作のRuby Videoのように、このRails 8の技術スタック上に構築されて既に現在稼働しているRailsアプリケーションがいくつもあります。

ちなみにこちらのRuby Videoアプリは、IO周りのニーズをSQLiteでサポートし、月額4ドルのHetznerボックス1個だけで稼働し、平均応答時間100ミリ秒未満、4ナインすなわち99.99%の稼働率で数百万件のリクエストをさばき続けています。

また、私が以前いた会社には、1台のマシン上で何年もの間SQLiteだけで運用していたアプリケーションがいくつもあります。
残念ながら、こちらについては大企業とのNDA（秘密保持契約）に関連する独自のアプリケーションなので、詳細やスクリーンショットをお見せするわけにはいきません。しかし、これらのアプリケーションは今でもスムーズに動き続けて数百万ドルの収益をもたらしており、しかもパフォーマンスに関する苦情は一度もありませんでした。

もちろん、最近テック系Twitterアカウントの間ではPeter Levels氏の強力なセットアップの話題で持ちきりです。何しろ同氏による多くの成功したアプリケーションは、どれもすべてSQLiteを単一の強力なVPS上で実行しているというのですから。

念のため申し上げますが、「単一サーバーをproductionにデプロイする」という方式は、最も初期のRailsアプリケーションのときから今に至るまでずっと有効です。

つまり、機能やパフォーマンスについて一切妥協しないフル機能のRailsアプリケーションを、production環境の1台のコンピュータだけで運用することは、実際に可能なのです。

そういうわけで、「SQLiteだけを使うRailsアプリケーションを単一マシンにデプロイしたってproduction環境の負荷に耐えられるはずがない」などという考えはもはや神話であることを皆さんに信じていただければと思います。

そして来年は、今日ここにお集まりの皆さんの中から、プロジェクトを立ち上げて運営を成功させる人が何人も出現して、さらに多くの裏付けを加えてくれることを願っています。

SQLiteならではの特徴と注意点

ただし、SQLiteは銀の弾丸などではありません。

このアーキテクチャが効果を発揮するユースケースもあれば、そうでないユースケースも当然ありますし、さらに細かな配慮が必要な分野もあります。

バックアップ

SQLiteをproduction環境で実行するなら、堅牢なバックアップメカニズムも用意しておく必要があります。production環境のSQLiteデータベースを誤って削除してしまったやらかし経験のある私が申し上げているのですから、どうか信じてください、回復のしくみは初日から設定しておくべきです。

SQLiteのバックアップに最適なツールはLitestreamだと思います。Litestreamユーティリティを使えば、SQLiteデータベースなどのさまざまなデータベースにおけるあらゆる更新を、さまざまなバケットストレージシステムや、さらにはFTS（ファイル転送システム）サーバーにストリーミングできます。これによって、ポイントインタイムバックアップと非常に安価なストレージコストを実現できます。

Litestreamは単一のGo実行ファイルなので、手軽にインストールできるよう私がRuby gemにまとめました。このgemはレプリケーションプロセスの管理にPumaプラグインも使っているため、まさにプラグアンドプレイソリューションです。
また、定期的なバックアップをスケジューリングできる検証ジョブも付属しているので、バックアッププロセスを継続的かつスムーズに実行できるようになります。

SQLiteの「線形書き込み」

データの復元力以外で私が最もよく耳にするのは、現在のSQLiteでは線形書き込みしかサポートされていないことが心配だという話です。

つまり、一度に1つの書き込み操作しか実行できないため、アプリケーションの「スケーリング」が妨げられることが心配だというのです。
これはどういう意味でしょうか。しかし、この心配は大げさです。

まず、ほとんどのアプリケーションは読み取りが中心で、書き込みが中心ではありません。したがって、書き込みはせいぜいトラフィックの約20%にとどまる可能性が高いでしょう。しかも、埋め込み型データベースを使ったときにパフォーマンスがどれだけ違ってくるかを見落としています。

埋め込み型データベースの強み

アプリケーションと同じコンピュータでPostgreSQLを実行する場合でも、PostgreSQLクエリを1件実行するのにかかるのと同じ時間で、SQLiteクエリを10件実行できます。

ただし、近年のWebアプリケーションは全般に、従来のセルフホスティングで独自のデータベースサーバーを管理する運用から移行しつつあり、クラウドデータベースがかつてないほど人気になっています。

クラウドデータベースを使う場合、データベースサーバーはアプリケーションサーバーとは異なるリージョンに配置されている可能性が高いでしょう。この場合、仮にリージョンが隣接しているとしても、レイテンシが増加すれば、PostgreSQLクエリ1件を実行するのと同じ時間で、SQLiteクエリを約600件実行できることになります[1]。

原注1: この見積もりは、Litestreamの作者にしてSQLite全般のエキスパートであるBen Johnsonが、GopherConで発表した内容を元にしています。

従来のクライアント/サーバー型データベースアーキテクチャから埋め込み型データベースに移行すれば、クエリの測定単位はミリ秒からマイクロ秒になります！

ただしデータの書き込みが大量でなければの話です（ここで言う「大量」は1秒あたり50,000回オーダーの書き込みです）。
私は、SQLiteアーキテクチャのこの側面がアプリケーションに大きな影響を与えることはないと断言できます。

マイグレーションには注意

しかしSQLiteでは、データベースの大規模なマイグレーションに関して慎重になる必要もあります。

数百万行のテーブルに新しいインデックスを追加するような長時間の書き込み集中型のマイグレーションは、アプリケーションのパフォーマンスに影響します。
現時点では、この制限を回避するための有名な実績のあるツールは存在しないため、そのような大規模なマイグレーションを実行する場合は計画的なダウンタイムが必要になる点にご注意ください。

SQLiteと垂直スケーリング

次に考慮すべき点は、SQLiteは単一のコンピュータ上で最適に動作するように構築されていることです。つまり、スケーリングが必要な場合は垂直スケーリングが最適だということです。必要に応じて単一マシンのスペックサイズを拡張することになります。

ところで、Digital Ocean、Hetzner、AWSなどの既成プロバイダが提供しているレンタルマシンのサイズについて、多くの人がひと昔前のつつましいスペックを想像している可能性がかなりありそうです。

今では、昔よりもずっとハイスペックのマシンをレンタルできるのです。

本当に大きな箱のようなものです。
たとえば、Hetznerでは48コア、192GB RAM、1テラバイトのNVME SSD容量をすべて備えたVPSを月額350ドル以下でレンタルできるのですから、これはすごいことです。

つまり、アプリケーションを垂直スケーリングでどこまで拡張できるかについて思い込みで上限を決めてかかるべきではないということです。

冗長化はどこまで必要か

しかしこの10年間、Webアプリを構築する唯一の「正しい」方法はこれらを導入するしかないと言われ続けてきました。

いわく冗長性、

いわく高可用性、

いわく自動フェイルオーバー、

いわくゼロから無限大までの自動スケーリング、といった具合です。

しかしこれらの高価なソリューションをすべて必要とするのは、実際にはインターネット上のごく一部のアプリケーションが抱えている（または今後抱えるであろう）問題に対応するときぐらいです。

そして、これらのソリューションと引き換えに、運用が複雑になるという実際のトレードオフが伴います。システムのサーフェス（表面積）が大きければ大きいほど、障害が発生する可能性が高くなることを忘れてはいけません。

ですから、特に最初の段階で自問してみましょう。
果たして最初からこんなに強力なソリューションが本当に全部必要なのか、それとも最初のうちは、楽に覚えていられるほどシンプルで、顧客のニーズに十分応えられる強力な技術スタックにしておく方がよいのではないかと。

したがって、他のツールと同様に、SQLiteにもトレードオフがあります。
世の中には完璧なツールも完璧な技術スタックもありませんし、決定を下すにはさまざまなことを考慮をしないわけにはいきません。

まとめ

ツールを最大限に活用するには、ツールとその特徴や特性について学ぶしかありません。しかし、効果の高いツールを選べば、シンプルさのパワーが発揮されるのです。そのツールは素晴らしい作りの有名なツールで、おそらく退屈なものと思われているでしょう。

今や誰でも、次のアイデアを火星にまで届ける力を持つアプリケーションを本当に構築できます。しかし、そのためにロケット科学者になる必要はありません。Rails 8とSQLiteは、そうしたわずらわしさを取り去ってくれるのです。

想像できる限り最もスリムで、最もシンプルで、最も強力なアプリケーションスタックが完成しました。長年かけて進化と考慮を繰り返した末にシンプルさを獲得したツールほど強力なものは、まずありません。

Rails 8とSQLiteの組み合わせによって、個人が、productionで通用するレベルのフル機能を備えた価値あるアプリケーションを、これまでよりも短期間で、シンプルに、そして安価に構築することが可能になります。これらは「個人のためのフレームワーク」を実現するツールでありエンジンです。個人、小規模チーム、大規模チームを問わず、ビジネスを立ち上げる勢いとパワーを提供するツールです。

SQLiteとRailsは、他に類を見ない唯一の取り合わせであり、力強いコンビです。
ここで発表した調査によって、SQLiteが創造性とアプリ構築を推進するエンジンとしてRailsと見事に連携できることをより深く理解し、評価していただければ幸いです。
そして、次に作るRailsアプリケーションをSQLiteで構築して実行できる（あるいは「そうすべきだ」）という自信が持てるようになることを願っています。

ありがとうございました。

本記事は、Rails World 2024における私の発表を編集して記事化したものです。以下のYouTube動画でもご覧いただけます。

YassLab 社が運営するRailsチュートリアルでも Rails 7 対応版から徐々に SQLite 対応を進めています。また現在制作中の Rails 8 対応版では PostgreSQL 対応を完走後の演習課題の１つとして配置し、チュートリアル自体は SQLite で最初から最後まで走り切れる構成になる予定です。

より多くの方々が（経験者だけでなく初心者も！）プロダクト開発の世界を楽しめるよう、今後も継続的に改善を重ねていきますので、引き続きよろしくお願いいたします…!! 

↓ これまでの改善例

法人向けの研修支援や協賛プランなども提供しておりますので、コチラもよければぜひ! 🤝✨