How to build a graph visualization engine

Scale - backend: As we're rapids.ai-native (helped start early days of both Apache Arrow + Nvidia RAPIDS.ai), we work with customers doing billion-level nodes/edges in interactive time on GPU servers. Mostly for fast ingest, ETL, + graph neural nets / manifold learning, and we're slowly pushing that into the visual stack.

Scale - frontend: We normally recommend reducing down to about ~2M edges or less. For sensible visual experiences, add in auto algorithms that cut to more like 500K. We've planned a way we think we can do another 100X, just not (yet) an engineering priority. Fun fact: your browser's JS VM is limited to ~1GB of RAM, so we're already at that limit in practice.

RE:Scaling graph visuals as an engineering practice, it looks like memgraph is starting where neo4j reached a few years ago, and makes sense. That approach doesn't really work well for the use cases memgraph advertises for, because as soon as a bunch of user/customer/IT/etc events happen and get visualized, the browser crashes. Optimization approaches like wasm and workers are clever -- a v0 prototype of graphistry did that! -- but we found is too unreliable to be the path for good performance across users of most operational teams ("Works on my machine" syndrome). Do it, but that shouldn't be the main source of 100X performance, just a 2X boost. We end up connecting GPUs in the browser to GPUs in the datacenter not just for 100X'ing this kind of stuff, but for a predictable performance way that limits how often your user's browser crash on real datasets.

Also maybe not obvious, this article focuses on interactive rendering, but a lot of the challenge after they figure out how to solve it is interactive analytics too. Most layout algorithms have non-linear complexity, so O(500K) is actually a challenge. A lot of our GPU offloading work nowadays isn't just rendering but layout, ETL, ML/AI clustering, etc. This ends up overwhelming the browser (why we do distributed GPU), and OLTP graph DB's aren't good at that either -- Neo4j basically had to write a V2 DB-in-a-DB to make their Graph Data Science module perform.

And no worries: There's no competition because Graphistry isn't a graph database :) Most of our users will do something like databricks dashboard / jupyter notebook / powerbi / etc query graphistry visual. I bet pairing a great streaming db like memgraph with Graphistry would combine respective engineering strengths quite well!

[1] https://github.com/visjs/vis-network

Business models that support network visualization: mostly, not such a great story. Customers want to solve problems, not just look at pictures of networks. Inevitably this drives the work toward domain-specific capabilities in areas like computer security, fraud detection or bioinformatics. It's a slippery slope. If you stay focused on core algorithms, your audience is other tool builders i.e. cost centers.

Scaling up network visualization: fascinating technical problem, but a human can't actually see a million objects at once or form a mental map of their locations. So it's more like a clustering problem. Not a big surprise that Graphistry adopted uMAP. It's treating nodes more like points in big plot. We're not concerned with the same problems as illustration quality rendering of small readable graphs.

Building your own: an appeal of network visualization is that you can get going by just writing some kind of physical simulation, assign reasonable coordinates to nodes, drawing edges as lines, and poof you're done. If your goal is consistently making concrete diagrams that look like a human drew them (with nodes that have shapes and ports, various kinds of labels, constraints on edge routing, nesting, aspect ratio control, etc.) there are so many intricate subproblems that you could spend years on any of them. But what's the financial incentive?

The research frontier: no doubt machine learning will eventually transform this domain the way it has many others. The combinatorial objectives of network diagramming make it challenging for now. (Can an algorithm learn orthogonal planar layouts with port constraints? Maybe. Would like to see that.) Another frontier is to extend general methods for declarative 2D layouts. People don't want just pictures of networks, they want more elaborate diagrams: computer networks, metabolic pathways, business processes, cryptocurrency transactions. Network visualization is only a subproblem in information visualization. This ties in to the first point, people need to solve problems in a specific domain.

Except when you actually want to learn something. Worst possible advice to give someone and I haven't even read the second sentence of this blog post.