I still don't really understand the real "advantages" of such an architecture, over, say, a centralized Postgres server, which can process just as much data no?
The network round trips of queries to a database server add up, so much that they influence query design (though we don't much think about that anymore, because n-tier database designs are so prevalent that everyone writes queries that way). The advantage to SQLite is that queries are incredibly fast.
So it's often "presented" as "a local database which is replicated by streaming", but perhaps it would be more natural to view it as a kind of "centralized database, but with local caches that are kept near your server code, and sync'd"
I understand it's the same, but it makes the intent clearer: the intent is more to have a local cache to read/update (which is then sync'd), or at least it seems clearer to me presented that way :)
Comments
I still don't really understand the real "advantages" of such an architecture, over, say, a centralized Postgres server, which can process just as much data no?
The network round trips of queries to a database server add up, so much that they influence query design (though we don't much think about that anymore, because n-tier database designs are so prevalent that everyone writes queries that way). The advantage to SQLite is that queries are incredibly fast.
I see! Thanks.
So it's often "presented" as "a local database which is replicated by streaming", but perhaps it would be more natural to view it as a kind of "centralized database, but with local caches that are kept near your server code, and sync'd"
I understand it's the same, but it makes the intent clearer: the intent is more to have a local cache to read/update (which is then sync'd), or at least it seems clearer to me presented that way :)