Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm all-in on server-side SQLite (2022)

fly.io

Post reply on HN
Print view View original

1–10 of 167 posts

Re: I'm all-in on server-side SQLite (2022)

#5

Post by maxmcd »

Been feeling a little miffed about this recently. Litestream is excellent but if you have multiple writers your db gets corrupted. Quite easy to do with rolling deploys.

LifeFS was announced and is intended to help this. Now seems like (https://fly.io/docs/litefs/getting-started-fly/) it requires an HTTP proxy so that the application can guess about sqlite write/read usage by reading the HTTP request method. This seems... to introduce a different (maybe better?) set of gotchas to navigate.

There are now SQLite cloud offerings but you pay the network overhead and avoiding that was so much of the appeal of using SQLite.

Are people successfully using SQLite in a work or production setting with a replication and consistency strategy that they like? I've had trouble getting a setup to the point where I can recommend it for use at my jarb.

Re: I'm all-in on server-side SQLite (2022)

#6

Post by capableweb »

maxmcd wrote: post #5

Been feeling a little miffed about this recently. Litestream is excellent but if you have multiple writers your db gets corrupted. Quite easy to do with rolling deploys. LifeFS was announced and is intended to help this. Now seems like ( https://fly.io/docs/litefs/getting-started-fly/ ) it requires an HTTP proxy so that the application can guess about sqlite write/read usage by reading the HTTP request method. This s…

I've had success in a production capacity with using rqlite before. There are also a bunch of other alternatives that still seem to be actively maintained, although I've only used rqlite myself before:

- https://github.com/canonical/dqlite

- https://github.com/rqlite/rqlite

- https://github.com/Expensify/Bedrock

Re: I'm all-in on server-side SQLite (2022)

#7

Post by matlin »

If you need multiple writers and can handle eventual correctness, you should really be using cr-sqlite[1]. It'll allow you to have any number of workers/clients that can write locally within the same process (so no network overhead) but still guarantee converge to the same state.

[1] https://github.com/vlcn-io/cr-sqlite

Re: I'm all-in on server-side SQLite (2022)

#8

Post by morelisp »

maxmcd wrote: post #5

Been feeling a little miffed about this recently. Litestream is excellent but if you have multiple writers your db gets corrupted. Quite easy to do with rolling deploys. LifeFS was announced and is intended to help this. Now seems like ( https://fly.io/docs/litefs/getting-started-fly/ ) it requires an HTTP proxy so that the application can guess about sqlite write/read usage by reading the HTTP request method. This s…

> Litestream is excellent but if you have multiple writers your db gets corrupted.

Isn't this not only well-documented, but (restricting to a single writer to avoid distributed systems issues while still making it easy to move that single writer around) sort of the whole point?

Re: I'm all-in on server-side SQLite (2022)

#9

Post by blagie »

I don't need to be sold on the virtues of applications running on systems like SQLite. The nineties had a lot of servers which were very simple (and performant) compared to LAMP, and I like systems like that.

What I would like is a good primer about the layers on top of SQLite. What does Litestream do for me? How does it compare to competitors? Why not just use SQLite directly? A more in-depth technical discussion would be nice. I'd also like to understand wrappers and ORMs for migration to other systems, should SQLite stop scaling.

Post reply on HN