Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
11–20 of 55 posts
Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#12What are your thoughts on eviction, re how easy to add some basic policy?
Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#13I do wonder - for projects that do ultimately enforce single writer sqlite setups - it still feels to me as if it would always be better to keep the sqlite db local (and then rsync/stream backups to whatever S3 storage one prefers).
The nut I've yet to see anyone crack on such setup is to figure out a way to achieve zero downtime deploys. For instance, adding a persistent disk to VMs on Render prevents zero downtime deploys (see https://render.com/docs/disks#disk-limitations-and-considera...) which is a real unfortunate side effect. I understand that the reason for this is because a VM instance is attached to the volume and needs to be swapped with the new version of said instance...
There are so many applications where merely scaling up a single VM as your product grows simplifies devops / product maintenance so much that it's a very compelling choice vs managing a cluster/separate db server. But getting forced downtime between releases to achieve that isn't acceptable in a lot of cases.
Not sure if it's truly a cheaply solvable problem. One potential option is to use a tool like turbolite as a parallel data store and, only during deployments, use it to keep the application running for the 10 to 60 seconds during a release swap. During this time, writes to the db are slower than usual but entirely online. And then, when your new release is live, it can sync the difference of data written to s3 back to the local db. In this way, during regular operation, we get the performance of local IO and fallback onto s3 backed sqlite during upgrades for persistent uptime.
Sounds like a fraught thing to build. But man it really is hard/impossible to beat the speed of local reads!
Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#14https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3...
https://docs.aws.amazon.com/AmazonS3/latest/userguide/condit...
Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#15Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#16Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#17i wonder how much that costs per hour to run any normal load? what benefit does this have versuss using mysql (or any similar rdbms) for the queries? mysql/pgsql/etc is free remember, so using S3 obviously charges by the request, or am i wrong?
Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#18You might be interested in taking a look at Graft ( https://graft.rs/ ). I have been iterating in this space for the last year, and have learned a lot about it. Graft has a slightly different set of goals, one of which is to keep writes fast and small and optimize for partial replication. That said, Graft shares several design decisions, including the use of framed ZStd compression to store pages. I do like the B-tre…
Very cool, thanks. I hadn’t seen Graft before, but that sounds pretty adjacent in a lot of interesting ways. I looked at the repo and see what I can apply. I've tried out all sorts of optimizations - for free pages, I've considered leaving empty space in each S3 object and serving those as free pages to get efficient writes without shuffling pages too much. My current bias has been to over-store a little if it keeps…
Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3
#19This is awesome! With all of the projects/teams working on improving sqlite, it feels like it's just a matter of time before it becomes a better default than postgres for serious projects. I do wonder - for projects that do ultimately enforce single writer sqlite setups - it still feels to me as if it would always be better to keep the sqlite db local (and then rsync/stream backups to whatever S3 storage one prefers)…