SQL Server VS SQLite3

You can read more discussion here: https://github.com/sparklemotion/sqlite3-ruby/pull/528 and here: https://github.com/digital-fabric/extralite/pull/46 to see how it was validated that simply releases the GVL for every `step` in the SQLite VM majorly hurts single-threaded performance. Finding a middle ground for both single threaded and multi-threaded performance is tricky. In Rails, we know it is multi-threaded because of the connection pool. But the lower level gem is used in many other libraries and tools where it is used in a single threaded environment

Extralite is a gem for working with SQLite databases. It is blazing fast (up to 11x the performance of the sqlite3 gem), and provides a rich API for accessing database data in a variety of formats.

DB: sparklemotion/sqlite3-ruby: Ruby bindings for the SQLite3 embedded database

# This configure_connection is run when each new connection is created. # see https://github.com/rails/rails/blob/main/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L1112 def configure_connection super puts "Configuring DB connection with app-specific PRAGMA statements" conn = self.raw_connection # see https://github.com/sparklemotion/sqlite3-ruby/blob/master/lib/sqlite3/pragmas.rb conn.synchronous = 1 # normal # this is a permanent pragma but in case DB is brand new, no harm is invoking it conn.journal_mode = 'wal' # this is unnecssary b/c rails' sqlite3adapter turns it on by default conn.foreign_keys = true # this is not yet supported with convenience method #conn.analysis_limit = 400 # PRAGMA temp_store = 'memory' # hold temporary indices and tables in memory # conn.temp_store = 2 end

That looks like you're missing the ruby module, not the OS package. If you're using bundler to manage your dependencies, add gem 'sqlite3', '~> 1.3', '>= 1.3.11' to your Gemfile. For reference, I got that line from this page: https://rubygems.org/gems/sqlite3/versions/1.3.11