[jjmod]

It might be feasible if you use sqlite's in-memory feature, because hitting the disk on each query is way too slow for a real-time application.

Why not just use an r-tree library for the language you're using? It'll be faster and easier to work with. Since scene data is usually hierarchial, sql doesn't seem like a great choice for storing it

[vlovich123]

Page cache and SQLite cache means you don’t actually end up hitting the disk usually. Also SSDs are pretty fast and NVMEs more so.

Maybe when you first start or access a new piece of data for the first time you maybe get a hiccup (maybe not - always profile to figure out how your specific application performs). If hiccups like that actually manifest, a nice way to solve that would be to attach the on-disk DB to the in-memory one, copy everything over (and maybe detach). If that DB is ever mutable at runtime, just copy the changes back in a background transaction to the on-disk DB (in this case I wouldn’t detach probably). This way you still get the persistence of the disk with the performance of RAM.

[pdpi]

Graphics are a notorious case of CPU-bound applications. Adding IO boundedness to the equation seems like a bad idea.

I’m not saying it can’t be done, or that it can’t be fast. But it’s very much against the grain and needs more justification Than “NVMe is fast”