ncruces
commented
2 weeks ago Just FYI, I just updated my fork with my results, which don't exactly match @cvilsmeier's. It's a manual process, that's why it's infrequent.
A regression in my driver is expected. The introduction of WAL mode in v0.14.0 forced memory to be allocated differently, and this negatively impacts performance for non-WAL mode as measured here.
This happens for fresh connections only. A long lived connection eventually reaches a steady state and doesn't need to mmap memory anymore (pooling connections helps).
If you look at my fork you'll see that yes: there's a performance benefit of forgoing database/sql.
But this is a benchmark, the real world is likely more nuanced: connection pooling helps; long-lived prepared statements that are automatically re-prepared on new connections help; and API cross compatibility has benefits as well.
PS: https://github.com/ncruces/go-sqlite3/commit/2d168136f157c9eb7b40d68660f1df7492d91c89 should close the gap even further, and win back some performance over latest release.
Accessing a database through a database/sql driver can bring significant performance overhead compared to SQLite libraries that forego the abstraction (the same holds true for other database types).
In the benchmarks, a number of libraries don't use database/sql. It would be good to call that out more explicitly in the results, and perhaps group the benchmark results accordingly.
For the ncruces/go-sqlite3 module, there's the ability to use it both directly and through the database/sql driver. It would be nice to have benchmarks for both, as that could also be used to show the overhead of database/sql for that particular module.