Database connections (in general) aren't thread safe, so the Rails connection pool ensures that you only get one connection per thread. Which explains why you're getting new connections.
Now, I'm not 100% sure about the thread safety guarantees for sqlite3. If they are safe, you may be able to adjust the connection pool to always hand out the same connection regardless of the thread. I suspect the sqlite3 API is thread safe (as in it won't crash), but you could definitely encounter race conditions in the Rails connection adapter.
Take these two methods as an example:
When Rails inserts a new record, it fetches the id of that record to set as the "id" value on your model by using the `last_insert_row_id` method. So it performs two distinct steps:
1. Insert a record
2. Get the last insert id
Since the connection is assumed not to be shared among threads, there is no lock around these two steps. If it is shared among threads there could be a race condition.
If you really need to run with the database in memory, I have two recommendations right now:
1. Run in memory, but don't use multiple threads to access the database
2. Use an in-memory FS and point sqlite3 there
I know this isn't the best solution, but I hope the info helps!