Live data from Hacker News

Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

github.com

11–20 of 55 posts

Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

#12

What are your thoughts on eviction, re how easy to add some basic policy?

Also it’s super easy to add them, it’s definitely on the roadmap. The manifest tracks the data locally and could quickly evict on any operation that accesses it. Very safe post-checkpoint

Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

#13
This 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).

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

#15
i 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

#16
Sub 250ms for cold queries from S3 is impressive, but curious about the consistency of those numbers. Are you doing any prefetching of table schemas or statistics? With geographic datasets we often see huge variance in S3 latency depending on object size and region - a 10Mb spatial index file might take 400ms to fetch while smaller lookup tables stay under 100ms.

Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

#17
post #15

i 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?

im also curious. GCS also charges per GET request

Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

#18

You 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…

Both of those roadmap items make sense! Excited to see how you evolve this project!

Re: Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

#19
post #13

This 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)…

[flagged]
Post reply on HN