We use Neo4j to manage all the relationships of our data. We didn't want to use anything else because joins get too slow for querying. Neo4j is actually the glue to our platform. Everything is connected using Neo4j, having it makes the management of our data fairly easy and also allows for easy analysis and reports.

If you are looking for a graph database solution Neo4j is the way to go. It is the easiest and most robust solution to use on the market. Even so, the community version is free and the community support around Neo4j is really good. The database performance is extremely fast.

As [we are] working in the US healthcare domain, we have to deal with large databases like UMLS. It also contains more than 12 relationships among the nodes. To analyze and build a relational module, Neo4j is good choice for us. Mostly Neo4j is used in the R&D department for analysis. But it is also in use at application level to support queries on a large dataset.

Neo4j is well suited for POC and analysis purposes on some subsets of large data sets; also very efficient query language to query the knowledge. But if you have to deal with a large and complex data set, it's not a good option.

We used Neo4J to store data that have tree relationships. It is being used by our entire organization for various data to be stored. It addresses the problem of storing data that has multiple relationships pretty well. Storing data in Neo4J allows for a very efficient way to look up nodes and their relationships are quicker than storing similar data in traditional SQL database.

Mature Query language, I found Cypher QL to be mature in handling all sorts of problems we throw at it. Its expressive enough to be intuitive while providing rich features for various scenarios.

Native support for REST API, that makes interacting with Neo4J intuitive and easy.

Support for Procedures in Java, procedures are custom code that could be added to the Neo4J to write custom querying of data. The best part about the procedures is it could be invoked using the REST API. This allows us to overcome any shortcomings from their Cypher query language.

Nice UI and interface for executing the Query and visualizing the response.

Support for language based libraries. Currently, Neo4J only supports Java-based libraries. We used node and found issues with documentation and support for this library. It helps if Neo4J supports libraries in popular languages.

Support for triggers, that's one of the neat features of Postgres and other traditional SQL databases.

Support for indexes for data lookup. Looking up multiple nodes information using Neo4J is not very efficient, it is more optimized for looking up relationships between nodes. So adding that support would be very useful.

Its very well suited for storing graph types relationship information, such as a group of people and their relationships. Data modeling this sort of information in a traditional SQL database is a pain and inefficient. Using Neo4J allows for efficient modeling of data while providing rich querying capabilities using Cypher. Its also a great fit for any programming language because of its support for REST API.

It's less appropriate for any other data structure other than Graph data. So as with any DB, evaluate the data structure and query and if the querying revolves around relationships, then Neo4J is a fit. If there is more need for looking up individual nodes and their associated information, Neo4J might not be the most efficient solution in the market.

Neo4j was an experiment for us. We needed to model people and relationships for which graph databases were most suited. Google search resulted "Neo4j" on top, so we tried it, and it is awesome! The project, unfortunately, has been shut down, but at the time, we used it as the primary database for the application. The database model was designed such that every piece of information could be mapped to either a node or an edge, so we didn't need to use any sort of relational or other no-SQL database.

One of the hardest challenges that Neo4j had to solve was the horizontal scaling problem. I am not updated on recent developments, but at the time of my use, I couldn't find a viable solution.

Neo4j does not play with other open source APIs like Blueprint. You have to use the native Neo4j API.

There wasn't a visual tool to see your data. Of course, third party tools are always available, but I would have loved something which came with the Neo4j bundle. I love that Docker comes bundled with Kitematic, so it's not wrong to hope that Neo4j could also ship with some default visualization software.

If you have a graph problem, or if you can model your data in nodes and edges, my friend, you need a graph database. And Neo4j is the leading one. So that is reason good enough to use it.

But if you try and use it without a use case, you are in for a rough ride. It is hard to switch from a relational or JSON like data structure to a graph one. You wouldn't have access to all the joins and tables (at least not in the traditional sense).

I am using it as schemaless data store to persist my knowledge graph. As the name indicates, neo4j is a perfect choice when the query pattern is about finding the relationships between entities. I evaluated it with similar use cases, besides knowledge graph, where finding patterns was essential. It is a very good choice when joins are very common in a relational store. As the data is completely materialized, all joins are in constant time which tremendously improves query performance out of the box without extra system design.

We use Neo4j as storage for data that can naturally be modeled as a graph (think nodes and edges). It allows us to create rich objects with multiple properties, ingest them at reasonable rates, and the search against the graph and return results fast enough that you can run a website directly off it.

It's not a general data storage solution, but for applications where you can about the graph or network nature of the data it excels.

Neo4j should only used when your data can be modeled as a graph (e.g. nodes and edges) AND you actually care about its network qualities. It's not a general purpose data store. If you have large amounts of text to store, you'll need to augment Neo4j with something else like Elasticsearch. Also Neo4j can be a little wonky with date time data (e.g., attempts at representing date time objects explicitly on the graph, as opposed to properties, is going to be a challenge).

Neo4j provides the framework for our business’ cloud solution, which helps companies digitize their supply chains. It is used primarily by our developer team, but our entire organization benefits from it. We were looking for a solution that would be able to handle very complex queries without sacrificing performance, and Neo4j really addresses these issues.