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.

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.

I have been using TigerGraph for roughly seven years, and I was one of the first people in the first batch of cohorts to get certified in TigerGraph.

My main use case for TigerGraph is for fraud detection and for looking at similarities in data sets. In my current job, when I worked within the finance space for certain banks such as Capital One and Washington Mutual Bank, I used TigerGraph for fraud detection. Most currently in my consulting work, I use a mix of graph databases, including TigerGraph, primarily for classification of metadata for models to adhere to compliance policies, such as the European Artificial Intelligence Act.

The main area I use those multi-modal capabilities for is fraud detection, but I also use TigerGraph for metadata and data model cards. Most recently, I worked for a travel company where I used TigerGraph for classifying transactions for hotel data and identifying commonalities for sales data, which helped tailor customized marketing to customers based on their travel destinations.

TigerGraph specifically helps me in managing compliance and fraud detection with its flexibility with algorithms, which I really appreciate. The top two graph databases are Neo4j and TigerGraph, and the way it allows for functionality with the algorithms is impressive. For detecting fraud, a main algorithm is Cosine Similarity, which uses vectors to determine similarity between inputs. Even though it is typically a graph database, it has vector functionality, making it multi-modal.

TigerGraph offers great speed, functionality, and adaptation. The team does a great job of adding new features and improving current ones. Their support is tremendous, and being in the first cohort to get certified in TigerGraph reflects positively on my LinkedIn profile. The community around support for certified users is really great if help is needed.

TigerGraph has positively impacted my organization, particularly in speed. While we pay for the license, we see great ROI because we are able to aggregate clients for targeted and specific marketing, increasing revenue and improving the speed with which we can react to customer needs.

I cannot really say much about needed improvements for TigerGraph in my current work. I think it has great adaptation with AI. If I had to pick at something, it might be more AI integration, but overall, it is hard to suggest improvements as TigerGraph supports many technologies well.

I have been using TigerGraph for roughly seven years, and I was one of the first people in the first batch of cohorts to get certified in TigerGraph.

I find TigerGraph to be stable in my experience.

TigerGraph's scalability is tremendous. It is inherently adaptable, allowing for easy addition of data and relationships through its pipeline capabilities.

TigerGraph offers great speed, functionality, and adaptation. The team does a great job of adding new features and improving current ones. Their support is tremendous, and being in the first cohort to get certified in TigerGraph reflects positively on my LinkedIn profile. The community around support for certified users is really great if help is needed.

The customer support and ecosystem around TigerGraph are fantastic.

We did not have a previous solution. We developed the current solution based on my expertise and experience with TigerGraph.

Integrating TigerGraph with existing systems was very easy, as it pulls in various data types seamlessly, including text files and PDFs.

I track specific metrics such as a reduction in churn, as customers tend to stick with us because of the valuable information we provide. This increased ROI helps expand our customer base and targets effectively, reducing churn significantly.

I have seen a return on investment through time and money saved, even though we did not necessarily need more employees. We have reduced phone time with customers and been able to market to a larger customer base effectively.

Regarding pricing, setup cost, and licensing, I was involved with the licensing part primarily. I recommended the solution, but pricing and setup costs were determined by our financial team.

I evaluated other options before choosing TigerGraph, primarily looking at Neo4j and various open-source graph implementations. TigerGraph stood out as the best choice.

The learning curve for new users getting started with TigerGraph can be somewhat challenging. Understanding tree diagrams and graph algorithms is necessary, so it could be tough initially.

TigerGraph handles real-time analytics and streaming data well, but you will need additional add-ons for that, such as streaming add-ons including Pub/Sub.

The documentation and training resources for TigerGraph are phenomenal and incredibly well done on their site.

My advice to others looking into using TigerGraph is to consider the strong support and tutorials available for learning it. For data scientists and engineers, I would recommend looking into TigerGraph alongside other major players such as Neo4j to make a fair comparison, as TigerGraph provides excellent support and licensing options. I give this review a rating of 9 out of 10.

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.

I have been looking at TigerGraph on and off initially. I used it for a proof of concept for our penetration testing, so I have been working with it for close to two years. We have been considering TigerGraph for the last four to five years.

The aim was to try out TigerGraph for the famous real estate use case, which is to search for a house or an office space. Traditional commercial solutions use relational models in the business, and the aim was to try TigerGraph as a graph database. We are helping people to find where they want to stay and how frequently they want to go to a location, or travel from location one to location two.

The aim is to bring in the public transport information also within the graph data model, so that people can quickly locate the most suitable location with public connectivity, where they can travel down to the office location or the rental apartments they live in. They get the place where they have the best connectivity to all the places where they have to go.

TigerGraph allows you to specify the schema using SQL, similar to how you would with a relational data model. If you are familiar with any of the SQL or GSQL concepts, it is much easier to program with it. TigerGraph has an exclusive language on its own, and they also have support for GSQL, which is the most widely used programming language. With support for their own exclusive programming language as well as for GSQL, TigerGraph makes it easier for both people who know SQL and people who know GSQL.

For people who have not worked with SQL, bringing them into TigerGraph is very easy, and once they are comfortable with how to solve problems using graph-based databases, it is easy for them to transition to GSQL, which is the graph query language and the most predominant language used for graph databases. That way, we can continue to move from the relational model to the GSQL graph-based model in two steps. Even though the learning curve seems to be in multiple steps, it makes it really much faster.

It is very easy to do mainly because all their machine learning algorithms are available. Once you draw your graph model and load the data, you can experiment faster, and making it GUI-driven makes it very much easier to figure out what would be the best possible choice out of the various algorithms they have. That way, the progress with TigerGraph is much easier.

Normally, once you build the graph, it takes around five to seven days for someone to apply a machine learning algorithm and arrive at the suitable machine learning algorithm. However, with TigerGraph, it is easy to do, especially for recommendations.

TigerGraph does not have enough number of experts, and in terms of the usability of the product, they are still evolving.

One thing that they have to improve very quickly is establishing a simple relationship with TigerGraph GUI is hard for anyone who does not have hands-on experience working with the product earlier. Tutorials-wise, TigerGraph is very weak.

I would give TigerGraph a seven rating because whatever the graph data model database for TigerGraph, it definitely works. I am not giving a rating higher than seven or eight because whatever they have on paper definitely works, and they have made it easier for developers. The minus point is that unless one has explored TigerGraph very thoroughly and knows that these functionalities can make things easier, it is very difficult for a group which is totally unknown to TigerGraph to explore all this and come out of it. That way, they could have gotten an even better rating if there were sufficient guiding tutorials. Unfortunately, they do not have them. They have the features in their product, but they have not put the technical documentation appropriately in place.

TigerGraph definitely needs at least one person who knows TigerGraph. Otherwise, even though they have all the functionalities, definite guidance is needed, and at least one person should know the product.

The key point is that they have a lot of functionalities and a user-friendly interface with programming language support, but the UI that they have requires guidance.

I have been using TigerGraph for the last 16 years.

TigerGraph is certainly stable. In fact, it is more stable than Neo4j. I also want to point out that at this stage, Memgraph and TigerGraph are both equally stable, and in fact, both are far more stable than Neo4j.

I have compared Neo4j, Memgraph, and TigerGraph, and I find Memgraph and TigerGraph to be equally good in terms of scalability, so I cannot claim TigerGraph as a clear winner. I can definitely say both TigerGraph and Memgraph are better than Neo4j.

We have used Neo4j before, and while we do not want to completely move out from Neo4j, for this specific use case, it was very easy with TigerGraph because of the ease with which the data import can be done with TigerGraph.

We considered Neo4j, and we also considered Memgraph.

TigerGraph can be validated mainly because of the ease with which you can see the data. It can be definitely validated, and they also have strong, strong, strong security, both in terms of storage as well as in terms of the GUI, mainly because they follow their own ways to access.

I have to put this conditionally here. As long as you have somebody who has worked with TigerGraph earlier, even with a set of people who have no background in graph databases, we can definitely get the project done. However, at least one person should have explored the product in detail. Otherwise, it could be a little expensive.

I am definitely very satisfied with TigerGraph. In fact, both Memgraph and TigerGraph are equally satisfactory, and they are better than Neo4j. I would rate this review a 9 overall.

I mainly use TigerGraph for enabling people on the migration of projects where they are using legacy systems and want to benefit from using a graph database, particularly for establishing recommendation engines for their different product-related information and relationships between the products, allowing them to recommend various products to end users.

We usually conduct sessions specifically like SME connects, where we walk teams through TigerGraph's features, the GSQL query language, various algorithms, and specific use cases that can help them with their projects. This full-fledged training delivery also enables certification and practical application for their individual projects.

We have deployed TigerGraph in the public cloud, specifically using TigerGraph Savana for our application.

TigerGraph offers key features including cloud and on-premises deployment, including TigerGraph Cloud DBaaS and self-managed enterprise deployment, which help anyone access TigerGraph. It also has various connectors for pulling data from legacy systems to up-to-date data sources such as Snowflake or Spark, allowing establishment of graphs and visual representation with development tools like Graph Studio that help visualize data concerning graphical schema design and exploration.

The data connectors are particularly important because when pulling data from legacy systems, being able to connect to any data source is essential for building the graph, which is crucial. Being in the NoSQL category, it also supports ACID transactions, something that many NoSQL categories do not promise but TigerGraph guarantees, which adds considerable value.

I feel that more enablement could be improved for better understanding, which is an area where I see room for enhancement.

It primarily needs more instructor-led training associated with TigerGraph University to enable broader usage and certifications, allowing more users to utilize its features effectively.

I chose a rating of eight out of ten mainly because documentation, more demos, and improved customer approachability still present opportunities for improvement. Having more projects using TigerGraph or additional use cases could potentially justify a perfect ten.

TigerGraph is well-equipped so far, but there could be enhancements in cost-wise partner enablement initiatives, aiming to reduce costs for implementations through AWS, Azure, or Google Cloud platforms.

I have been using TigerGraph for over two years, and it is one of the NoSQL graph databases that is helping me analyze the data with respect to various parts and relationships and how it connects, which is something different from the relational databases I have used.

TigerGraph is quite stable, enabling effective project implementation.

Specifically, in terms of scalability, TigerGraph promises us horizontal scalability that accommodates any amount of data. For instance, projects with product data involving countless customers needing to access products and provide billing also utilize recommendation engines, where significant customer demand necessitates robust scalability, which TigerGraph supports and significantly saves time.

TigerGraph supports horizontal scalability, which is crucial for large projects, making it applicable for any big data applications.

Customer support has been good so far, as interactions with the support team yield satisfactory resolutions, making it comfortable to approach them for solutions.

I would rate customer support a nine out of ten, as the support ticket system operates effectively, ensuring timely resolutions. Quicker response times could elevate this to a perfect ten.

Prior to TigerGraph, we mainly used legacy systems like Microsoft SQL Server or Oracle, seeking scalability and NoSQL features for recommendation engines, which prompted the transition to TigerGraph.

We purchased TigerGraph through the AWS Marketplace, managed by a separate team in charge of the procurement and enablement process.

While we have not made a significant investment yet and are in the enablement phase, we believe that leveraging TigerGraph's features will eventually lead to time and cost savings.

The pricing relies on usage and the amount of data handled through a pay-as-you-go model based on performance. Partner enablement will reduce costs and encourage greater adoption of the application.

We considered other options like Neo4j, which is also in the NoSQL category, and ArangoDB, but ultimately found TigerGraph's query language more comfortable for our needs.

Enabling TigerGraph represents a niche skill, and most people initially lack knowledge about it. However, once they understand TigerGraph's features, the exposure to the NoSQL category of graph databases fascinates many, demonstrating how we can visually see and represent data without the rigidity of legacy systems, significantly affecting project acceptance and positively impacting our approach.

Concerning agentic AI, graph RAG, and hybrid graph with vector search capabilities, TigerGraph has made significant advancements that cater to current needs.

My experience with TigerGraph involves establishing agents that automate processes, allowing an agent to convert text to GSQL language, facilitating output in English format. This in-house POC helps us understand leveraging LLMs for interaction with the database, making it accessible even for users without prior knowledge of TigerGraph.

The features and built-in use cases and solutions TigerGraph offers are compelling reasons for anyone to consider its implementations.

I gave this review a rating of eight out of ten overall. My experience with TigerGraph has been exceptional, and I believe more focused enablement and diverse use cases will encourage broader adoption and implementation across various projects.

Fraud detection is the main use case.

At the time that I was working there, which was from the beginning of 2024 to mid-2025, I believe there was no other product able to perform graph database operations on a distributed paradigm, so TigerGraph is something that was heavily advertised for its distributed nature of the product.

I think that is one of the good parts, as the scale at which it can handle data is impressive; we can hold terabytes and petabytes of graph data, and we can analyze it, write queries, and reduce the patterns accordingly.

We had a lot of data, and we wanted a database that could handle it, so at that time, TigerGraph was one of the top options that we had. Scale and distribution made our workflows run in a limited amount of time; without the distributed nature, it would have taken more hours, but now it takes significantly less time.

There are several features that I think are missing, as the connectivity through which TigerGraph can connect to different data ecosystems should be improved; currently, the connectivity is very limited.

TigerGraph should create a native Spark connector that works natively and is able to extract data at scale and ingest data at scale, so it should be able to integrate with other data products at any company. I think connectivity is quite underwhelming.

I believe it can be improved, as there are common security features that are missing.

I have used TigerGraph for almost fifteen months when I was working with Infosys for the client Bank of America, and we used it for one of the fraud detection projects.

That part is actually really important, as TigerGraph is very naive and it is somewhat a beta product. It has always been a beta product, even when they have released so many versions, it was very problematic. We used to have issues every now and then, and we had to raise tickets on their service desk.

There were a lot of issues we had to encounter consistently, and it was quite overwhelming; instead of working on project objectives, we were mostly working on fixing TigerGraph issues, working on updates for TigerGraph, downgrades when the upgrades had problems, going back and forth with the support team, and dealing with the inability of the support team to resolve the tickets in a timely fashion. That really destroyed our timelines, team spirit, and productivity.

TigerGraph was deployed on-premises, which really caused a lot of issues in addition to the TigerGraph issues.

The problem with the service desk and the resolution team was that everyone who joined TigerGraph in that team was not working long at the company, so tickets used to span for months, maybe three months and six months, and in between, we would see two or more employees changing.

It is not different people handling the tickets; it is that the person who has handled the tickets earlier has left the company because I think they were overwhelmed with all the customer requests and they could not do much to get rid of the customer complaints.

Before learning about TigerGraph, I wanted to learn about graph databases, and I started learning Neo4j, which looked to be a very good and stable tool, as it was good in terms of stability and the features it provided.

We had some scalability needs that made us choose TigerGraph, but now I think Neo4j has also come up with scalable graphs so that it can scale at a very large petabyte-level data.

Neo4j was on top of the list along with TigerGraph, but at the time of product selection, Neo4j did not support the distribution completely, so we had to choose TigerGraph.

I was not made aware of the licensing cost; the setup was adequate. They shared one package for us to set up in our on-premises servers, and the package had some issues that did not work properly. They had to come and do some things at the time of installation, and that is how the setup was done, which was not very good.

I cannot give any numbers, but TigerGraph was one of the key parts of fraud detection for the bank, which was a huge financial aspect, as it helped reduce fraud and save the bank from several fines from regulatory institutions. They were also able to maintain customers' trust.

If your data is not at a petabyte scale and is manageable on Neo4j, just go ahead with Neo4j. Otherwise, if there is no particular solution that can cater to your needs, then you do not really have a choice; but TigerGraph should not be at the top of your list, it should be somewhere at the bottom. If you have very specific requirements that match with TigerGraph and if they are able to provide a cost that is reasonable compared to others, then you can go ahead.

I think TigerGraph is reasonably accurate; it all depends on the kind of algorithm that we use and the relevance of the algorithm with respect to graph databases. The use case will also play a role here, but I think it is quite decent; I would not say excellent, but decent. I gave this review a rating of five out of ten.

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.

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.

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.