SQLite3 is a library. Everything it does executes within the thread that you provide when you made a call into the library. Hence if this thread is executing on Processor 1, then the library code will execute on Processor 1. If the thread making the call is executing on Saturn, then the library code will execute on Saturn. The only possible exception to this is if you have compiled the library to use a mode other than single-threaded and you have enabled `worker_threads` in which case the library may spin up worker threads to help process sort and index operations. The request for a "thread" will be made the the "Operating System" which owns the current thread of execution and will execute wherever the "Operating System" (being in charge of such things) dispatches it to execute. You may set the number of worker_threads to zero either at compile time or in a pragma (per connection) at runtime. As a library, SQLite3 neither knows nor cares where it is executing. It is no different than any other library (zlib, glibc, etc) in that that knowledge is beyond the scope and control of the library and is in the charge of the Operating System under which the application that is linked with the library is running. Using the library under Linux should be no problem. Whether or not you can compile the library for your RTOS is another issue.