Memory and runtime limits for NetworkX betweenness centrality on graphs with millions of edges

Goal

I want to compute betweenness centrality on a directed graph that may grow to several million edges, using NetworkX in pure Python. Before committing to this design, I need to understand the practical limits of the documented betweenness_centrality implementation and the dict-of-dicts graph storage model.

Constraints and uncertainty

The graph is built incrementally with node and edge attributes, so the flexible attribute storage is a requirement rather than optional. I am aware that core NetworkX algorithms are pure Python and that betweenness centrality has roughly O(V*E) complexity, but I do not know at what graph size memory usage or runtime typically becomes unworkable on a standard workstation, or whether the dict-of-dicts overhead grows in a predictable way per node and edge.

Converting to a NumPy adjacency matrix via to_numpy_array is an option for some numerical work, but it is unclear whether that path helps for centrality specifically or only for linear-algebra-based measures.

Questions

1. At roughly what node/edge counts does pure-Python betweenness centrality in current NetworkX releases stop being practical, and is memory or runtime usually the first limit hit?
2. Does the per-node and per-edge memory overhead of the dict-of-dicts structure scale linearly, and what is the recommended way to measure it (e.g., sys.getsizeof limitations)?
3. Is there a documented, supported path within NetworkX to reduce this cost (sampling, approximation parameters, or backend dispatching) without changing graph classes?