IT industry is the most progressive industry comparing to any other industries. Many IT technologies were appeared/disappeared and speed of technology advancement was extremely fast. The typical example of this fast pace movement is Financial Technology (what we call “FinTech” recently). Many IT company had started financial services, and many related start-up companies had been born.
What is the main goal of these IT companies? It’s clear that they want to make profit by providing new financial services, which traditional financial companies could not provide for their customers. From this aspect, the way of making the ultimate profits to financial technology company is providing differentiated services from what existing financial institutions are offering by integrating financial data with their own data.
Then, we must consider the IT infrastructure which is ‘optimized’ for financial technology. The word ‘optimized’ means that we must be able to access transparently to different business domains. From the aspect of database, we should be able to query naturally to different domains. (Hereby, I’ll call this multi-domain environment as cross-domain)
In the case of traditional relational database, many unnecessary jobs were needed. (For example, creating unnecessary column, table or OLAP, assigning the value which is used temporally, multi-way joining which is inefficient)
Contrariwise, graph databases are free from constraint generated in cross-domain querying. It is because the concept of ‘anything-can-connect-to-anything’ that graph databases have. It needs another job like creating schema, rules and business in the case of using traditional relational database. But in the graph database, you can do cross-domain querying by just creating an edge (relationship) to nodes that is the member of different domains.
Let’s see a cross-domain example below.
‘A’ company is a portal service company. It is using graph database in its system. Like other portal service companies, the ‘A’ company’s main page shows the information that is optimized for its customers (news, shopping items, blogs and so on). Recently, the ‘A’ company started an easy payment service. One of customers whose name is ‘X’ bought the cell phone: ‘iGalaxy’ using the easy payment service.(payment’s account number is ‘12345’) This event can be described like below in graph data model. (payment domain)
In this situation, the most interesting information to ‘X’ is ‘how to use iGalaxy’ or accessary for iGalaxy or news that is related to iGalaxy. Fortunately, news, blogs and accessary shops that tag the iGalaxy were registered in the portal like below.(portal domain)
And now, the ‘A’ company wants to show the information that seems the ‘X’ would be interested. It runs next query and show the result to the ‘X’. Finally, the ‘X’ can see the right information that he needs.
Detail of this whole graph model is described below.
As a result, it have become possible to do cross-domain query by considering the iGalaxy node as a target point and creating relationships(Tag, BUY) between the payment domain and the portal domain.
We have examined the cross-domain in graph database. It was just one example of the easy payment service, but similar mechanism could be used in many services implementing graph databases. Of course, it’ll be very easy and natural like the example above.
Lately, in the Bloomberg Technology conference that is held on June 14th, Marc Andreessen, who is the famous venture capitalist and co-founder of Andreessen Horowitz, expects far more M&A and IPO than the tech industry has seen in recent years. (On June 13th, the MS disclosed that they bought the LinkedIn.)
Referring to above mentioned market trend, integrating organizations’ IT infrastructures (such as databases) and expanding organizations’ area of service are mandatory to find new opportunities and hidden assets through company merging and acquirement. To achieve the goal, the characteristic of graph database, which is easy to execute cross-domain query, would be the best guide.
Common questions
Is a cross-domain graph the same as a multi-model database?
No. Multi-model refers to a database engine that supports more than one data model, such as graph plus document plus key-value, inside one product. Cross-domain refers to how data is organized inside a single graph model, regardless of whether that engine also supports other models.
Can a relational database do what a cross-domain graph does?
A relational database can represent the same data and answer the same questions using joins across tables. The practical difference shows up as the number of hops grows: each additional join in SQL generally needs to be planned and indexed explicitly, while a graph engine walks adjacency lists directly, which tends to scale better for deep, variable-length cross-domain paths.
Does a cross-domain graph need a fixed schema up front?
Property graph databases typically let you add new node labels and relationship types without a migration step, so a new domain can be introduced incrementally. Teams still benefit from agreeing on naming conventions and required properties per label before loading a new domain's data, to keep the graph queryable.
How should deeply nested or hierarchical data be modeled in a graph?
Break out each level that needs to be queried or filtered into its own node connected by an edge, rather than storing the whole nested structure as one property. Property graphs generally accept only scalar or flat-list values per property, so a multi-level structure stored as a single serialized value becomes opaque to the query engine: it can be read back out, but not indexed, filtered, or traversed into.
How do you keep sensitive data safe in a cross-domain graph?
Apply access control at the label and relationship-type level, not just at the database level, and review what a multi-hop query can expose even when each domain's data is individually authorized. Some graph databases support label-level security directly; for others this has to be enforced in the application layer or a query-rewriting proxy.
Sources
About this page
Last reviewed October 30, 2026 by the Nine Bits editors. Read our editorial policy or report an error.