PuppyGraph Professional

The main use case for PuppyGraph is establishing a graph data model layer on top of our existing systems. We do not want to bring in a new product which is completely graph-oriented, mainly because we are not sure about what attributes have to be brought into the graph. PuppyGraph provides an easy virtualization layer wherein we can keep the data wherever it is, simply connect PuppyGraph to the sources and establish the graph model very easily to see whether we are able to get the data model correctly. We can check all the attributes and check the relationships. When it comes to graph modeling, checking whether one-to-one relationships exist is very challenging. However, with PuppyGraph, we are able to decide what kind of nodes and what attributes they should have. This way, PuppyGraph makes it much easier, particularly when you have a large number of attributes and you do not even know which attributes are needed for establishing a proper graph data model.

PuppyGraph helps manage large numbers of attributes and relationships by addressing the question of what kind of edges we need when we have a large number of many-to-many transactions and relationships. If we model all the many-to-many relationships at a transaction level, the number of edges will be too high in any graph. To avoid that, we need to figure out the optimal way by which we can have the minimum number of edges, minimum number of nodes, and minimum number of attributes and still be able to find and identify customer churn or fraud detection very easily. These are two complex algorithms where graph data modelers, even though they are technically well-equipped, will end up with a large number of edges and nodes. A tool PuppyGraph, which is not a real graph database but sits on the existing sources, helps us a lot. It helps us get the clear, proper, specific graph data model for our attributes and system properly and very fast.

PuppyGraph fits into our workflow mainly because we do not want to spend time on importing and exporting. Every time we add or remove an attribute, it takes a lot of effort to bring the data into a proper database such as Neo4j, TigerGraph, or Memgraph. PuppyGraph simply always connects to the source. It is a matter of simply specifying the attribute name. We are not doing a full import into the graph data model. We keep the data wherever it is but simply specify the list of attributes and list of graph pages, and we are able to see the revised graph data model in action immediately and easily. The traditional solutions help a lot only if you have a proper graph data model and you have established an import-export mechanism. If there is a huge amount of uncertainty and you are not sure about what nodes you have, what attributes you need, and what edges you need, a virtual graph database PuppyGraph helps us a lot. It is very easy to arrive at the proper data model with PuppyGraph than with any other solutions.

PuppyGraph offers the best features by being a virtual graph data model which sits on the other data sources that we already have. It makes it very easy for us to model the graph that we exclusively need, that graph model that gives us the best results. We are able to get there very fast, mainly because it is so easy to make corrections with PuppyGraph.

The flexibility and speed of PuppyGraph help my team in case we have 300 attributes and we are not sure about the importance of every attribute. We will not load a lot of data into Neo4j, TigerGraph, or Memgraph without even knowing which attributes will be helpful. However, with PuppyGraph, we are able to design the graph with all 300 fields and then gradually remove what we do not want, so easily, that we are able to trim the 300 features to the real 40 features very fast. We are not doing a real import into a real graph. We are simply keeping the attributes. PuppyGraph simply points to the source all the time. This way, it saves a lot of time to come down to the real 40 fields you need than when you start with 300 fields. PuppyGraph helps you to evolve very fast when there is uncertainty, within a matter of four or five days, to arrive at the best graph model.

PuppyGraph has positively impacted our organization because we have a huge warehouse with a huge number of fields every day. It is easy for us to bring the elemental view of the data very fast. We can add an attribute easily or remove an attribute easily, mainly because we only specify. We do not import the data. The traditional mechanism of taking the data, importing it into Neo4j, and adding a new feature disappears with a solution like PuppyGraph. PuppyGraph is a virtual graph, not a real graph database. This is the best case when you are not sure about what graph model you need and you have too many features. PuppyGraph makes it very easy, mainly because you do not spend a lot of time trying to import and export the data. You profile the data very fast in a graph and get the elemental view of any data as a graph very fast. PuppyGraph is the best answer.

PuppyGraph is a virtual graph and not a real graph data model. However, at some point in time, once we freeze this as the graph and the graph data model, we would like to extend to a proper graph, mainly because some of the attributes in the source will change over a period of time. We would like to maintain the historical data. Therefore, once we build a virtual layer, we need a real concrete graph layer. PuppyGraph has not provided the concrete graph layer or a mechanism by which we can build our own concrete layer on top of the virtual layer. This functionality will be needed if we have to keep the investment on PuppyGraph after we discover what attributes we need. If we need to continue with PuppyGraph, we need a compelling reason. It has to be extended with a real graph database solution.

PuppyGraph could be improved because at some point in time, it always connects to the source system, which means that the source system will always be overloaded because it is a virtual graph. At some point in time, we should be able to decide to bring in the data, but PuppyGraph does not have the support for it. It always depends on the source. The source systems are overloaded once we finalize the graph. PuppyGraph does not have a real native engine for a graph. It has to be extended with a native engine for a graph in the future.

I used PuppyGraph for about four years.

PuppyGraph is very much stable.

The scalability of PuppyGraph is really good in terms of the volume of data. However, they cannot support many users. PuppyGraph essentially does not have a full-fledged native engine. The load is still on the source system. PuppyGraph can scale a lot. However, the load is transferred to the source system. This is the reason why it can be used only by a limited number of users because the actual source transfers the load to the source systems.

The customer support is very satisfactory.

We have not used a different solution before PuppyGraph. We considered Neo4j, Memgraph, and TigerGraph as we were using PuppyGraph side by side. PuppyGraph is not a long-term solution as it is a virtual graph. Eventually, after we get the model right, we needed to move to Memgraph, another graph database.

There are no concrete recommendations. The important thing is that if they have to choose PuppyGraph, they need to have the clarity that PuppyGraph is not a long-term solution. Only if they have a huge collection of attributes and they do not want to spend time importing every attribute into Neo4j, Memgraph, or TigerGraph, then only they can consider PuppyGraph. PuppyGraph is a short-term solution for you to arrive at the correct list of attributes and how they should be modeled. It is not a long-term solution.

I have no specific comments on PuppyGraph because we went with the clear awareness that PuppyGraph is not a full solution for a graph database. The overall review rating for PuppyGraph is 7 out of 10.