nutsdb VS dgraph

if you're looking for something simpler/embedded, NutsDB is pretty good.

The best example I can give you is https://github.com/nutsdb/nutsdb it’s great project that got me started, one thing one should know is Go is different “yep” so there’re some coding habits that may bite you in Go and the Go compiler won’t correct you, you wanna learn about optimizations, unsafe usage check out https://github.com/valyala/fasthttp (note this is deep the rabbit hole), wanna learn concurrency check out ants https://github.com/panjf2000/ants with a little aid from “Go by example” you’re good to go

NutsDB v0.9.0 release detail : https://github.com/nutsdb/nutsdb/issues/167

See https://github.com/xujiajun/nutsdb for detail.

Dgraph: A distributed and scalable graph database known for high performance. It's a good fit for large-scale graph processing, offering a GraphQL-like query language and gRPC API support.

Dgraph (GraphQL, DQL)

Have you tried dgraph.io?

DGraph – A distributed GraphQL database with a graph backend.

How does it compare to, say grakn (renamed https://vaticle.com/, I think?), or draph (https://dgraph.io/), or Ontotext's GraphDB (https://www.ontotext.com/products/graphdb/), or Datomic?

Consul Connect service mesh has a higher memory footprint, so on a small cluster with e5-medium nodes (2 vCPUs, 4 GB memory), you will only be able to support a maximum of 6 side-car proxies. In order to get an application like Dgraph working, which will have 6 nodes (3 Dgraph Alpha pods and 3 Dgraph Zero pods) for high availability along with at least one client, a larger footprint with more robust Kubernetes worker nodes were required.