> (3) The primary DB connection > (5) Coordination between DB closing In embedded mode, the pimary DB connection can be coming from the host. I.e. one should neither open nor close it. In my case, it is **the** DB with all the vtables representing the state of the C++ host application, which only the host app can configure, and which the host app will continue using once the embedded shell *exists*. The embedded shell can open other connections (recent addition), or attach other DBs. If attaching other DBs to the primary host-managed connection, once might wonder whether the shell should detach those, or let them attached, to be available again later if/when another embedded shell is re-started. I think leaving them as-is makes more sense. The host can setup an [authorizer][AUTH] if it wants to, to prevent or know about those, and detach them *post* embedded-shell *exit*. Regarding your thinking of a struct and a main()-like entry point. Why not replicate the design of SQLite itself, with the shell taking an optional VFS, defaulted otherwise, and a new VIO (Virtual IO) interface specific to the shell? I.e. make the shell a stateful object to new/config/close? [AUTH]: https://www.sqlite.org/c3ref/set_authorizer.html