Feature Request: Configurable Relationship Limit on Node Expansion in Neo4j Browser

[shifenhutu]

Hello Neo4j team,

When using Neo4j Browser, I often right-click a node and choose Expand to explore its connected relationships. Currently, it seems that the Browser will return all relationships without any limit, which may cause performance issues or freeze the UI when expanding highly connected nodes.

It would be very helpful if we could configure a maximum number of relationships to return when expanding a node (similar to other visualization settings like "Initial Node Display" or "Max new neighbours").

This feature would give users more control, improve performance, and make the exploration experience smoother when dealing with large or dense graphs.

Thank you for considering this request!

[OskarDamkjaer]

Max new neighbours is the setting that should control how many new relationships get added when double clicking, does it not work for you?

[shifenhutu]

thank you very much

sorry， my English is not good， i used AI translate my word

first , i will double click this node

then, i got this

it returned so many edges/relationship lines， i want to custom the edges/relationship lines number

---

---

---

Limit displayed relationship lines per node (edge display limit) without restricting displayed nodes

Describe the goal
Add a visualization option that limits the number of rendered relationship lines (edges) per node while still allowing the connected target nodes to be displayed. This reduces visual clutter and improves rendering performance for high-degree nodes, without preventing the graph from showing the connected nodes.

Current behavior (or problem)

• When I expand/double-click a node in the graph UI (Browser / Bloom / visualization plugin), the client renders all relationships (edges) of that node.
• For nodes with many relationships this results in large numbers of overlapping edges, visual clutter, degraded performance, and poor interactivity.
• I want to display many connected nodes but limit the number of visible relationship lines; current visualization settings do not provide an option to cap displayed edges per node while still showing the related nodes.

Expected behavior (proposed)
Provide a configurable option to cap the number of relationship lines rendered per node (edge display limit) without blocking the display of the associated nodes. When the relationship count exceeds that cap, the client should use one or more strategies to indicate or condense the extra relationships while keeping target nodes visible. Suggested strategies include:

• Aggregated display (edge bundling / collapsed group): merge many edges into a single aggregated edge that can be expanded on hover or click.
• Priority display: show the top N relationships by weight/frequency/recentness/user-defined property; represent the rest in a simplified/condensed way (e.g., faded lines, small dot indicators, or a count badge).
• Visual simplification: render simplified indicators (e.g., small markers or count labels) for additional relationships and expand full edges on demand.
• Lazy-load edges: initially render nodes and incrementally render relationship lines on user request or as resources permit.

Reproduction steps (if applicable)

1. Use Browser/Bloom or a graph visualization that expands nodes on double-click.
2. Double-click a high-degree node (one with many relationships).
3. Observe that all relationship lines are drawn, causing clutter and slow rendering.

Suggested implementation details

• Add an optional visualization setting (client-side) such as edgeDisplayLimit (per-node threshold) and edgeAggregationPolicy.
• Provide UI controls: enable/disable toggle, numeric threshold input, and prioritization rules (by relationship type, weight, timestamp, custom property).
• Support strategies like bundling, priority selection, visual simplification, and lazy-loading.
• Return visualization hints in API responses where applicable (e.g., displayEdgeLimit, edgeAggregationPolicy) to help front-ends render appropriately.
• Make the feature opt-in to preserve backward compatibility.

Benefits

• Improved readability and usability for large or dense graphs.
• Reduced rendering and interaction latency for high-degree nodes.
• Greater flexibility for users to balance detail vs. performance.