I benchmarked six Go SQLite drivers
github.com
I benchmarked six Go SQLite drivers
1–10 of 64 posts
Re: I benchmarked six Go SQLite drivers
#2I hadn't heard of sqinn before. According to these benchmarks it beats Cgo-based solutions most of the time, which makes it a very interesting candidate. Anyone have real-world experience using it?
Re: I benchmarked six Go SQLite drivers
#3Thanks for creating the benchmarks, I hadn't heard of most of those libs.
I seem to remember that modernc worked great until i added a FTS5 [1] table and things became very slow. This was a while ago now, so it may have changed or I may mave misattributed the slowness to the non-CGO implementation.
I'd be curious to see how each performs with a fts index and some triggers.
Re: I benchmarked six Go SQLite drivers
#4I hadn't heard of sqinn before. According to these benchmarks it beats Cgo-based solutions most of the time, which makes it a very interesting candidate. Anyone have real-world experience using it?
(Sqinn is made by the same guy that made these benchmarks in case you didn't realize)
Re: I benchmarked six Go SQLite drivers
#5What a curious state, there is just one jdbc (=java) driver for SQLite. Why are there 6 (or more!) for Go?
Re: I benchmarked six Go SQLite drivers
#6I've done some variations of this as well recently. For inserts: https://github.com/eatonphil/databases-intuition/blob/main/R.... And for selects: https://github.com/eatonphil/databases-intuition/blob/main/R....
Our workloads are a bit different and obviously our machines are a bit different.
Mine only compares mattn/go-sqlite3 to my own fork of https://github.com/bvinc/go-sqlite-lite. go-sqlite-lite seemed like an easier-to-use version of crawshaw's package but it was abandoned so I forked it to bring it up to date.
I agree, for best performance you shouldn't use mattn/go-sqlite3. It does some extra work in hotpaths. It is also higher level and easier to use though. So pick what's important to you.
Re: I benchmarked six Go SQLite drivers
#7I hadn't heard of sqinn before. According to these benchmarks it beats Cgo-based solutions most of the time, which makes it a very interesting candidate. Anyone have real-world experience using it?
Sqinn author here. Yes, sqinn performs quite well compared to the 'standard' mattn driver. The only use case it clearly breaks down is when SELECTing very large (gigabytes) resultsets.
Re: I benchmarked six Go SQLite drivers
#8What a curious state, there is just one jdbc (=java) driver for SQLite. Why are there 6 (or more!) for Go?
Maybe because Go devs are more allergic to 'non-Go' solutions that Java devs are to 'non-Java' solutions? (Explain: Java's xerial driver is a DLL/SO wrapped in a Java library)
Re: I benchmarked six Go SQLite drivers
#9What a curious state, there is just one jdbc (=java) driver for SQLite. Why are there 6 (or more!) for Go?
If you search "topic:jdbc topic:sqlite" on GitHub [0] (and look closely, since most results are not relevant) you'll see there are more than one (e.g. [1]). xerial may be the defacto SQLite driver for Java. mattn/go-sqlite3 is the defacto SQLite driver for Go. But there are other options.
[0] https://github.com/search?q=topic%3Ajdbc%20topic%3Asqlite&ty...
Re: I benchmarked six Go SQLite drivers
#10"without cgo" benchmarks should probably have comparisons for stuff like indexing too, since that's no longer in the shared C library that every other library uses - I would generally expect them to be slower here. And interop with Go code for custom funcs, since sqlite makes that so easy, where I'd expect them to be faster in at least some cases (no repeated cgo overhead).
"Complex" kinda covers this, since there are foreign keys involved, and it's also where e.g. Zombie shows an uncharacteristic slowdown compared to the other benchmarks. Seems like it's probably not a coincidence?