With all respect, but WHY?!
Why wrap a lightweight, filebased and file-optimised database, if you clearly need memory-based performance?
If you really need SQL features and good caching, why not use a full scale relational database, that has been optimised for literal decades to solve exactly this problem?
(E.g. PostgreSQL, which even supports Multicore across single queries in the latest versions, and has excellent diesel rust bindings)
By wrapping a lightweight DB in a caching layer, you are basically (poorly) reinventing the wheel: you need to keep reopening your sqlite file(s), repeating all the parsing, and sqlite, awesome as is, can not hold a candle to the incredible optimisation and (integrated, content aware) caching powers of PostgreSQL, MySQL or Microsoft SQL Server.
Don't solve your performance problems, solve your architecture problems!
(My apologies for going on a rant here 
, but I have a very hard time imagining why you would build something in this way, I am also very curious about the constraints/reasoning that brought you to this solution.
Please do explain, and I am willing to learn if/why this could make sense!)
edit 1: links to postgres+diesel
edit 2: rant apology
edit 3: I found your original topic about this project, sorry for not noticing it back then.