Scaling Dimensions

Documentation status: architecture — see Maturity and evidence.

Scaling a conceptual hypergraph is not a single technique. Different pressures require different responses.

Main dimensions

• cardinality — more concepts, instances and relations;
• query breadth — wider traversals or higher-order matching;
• write rate — more concurrent mutations and transaction pressure;
• durability — larger persistent datasets, journal volume and index maintenance;
• distribution — more nodes, tenants or remote execution boundaries;
• numerical workload — larger embeddings, tensors and learned models.

Choose the mechanism from the bottleneck

Use indexing for lookup pressure, partition/distribution for placement pressure, persistent storage for lifetime/dataset pressure, batching for call/write amplification, and accelerator-backed tensors for suitable numerical kernels. Do not introduce distribution or GPU execution merely because the graph is large.

Preserve semantics

A scaling strategy is correct only if identity, relation meaning, transaction boundaries and authorization remain stable. Performance optimization must not silently redefine the conceptual model.