database/sql adds some overhead; in return, it gives you a connection pool, and tries not to have you worry about connections. A lot of the interesting feature

database/sql adds some overhead; in return, it gives you a connection pool, and tries not to have you worry about connections. A lot of the interesting features of SQLite are connection oriented, and compared to other databases, connections are cheap (because it's all local). So the things database/sql offers are (relatively) less valuable, and it makes other things harder. Yet (IMO) connection pools still offer some performance benefits, not having to worry about (re)preparing statements on new connections is still helpful, and many of the connection oriented things you might want to do can be exposed through database/sql with some imagination. I have a lot of respect for crawshaw and zombiezen; I started from their PoV. But I've since come around to database/sql. A lot of what is mentioned in [1] has been fixed in database/sql or can be fixed in drivers: parameter names now work in database/sql; their approach to statement caching isn't necessarily better, but can be added to a driver, or live in a compatible framework; panics vs. errors is contentious; savepoints can be made to work just fine [2]; and for contexts, I started with crawshaw and built an improved version of it into my driver, that is both low overhead, interacts well with the Go scheduler, and doesn't start additional goroutines. Living in database/sql land gives you access to other amazing tooling like SQLC, just to name a single one. And it doesn't need to be either/or: drivers should support both high and low level APIs. [1]: https://crawshaw.io/blog/go-and-sqlite https://crawshaw.io/blog/go-and-sqlite [2]: https://pkg.go.dev/github.com/ncruces/go-sqlite3/driver#example-Savepoint https://pkg.go.dev/github.com/ncruces/go-sqlite3/driver#exam...