TigerGraph Cloud Classic

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 case for TigerGraph involves finding default patterns in cryptocurrency transactions, where my company received a project that required us to identify those patterns.

A specific example of how I used TigerGraph to find patterns in cryptocurrency transactions was to observe multi-hopping in a limited time frame, where the maximum transaction was happening from one person to multiple people, which is a fraud detection pattern indicating a large amount from one person going to different people in a very small amount of time.

Another use case I had was to observe the amount accumulation with the top five people in a given time frame. As cryptocurrency data is increasing day by day, we took three months of data and inserted it into TigerGraph using CSVs rather than any API to identify the top five people accumulating the most amount, utilizing a heap accumulator in that case.

The best features TigerGraph offers in my experience include its ability to handle large data sets, which made client handling much easier as visualizing that data in table form was very tiring and not at all effective. TigerGraph provided a great experience in data visualization.

I appreciated TigerGraph's visualization because it was easy to see when one person accumulates an amount that goes to one hundred or more people, as the edges and vertices displayed relationships in an amazing way, making it very easy to visualize transactions and patterns. We could change colors, names, and icons according to our requirements, which was very helpful.

Regarding additional features, writing queries was also very interesting, as the queries and accumulators used in TigerGraph made changing the requirements from customers very easy because G-SQL is, in my opinion, quite easy to grasp.

TigerGraph has positively impacted my organization by providing better visualization and transaction patterns compared to our original database, BigQuery, which did not meet client expectations in data representation.

Specific outcomes that show how TigerGraph helped our organization include saving time, as BigQuery was costly in terms of data querying. TigerGraph allowed us to write G-SQL queries and filter out data, definitely reducing manual work and helping us with cost optimization.

TigerGraph can be improved by providing more tutorials about G-SQL. With experience, I have increased my skills for G-SQL, but I found limited tutorials online, so I would really want to see an improvement in G-SQL tutorials or proper documentation.

I have used TigerGraph for about two years.

I did not find any fault regarding TigerGraph's stability.

As for scalability, I did not find any slowdowns or challenges. As the dataset increased, it performed better, and I found no inconsistencies.

I previously used Google Cloud's BigQuery, and we switched because querying data there was very costly, and its table format did not make sense for the relationships of transactions.

I have seen a return on investment with TigerGraph. It is much cheaper than using BigQuery, saving time because we can see patterns right in front of our eyes without needing to go back and change previous queries, thus requiring fewer employees as only a small team worked on TigerGraph.

I do not remember the other software that displays vertices and edges as relationships, but the volume of data we had made TigerGraph the best option due to its architecture and other technical aspects, making it much faster.

For those looking into using TigerGraph, I would advise that understanding the G-SQL part is crucial because without that, choosing TigerGraph would not be beneficial. However, once you grasp G-SQL, which I think is easy, you can master TigerGraph as a developer.

Overall, I think it was good to use TigerGraph, and I had a nice experience. I have given this review a rating of eight 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 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.

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.

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.