buntdb
go-sqlite3
Our great sponsors
buntdb | go-sqlite3 | |
---|---|---|
7 | 39 | |
4,381 | 7,446 | |
- | - | |
0.0 | 6.3 | |
25 days ago | 7 days ago | |
Go | C | |
MIT License | MIT License |
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.
buntdb
-
PostgreSQL: No More Vacuum, No More Bloat
Experimental format to help readability of a long rant:
1.
According to the OP, there's a "terrifying tale of VACUUM in PostgreSQL," dating back to "a historical artifact that traces its roots back to the Berkeley Postgres project." (1986?)
2.
Maybe the whole idea of "use X, it has been battle-tested for [TIME], is robust, all the bugs have been and keep being fixed," etc., should not really be that attractive or realistic for at least a large subset of projects.
3.
In the case of Postgres, on top of piles of "historic code" and cruft, there's the fact that each user of Postgres installs and runs a huge software artifact with hundreds or even thousands of features and dependencies, of which every particular user may only use a tiny subset.
4.
In Kleppmann's DDOA [1], after explaining why the declarative SQL language is "better," he writes: "in databases, declarative query languages like SQL turned out to be much better than imperative query APIs." I find this footnote to the paragraph a bit ironic: "IMS and CODASYL both used imperative query APIs. Applications typically used COBOL code to iterate over records in the database, one record at a time." So, SQL was better than CODASYL and COBOL in a number of ways... big surprise?
Postgres' own PL/pgSQL [2] is a language that (I imagine) most people would rather NOT use: hence a bunch of alternatives, including PL/v8, on its own a huge mass of additional complexity. SQL is definitely "COBOLESQUE" itself.
5.
Could we come up with something more minimal than SQL and looking less like COBOL? (Hopefully also getting rid of ORMs in the process). Also, I have found inspiring to see some people creating databases for themselves. Perhaps not a bad idea for small applications? For instance, I found BuntDB [3], which the developer seems to be using to run his own business [4]. Also, HYTRADBOI? :-) [5].
6.
A usual objection to use anything other than a stablished relational DB is "creating a database is too difficult for the average programmer." How about debugging PostgreSQL issues, developing new storage engines for it, or even building expertise on how to set up the instances properly and keep it alive and performant? Is that easier?
I personally feel more capable of implementing a small, well-tested, problem-specific, small implementation of a B-Tree than learning how to develop Postgres extensions, become an expert in its configuration and internals, or debug its many issues.
Another common opinion is "SQL is easy to use for non-programmers." But every person that knows SQL had to learn it somehow. I'm 100% confident that anyone able to learn SQL should be able to learn a simple, domain-specific, programming language designed for querying DBs. And how many of these people that are not able to program imperatively would be able to read a SQL EXPLAIN output and fix deficient queries? If they can, that supports even more the idea that they should be able to learn something different than SQL.
----
1: https://dataintensive.net/
2: https://www.postgresql.org/docs/7.3/plpgsql-examples.html
3: https://github.com/tidwall/buntdb
4: https://tile38.com/
5: https://www.hytradboi.com/
-
Is there a nice embedded json db, like PoloDB (Rust) for Golang
https://github.com/tidwall/buntdb -> i think this one you might want
-
Open Source Databases in Go
buntdb - Fast, embeddable, in-memory key/value database for Go with custom indexing and spatial support.
-
Alternative to MongoDB?
BuntDB for NoSQL
-
Path hints for B-trees can bring a performance increase of 150% – 300%
BuntDB [0] from @tidwall uses this package as a backing data structure. And BuntDB is in turn used by Tile38 [1]
[0] https://github.com/tidwall/buntdb
- The start of my journey learning Go. Any tips/suggestions would greatly appreciated!
-
In-memory caching solutions
I've used BuntDB and had a great experience with it. It's basically just a JSON-based key-value store. I'm a huge fan of the developers other work (sjson, gjson, jj, etc) and stumbled on it while looking for a simple, embedded DB solution. It's not specifically a cache, though--just a simple DB, so you'd have to write the caching logic yourself.
go-sqlite3
-
Redis Re-Implemented with SQLite
for what it's worth, the two pool approach is suggested here by a collaborator to github.com/mattn/go-sqlite3: https://github.com/mattn/go-sqlite3/issues/1179#issuecomment...
-
Replacing Complicated Hashmaps with SQLite
SQLite is great. I've also recently settled on it as a key-value store, after considering a few purpose-built key-value solutions. Turns out that it's really easy to make SQLite work as a key-value store, but very difficult to make key-value stores relational.
Just be careful with `:memory:` databases. From the mattn/go-sqlite3 FAQ[1]:
> Each connection to ":memory:" opens a brand new in-memory sql database, so if the stdlib's sql engine happens to open another connection and you've only specified ":memory:", that connection will see a brand new database. A workaround is to use "file::memory:?cache=shared" (or "file:foobar?mode=memory&cache=shared"). Every connection to this string will point to the same in-memory database.
I noticed strange behaviors with just `:memory:` where tables would just disappear at random, and this workaround helped. Make sure to use a unique filename as the `file:` value, especially if using this in tests.
[1]: https://github.com/mattn/go-sqlite3#faq
-
What 3rd-party libraries do you use often/all the time?
github.com/mattn/go-sqlite3
-
From Golang Beginner to Building Basic Web Server in 4 Days!
For building my web server, I chose to use the Gin framework as the foundation of my app. It was incredibly easy to understand and work with, and I was pleasantly surprised by how seamlessly it integrated with writing unit tests for the server. To handle the database, I leveraged the power of go-sqlite and migrate for efficient SQL queries and migrations. These libraries proved to be both powerful and user-friendly, making the development process a breeze.
-
Zig now has built-in HTTP server and client in std
https://github.com/mattn/go-sqlite3/blob/master/_example/sim...
-
Exciting SQLite Improvements Since 2020
SQLite does have an optional "user authentication" extension, though I've not personally tried it out:
https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth....
The widely used Go SQLite library by mattn says it supports it, if that's useful:
https://github.com/mattn/go-sqlite3#user-authentication
-
Go port of SQLite without CGo
I have an OSS project, sq which is a data-wrangling swiss-army knife for structured data. Think of it as jq for databases. It supports Postgres, SQLServer, MySQL and - relevantly - SQLite. It embeds SQLite via CGo and the mattn/go-sqlite3 driver.
- In-memory key value store
-
Tools besides Go for a newbie
IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here
- GitHub - elgs/gosqlapi: Turns any SQL database into a RESTful API.
What are some alternatives?
bolt
GORM - The fantastic ORM library for Golang, aims to be developer friendly
badger - Fast key-value DB in Go.
sqlx - general purpose extensions to golang's database/sql
nutsdb - A simple, fast, embeddable, persistent key/value store written in pure Go. It supports fully serializable transactions and many data structures such as list, set, sorted set.
pgx - PostgreSQL driver and toolkit for Go
go-memdb - Golang in-memory database built on immutable radix trees
go-sqlite - Low-level Go interface to SQLite 3
goleveldb - LevelDB key/value database in Go.
go-sqlite-lite - SQLite driver for the Go programming language
ledisdb - A high performance NoSQL Database Server powered by Go
Sqinn-Go - Golang SQLite without cgo