cannadayr
Remote: Yes
Willing to relocate: Maybe
Technologies: BQN, Erlang, C
Résumé/CV: email me
Email: my username at gmail dot com
Remote: Yes
Willing to relocate: No
Technologies: PHP, Bash, SQL, Javascript, Apache2, MariaDB, Postfix, Bind9, OpenVPN, Varnish, Debian, FreeBSD
Résumé/CV: https://github.com/cannadayr/resume/blob/master/resume.pdf
Email: [email protected]
Basically, git-sqlite already supports merges (see link above)
I don't have stress test results, but it should be similar to git. I think I remember getting it up to several hundred megabytes at one point and it was fine. I mostly use it for smaller sets of highly relational data that I want to track like I would source code.
By leveraging git & sqlite it lets me avoid writing a network sync implementation, architecture specific code, or patching any C code to recompile.
https://github.com/cannadayr/git-sqlite
Instead of storing the transactions as a separate lmdb commit, I decided to store the database in a git repository and expose the diffs using sqlite's sqldiff utility. This allowed my workflow to be almost unchanged and limits the dependencies to git, sqlite, sqldiff, & bash.
I have found it to be extremely useful for certain problems.