A common architecture evolution path is: the original associative database continues to store entity data and core fields; a new graph database is added to store inter-entity relationships and specializes in multi-hop traversal; and then the Application Layer is responsible for "gluing" the results from both sides back to the same return object. The design document seems to have clear boundaries: associative answers to the question "what is the data", and graph database answers to the question "how is the data connected", but real-world querying needs almost never stay in a single model.
In practice, most queries are a hybrid of "attribute + relationship": first capture "active users in the last 30 days" (attribute filtering, favoring relational), then look at the friends/interactions between these people (multi-hopping, favoring graphical database); or first identify "high-risk accounts" (attribute and transaction history filtering), and then expand along the path of the relationship to check for potential relationships. These are actually a closed loop in business language, but under the framework of "Associative + Graph Database" hybridization, it will be forced to split into multiple processes: first filter the ID list in the associative database, then synchronize or instantly push to the graph database, traverse the graph, and finally go back to the application layer for secondary assembly and processing. What really eats up the development cost of enterprises is often the "cross-system query semantics" rather than a particular database itself.
Next, the technical team encounters the more difficult issue of Data Consistency:
- Entities are deleted from the relational database, edges in the graph database are not cleaned up, and queries pop up with "ghost relationships";
- The key attributes in the correlation are updated (e.g., user status, account level), but the graph analysis still eats the old data, resulting in distorted results;
- When the same business action needs to modify both sides of the data at the same time, it is difficult to achieve atomicity by writing twice, and the dilemma of "one side succeeds and the other side fails" often occurs.
To remedy these architectural holes, teams often add Event-driven Architecture/Message Queue, compensation mechanisms, regular review and repair tasks, and accept some level of Eventual Consistency at the business level; but these "fixes" gradually shift the focus from creating business value to fault tolerance and remediation. However, these "enhancements" gradually shift the focus of the system from creating business value to fault tolerance and remediation.
What is more easily ignored, but extremely damaging, is that the transaction semantics are broken down: originally, in a single database, a business operation could be wrapped in the same ACID transaction, and the rollback would be complete upon failure; after mixing, a business operation becomes multiple cross-system writes, and the strong consistency is often degraded to final consistency, and the rollback logic is forced to be manually written at the application level. After mixing, a single business operation becomes multiple cross-system writes, and strong consistency often degrades into eventual consistency, and the rollback logic is forced to move up to the application layer for manual writing. As a result, statefulness judgment fills the core process, error handling "invades" business code, and system behavior becomes increasingly difficult to reason about. Troubleshooting a problem requires crossing two databases and an entire call chain, and the cost of localization skyrockets.
When complexity builds to a critical point, the architecture limits the speed of business evolution: a small requirement may require changes to the federated database, graph database, synchronization pipelines, and application layer assembly; a small exception may take days to track down across multiple technology stacks (databases, queues, services). The team's technical decisions become more and more conservative, because any change may step on the existing cross-system coupling points. At this point, even if the enterprise has a strong graphical query capability, it is often completely swallowed up by the "integration and consistency costs".
Therefore, the problem is not the graph database itself, but the "Split Data Views": the same business view is split into two sets (entities/attributes in relational and relationships in graph database), and the application layer is forced to take the responsibility of "integrating data semantics", which should be absorbed by the data layer as much as possible. The industry often refers to the strategy of using multiple databases for the same application as Polyglot Persistence, which has the advantage of taking advantage of each other's strengths, but at the cost of higher integration and consistency, and a significant increase in the complexity of maintenance and operation.
Back to the solution idea of Multi-model Database (Multi-model Database): the core focus is to "unify" rather than keep "stacking" technology stacks on the same core chain. It wants to answer the question:
- Can entities, attributes and relationships be represented simultaneously in the same system?
- Is it possible to do attribute filtering and relationship traversal at the same time with one query?
- Can entities and relationships be updated under a consistent Transaction Semantics to avoid transaction boundaries being split?
