dqlite VS boringproxy

I'd be curious for a similar tuning with Dqlite: https://github.com/canonical/dqlite

Anyone knows how the DB this is about, https://rqlite.io/, compares with https://dqlite.io/ by Canonical (both seem to be distributed versions of sqlite)?

For folks' context, the new tool that's being discussed in the thread mentioned by the parent here is litefs [0], as well as which you can also look at rqlite [1] and dqlite [2], which all provide different trade-offs (e.g. rqlite is 'more strongly consistent' than litefs).

[0]: https://github.com/superfly/litefs

[1]: https://github.com/rqlite/rqlite

[2]: https://github.com/canonical/dqlite

I presume you're familiar with https://github.com/canonical/dqlite (made by my employer) and https://github.com/rqlite/rqlite (unrelated)? How will mvsqlite compare to those?

Check out dqlite, it's sqlite but with a raft consensus to distribute changes through a log: https://dqlite.io/ You can link it in as a library too, it sounds like exactly what you want.

https://dqlite.io/

I’m sure there’s more, those are just the ones I remember.

Finally, someone in the above project's Matrix room directed me towards boringproxy - https://github.com/boringproxy/boringproxy. This was the perfect solution. No lengthy config files, easy to use and automate. Setup took about an hour and now everything is back up and running. The only issue I've currently not been able to solve is one where the container seems to use a websocket, which keeps getting timed out (will investigate this further tomorrow).

boringproxy (GitHub) is my go-to for this sort of thing. Thanks for the announcement, I'll have to do a head-to-head and see how they stack up!

Am I the only one who thinks SQLite is still too complicated for many programs? Maybe it's just the particular type of software I normally work on, which tends towards small, self-hosted networking services[0] that would often have a single user, or maybe federated with <100 users. These programs need a small amount of state for things like tokens, users accounts, and maybe a bit of domain-specific things. This can all live in memory, but needs to be persisted to disk on writes. I've reached for SQLite several times, and always come back to just keeping a struct of hashmaps[1] in memory and dumping JSON to disk. It's worked great for my needs.

Now obviously if I wanted to scale up, at some point you would have too many users to fit in memory. But do programs at that scale actually need to exist? Why can't everyone be on a federated server with state that fits in memory/JSON? I guess that's more of a philosophical question about big tech. But I think it's interesting that most of our tech stack choices are driven by projects designed to work at a scale most of us will never need, and maybe nobody needs.

[0]: https://boringproxy.io/

[1]: https://github.com/boringproxy/boringproxy/blob/master/datab...

Hi, so I'm trying to build a project using Docker: (https://github.com/boringproxy/boringproxy) but I can't get it to run because I get this error: root@ubuntu:~/boringproxy# docker-compose up Recreating boringproxy_boringproxy_1 ... done Attaching to boringproxy_boringproxy_1 boringproxy_1 | standard_init_linux.go:219: exec user process caused: exec format error boringproxy_boringproxy_1 exited with code 1 Everything seems to build fine but it just won't execute on docker-compose up. I know the error above is an architectural issue, e.g. building an arm64 image and running it on amd64 but I can't work out why it's building for another arch. I was looking around and commit ada81bae62 actually worked for me, but obviously it doesn't have the most up-to date source code. I did browse the files in the commit and I can't see any changes that absolutely jump out at me; I have no experience of Docker and I've used several different distributions and architectures (arm64, amd64 etc) but nothing works. If someone with even slightly more experience with Docker could have a look at this, I'd appreciate it!

This is the commit that seems to have broken the docker image.