Since Envoy will always depend on libc, it seems reasonable for IO to also.
Originally IO used a version of SQLite that was translated into Go and then compiled as Go code. This allowed SQLite to be used without CGO, which allowed IO to be run in lightweight Alpine containers which include musl instead of libc.
But since IO is used alongside Envoy, this benefit is moot. Envoy depends on libc and the project has no interest in supporting musl. Since Envoy will always depend on libc, it seems reasonable for IO to also.
Pros
- This allows IO to directly use the C SQLite (possibly via the crawshaw/sqlite driver) and reduces compatibility risks and performance overhead of the Go reimplementation.
Cons
- With this, IO won’t be usable in Alpine containers.
