Current and Future State of Windows Support

I changed the title because the discussion drifted to far away from the original topic.

During the discussion it was noticed that there are no real plans to extend support for windows. This was quite suprising for me and other users as the download page gives the assumption that windows and macOS are fully supported.


I’ve noticed that the RAM usage on windows is quite high. Dgraph Alpha and Zero are using 3.5 GB.
Are there any options to reduce RAM usage? Performance is not a concern.

Edit: It seems that the RAM usage shoots up and eats my whole memory. But only when I post a new schema. After posting the schema, the RAM usage gets lower to the ~3.5 GB (I guess go-garbage collector at work?)

When I restart dgraph, the usage is at a stable 129MB (which is the roughly the size of my cache set with --cache_mb 128.

FYI: I used the “fix” described in Dgraph takes all disk space in windows

1 Like

We do not recommend using Windows on production. Just learning or testing.
Some RAM issues still exist in Windows cuz jemalloc doesn’t work well on Windows. So the windows binary is not build with jemalloc activated.

You can use WSL tho.

Will this change in the future? I really hope so. Sadly, the majority of people are still using windows in production.

WSL is great but customers might not be sophisticated enough to configurate it or they lack admin rights which are required to do that.

It depends. In general, Dgraph is largely used in Unix like systems. Docker and k8s(Linux) are the biggest players.

It could change If we see more and more .NET and Windows related devs coming to Dgraph. I personally never saw a Dgraph user using “Windows Server” to deploy Dgraph. And I think the Windows Devs are a large community. But not so interested in Dgraph so far. I see lots of Windows users in the community(here). But I don’t think they might use Windows in prod. Also, they don’t share their experiences and intentions.

I see, but tell me. What Windows scenarios do you see Dgraph running? I don’t believe in a customer serving Dgraph on a machine with Windows 10 home. Do you use Windows server? Azure?


At a previous employer we primarily used Windows Server 2012 for all systems needs until we decided to build an in-house application and then had to breakdown and buy a server to run Ubuntu Server. Many intranets are comprised completely of Windows devices because of the infrastructure for Active Directory, Remote Storage System, Remote Desktops, and thin clients for users. If I was in this environment again, I would definitely want support for Dgraph with Active Directory ACL. It was a non-profit organization and the company had really discounted licensing and would have no problem deploying more Windows Servers but cringed when we had to deploy a Linux server in an otherwise pure Windows intranet.

So from my POV, Windows support is not really a big factor right now because Dgraph has been for the most part focused on startups which don’t really have a Windows intranet already. But as the enterprise family grows, I definitely see this as being a big issue for organizations who don’t want to use a cloud based service but would rather want an on premise solution in a pure Windows intranet.

Either way, it needs to be clarified on Dgraph’s official Windows support. Either it is only supported for learning and testing and not recommended for production, supported for production, or not supported at all. The downloads page should really make this clear as right now all downloads appear equal across platforms.

There is a quick start guide linked for Docker and Linux, but for Windows it is a download link that just simply downloads the .zip Windows files.

Kubernetes, MacOS, neither have the link to the quick start guide. The Source tab has instructions for compiling from source but make no mention whatsoever about prerequisites of the environment.

I think it is dangerous to make this assumption. IMO. If they are installing Dgraph, most likely they are full system admins and have power to install applications and WSL.

You won’t get more Windows devs coming to Dgraph if they are not supported, simple as that.

The better question to ask is how many Windows devs have came and gone back to Windows SQL Server instead of sticking around and begging for support.

Why be interested in something where you are not welcomed with open arms, but rather told you are not supported.

Hmm… If I was in my previous position and saw a post stating that Windows was not supported for production, why would I bother to share my experience and intentions when it has been clearly stated already that my system is not supported and I need to either use a different database or change my production environment.

Bottom line, I don’t think Windows Devs are gonna stick around to beg for support, they will just go elsewhere or change environments. The later is preferred by Dgraph, but is the former acceptable?


Agree, our @docs team is working on it. We have decided that WSL is the way to go for now. But for sure, companies limitations in user access(administrative functions) can be a problem. In fact, I see this as a bit of a “sign”. If the user can’t install WSL, he isn’t authorized to do so, right? he must have the admin’s authorization to install WSL and then Dgraph. Otherwise is a true no-go. And we can do nothing.

The build prerequisites aren’t a big thing. In general go builds are fine in all types of machines. There are no blockers at all. Just a performance bottleneck can appear.

They are, but they don’t come anyway. That’s the point. Windows was always supported since 0.1 binary. And we have a .NET client made by Michael (The GraphQL dev head).

That type of information would be handy. But no dev core or even me, have signs from the Windows devs about their interest. Turns out that Windows became a low priority.

They are, the thing is that they might be engaged with something better(?) for them.

BTW, the low priority on Windows is turning to be a thing this year(not ever before). Just because the Windows users seem absent.

That’s not the point. Again, this is happening cuz of the opposite. Dgraph was always open to Windows users. Is the demand that makes things shine. If we open the tent in the market, but no customer or just a few comes to buy that specific product. We tend to not produce it anymore, or reduce the production. Cuz it is now a “niche”.

You didn’t get it. But anyway. Dgraph will continue to support Windows. But with low priority and for learning purposes only. As far as I know.


I get it. This is the answer they will see as the official statement it just needs to be reflected early on in the downloads page as well.

Not bantering to say a change of support is needed, just that it needs to be clarified early on for Windows developers that their support will be low priority and only for learning purposes.

Thank you @MichelDiz for your great responses and clarity in this matter. You are always a really big help to the community and have a lot of insight and knowledge.


In my professional experience since 2012 in the domain of operations, I have only engaged with a single company that used Windows Servers for a SaaS oriented cloud offering. Every other engagement was on Linux. I occasionally come across others at conferences that use Windows for servers for some services, such as Active Directory. Most would use Linux and if they needed services on Windows, like Active Directory, run those independently alongside their Linux services.


Furthermore, there is the use case to use dgraph locally in a standalone application. It is fast, its supported on windows as a single .exe and really easy to setup with the schema.

I think, it should not be on low priority because it has great potential on windows. Moreover, there was no disclaimer on the downloads page and some (i.e. me) have built a application using dgraph.

Also, its not useable for learning purposes if you need > 8GB of RAM to post one schema.


Actually it is exactly that use-case.

Same use-case as with @marcown here. We’re using a dgraph instance integrated into an app that the user can download. That user will be in 90% of cases a windows user. And in 80% of cases this user will have not the experience to configurate WSL or docker or whatever “workaround”.

Let me try to explain our use-case very briefly:

  1. The user can do his work offline (which is often a requirement for software that is being used in production facilities due to security/connection issues)
  2. His work is saved in a local running dgraph instance
  3. As soon as he has internet his instance is synchronized with our dgraph instance and he can use our cloud services on his data

As @verneleem pointed out there was no reason to belief that windows is not equal to linux or macOS. As a startup with small budget, we’ve spent the last 10 month to build our application, relying on the fact that windows is fully supported and I’m literally shocked that this might not be the case.

I urge you to please re-communicate this with the team and reconsider this decision (not sure if it was even decided yet) to support windows again.

Like it or not (I don’t like it obviously), Windows is so wide-spread in coorporate intranets so that building on-premise solutions will require dgraph to support windows.


I meant as a server. In general Windows env for a server is “Windows Server 2019”.

That’s an interesting use case.

I’ll share this discussion with them. if they haven’t read already.

1 Like

Thank you!

Have you thought about using Apollo state management? or pouchdb, lowdb, or even SQLite. Those are DBs for that purpose. Dgraph is meant to be a cluster, therefore a server-based only. I think the Apollo State fits well this case. It can (theoretically) sync with Dgraph’s GraphQL.

That’s a point against Windows Licenses right? With Dgraph Cloud or Slash, you pay only for a single license (dgraph’s license). But for Windows, you have to pay for Microsoft’s license too. Proprietary software with a close source is good for big and well-established companies, but not so well for startups. (BTW, talking about server licensing).

The numbers are against it. Our telemetry says that a very thin portion of the users uses Windows and nothing* on prod. And we don’t have the bandwidth to keep up supporting Windows as before. Sorry.

If the telemetry starts to ramp up, who knows.


How does this help with offline-first applications? They can run offline for several weeks without seeing any internet. A cache doesn’t help here. The app will be closed and restarted during that period. We need persistence.
The client uses the same graphql queries supported by dgraph. How do you think will we be able to use pagination, filtering and all the other dgraph stuff on non-graph databases? We decided for dgraph because its “schema-first” and easy to use. Our complete code is build around the fact that the dgraph schema is the single source of truth. Using any other database than dgraph would require:

  • to implement a translation layer dgraph-style-graphql-queries <-> SQL (incl. pagination, filtering, @cascade etc pp) this is a complete nightmare because it basically means to re-implement dgraph from scratch
  • use two different react apps that use different APIs a complete nightmare because it will mean double the frontend-dev work and lead to unmaintainable code

Sorry, this is nowhere close to a solution. I’d be honestly happy if it was though.

Why would we need windows licences when we build windows apps? We’re not using windows server.

Well, what does this mean now? What will change? Does it only affect new features? Isn’t the core of dgraph still cross-plattform and therefore new features will also be available? Will only bugs be fixed? Will they not? We’re happy to dedicate a portion of our development to windows dgrap to keep it running and write PRs. But we need clarity here.

This discussion is currently only held between us so maybe someone else from the team or community can also give their opionion? @chewxy @amaster507 maybe?

I’ll also open a new discussion about how offline-first apps should use dgraph - maybe we can channel our efforts and find a solution to this.

Apollo State Management isn’t a cache. But you can use DBs well stabilized in applications like SQLite.

You wanna provide the whole DB? That sounds insecure. Give end-user access to the whole DB. He just needs the basics. A DB commonly used in smartphones is enough. But it requires a business logic to be built.

BTW, I’m pretty sure that others have been in your situation before. You may find better solutions out there. With the experience of others.

Well, for me this design looks like two sources of truth. You are basically having two clusters. One with the real source of truth and the other just a copy. I don’t see the difference. You have to create a way to sync the data between the two.

They are not two APIs. They are two ways of managing the same data. Nobody provides an MYSQL server on Android and sync it with the cloud one. There are different approaches to dealing with this.

Just prioritization.

No, cuz who “translates” the binary code is the Go compiler.


Everything will be resolved, but with low priority.

The app we are building uses Slash 100%. Having said that, we currently have no way to have an offline version.

I understand the position of Dgraph on Windows support and honestly Dgraph is not a client side database, it is built for server clusters with high resources and throughput.

I think this should be a new topic and maybe even under the Application category as it is not db focused but rather how to best sync data with a client lite dbms and how to best build a frontend that can can work in an offline mode.

@pbassham and I have discussed this and our ideas where to do some queries in advanced and offer limited functionality in an offline mode. We can’t pull the entire database locally to the client but need to develop a way for a user to pick data that they want to use offlinem

I imagine it working somewhat like Google Sheets where a user can sync an offline version and still have some functionality when no network.

1 Like

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 :wink:

1 Like

Not exactly. The low interest in supporting Windows comes from a long time. I personally have tried to push it, I have incentivate Windows support, and have done tests myself using VMs as I was Windows Db admin. I don’t use Windows for about 5 years on regular basis. But even tho I have tried. And we see by telemetry that there are almost zero Clusters (I mean cluster in a Server, not client-based DB). So Dgraph is basically focused on Linux. All Devs in the company are Linux based. Windows issues slows down the whole thing.

I don’t. I just not used anymore. And there are some behaviors on windows that don’t please myself. I hate some politics they implemented. That on macOS or Linux isn’t a thing.


I personally don’t think it is a good design. Having MongoDB or MySQL, Elastic, Neo4j, and so on embedded. That was never the purpose of Dgraph. It is possible, but not recommend. That’s why we recommend creating a custom API or use GraphQL. Cuz there are solutions for virtually all issues in those scenarios. No need to reinvent the wheel.

Try out Apollo State. It was meant for that.

This will be change, this idea still new.

I use macOS on daily basis.

Hey all,

Thanks for bringing all these points up. It’s time we make a decision about our support for non-Linux environments. I’ll talk to the team and get back here about our level of support for Windows and Mac.


We would not be supporting Windows or Mac going forward natively. They would be accessible via Docker or Cloud on those platforms.

Dropping support for Windows and Mac