Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libc
-
Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go
I don't think I understand what the argument for that is, because I've only ever heard it articulated as "cgo isn't go" which doesn't really convey much information.
Is this go? https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go?...
I mean technically I suppose it is code that conforms to the go language grammar, but I'm not sure why a language purist would accept this.
- Go port of SQLite without CGo
-
SQLite in Go, with and without cgo
Maybe you can contribute a fix? The related discussion is here: https://gitlab.com/cznic/libc/-/issues/20
ctlstore
-
SQLedge: Replicate Postgres to SQLite on the Edge
We replicated our MySQL database to a SQLite edge at Segment in ctlstore: https://github.com/segmentio/ctlstore
We considered tailing binlogs directly but there's so much cruft and complexity involved trying to translate between types and such at that end, once you even just get passed properly parsing the binlogs and maintaining the replication connection. Then you have to deal with schema management across both systems too. Similar sets of problems using PostgreSQL as a source of truth.
In the end we decided just to wrap the whole thing up and abstract away the schema with a common set of types and a limited set of read APIs. Biggest missing piece I regret not getting in was support for secondary indexes.
-
Sharing an SQLite database across containers is surprisingly brilliant
> it is only practical for situations where the write rate (<100/s total) and data volumes (<10GB total) are low.
This comment from the GitHub project page is pretty important. Configuration data often sees slow change, and isn't huge so a custom approach seems viable. I wonder how close they are to that 100/s ceiling.
There's also an unmentioned transition to eventual consistency happening here:
> The implications of this decoupling is that the data at each instance is usually slightly out-of-date (by 1-2 seconds).
> The reader API provides a way to fetch an approximate staleness measurement that is accurate to within ~5 seconds.
That's could lead to more complex application logic or risk of confusing users with stale behavior. No free lunch here.
[1] https://segment.com/blog/separating-our-data-and-control-pla...
[2] https://github.com/segmentio/ctlstore
-
Go port of SQLite without CGo
at segment we benchmarked https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read performance, so we didn't move forward with it, but the improvements in service build times were really appealing.
What are some alternatives?
sqlite
go-sqlite - pure-Go SQLite driver for Go (SQLite embedded)
go-sqlite3 - Go bindings to SQLite using wazero
homebrew-musl-cross - Homebrew Formula for static-friendly musl-based GCC macOS-to-Linux cross-compilers
sysroot - Files for cross-compilation
purego
sqlite - The pure-Go SQLite driver for GORM
sqledge - Replicate postgres to SQLite on the edge
go-sqlite-bench - Benchmarks for Golang SQLite Drivers