gogm VS dgraph

Has anybody used golang and neo4j together with a data model bigger than a few small nodes and relationships? I have 45 node types that can have varying numbers of up to 48 relationship types all modeled as structs that I want to be able to store and manipulate with neo4j. The main golang neo4j driver requires translation of data directly into cypher query, which with this many nodes / relationships would require me to create a massive translation wrapper. I looked at gogm (https://github.com/mindstand/gogm) but it doesn't seem mature enough for my use (please let me know if you have any reviews of it). To avoid having to write a large wrapper I figured I could probably store the data in mongodb or elastic and then use their neo4j connector plugins to auto-propagate data to neo4j - this would be a fine solution but I'd rather avoid adding a secondary database technology if I can.

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.