4 ms·

Litestream is a database server, isn’t it?

tptacek 4y ago
No; there's no such thing as a sqlite3 server. The database is the file(s). Litestream runs alongside everything else using sqlite3 and ensures that it's replicating. If Litestream crashes, reads from the database keep working fine (though, of course, they'll start to stale if it doesn't come back up). This is why we called out in the post that Litestream is "just sqlite3". It's not sitting between apps and the database.
- throwoutway 4y ago
  That seems disingenuous. If sqlite3 isn't a server, then neither is apache2. But in reality they're both binaries 'serving' 'files' over an interface. You're just hosting them on the same machine, reverting to a monolith-style deployment. Which is fine, but then lets call it what it is.
  - dagw 4y ago
    But in reality they're both binaries 'serving' 'files' over an interface. By that definition fopen() is also a server.
    - WorldMaker 4y ago
      According to Plan9, fopen() is also a server.
  - ignoramous 4y ago
    > That seems disingenuous. If sqlite3 isn't a server, then neither is apache2. Your argument really is with Dr. Richard Hipp: https://sqlite.org/serverless.html https://sqlite.org/serverless.html
- ignoramous 4y ago
  > Litestream crashes, reads from the database keep working fine. fly-app's litestream-base dockerfile suggests that the litestream process supervises the app process... I guess then that's a limitation specific to fly.io's deployment model and not litestream?
- nwienert 4y ago
  That’s my point though, if you want to use SQLite in production / with Litestream, you’re comparing two databases that need servers to function just implemented quite differently. In the same vein as your article, it seems very fair to say that if the Litestream server went down in production you’d have a broken app for most use cases within a few minutes. So in practical effect, the server of Litestream is about as essential.
deleted 4y ago
[deleted]

No; there's no such thing as a sqlite3 server. The database is the file(s). Litestream runs alongside everything else using sqlite3 and ensures that it's replicating. If Litestream crashes, reads from the database keep working fine (though, of course, they'll start to stale if it doesn't come back up). This is why we called out in the post that Litestream is "just sqlite3". It's not sitting between apps and the database.

throwoutway 4y ago
That seems disingenuous. If sqlite3 isn't a server, then neither is apache2. But in reality they're both binaries 'serving' 'files' over an interface. You're just hosting them on the same machine, reverting to a monolith-style deployment. Which is fine, but then lets call it what it is.
- dagw 4y ago
  But in reality they're both binaries 'serving' 'files' over an interface. By that definition fopen() is also a server.
  - WorldMaker 4y ago
    According to Plan9, fopen() is also a server.
- ignoramous 4y ago
  > That seems disingenuous. If sqlite3 isn't a server, then neither is apache2. Your argument really is with Dr. Richard Hipp: https://sqlite.org/serverless.html https://sqlite.org/serverless.html
ignoramous 4y ago
> Litestream crashes, reads from the database keep working fine. fly-app's litestream-base dockerfile suggests that the litestream process supervises the app process... I guess then that's a limitation specific to fly.io's deployment model and not litestream?
nwienert 4y ago
That’s my point though, if you want to use SQLite in production / with Litestream, you’re comparing two databases that need servers to function just implemented quite differently. In the same vein as your article, it seems very fair to say that if the Litestream server went down in production you’d have a broken app for most use cases within a few minutes. So in practical effect, the server of Litestream is about as essential.

deleted 4y ago

[deleted]