Comment by bravura
2 days ago
The top line of the README says: "Embed an SQLite database in your PostgreSQL table. AKA multitenancy has been solved."
But I'm still having trouble trying to grok the intricacies of it. In a sense, I guess it has well isolated individual SQLite DBs and you'd have to go out of your way to join over them. With that said, does PostgreSQL manage and pool all the writes correctly? So you don't need to worry about SQLite concurrency issues?
If by solving multinenancy they mean
then they don't need to make joins between sqlite dbs.
Your other concerns are very real. Those sqlite dbs could become very large. I prefer the use case depicted in another reply: preparing sqlite dbs before shipping them to their own devices. Or maybe receiving them and performing analysis, maybe after having imported it in overall psql tables. Or similar scenarios in which all the db is read or written at once. Anyway, once we have a tool we start using it.
> then they don't need to make joins between sqlite dbs.
The extension could also provide custom index access methods (considering that SQLite only has a handful of column types in the first place.) That would allow you to incorporate the keys in the index heaps, as opposed to table heaps, boom, you get bitmap index scans for Joins, i.e. GIN but with a bit more redundancy.
Each of the columns is an instance of a SQLite database, so I assume (without looking at the source) that they properly multi-thread as needed.
So there's not cross-SQLite-database connections or multiple writers going on.
You could join over them, but not really in the way you're thinking.
Each of the columns that are databases would be updated when the functions execute.
You could do weird crap like INSERT/DELETE as part of a postgres level SELECT.
You can do that with any function already. This isn't new because of nested databases.