3 ms·

hmm but how would the replication and sync be handled if you have many sqlite instances on edge locations around the world? If someone inserts a row with id 234

hmm but how would the replication and sync be handled if you have many sqlite instances on edge locations around the world? If someone inserts a row with id 234 and somebody from other side of the world does it, wouldn't this type of logic involve reaching into a central source of truth to compare the diff? tryna wrap my head around this architecture, it is quite interesting but concerning that it is now sharding into close-to-local sqlite instances located near the user.

tptacek 4y ago
Yes: the model topology you should have in your head is "single writer, multiple readers" --- exactly the same way it would work with a conventional Postgres setup. What you're getting with SQLite here is that the reads themselves are served out of the app process rather than round-tripping over the network; otherwise, it's the same architecture. (You're not generally "reaching back to the central source of truth to compare" things, so much as "satisfying the write centrally and shipping out the new database pages back to the read replicas at the edges"). More on this model: https://fly.io/blog/globally-distributed-postgres/ https://fly.io/blog/globally-distributed-postgres/
- shabbatt 4y ago
  Interesting, do you have plans to support GPU as well? I can see this is a bottom up approach: put a low load instance close to the user for reads and have a globally synced write that should handle race conditions etc Are there cold start delays? From the moment I type domain.com is it going to spin up a fly instance closest to me and serve the SQLite database reads? I'm gonna give this a go this weekend to see what it can do
  - tptacek 4y ago
    This is getting into Fly.io stuff and not WunderBase or SQLite stuff. GPU is a ways off for us: the programming interface for GPUs is tricky to implement with full isolation between VMs. The post we're commenting on talks a bit about cold start delays (a couple hundred milliseconds).

tptacek 4y ago

Yes: the model topology you should have in your head is "single writer, multiple readers" --- exactly the same way it would work with a conventional Postgres setup. What you're getting with SQLite here is that the reads themselves are served out of the app process rather than round-tripping over the network; otherwise, it's the same architecture. (You're not generally "reaching back to the central source of truth to compare" things, so much as "satisfying the write centrally and shipping out the new database pages back to the read replicas at the edges"). More on this model: https://fly.io/blog/globally-distributed-postgres/ https://fly.io/blog/globally-distributed-postgres/

shabbatt 4y ago
Interesting, do you have plans to support GPU as well? I can see this is a bottom up approach: put a low load instance close to the user for reads and have a globally synced write that should handle race conditions etc Are there cold start delays? From the moment I type domain.com is it going to spin up a fly instance closest to me and serve the SQLite database reads? I'm gonna give this a go this weekend to see what it can do
- tptacek 4y ago
  This is getting into Fly.io stuff and not WunderBase or SQLite stuff. GPU is a ways off for us: the programming interface for GPUs is tricky to implement with full isolation between VMs. The post we're commenting on talks a bit about cold start delays (a couple hundred milliseconds).