about
Gathering some info on SQLite usage on servers.
My use-case is single-instance servers and non/rarely-communicating nodes. Once you introduce frequent internode network calls - you may as well just go full Postgres instead of re-implementing it. Single-node systems are nonetheless very appealing and here I'll be collecting some relevant info for such use-cases.
https://news.ycombinator.com/item?id=26445688
Hey, lead of Debezium here, a change data capture tool for a number of databases (not SQLite, though). Out of curiousity, how are you implementing change ingestion, is there some interface/API in SQLite which lets you do this? Or are you manually parsing its log files?
https://news.ycombinator.com/item?id=26447995
Hi Gunnar, good to meet you. Litestream works by reading off the SQLite WAL file which acts as a circular buffer. It takes over the checkpointing process to control when the buffer rolls over so it doesn't miss any frames. Those frames get copied over and each buffer is recreated as a sequential set of WAL files that can be replayed to reconstruct the state of the database at a given point-in-time.
It sounds like Litestream differs from Debezium in that it provides physical replication rather than logical row changes. However, I've been toying with the idea of determining row-level changes from the WAL frames by using ptrmap pages to traverse up the b-tree and determine the owner table. There's a bunch of stuff on the roadmap before that like live read replication though.
There's some additional info on the site about how Litestream works1 and I'm planning on making a video similar to this Raft visualization2 I did a while back.
https://news.ycombinator.com/item?id=26447045:
How does Litstream actually works? Do you read from WAL and then sync with S3?
https://news.ycombinator.com/item?id=26447917
Yes, it reads off the WAL then compresses the frames using LZ4 and then uploads to S3. The SQLite WAL acts as a circular buffer so Litestream takes over the checkpointing process to control when it rolls over so it can recreate that buffer as separate files. There's additional information on the web site: https://litestream.io/how-it-works/
SQLite fork.
SQLite re-write in Rust. WIP.