Technology consulting firm Coshx uses Neo4j whenever it sees a lot of database JOINs in a client’s current architecture, knowing performance will be greatly improved.
In this week’s five-minute interview (conducted at GraphConnect 2018 in NYC), we discuss why Coshx chose Neo4j and how a graph data model makes it easier to communicate with business stakeholders and solve difficult engineering problems.
How do you use Neo4j?
Michael Wytock: We used Neo4j in a couple of client projects that we’ve worked on, some of them in the intellectual property domain. We transitioned from a relational database to Neo4j in order to get some performance enhancements in some of the work that we’ve done.
What made you choose Neo4j?
Wytock: We noticed that there were a lot of database JOINs with the client’s current architecture. We chose Neo4j because we knew that we would be able to more expressively look through the data if we could avoid those database JOINs in the relational database and instead write queries that would allow us to flexibly look through those pathways in the graph database.
When we were evaluating choices, naturally we started looking at different graph databases, and the native graph model in Neo4j was a really big plus.
What have been the most surprising results you have seen from Neo4j?
Wytock: We’ve been surprised at the connectedness of some data versus others. Often when you’re in a relational database you’re not really thinking about those connections; it’s not front and center to the analysis.
You know that there are JOINs happening in the background to get from one table to another. Sometimes you’re creating some explicit ways to do those JOINs but when you’re writing a query you’re not getting bombarded with what those are.
We found that for certain types of analyses, there are huge performance concerns running certain queries versus others on data that is more connected.
If you could go back to when you started using graphs, what would you change?
Wytock: There are a couple of things that we would probably do differently if we were to start the projects we’ve been working on over again.
First, we’d make sure that we really know ahead of time what the model is going to be, so investing that time in planning and white boarding and looking at, if you’re coming from a tabular data format, the end result you want.
We would probably also reach out to the community a little bit more quickly than we did. We ran into a couple of performance concerns. We really thought that there was just some bug in the system.
Often it’s something that someone else has encountered and folks in the community have been super helpful in fixing those problems for us or pointing us to a resource that we didn’t know about.
What do you think is in store for the future of graphs?
Wytock: With graph databases and data analytics, I think that some really difficult engineering problems have been ameliorated by having an interface to see the connections in our data.
When clients or business-facing folks ask for things that violate a relational database model, you now have a tool to show them what those relationships look like, and that wasn’t really available before. That interface between the business-facing side and the engineering side is a lot easier, the friction is a little bit less, and there’s not as much work that has to be undone to explore data.
What is your favorite aspect of working with Neo4j?
Wytock: In working with Neo4j we found a really helpful community that cares about the product that they’re working on. That’s been really great to see. Sometimes projects are really promising but are wrapped up in one or two people.
The organization as a whole has been really easy to work with and extremely helpful and interested in the problems that we’re working on.
Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at content@neo4j.com
Never write another JOIN! Solve your RDBMS problems by reading the white paper,Overcoming SQL Strain and SQL Pain
Read the White Paper
Read the White Paper
