I’m a bit new to dgraph. I had the same windows/memory issues which brought me here. I just wanted to add some thoughts.
My team is working on an electron/react based app (so highly portable by design) and we are trying to find a fitting backend which does not reduce our portability options. We already started a backend in go with prisma/sqlite which is already really nice and also highly portable. But getting all the graphql queries without writing code with dgraph would be a huge thing for us.
So I gave dgraph a try. I was running it on windows and I also had these strange memory issues.
Maybe this “it’s broken on windows” thing and your openly admitted neglect of windows support in general somehow relates to your poor perceived interest from windows users? I personally despise windows, but you know what? All our clients use it. Linux on desktop is a myth, so we have to build software for windows. From what I read, dgraph is intended for large-scale, multiserver environments exclusively and not so much for our intended embedded-like use-case. This is really sad because it would fit incredibly good as a persistence layer that we can ship with our software. Seeing the posts above it’s clear that I am not the first with this seemingly unusual idea.
Here is another point: @maaft mentioned something about server synchronisation which we also want to to do in the near future, but probably within our application layer. I imagine this should be pretty easy to do when you can use the same graphql client and the same data types to access the local “embedded” dgraph and the central server.
So please at least be honest on the download page about the usability of the windows port. Or even better: fix it! I have’t tried macOS yet, is it any better there? And some more unsolicited advice: please do not scare away early adopters who explore potential new use cases you might not have thought of yet. Sooner or later someone will do the strangest things with your software and this may be a good thing 