Graph databases are gaining in popularity, yet surprisingly, they’ve been around for over two decades. To understand more about the rise and use of graph databases, Enterprise Times spoke with Dr Yu Xu, CEO of TigerGraph.
One of the challenges of any database technology is maturity and acceptance. Yet, given the size of the market, there should be plenty of room for multiple technologies. We asked Dr Xu what has been holding graph databases back.
Dr Xu replied, “It’s harder to make a breakthrough because people feel more comfortable with traditional databases, like a relational database. They think they can use the relational database for everything and don’t need any other tools.” The problem here is that we know the RDBMS is struggling to support all our use cases.
Dr Xu continued, “In the past ten years, we see the big data movement. But, it’s around a distributed system. How can we store data in a distributed way, so I don’t lose data? Companies are also dealing with unstructured data.”
While costs of distributed computing have come down, we have more data. So is this solving the problem? Dr Xu doesn’t believe so. One problem he sees is people saying, “I spent so much money. Where are the insights? What is the business ROI?
“What they are realising is that the relational database has limitations. It is good for BI tooling, and BI reports, but what about more advanced analytics, finding more fraud, improving patient care?”
Graph databases have matured to provide that tooling
One reason for the slower uptake of graph databases has been their maturity. Dr.. Xu acknowledges that while graph databases can solve the problems above, the early generations couldn’t handle the big data sets or complex queries. Now that has changed, especially when it comes to queries.
This is where Dr Xu sees TigerGraph delivering. He no longer sees people looking at graph databases as concepts or prototypes. He said, “now we are in production powering all kinds of applications.” It means that the technology has moved from niche to production. His analogy was the breakthrough of the iPhone and its ease of use. It took the early smartphone market and redefined it.
Dr Xu thinks that the emergence of the Graph Query Language (GQL) as a standardised language is pretty exciting. He says there is a lot of international demand for GQL. If it succeeds as SQL did for RDBMS, he will be right, and it will likely help drive the adoption of graph databases. One reason is that customers will no longer be locked into any one vendor or a proprietary language.
It was also interesting to hear him talk about Amazon and its adoption of graph databases. In 2017 it announced Amazon Neptune. Dr Xu says that Amazon being a pioneer in this, will help move graph databases to the cloud.
So who is using graph databases and why?
One area where Dr Xu sees a lot of graph database adoption is in financial services. He talks about the work TigerGraph has done with JP Morgan and how that has attracted other banks. “JP Morgan’s using this product. After that, it’s so easy for us to work with other bigger banks. We have seven of the ten largest banks or financial institutions using TigerGraph.”
It’s not just banks adopting the technology. TigerGraph has signed a deal with Jaguar Land Rover and is targeting more car manufacturers. Meanwhile, telcos, startups and supply chain companies are also adopting the technology.
But the key to the adoption of any technology is the use cases and how they fit.
Dr Xu replied, “This year, we will focus on use cases so customers can understand the end to end value. The first is anti-money laundering and fraud detection for banking and financial institutions. Number two is the supply chain, supply chain optimisation, inventory, prediction control, and optimisation.
“The third one, because of the pandemic and digital transformation, is data 360 or customer 360. Because companies care more about customer behaviour, care more about the customer experience. They want to use graph to connect all of the data. It helps them create smarter campaigns. That’s the three use cases.”
In addition, Dr Xu sees machine learning as another focus. “We just announced Workbench dedicated for machine learning and AI engineers.” What is interesting here is the openness from Dr Xu. He doesn’t see graph databases as “the be all and end all solution for machine learning and AI.”
What he does is see is graph augmenting ML and AI. He sees it as bringing new features. In particular, its ability to add more data points than can be done using fields and data from relational and other database technologies.
The challenge of supply chain technology
It was interesting to hear supply chain as one of the key use cases. It is an area where very large vendors have poured in large sums of money over the years. Things that sound simple, like optimising transport links or product design, are far from simple. Yet, the right solution can significantly reduce costs and time for manufacturers and distributors.
Martin Darling, Regional Manager at TigerGraph, commented, “I spent quite a lot of time with Jaguar Land Rover recently. They have their main supply chain vendor and use Anaplan planning tools. They say that TigerGraph is the third pillar. We are what they call the ‘what-if’ engine. Their other tools do a fantastic job, and they do exactly what it says on the tin. But, what you can’t do is ask a what-if question. They are also not systems that can change quickly if there is a change in regulations or if there’s a change in data sources.
“We are the engine they go to when they need to resolve something quickly. This specific example talks about 1000 Range Rovers sitting in their factory in Slovakia. They’re all being fitted with tow bars. The tow bars turn up, and they’re all faulty. So the question is, which cars should I now build, which look most like the ones I was going to build but don’t have a tow bar.
“This is not something they could quickly ask of those ERP tools. It took them 45 minutes to write the query, run it in TigerGraph, and then build exactly the right series of vehicles.”
Is it time to OEM the supply chain?
Given the problems with ERP tools and the benefits Darling laid out for Jaguar Land Rover (JLR), the question is, is it time to OEM with an ERP vendor? Perhaps create a hybrid relational graph database model?
Dr Xu replied, “We will have a dedicated team for the partnership team. Being a database company, our database is horizontal, so that we can solve any problem in any vertical. But, we need to focus, so we will focus on the supply chain.
“One question I told the team to solve is to look at the top 20 Supply Chain companies. Can they OEM TigerGraph so we don’t need to talk to each company individually? Can you embed us in some way so we can empower them? That’s a bigger initiative that takes some time before that happens.
“We don’t have a sales and marketing dedicated for car manufacturers and we still need to do education. We still need a win customer to have more knowledge when we’re working with partners in the supply chain. The way we’re doing this is to work with visionary customers. They have engineers. They are visionary, and they have the engineering resources to use new technology like TigerGraph.
“The beauty of using TigerGraph is that our language is GQL. It is so powerful and easy to use. As Martin mentioned, they can write a query in a few minutes. Then they can do integrations themselves with other tools. But ideally, we want to be embedded in many software.”
Who will do the integrations?
Writing integrations is something many vendors leave to customers. The problem is that the customer often lacks the skills or knowledge. Additionally, when the customer writes the integration, they have problems with upgrades. Integrations often have to be written again. Who will do the integrations here, TigerGraph or its partners?
According to Dr Xu, “We initially did a lot. Easy data in and easy data out is super important to our ecosystem. Right now, we have connectors for any relational database and connectors for cloud storage systems like S3, Azure Blob and Google Blob system.
“We’re mostly based on Kafka. Kafka already has many connectors. We built our system on top of Kafka to do data ingestion. We are going to open this to anyone who wants to do customisation. So initially, we have to do the job, but then we can open to a customer, to the community, since it can customise for any data sources.”
How do you build a body of trained people?
One challenge for any technology as it looks to take market share is education. It is one thing to say that JLR took just 45 minutes to write a key query, but not everyone will have a skilled GQL person on hand. How will TigerGraph build a groundswell of trained people?
Dr Xu said, “You have young, smart people who can quickly pick up the graph language in days or a week or so. But, it’s also a new language. It still has a learning curve. So if we look at a relational database, you have several tools that help write queries.
“We have a new product called the graph analyser. Basically, it is a type of visual Query Builder. The idea is that you use a web browser, and you have a graph schema prebuilt for you by your DBAs. Then you drag on a job to ask a question. For example, who graduated from this university, who moved to London, working for this company, and also has a friend working but in a different city?”
How do you move people from RDBMS to TigerGraph?
Moving between different database technologies is always challenging at the schema level. Translating the data schema can be a huge task that requires a lot of knowledge of both products. How do you manage this?
Dr Xu commented, “We call it a one-click no-code migration from your DBMS. You give the database, username and password through JDBC or ODBC, and we will show you how many tables you have and how many columns you have on each table. We will load the app and create the default graph schema.
“The default graph schema is really simple. It might not be the most optimal schema for your particular work node, but at least we have a default graph schema for you. You click one button, and data will automatically be migrated to the graph database. So you don’t need to write any code.”
You can also limit the number of tables, columns, or even the amount of data you want to import. That allows people to play with the migration and choose exactly what they need. It is also interesting that you don’t have to worry about RDBMS constraints such as entity relationships and referential integrity. The schema and data are just provisioned easily.
That flexibility also allows a DBA to be dynamic with the data they want to pull into TigerGraph. They can mix and match based on user requirements. Importantly, it also plays into the comment from Dr Xu about reducing the learning curve.
Enterprise Times: What does it mean?
I have worked on everything from flat files to network databases, RDBMS, Object databases and Object-relational hybrids. I’ve also bumped into graph databases but only as part of a solution. What was interesting in talking to Dr Xu was how focused he was on the goals of simplicity and standardisation. As vendors collaborate with ISO to standardise GQL, it also shows maturity in the graph database market.
It will be interesting to see how quickly graph databases continue to grow. The use cases outlined are nothing new which means this is about fitting in with what people know. However, doing what people know in a simpler and faster way will always win business.
The big bet will be creating those relational graph hybrids. For object databases, they remained a niche solution until that started to happen. Even then, it took a lot of time before they gained a reasonable market share. Can a relational hybrid mix be the solution to get graph databases in the door and establish them as a mainstream technology?
