Graphistry 2.53.0: 10 million edges in 537 MB of browser memory

The biggest news in 2.53.0 is that we are making big graphs feel fast. This means analysts don’t feel resistance in tackling bigger datasets and don’t get knocked out of the analyst loop for potentially slow steps. For example, a 10-million-edge graph that needed 7.6 GB of browser memory now needs 537 MB to open on your browser, on an ordinary laptop. The reason is a rewritten edge renderer, on by default.

Loading was unreliable above roughly 500K edges: it could fail outright, or take a while when it did work. And well below a million edges, on pan and zoom, we’d not render edges as a perceptual trick, which lost visual constancy.

With this release, both are fixed: big graphs come up straight away, and the edges stay drawn while you pan, zoom, and run a live layout.

This change is a complete re-architecture of the front-end rendering pipeline, which not only allows us to dramatically accelerate rendering, it also unlocks a suite of visual improvements and features which we will be introducing in the coming weeks and months as part of the 100x initiative announced on July 24, 2026.

One compatibility note: this moves the renderer to WebGL2 and drops WebGL1. But any current browser is fine, and in practice the only browser affected is Internet Explorer, and users on it will need to switch. WebGL2 bought us some of these speedups, but most of the win comes from deeper frontend work, we’ve split rendering across client and server GPUs for a long time, but the frontend was the bottleneck until now, and this is the first time that split’s benefit really shows, pushing past what a browser-only renderer could do.This raises the ceiling on all hardware, letting weaker hardware render larger and larger graphs, though a workstation with a discrete GPU will still pull ahead of a laptop at the top end.

Large graphs load immediately, and they fit in memory

Edges are usually what makes a big graph slow, while edges have always been drawn on GPU, the old architecture performed one CPU-side preprocessing step before rendering. You would have noticed this as a long delay after a large graph had already arrived in your browser, in the range of tens of seconds on larger graphs.

The new architecture almost completely eliminates that step, graphs appear the moment they arrive, and browser memory came down with it. The same 10-million-edge graph took 7.6 GB under the old renderer and now takes 537 MB; most of that 7.6 GB was the precomputation, not the graph. Graphs that used to push a tab toward the browser’s memory ceiling now fit comfortably, with room to keep more of them open at once.

Edges stay on screen while you move the graph

The second thing is that your edges stop disappearing. Previously, panning, zooming, or running a live layout on a large graph made the edges vanish, leaving bare nodes floating until the view went still. That was a survival tactic: hiding edges was the only way to keep gestures responsive when redrawing them was expensive but it also broke visual context for important edges. The new renderer draws edges fast enough to simply keep everything on screen, every frame, through every gesture, and all the way through a live layout. For the first time at this scale, you’re looking at your actual data while you move through it.

The improvements run through the rest of the experience too, the hitch after a layout finishes on a 1.6-million-edge graph dropped from about a second to under a tenth of 1, and the worst frame during interaction at that scale dropped from 83 ms to 29 ms. At the top end, a 10-million-edge graph that used to crash the GPU outright now settles in under half a second.

Arrowheads, edge widths, and curves that draw correctly

A renderer rewrite is a chance to pay down a decade of small rendering debts and the most visible change is that curves are actually curves now. Curved edges used to be built from a handful of straight segments, and you could see the corners, especially zoomed in on a gentle arc. Every edge is now a smooth curve at every zoom level.

Several long-standing blemishes went with it. Edges are fully anti-aliased now, so the staircasing effect on edges should now be gone. Hairline edges no longer show banding artifacts on shallow arcs and arrowheads no longer hide behind their own edges.

What’s next

This release rebuilt edge rendering for every graph, but interacting with a 10 million-edge graph that size is still choppy, which the next release addresses. Two follow-ups are already running in our benchmarks and landing in upcoming releases.

Parallel edges you can actually read

The next release is aimed squarely at multigraphs, that is, networks where the same pair of nodes is connected by many parallel edges. That describes most real-world event data: network flows, transactions, communications logs.

The change you’ll notice first is color. Today, when many differently-colored edges connect the same two nodes, they pile on top of each other and blend into a muddy mess, which makes your information-dense color encoding completely unreadable. In the next release, parallel edges will be sorted by color into distinct bands with visually defined widths, so at a glance you can see which colors run between two nodes and how much of each. Instead of a heap of overlapping arrowheads, each color band arrives with one clean arrowhead, hovering and selecting still pick out the exact individual edge, even inside a dense band.

The other change is speed, especially for the heaviest graphs. In a preview, continuously panning a 10-million-edge benchmark goes from about 15 frames per second on today’s release to hitting the v-sync ceiling on a 240 Hz display.

Live layout that streams lighter

With large graphs, extremely good internet bandwidth is a requirement for smooth real-time layout: the server streams fresh positions for every node many times a second, and connection quality shows up directly as choppy motion. On large graphs it is possible to accumulate gigabytes of received data over tens of seconds. An upcoming update cuts the bandwidth layout streaming needs to roughly a quarter of what it takes today. That doesn’t remove the requirement, but it means far more connections fit under the bar for a good experience, on larger and larger graphs.

Together, the multigraph update makes the previously unloadable real-world graphs fully interactive, and leaner streaming brings live layout to ordinary connections, all pointing at the same goal of exploring graphs of 100 million edges, live in a stock browser.

Try it on a graph of your own

The fastest way to see this is Graphistry Hub. The free tier runs the new renderer, needs no install, and tturns a CSV or dataframe into a graph: hub.graphistry.com/accounts/signup

Already using PyGraphistry? pip install -U graphistry and your existing notebooks pick up the new renderer with no code changes.

Self-hosted deployments pick it up in an upcoming release.

The practical notes

The new renderer is on by default but the previous renderer remains available by adding ?legacyRenderer=true to the visualization URL as a query parameter. If you hit anything odd, that’s your escape hatch, and we’d like to hear about it. Feedback and issue reports are welcome in our Discord channel.