What does HackerNews think of bolt?

I mean, not really. The hard work was done by benbjohnson who is now working on https://litestream.io/ and https://fly.io/

He's the one who wrote BoltDB https://github.com/boltdb/bolt

I just put a relatively thin layer on top of it.

Now, to address your point more directly: I'm too stupid to figure out configuration, but not too stupid to figure out code. Code gets compiled and type checked. You can have tests, etc. Tractability for code is much higher than configuration.

With configuration, you have to be really smart and keep many moving parts in your head.

With code, you can be a bit dumb and lean heavily on the tooling.

The litestream project was created by https://github.com/benbjohnson who wrote https://github.com/boltdb/bolt (a key value store) which has been instrumental (from my point of view) in the Go community as one of the original choices for an embedded database as it was not only fast, but had transactions with stable snapshots.

It was used by https://github.com/blevesearch/bleve, https://github.com/etcd-io/etcd, and number of other projects.

These days, https://github.com/dgraph-io/badger is often favored because of it's improved write throughput.

For a single server, SQLite, or boltdb[0]

I've never had to scale horizontally. I develop in Go and you can get very far along with just vertical scaling (aka beefier hardware).

Therefore I can't give concrete examples of a distributed db-as-a-library.

But all that you need is to extend the functions that fetch data to not just fetch from disk but from "peers" as well. For this to work you need servers (instances) to know about each other, and as you add more they also get added to their peers - sort of like a bittorrent network. I don't think it's difficult to do.

SQLite might not be suited for being distributed (although RQlite[1] claims to have done it).

Making a distributed data storage based on boltdb[0] is probably more feasible.

Whatever the case, there's no reason why a data storage engine can't be a library, even if it's distributed.

[0]: https://github.com/boltdb/bolt

[1]: https://github.com/rqlite/rqlite

Check out this: https://github.com/boltdb/bolt

Always been considered a good example to study.

Yes, Ben Johnson's (https://github.com/benbjohnson) presentation on Raft is great. He is also the creator of BoltDB (https://github.com/boltdb/bolt) which is a core component of Hashiscorp's Raft implementation (https://github.com/hashicorp/raft).

Does it need to be relational? Perhaps boltdb could do it

https://github.com/boltdb/bolt

I was wondering too, but Badger doesn't offer transactions and stuff like that (on purpose). It seems to be more low-level in some regards.

https://github.com/boltdb/bolt

There are a plenty of in-process 'databases' for Go starting from a simple built-in map and ending with something like https://github.com/boltdb/bolt or even https://github.com/hashicorp/go-memdb .

Not including an ORM layer does not decrease "value" of this framework, because you can attach such lib on your own. In Go the you are very flexible to set up a "a place where data will be stored/queried" - there is fabulous database/sql (or additional layers like lib/pq [1]) which is great for many use cases; also orm-like solutions like gocraft/dbr [2]; oh, I also should mention Gorm [3] or Bolt [4]. Setting them up is really easy in any Go web frameworks because (almost) all database modules rely on abstraction from stdlib.

[1] https://github.com/lib/pq

[2] https://github.com/gocraft/dbr

[3] https://github.com/jinzhu/gorm

[4] https://github.com/boltdb/bolt

thats interesting! since Consul / Serf are written in Go.. have you considered using boltdb? https://github.com/boltdb/bolt it's an LMDB implementation in Go, really clean code.