Hi!

• Million
• Interactivity:
  • Our focus is generally interactive analytics, not long renders (> 1s) of bigger graphs
  • For bigger graphs, we find the typical scenario is more like, identify a subgraph (e.g., billion scale graph quickly filtered down via gfql) and look at that graph, or network-of-networks, which the current system already supports
• Backend scale:
  • Most of the backend GPU code (cuda) supports billion-scale single-node GPU
  • We're working to port the remaining pieces via the GFQL subproject that was recently launched. This has been rolling out in waves throughout 2024.
  • Pieces of the backend are also already multi-gpu/multi-node, but we don't stress that much in practice, I'm guessing that'll be more of a focus in 2025
• Frontend scale & WebGPU
  • We're working on V3 of the frontend components, I recommend checking back in a few months for status on that release and numbers around it
  • Our analysis of WebGPU shows we would only expect maybe a 5-10% speedup, and it would fail to enable bigger graphs
  • Conceptually, our server GPUs are generally working with much more GPU RAM and GPU compute than browser GPUs have available, so we only use browser GPUs for rendering (vs layout), and already do big packed buffers for them... so there's little extra benefit of the new GPU standards for the current mode wrt scale
  • We are also planning some new rendering features this year -- so more complexity/compute per-node/edge -- where webgpu etc extensions may have some benefit
  • Overall, as our new features come in, and browser compatibility supports the new web gpu modes, we'll probably revisit.. Currently, however, webgpu & friends give very little benefit, a lot of rewrite overhead, and most people's browsers would not support these extensions