From a user perspective, what we find the graph dynamism is more important for Self-Serve Analytics, like a fast-moving data science or analyst or dev team, tha

From a user perspective, what we find the graph dynamism is more important for Self-Serve Analytics, like a fast-moving data science or analyst or dev team, than for DBAs. So a diff perspective: DBA SCHEMA CHANGE - Relational: Admins alter the schema and devs maybe run a migration - Graph: Projects start untyped, but almost all Graphistry has helped are effectively & ultimately typed & locked. So ends up working same as relational. (Ex: ProjectDomino.org took just maybe 1mo before the neo4j DBA locked the schema to avoid inadvertent value pollution.) DYNAMIC QUERIES Once a bunch of entity types and relationships get involved, you build up a zoo of tables. This is painful for adding data ("new dataset X needs schema Y, or subtypes into existing table Z by dynamic type field A + generic data stuffed into field metadata"), and much worse, given some data, trying to figure out how it indexes across 20+ tables. Three examples: an Infosec Jupyterthon talk was about how to make sense of OSQuery's ~100 different tables for OS logs, a genetics friend got onboarded to a DB with 30 tables & views they know nothing about, and in Project Domino, you can do all sorts of things with URLs and Topics across our datasets & analyses. Relational is great for a rigid CRUD app. But once you hit analytics, you get swamped with data integration tasks (discovery, linking, fusion, ...), and tables become a PITA. Formally, graph queries like ("everything 1 step out") gives you genericity in quantification where SQL forces you to know the exact table name & field name ahead of time.