3 ms·

For many fly.io is not a viable alternative especially those that are already on the AWS train. I think that AWS already offers Aurora Serverless v2 which pret

For many fly.io is not a viable alternative especially those that are already on the AWS train. I think that AWS already offers Aurora Serverless v2 which pretty much accomplishes what a lot of these me-too-serverless services that won't integrate as well as something that is offered out of AWS. Even if you were insistent on cloud-agnostic mandate (which is really not logical since there is at best 3 public clouds to choose from that are also vulnerable to targeted cyberattacks and faultlines), it would be hard to convince a large organization to switch to using Sqlite on Fly.io

tptacek 4y ago
Forget the Fly.io part; SQLite is what's interesting here. I agree in advance that it's unlikely anyone's going to convert a large app from Postgres to SQLite; if full-stack SQLite succeeds as a trend, it'll be with new apps that grow up using it.
- shabbatt 4y ago
  interested to know what you see in sqlite here? why is there so much interest in this all of a sudden lately? am I missing something?
  - tptacek 4y ago
    It's a database that in full-stack culture has been relegated to "unit test database mock" for about 15 years that is (1) surprisingly capable as a SQL engine, (2) the simplest SQL database to get your head around and manage, and (3) can embed directly in literally every application stack, which is especially interesting in latency-sensitive and globally-distributed applications. Reason (3) is clearly our ulterior motive here, so we're not disinterested: our model user deploys a full-stack app (Rails, Elixir, Express, whatever) in a bunch of regions around the world, hoping for sub-100ms responses for users in most places around the world. Even within a single data center, repeated queries to SQL servers can blow that budget. Running an in-process SQL server neatly addresses it. Conveniently, most applications are read-heavy, and most performance-sensitive app requests are reads.
    - shabbatt 4y ago
      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).
vosper 4y ago
> I think that AWS already offers Aurora Serverless v2 which pretty much accomplishes what a lot of these me-too-serverless services that won't integrate as well as something that is offered out of AWS. People should just be aware that Aurora Serverless v2 won't scale to zero, and you'll pay for it even if you never use it. https://www.lastweekinaws.com/blog/no-aws-aurora-serverless-v2-is-not-serverless/ https://www.lastweekinaws.com/blog/no-aws-aurora-serverless-...
- shabbatt 4y ago
  ah thanks for pointing that out, since this is new its bound to change. will be surprised if this didn't eventually scale to zero but if I had to bet I would back AWS here going forward. This is way too critical for it's serverless stack to get the Cognito treatment.

tptacek 4y ago

Forget the Fly.io part; SQLite is what's interesting here. I agree in advance that it's unlikely anyone's going to convert a large app from Postgres to SQLite; if full-stack SQLite succeeds as a trend, it'll be with new apps that grow up using it.

shabbatt 4y ago
interested to know what you see in sqlite here? why is there so much interest in this all of a sudden lately? am I missing something?
- tptacek 4y ago
  It's a database that in full-stack culture has been relegated to "unit test database mock" for about 15 years that is (1) surprisingly capable as a SQL engine, (2) the simplest SQL database to get your head around and manage, and (3) can embed directly in literally every application stack, which is especially interesting in latency-sensitive and globally-distributed applications. Reason (3) is clearly our ulterior motive here, so we're not disinterested: our model user deploys a full-stack app (Rails, Elixir, Express, whatever) in a bunch of regions around the world, hoping for sub-100ms responses for users in most places around the world. Even within a single data center, repeated queries to SQL servers can blow that budget. Running an in-process SQL server neatly addresses it. Conveniently, most applications are read-heavy, and most performance-sensitive app requests are reads.
  - shabbatt 4y ago
    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).

vosper 4y ago

> I think that AWS already offers Aurora Serverless v2 which pretty much accomplishes what a lot of these me-too-serverless services that won't integrate as well as something that is offered out of AWS. People should just be aware that Aurora Serverless v2 won't scale to zero, and you'll pay for it even if you never use it. https://www.lastweekinaws.com/blog/no-aws-aurora-serverless-v2-is-not-serverless/ https://www.lastweekinaws.com/blog/no-aws-aurora-serverless-...

shabbatt 4y ago
ah thanks for pointing that out, since this is new its bound to change. will be surprised if this didn't eventually scale to zero but if I had to bet I would back AWS here going forward. This is way too critical for it's serverless stack to get the Cognito treatment.