TigerGraph Reviews

TigerGraph serves as a graph database to model accounts and transactions as edges for our company. In our organization, we implement TigerGraph in an application called Hi HQ. We deal with a large amount of interconnected data, such as customer, transaction, and product relations, so we needed to implement a solution that can effectively analyze highly connected data. We modeled entities like customers, products, and transactions as nodes, and their interactions as edges. Using this, we built graph analytics workflows to traverse the relationships quickly and identify patterns such as suspicious activity and customer behavior trends.

TigerGraph has positively impacted our organization as we needed to deal with a large volume of datasets like customer transactions and product interactions. The goal was to implement a system that can easily and efficiently provide complex relationships in the data and facilitate faster insights. We implemented TigerGraph to model our data as nodes and relations using its analytic capabilities and parallel processing architecture. We built queries that could traverse multiple connections and analyze patterns much faster than before, significantly improving our ability to analyze connected data, reducing query processing time, and enabling faster decision-making. It helps our team uncover hidden relationships in data, improving our operational efficiency and analytical capabilities.

Since we needed to reduce the query execution time in our application, it has reduced it by up to 60%. Data relationship analysis that used to take minutes is now reduced to seconds, and we can process multiple millions of relationships in real-time, which provides significant value.

We have seen a return on investment since query processing has improved to under 30 seconds, and our analytic team's productivity has improved by 30%. The infrastructure cost has reduced as fewer complex queries are now required. Previously, if three people were needed for an analysis, it can now be handled by one member, and the business team receives insights much faster, improving the speed of decision-making.

The best feature of TigerGraph is the interconnectivity, which is very good for our needs as we were looking for highly connected data such as customer transactions. We needed our database to provide solutions for complex relationship queries quickly, and we can scale it with a large dataset. We adopted TigerGraph because it has massively parallel processing, real-time graph analytics, and deep link multi-hop queries.

I find the GSQL query feature to be the most reliable because it is a powerful SQL-like query language designed for graph analytics and complex pattern matching, which is the best aspect of TigerGraph.

Scalability is one of the key factors why we chose TigerGraph, as it provides fast analytics when the dataset increases and meets our needs very well.

TigerGraph can improve on certain factors, particularly the simple query language, as the learning curve can be very hard for new users or beginners. The visualization tools could also be improved.

For new developers, especially those who are freshers, the learning curve for the simple query language should be made easier because it is relatively harder for them to learn without much experience in any tech stack. I have a few team members who are freshers, and it is relatively harder for them to learn this kind of solution.

I have been using TigerGraph for the past 1.5 years.

TigerGraph is very stable.

Scalability is one of the key factors why we chose TigerGraph, as it provides fast analytics when the dataset increases and meets our needs very well.

I have not needed customer support for any tasks, but I think it is good.

Positive

We did not use any different solution prior.

TigerGraph is deployed in our organization in a public cloud environment with TigerGraph servers set up in our organization's cloud environment. The deployment involves setting up TigerGraph servers in our organization's cloud environment.

We are just a buyer and do not have any other business relationship with this vendor.

Since we needed to reduce the query execution time in our application, it has reduced it by up to 60%. Data relationship analysis that used to take minutes is now reduced to seconds, and we can process multiple millions of relationships in real-time, which provides significant value.

We have seen a return on investment since query processing has improved to under 30 seconds, and our analytic team's productivity has improved by 30%. The infrastructure cost has reduced as fewer complex queries are now required. Previously, if three people were needed for an analysis, it can now be handled by one member, and the business team receives insights much faster, improving the speed of decision-making.

I do not know much about the setup cost and pricing, as I did not set it up. The initial setup is a little costlier compared to traditional databases, but it is justified for our organization's needs.

Before choosing TigerGraph, we evaluated Amazon Neptune, which is a fully managed graph database service available on AWS that supports both property graph and RDF model.

If your application or company needs a platform that will grow and handle datasets growing into millions in the near future, and if your company has the budget for TigerGraph, then you should go for it. It may be a little costly, but it ultimately provides very fast analytical capabilities of datasets, which is great. I would rate this product a 9 out of 10.

Public Cloud

Other

I have been using TigerGraph for the last two years. The use case for TigerGraph is at quran.com, where we need to connect the mapping verse connections to model each verse as a node and the relationship between the verses, such as shared themes, concepts, and linguistic links. This creates a semantic network of the Quran, and I made a thematic visualization of the Quran for this structure.

First, I needed to define what kind of nodes and relationships our graph would contain using TigerGraph. For the verse, I made it Surah, including Surah number, verse number, Arabic text, and translation. Then I created a theme with the primary ID and the description. I created a unidirectional edge called has_theme from verse to theme, and then I created a unidirectional edge called related_to from verse to verse with relationship type, which could be a string such as same_theme, cities, or explains, and then the weight as a double.

In this schema, each verse is a vertex, each theme is a vertex, and vertices connect to themes through has_theme edges. Verses can also connect directly to other verses through related_to edges where they share semantic connections. I inserted data for verses sharing the same theme. I then wrote a query to find verses by theme using the TigerGraph GSQL query language to retrieve all verses connected to a specific theme. The visualization graph shows two circular nodes representing the verses, labeled such as 2:1, 3, and 3:200, and one center node representing the theme patient. Edges shown as arrows connect each verse to the patient node and also a direct edge between the two verses if the related_to connection was added.

The best features TigerGraph offers include, first of all, the performance and scalability, which is why we started using it. Then there is the modern hybrid engine for AI that moves beyond simple data connection to real on-the-graph RAG for explainable AI, and the developer and enterprise features like powerful query language, low-cost solution, and cloud-native deployment. Additionally, it seamlessly connects with the ultra-fast connectors for common data sources like Snowflake, Databricks, and Kafka, which we are using.

Regarding how TigerGraph has handled large datasets or high query loads in my experience, it demonstrates world record scale with the ability to process graph data containing large dataset sizes. In this context, we can increase throughput by adjusting concurrency settings for loading jobs and modifying the Kafka loader replica number configuration to increase the number of concurrent Kafka loading jobs beyond the default one. With the ultra-fast connector and Kafka integration, we can add the built-in primary TigerGraph Kafka connector, which requires nothing to install as it is based on a trusted Kafka Connect framework. The connector streams from one source data, such as our application stream, into TigerGraph on the internal Kafka cluster. A Kafka loading job ingests the messages into the graph dataset. This design allows for faster, scalable, and concurrent data streams from multiple sources and supports modern data formats.

GSQL is Turing complete and combines SQL-like syntax with procedural programming, supporting accum, post-accum, and order by with traversals. It also supports openCypher and ISO GQL for flexibility across teams. With cloud-native deployments like Savanna, TigerGraph Savanna offers separate storage and compute so you can scale resources independently and pause workspaces for cost savings. It includes automatic failover, high availability, and fine-grained role-based authentication out of the box.

The impact of TigerGraph has been significant. It reduced complex multi-join query times from minutes to milliseconds, enabled real-time fraud detection across billions of transactions, and cut development effort by over seventy percent because the graph traversal logic that previously required thousands of lines of SQL became just a few dozens of lines of GSQL. The ability to visualize connected data in GraphStudio helped business users discover hidden relationships, such as shared account identifiers that had gone undetected for years.

Every organization needs improvements. GraphStudio has UI/UX issues and bugs. The visual interface has several frustrating bugs, for example, graph exploration results sometimes disappear and node selection can be difficult when edges are very close together. Additionally, loading jobs created by GSQL do not appear in GraphStudio at all, forcing users to manage the UI and command line separately. A dark theme is also missing in the new versions.

Regarding query development, the query installation process can be painfully slow, with some users reporting that installed queries get dropped or hang, especially when the system is overloaded. Additionally, there is no way to create or replace a query directly, which complicates iterative development. Large result sets over two gigabytes cannot be paginated, requiring workarounds such as writing to files.

There are some missing modern developer features such as query profiling, and TigerGraph does not support openCypher syntax or interpret queries, and it failed to track create, update, and delete operations. The lack of built-in pagination for large REST API responses remains a pain point for building production applications. Integrating TigerGraph with popular Graph RAG frameworks has been challenging. The light-RAG integration suffers from performance issues due to inefficient per-node operations rather than batch processing. Microsoft's GraphRAG does not abstract the storage layer, so its output can be stored independently.

TigerGraph is stable in my experience.

Regarding scalability, TigerGraph is exceptional as demonstrated by verified benchmarks. The performance scales horizontally while automatic partitioning maintains sub-second performance for deep multiple-hop traversals even as data grows and supports real-time streaming ingestion with over one hundred million updates per machine per hour.

The customer support is better, and whenever I reached out, it was extremely responsive.

Before choosing TigerGraph, we evaluated other options, including Amazon Neptune and Neo4j. Neo4j was the strongest contender given its mature ecosystem, Cypher query language, and strong community support. Neptune was also appealing for its managed and cloud-native architecture. However, TigerGraph's on-premises flexibility and proven performance at petabyte scale ultimately aligned better with our data sovereignty and performance needs, which is why we chose TigerGraph.

I have been working in my field for more than six years. I started with front-end development and then moved towards back-end development and also worked on a couple of mobile apps and other areas such as DevOps, augmented reality, virtual reality, and some AI automations.

The documented ROI is substantial based on a Forrester Total Economic Impact study. We saved nine point six million dollars in increased profits over three years from the new products and services enabled by graph-powered insights.

Regarding pricing and setup cost, I am not much aware of the details because I am handling the technical part of full-stack development, and the accounts team handles these matters. However, I can say that the Community Edition is completely free and supports production usage, and it is perfect for development and proof of concept work. For the cloud-based Savanna offering, free credits are provided to new users for a full year, allowing for thorough evaluation before any financial commitment. Moving forward, it works with a pay-as-you-go model.

Before choosing TigerGraph, we evaluated other options, including Amazon Neptune and Neo4j. Neo4j was the strongest contender given its mature ecosystem, Cypher query language, and strong community support. Neptune was also appealing for its managed and cloud-native architecture. However, TigerGraph's on-premises flexibility and proven performance at petabyte scale ultimately aligned better with our data sovereignty and performance needs, which is why we chose TigerGraph.

Start with the Community Edition and then design your graph schema iteratively. Expect a learning curve with GSQL and test real-world scale early so you can plan your export strategy and engage with the TigerGraph solution team for any enterprise licenses. I would rate this product a nine out of ten.

On-premises

My main use cases for TigerGraph include a knowledge base, which is the number one use case, and second is fraud detection analysis.

A specific example of how I use TigerGraph for fraud detection relates to cybersecurity or threat detection, which is very relevant to our infrastructure. It can identify the model, the host, users, permissions, logging patterns, and network connections. It can detect any kind of insider threat detection, attack path analysis, and lateral movement detection. It can find all the systems reachable from one compromised account, enabling threat detection or fraud detection.

TigerGraph fits very well in the AI world as it provides the enterprise knowledge graph and gives a semantic relationship engine that can be used with LLM, AI agents, and RAG pipelines. It connects to documents, people, tickets, systems, incidents, and metadata and generates relationships, offering very fast relation and multi-hop traversal. Native relationship and graph analysis scalability can be done compared to Neo4j.

TigerGraph offers the best features in relationship intelligence, VectorDB semantic similar search, LLM reasoning and chat, and also provides graph traversals, delivering connected intelligence which is why it is used across social media, banking, healthcare, fraud analysis, and recommendation systems.

Of those features, relationship intelligence, VectorDB, semantic search, LLM reasoning, and graph traversals, TigerGraph stands out as the most valuable for my team. Compared to other graph technologies including Neo4j and ArangoDB, TigerGraph is very scalable, suitable for larger enterprises with bigger data sizes, and enables faster graph traversal. It also provides a lot of intelligence on top of that, which others do not, along with solid enterprise support including backup and restore features. Overall, operational data, semantic search, and AI agentic integration make it very helpful.

The features I mentioned are very well architected for enterprise setups, and additional AI plus graph features provide significant help in ML and AI integration.

TigerGraph has positively impacted my organization through numerous applications in AI, fintech, insurance, and crypto-related use cases. It allows real-time analysis and real-time fraud ring detections, providing insights into suspicious transactions and path analysis. It enables account linkage analysis, offering faster risk decision-making than traditional SQL and NoSQL, which can take minutes or hours for complex relationship queries. The relationship and knowledge graph support reduced fraud losses and improved compliance, alongside a better AI recommendation system that includes personalization and smarter AI responses.

Since using TigerGraph, I have noticed outcomes such as faster analysis in areas including root cause detection. It effectively delivers relationships that are critical, providing connection intelligence that matters a lot. It handles standard transactional workloads better than standard options and its distributed architecture supports various use cases, including supply chain and recommendation.

TigerGraph can be improved by adding features for multi-updates and in-place upgrades when documents are inserted. Additionally, it should enhance scaling capabilities as data grows, with more collections and documents added. The performance of complex joins should improve to make relationships more direct instead of requiring multiple hops.

Beyond those improvements, I suggest increasing visibility on internal features, more metrics, and views to help identify potential issues.

I have been using TigerGraph for almost two and a half years.

TigerGraph is stable.

Its scalability is impressive; it scales very well to a certain level and quite fast, showing improved performance compared to other technologies.

Customer support is very good and has been helpful in resolving any issues, with fast interaction and effective solutions.

Before TigerGraph, I used Neo4j with the goal of achieving a more scalable solution and improving performance, particularly as data sizes increased.

TigerGraph has led to a significant return on investment, saving mostly major time compared to when I previously used Neo4j, where it typically consumed a lot of time. With TigerGraph, I save about thirty percent of time compared to before.

I did evaluate other options, particularly Neo4j, before deciding on TigerGraph.

My advice for others considering using TigerGraph is to test it, conduct a proof of concept, and verify that it meets their requirements. Perform a load test to see the performance. I would rate this review as a seven out of ten.

Private Cloud

Amazon Web Services (AWS)

My main use cases for TigerGraph are building knowledge graphs and identifying financial frauds.

One specific example of how I used TigerGraph for identifying financial fraud is identifying insider trading. Insider trading works in a way where people working in a particular organization have information about the company that could drastically impact their stock price. They attempt to communicate with people they are connected to and place trades through them. We gather their communication information, and in this case, we had a small subset of information for a proof of concept. We attempt to find the trades they have made, examine the interconnection between them and the trades, note the day of the trades, and find deviations in their trade sizes. Utilizing these details, we identify interrelationships and flag individuals as insider traders. The main hurdle is that we can only flag individuals and not definitively state they are part of insider trading. That is how we can utilize graph databases such as TigerGraph.

In the knowledge graph use case, we connect people based on additional factors. In this context, it is a product-based company with an API that assesses if a user applying for a loan is eligible for that amount. We connect people, check their previous records, uncover data interconnections, and provide a score. The key aspect was the latency in which the API responds to requests. With tens of gigabytes of data, we needed to deliver responses within 100 milliseconds, and that is something we were able to achieve. I would consider that another significant advantage of TigerGraph: its query execution speed.

The best features TigerGraph offers are its low latency, the pay-as-you-go model, and the inbuilt capability of integrating machine learning.

The pay-as-you-go model works based on the amount of data you have and the computational power you wish to consume from TigerGraph since it is a cloud-based model. The payment is determined by the data size and the speed at which you want to execute queries. Integrating machine learning models means having TigerGraph as a foundation for generating embeddings, which enhances accuracy for machine learning models and assists in building retrieval-augmented generation models.

TigerGraph has positively impacted my organization by allowing us to provide solutions to customers, helping them reduce false positives in their machine learning models. They achieve results much faster compared to traditional methods for identifying fraud. Although the cost is slightly higher compared to other technologies, the features it provides justify the extra expense.

Regarding improvements for TigerGraph, ease of writing queries is a significant advantage because the language used, GSQL, is very similar to SQL. The learning curve is not as steep as it is with other graph technologies.

I have been using TigerGraph for two years.

TigerGraph is a very stable product, and they regularly introduce updates, though not major ones. These updates primarily enhance query execution and improve documentation.

TigerGraph's scalability is notable. It operates on a pay-as-you-go model for cloud solutions. In terms of scalability, we can scale vertically and horizontally. The key factor affecting query latency is the hardware and the queries we write. There are various ways to optimize queries and monitor query performance. TigerGraph excels in scalability, which is one of its main features.

TigerGraph's support team is reliable, and they have a user-friendly interface for building graphs and writing queries.

Customer support is commendable. They typically respond within 24 hours and are willing to hop on calls if necessary. In cases where further assistance is required, their engineers join the call to provide deeper insights about the product.

I have not used other graph databases before TigerGraph, but after my experience with TigerGraph, we have explored Neo4j. I find Neo4j has a steeper learning curve. The reason for considering a switch was its more extensive industry recognition relative to TigerGraph and its lower cost, but the performance in handling data and query latency does not match TigerGraph's capabilities.

The development time has significantly shortened, and the number of employees needed for projects has also reduced. The solutions provided to our customers have helped them save money, particularly in processing and fraud avoidance.

Our experience with pricing, setup costs, and licensing involved connecting with their sales team to discuss our hardware requirements. Since we have an on-premises setup, we focused on the data volume we wished to store. Initially, when we considered a cloud instance, we discussed the data to be loaded and the required hardware for execution. Those were the points covered during licensing discussions, including discounts they provided. TigerGraph has aided our organization in attracting clients, as people approach TigerGraph directly, and they often redirect customers to us. My experience interacting with the sales team was positive.

Traditional methods for identifying fraud have resulted in a decrease in false positives of over 50 percent. When it comes to execution speed, latency reduction exceeds 200 percent after implementing TigerGraph.

The two points contributing to the lower score are its cost and the challenges encountered while implementing machine learning models. The positives include the ease of learning, executing queries, and good documentation.

I would advise others looking to use TigerGraph that it is a robust product with a learning curve that is not steep compared to other graph databases, and it closely aligns with SQL. Exploring its machine learning features is also a beneficial aspect of TigerGraph.

I believe my company has a partnership relationship with TigerGraph based on the fact that TigerGraph helps bring customers to us.

I rate TigerGraph an eight out of ten.

On-premises

We are currently using TigerGraph for fraud detection purposes, and mule identification is one of the key use cases that we are developing a TigerGraph base for.

Our focus is on card transactions, and when there are multiple hops in a particular fraudulent card transaction, TigerGraph allows us to identify the fraudulent hop sooner compared to traditional databases.

At the moment, we are at a very early phase where we are still developing the use cases, so that is the extent of TigerGraph usage that we have at our organization.

One of the key features that differentiates TigerGraph from traditional databases is the way it has been architected, as it does not rely on traditional rows and columns but rather on graphical architecture, which sets it apart from normal relational databases, helping us with analytics and analysis, making it better in terms of performance and processing capabilities.

In terms of both speed and efficiency, TigerGraph is particularly valuable, as we have millions and billions of inputs in our data sets, and the processing speed and performance that TigerGraph brings to the picture are helpful in running queries across those large data sets.

We are using TigerGraph for generating insights on how the different vertices or different parameters of a particular data set interact with each other, which is something that we are exploring.

TigerGraph is focused on the improvement and speed of identification, as the records and data sets usually contain millions and billions of records, making traditional navigation take a large amount of time to identify relations between those fraudulent transactions, whereas TigerGraph makes that easy, as the algorithms based on its architecture make it easy to identify connections between different fraudulent hops.

At the moment, TigerGraph is at a very early stage, but it has already started showing some very good results for the data science teams who are running the algorithms and queries to better improve their fraud detection capabilities.

TigerGraph as a product is currently limited in its modularity, being heavily AWS focused, and since we are on Google Cloud Platform, this caused some challenges during setup, although TigerGraph as a service was very proactive in assisting with this. Improving modularity for multiple environments would be a key enhancement, alongside more granular identity and access management and better visibility and observability of query executions.

Those are the key points that would definitely make TigerGraph a better product.

I have been using TigerGraph for about a year.

TigerGraph is fairly stable so far, though it could certainly be better.

TigerGraph is easily scalable but is constrained by the method of scaling, which depends on how the organization restricts it.

TigerGraph's customer support is fairly good, as we have received relatively quick resolutions to most issues and they have supported us in creating new feature requests for options the product currently lacks.

Rather than forums or user groups, we primarily use TigerGraph's own support team as our main support channel, having a dedicated RM for our organization with whom we usually have a weekly connect to discuss issues and difficulties.

This is our first time working with a graph analytic tool, introduced to enhance our fraud detection capabilities.

TigerGraph is fairly tricky to get used to as a new product since, unlike traditional databases, you have to be familiar with TigerGraph's own SQL language, called G-SQL, which takes a fair bit of time to understand.

We are primarily integrating TigerGraph with Google Cloud Platform at the moment, and it is a bit tricky to integrate with other tools due to its limited capacity or options, so we have to make do with what is available right now.

We have been using the documentation for the initial setup and normal management of TigerGraph, and it has been very helpful.

At the moment, since TigerGraph is still in a very early stage, there is not any concrete return on investment yet, but it has helped to decrease analysis time, so while I cannot share specific metrics, I expect future improvements in reducing costs.

Pricing-wise, TigerGraph tends to focus more on the infrastructure side, as TigerGraph is a memory-intensive product that requires significant compute power in terms of RAM, increasing costs, along with the organization's requirement for replication. However, the licensing is decent and a bit cheaper than competitors such as Neo4j, though infrastructure costs are high.

We compared TigerGraph with Neo4j, which is another graph database available in the market.

I would rate TigerGraph a nine out of ten, and it is a pretty solid service or product with good support in terms of technical and managerial help from the TigerGraph team for organizations, though it has some things to improve, such as the improvement points we discussed earlier.

TigerGraph has improvement points that hold it back from being a perfect ten.

We have our own set of security policies that are specific to our organization, so one key factor we need to ensure is that TigerGraph itself is compliant. For this, we have implemented end-to-end encryption using TigerGraph's Nginx SSL services, along with some identity and access management, which could be better, but is what we have done for now.

We are primarily using Prometheus as a tool to monitor TigerGraph's performance, current utilization, and behavior, and if there are any issues, we get alerts based on that.

My overall review rating for TigerGraph is ten out of ten.

Public Cloud

Google

My main use case for TigerGraph involves using the main interface to establish the nodes, the edges, and making the connections between the transactions and other things, as well as developing the background codes for different kinds of algorithms like the community algorithm and PageRank algorithm using GSQL for the company.

Initially, there was no problem statement while I was working because the company was just developing these things, so we did not have any specific problem statement in mind. However, while developing TigerGraph, we considered how we could establish if there are mules or fraudulent activities inside the company, potentially identifying problems such as the traffic of transactions and money laundering.

I cannot give every single detail about how I approached modeling or detecting suspicious cycles with TigerGraph, but I can provide a general overview. We mainly checked for community detection, and in case of already detected fraudulent transactions, we analyzed outflows for that transaction. We noticed if some other node is a center receiving a huge number of small transactions, which led us to start suspecting that kind of activity.

The best features that I found useful in TigerGraph include their already provided algorithms, the user-friendly interface for visualizing graphs, and the ease of connecting nodes and edges by their properties attributes. Additionally, while running GSQL, I appreciated the ability to visualize how the graph changes, allowing me to save and share this with others.

TigerGraph has not positively impacted my organization much yet since it is still in development. When I joined, I learned that it has potential as a prospect for our company, but we have not started working on any specific use cases yet.

To improve TigerGraph, one key area is its handling of data uploads, where sometimes attribute problems arise without any error indication, resulting in blank spaces in attribute slots. For example, if the transfer age's datetime format is inconsistent, it uploads without error notifications. Informing users about data type mismatches before final execution would greatly enhance the upload process.

I have worked for around six months in my internship, gaining experience in my current field.

TigerGraph is generally stable. However, there were a couple of occasions early on when data was removed from the domain due to changes in the domain setup. Apart from those incidents, it has been quite stable.

TigerGraph's scalability is excellent, as horizontal scaling is significantly better compared to SQL, reflecting its strengths as a graph database.

The customer support provided by TigerGraph is commendable. They address every issue rapidly and engage with me proactively whenever I report problems, often resolving them within an hour or two.

We did not switch to TigerGraph from another solution but rather used different methods such as SQL and machine learning algorithms. TigerGraph was explored as a development tool to see if it might serve as a complementary resource for our existing approaches.

Before adopting TigerGraph, I do not think we evaluated any alternatives related to graph data solutions beyond what was necessary for graph data work.

My experience shows that TigerGraph is somewhat challenging to get into since I initially did not know anything about SQL or GSQL and did not have much coding knowledge in general. However, the visualization feature was very useful for me, allowing me to connect data maps for nodes and edges without writing code. Slowly, I began learning SQL and GSQL, noticing that while Graph SQL is similar to SQL, GSQL offers more flexibility regarding accumulators and other properties, which I utilized extensively. TigerGraph's extensive list of prepared codes and algorithms also helped me understand the thought process behind coding, and their responsive customer support was invaluable whenever there were server issues.

I relied most on the visualization part of TigerGraph because it facilitated my understanding of the codes and how to write and develop algorithms. During data uploads, the visualization's clarity was essential for mapping vast amounts of bank data accurately and troubleshooting attribute mapping issues, making problem detection much easier.

Once fully implemented, I expect TigerGraph to enhance data traversal and connection finding between different data points, reducing complexity compared to traditional SQL, thereby requiring more data storage but less computational power overall. In the context of fraud detection and similar applications, I believe it will prove much more helpful than existing methods given its capacity for community detection and other graph-related processes.

I rely most on the visualization part of TigerGraph because it facilitated my understanding of the codes and how to write and develop algorithms. During data uploads, the visualization's clarity was essential for mapping vast amounts of bank data accurately and troubleshooting attribute mapping issues, making problem detection much easier.

I rated TigerGraph an eight because I have not worked in a fully developed setup yet, and while my experiences have been largely positive, there is still room for improvement. I give TigerGraph an eight because I rarely encounter problems with it, I enjoy using the platform, and I find the available features very helpful for learning and developing new processes. While TigerGraph seems to have considered what users would need, I do not assign a perfect score because I have faced issues with data type mismatches during uploads, warranting a two-point deduction.

Regarding TigerGraph's AI capabilities, given that my use case is for a bank, I feel that using AI for handling sensitive data is generally not advisable. However, it can be useful for creating algorithms or code if needed.

I believe that the output from TigerGraph is generally accurate. There are few instances where issues arise possibly due to server or internet problems, but aside from that, I find little misinformation in the answers generated.

My advice to others considering TigerGraph would be to start with the interface to visualize and understand the backend processes. Simultaneously using GSQL while visualizing can greatly enhance comprehension, assisting in identifying bugs before deploying code. I rated TigerGraph an overall score of eight out of ten.

Private Cloud

Other

My main use case for TigerGraph is a digital twin of the supply chain. I put all the data from companies' supply chains into it, model them as a graph, and in this way, link all the relationships between all the nodes. I am able to simulate what will happen in the supply chain based on the information from the graph. I also use TigerGraph for Graph RAG in different language model applications.

A specific example of how the digital twin has benefited my organization is that I have managed to make the digital twin work in near real time, carrying out scenario simulations that in traditional databases take several minutes or tens of minutes to run the queries. In TigerGraph, it is a matter of seconds. I have been able to show clients how the digital twin is capable of working in near real time by simulating scenarios of their supply chain.

The best features that TigerGraph offers are the cloud storage, not having to run it on-premises, and the graph visualization layer from TigerGraph cloud. I am also able to play with schemas, draw them, and modify them from a user-friendly interface.

The visualization layer and the management from the cloud have made my team's work easier compared to previous solutions because it allows us to run queries and modify the graph schema practically effortlessly.

TigerGraph has positively impacted my organization by allowing me to show how graphs and their algorithms are used. It has allowed my organization to be at the forefront of this technology because I bet on it before anyone else did, and now this technology is in demand. This has put my organization in a very prevalent market position.

A specific result that reflects this positive impact on my company's market position is that I have almost a 100% win rate on bids for projects that involve graphs, thanks to my experience with TigerGraph.

TigerGraph could improve by making the community version more complete and not limited to a monolithic service. Additionally, integrating models well would be beneficial.

I have been using TigerGraph for two and a half years.

TigerGraph is a stable platform.

The scalability of TigerGraph is acceptable.

I rate TigerGraph's technical support an eight.

I have seen a return on investment with TigerGraph, with computation times reduced by a factor of 10.

My experience with TigerGraph's pricing, implementation cost, and licenses is that with technical support, it is good. The prices are a bit high, but they are worth it.

Before choosing TigerGraph, I did not evaluate other options. I went straight for TigerGraph.

My advice to other people who are considering using TigerGraph is to learn GSQL well in order to write good queries, to understand how graphs work, and to thoroughly review TigerGraph's user guides. I rate this review seven overall.

On-premises

Amazon Web Services (AWS)