4 ms·

Are people still trying to shoehorn sqlite to run in a server-side context? I thought that was a fad that everyone gave up on.

by petcat 11mo ago

ashish01 11mo ago
I use Litestream for near real-time backups. Does not change how SQLite is used on the server, just a replacement for .backup
mhitza 11mo ago
No, it's still pretty cool, easy to use with low operational complexity in low volume read-mostly projects: CMSs, blogs, ecommerce platforms.
- deleted 11mo ago
  [deleted]
- andersmurphy 11mo ago
  It's got crazy write throughput too if you hold it right.
jtbayly 11mo ago
I am. Super simple. Super cheap. Great dev experience. Want to know whether the migration is going to work? Just download the prod db locally and test it. I'm happy.
- christophilus 11mo ago
  Works for very small prod databases, I guess.
  - tptacek 11mo ago
    We use it internally for some rather large databases. It's not database size that matters, it's usage pattern.
  - andersmurphy 11mo ago
    Handles billions of rows just fine. Can take you unreasonably far on a single server.
  - victorbjorklund 11mo ago
    What is a very small database? At what size do you think read queries stops working in SQLite?
9rx 11mo ago
People are building DBMSes and, instead of writing the engine from scratch, are choosing an off-the-shelf solution that integrates into a DBMS with ease. A better question to ask is why the world needs yet another DBMS, but the reasons are no doubt valid.
jauntywundrkind 11mo ago
For things like config management I feel like it makes all the sense in the world. Whomever the primary is can soak some infrequent-ish write-load. Then the whole DB can quickly copy to where it's needed, or, in lite stream VFS 's case, even less needs to be shipped.
0xbadcafebee 11mo ago
I am a heavy skeptic of this thing, but I can see a good use case for it: S3 I/O, ephemeral compute (1 instance), versioned blobs. The first two allow you to abstract the data away from the compute (flexibility), and the third lets you recover from mistakes or bugs quicker (or do immutable migrations easier). I think the devil's in the details though. I expect a high number of unusual bugs due to the novel code, networking, and multiple abstractions. I'd need to trial it for a year before I called it reliable.
andersmurphy 11mo ago
Nope, still going strong. https://news.ycombinator.com/item?id=46124205 https://news.ycombinator.com/item?id=46124205

Are people still trying to shoehorn sqlite to run in a server-side context? I thought that was a fad that everyone gave up on.

by petcat 11mo ago

Are people still trying to shoehorn sqlite to run in a server-side context? I thought that was a fad that everyone gave up on.

ashish01 11mo ago

I use Litestream for near real-time backups. Does not change how SQLite is used on the server, just a replacement for .backup

mhitza 11mo ago

No, it's still pretty cool, easy to use with low operational complexity in low volume read-mostly projects: CMSs, blogs, ecommerce platforms.

deleted 11mo ago
[deleted]
andersmurphy 11mo ago
It's got crazy write throughput too if you hold it right.

jtbayly 11mo ago

I am. Super simple. Super cheap. Great dev experience. Want to know whether the migration is going to work? Just download the prod db locally and test it. I'm happy.

christophilus 11mo ago
Works for very small prod databases, I guess.
- tptacek 11mo ago
  We use it internally for some rather large databases. It's not database size that matters, it's usage pattern.
- andersmurphy 11mo ago
  Handles billions of rows just fine. Can take you unreasonably far on a single server.
- victorbjorklund 11mo ago
  What is a very small database? At what size do you think read queries stops working in SQLite?

9rx 11mo ago

People are building DBMSes and, instead of writing the engine from scratch, are choosing an off-the-shelf solution that integrates into a DBMS with ease. A better question to ask is why the world needs yet another DBMS, but the reasons are no doubt valid.

jauntywundrkind 11mo ago

For things like config management I feel like it makes all the sense in the world. Whomever the primary is can soak some infrequent-ish write-load. Then the whole DB can quickly copy to where it's needed, or, in lite stream VFS 's case, even less needs to be shipped.

0xbadcafebee 11mo ago

I am a heavy skeptic of this thing, but I can see a good use case for it: S3 I/O, ephemeral compute (1 instance), versioned blobs. The first two allow you to abstract the data away from the compute (flexibility), and the third lets you recover from mistakes or bugs quicker (or do immutable migrations easier). I think the devil's in the details though. I expect a high number of unusual bugs due to the novel code, networking, and multiple abstractions. I'd need to trial it for a year before I called it reliable.

andersmurphy 11mo ago

Nope, still going strong. https://news.ycombinator.com/item?id=46124205 https://news.ycombinator.com/item?id=46124205