One thing to be aware of, is that many small DBs waste more space than larger DBs because the space overhead of non-full pages is better amortized; especially if you have a large number of tables with fewer and small rows inside. For example, I have a schema where most of the bulk ends up in only 3 tables, and many other small *lookup* tables use just a single page each, with those single-page B-Tree *wasting* quite of bit of space. If I have hundreds of multi-MBs of those DBs, then I can live with that overhead. But if I had millions of only a few KB DBs, then the overhead would become unacceptable. For some tables, you want large pages, for performance reasons. For others, you want small pages. And SQLite does not support that, unfortunately. You'd be forced to use two different DBs, but then you loose referential integrity which does not cross DB boundaries. Note also that one of the reason [SQLite can be faster than the filesystem](https://www.sqlite.org/fasterthanfs.html) is because there are fewer `fopen()` calls. If you have millions of DBs, you are back into many fopen calls territory. So some sharding is good (if your scale truly requires it, which is rarely the case...). But excessive sharding is not. So do yourself a favor, and start with a single DB. And when (if really...) you actually outgrow that, look into alternative to a single DB. Research for example how Expensify scales SQLite. There are other SQLite-derived projects for scaling too.