Category: graph database (Page 1 of 2)

Graph Story is now all-Enterprise, all the time

Today we have some exciting news!


All Graph Story Neo4j plans now offer Neo4j Enterprise Edition.

That means every plan we offer from here on will include Neo4j Enterprise, and everything that goes along with that:

  • Automatic daily, weekly, and monthly backups
  • Hot backups and hot exports
  • Clustered Replication in Multi-Server Setups
  • Enterprise Lock Manager
  • Cache Sharding
  • Cypher Query Tracing
  • Property Existence Constraints

With this change comes a new pricing model for our plans. As a Neo4j Solution Partner, Graph Story will include the price of the Neo4j Enterprise license as part of every plan. Pricing for that license varies based on the size of the company. Under this tiered pricing, startups and smaller companies receive significant discounts, and larger companies can get the dedicated support options they need.

Here are our three pricing tiers:

Level Startup Growth Premier
Monitoring 24×7 24×7 24×7
Guaranteed resp time 24hr1 12hr1 15m1
Named Contacts 1 3 5
Support Chat & Email Phone, Chat, & Email Dedicated
For companies with 1-20 employees
Up to US$3M annual revenue
21-50 employees
Up to US$3M annual revenue
Over 50 employees
Over to US$3M annual revenue
Availability Simple application required2 Immediate deployment Immediate deployment

View our new pricing now

Within 6 months, we will transition all of our existing customers on Community Edition plans to Enterprise Edition plans. We will have more information about that process in the very near future.

We are committed to helping our new and existing customers be successful, no matter their size or needs. If you have any questions or concerns, please let us know via email at or contact us using web chat.

Ed Finkler
Graph Story

1: While these are guaranteed times, our median first response time in the last 90 days is 5 minutes (as of Tuesday; November 29, 2016)

2: Startup pricing requires that you send us an email with information about your company’s qualifications, and what plan you’re interested in. More info

Graph Story Newsletter: Much Love for Beginners 💚💜💙💛

This week is all about BEGINNERS! Here are the best resources we could find for folks just starting out with graph databases and Neo4j.

What the heck is a graph database?

We created a short series on the what, why, and how of graph DBs, aimed at people who have never touched one. It’s important to get the basic concepts, but so many articles focus on big picture stuff (BIG DATA AND MACHINE LEARNING AND NETWORKS AND STUFF). Our articles make it easy to understand what the graph is, and how to make it work.

Getting Started with Neo4j

This tutorial is a nice intro to Neo4j by Neo Technologies. It’s essentially the same thing as the built-in :play movie graph command in the Neo4j Web UI that you get with every Graph Story instance, but this has more explanatory content to go along with it, as well as exercises and solutions.

Exploring networks with graph databases

Data journalist Leila Haddou has a great tutorial for beginners that focuses on exploring data relationships with Neo4j. It steps you through very basic Cypher, and importing CSV datasets into Neo4j, then finding connections that would be difficult or impossible to discover in a relational DB.

Neo4j Flask

Data scientist Nicole White created a small microblogging app powered by Neo4j and the Flask microframework for Python. This is a great example of seeing Neo4j and Cypher in a real, working app situation.

Cypher Cheat Sheet

They call it a “Refcard,” but it’s more fun to call it a cheat sheet. I’m always forgetting how to do this or that in Neo4j, and having this quick reference close by is super handy.

• • •

Found other awesome resources for graph dbs or Neo4j? Let us know!!

Until next week,

Ed Finkler
Graph Story

Graph Story Newsletter: 10% Off Any New Instance 💰

Have we mentioned how much we love you lately? We love our customers, because you’re the best. Because you’re so great, we’ve got an awesome offer for you!

ONE WEEK ONLY: Get 10% Off ANY New Graph Story Instance for 12 months

We have the best prices in the graph game, but we love you SO MUCH that we’re gonna do you a real solid. 10% off any new instance, any price, any provider, for 12 months. That’s the kind of awesome stuff you get when you subscribe to the GS Newsletter. Only the link in this newsletter will work – accept no imitations.

10% off any new instance for 12 months

Offer expires in one week!

Create a CMS with Neo4j & Elasticsearch

John David Martin from Unicon has a cool post on the Neo4j blog about creating a CMS with Neo4j and Elasticsearch. In this case, he demonstrates how he created a tool to provide personally relevant content via text search, utilizing the Page Rank algorithm to score results.

Natural Language Processing Made Easy

Another William Lyon article on pulling data from an API and doing analysis on it caught my eye, this time about grabbing data from Best Buy product reviews and analyzing the text for opinions. William’s article Building a text adjacency graph from product reviews with the Best Buy API shows how you’d grab the data, but then it turns over the subject of doing natural language analysis to a couple other blog posts.

The one I liked the most was Natural Language Analytics made simple and visual with Neo4j by Michael Hunger, which does a great job of demonstrating how you split up natural language into a graph structure, and then do stuff like find the most important phrase of the text.

William also pointed to Max de Marzi’s post Summarize Opinions With A Graph. It’s from a few years ago, but it’s still very relevant, focusing primarily on the concepts used in breaking down natural language into analyze-able graphs.

Internationalization with CypherMessageSource, Spring and Neo4j

Eric Spiegelberg has a guest post on the GraphAware blog about internationalization powered by Neo4j. This focuses on using the Spring framework and an implementation of the MessageSource interface that retrieves message definitions from a Cypher-powered graph like Neo4j. I’d love to see examples like this for other stacks.

• • •

Are you doing something cool with graphs at Graph Story? Let us know! We want to talk about what our customers are doing here in the newsletter.

Until next week,

Ed Finkler
CTO, Graph Story

Graph Story Newsletter: Graphs Make Us Safe From Tainted Burritos

I stopped eating burritos from a major chain a while ago because I didn’t want to die, but they pulled me back in with their brown rice and delicious barbacoa. As we learn below, I chew a little more confidently now, knowing graphs are watching out for my food safety. Also you should buy a Graph Story instance now.

The benefits of graph databases in relation to supply chain

This headline sounds like some business nerd mumbo jumbo, but it has real benefits when you’re getting your burrito on and don’t want to get food poisoning. Chris Morrison, CEO at Transparency One, writes about the need for food brangs to track supply chains, so they can know about potential disruptions or safety issues:

Graph database technology presented itself as a viable solution. That’s because graph databases recommend themselves as being uniquely well qualified at handling large, highly-connected volumes of data at scale.

There are a number of graph databases available, and as an example the Neo Technology’s Neo4j, which took 3 months to build, was tested with dummy data for several thousand products, and there were absolutely no performance issues.

As for the search response time, results were sent back within seconds.

Read the whole thing.


We’ve mentioned this before when talking about William Lyon’s awesome blog posts, but neovis.js is a promising JavaScript library that focuses on visualizing Neo4j data. The project could probably use some assistance from motivated individuals.

Neo4j With Scala: Migrate Data From Other Database to Neo4j

Part of the Neo4j With Scala blog series, this post focuses on importing data info Neo4j from PostgreSQL, MySQL, Cassandra, and Oracle. All of this is accomplished with the awesome APOC plugin, which we are happy to install on any Graph Story Neo4j instances.

• • •

Are you doing something cool with graphs at Graph Story? Let us know! We want to talk about what our customers are doing here in the newsletter.

Until next week,

Ed Finkler
CTO, Graph Story

Graph Story Newsletter: Leftpad wouldn’t have happened if you used Neo4j

I’m in Seattle this week to talk graphs at PNWPHP, but nothing can keep me from you, or writing this newsletter. NOTHING.

Graph Database with Neo4j and a .NET Client

If you’re using .NET, Chris Skardon and Michael Hunger have written a great intro to Neo4j on the .NET platform. It’s a quick intro to Graphs and Neo4j, plus the basics of calling Cypher queries from C#.

Oh, you wish you had Neo4j on Azure for your .NET application? Graph Story can do that for you!

Neo4j + KeyLines: The Developer’s Route out of Dependency Hell

Hey, remember leftpad? Oops! That sucked, right? Miro Marchi from Cambridge Intelligence breaks down how he used Neo4j and the KeyLines Toolkit to analyze NPM package dependencies and find what would be affected by loss of a single package. He also does analysis of code licenses and compatibility issues. Cool stuff!

William Lyon’s blog is filled with awesome Neo4j articles, and this one is no exception. It steps you through creating a content recommendation system based on links posted to Twitter using Python. It has great, detailed code examples, taking you from retrieving the data on Twitter to scoring links for recommendation in Neo4j.

• • •

Are you doing something cool with graphs at Graph Story? Let us know! We want to talk about what our customers are doing here in the newsletter.

Until next week,

Ed Finkler
CTO, Graph Story

Graph Story Newsletter for Friday, Sept 9, 2016

A Song of Vertices and Edges

Big RAM Neo4j Instances on Google Compute Engine

Do you need a phat, RAM-heavy virtual machine for Neo4j? It’s worth checking out what Graph Story offers on Google Compute Engine. A 4-core instance with 26GB RAM costs less than an AWS 4-core instance with 15GB. More RAM, less money, seems legit. More and more of our customers are getting on GCE because of the pricing we can offer. Check out our pricing page for more info.

NDP Episode #9: Graph Databases with Neo4j

On the latest episode of the NoSQL Database Podcast, host Nic Raboy is joined by Neo4j developer relations person Ryan Boyd to talk about some key advantages that graph databases have, and why they’re so much better than alternatives in modeling relationships. There’s important info here for winning database arguments with your friends and colleagues.

Analyzing the Graph of Thrones

Man, isn’t Game of Thrones cool? Not the books because I don’t read, but the show with the blood and the nudity and the swords. That is awesome. You know what else is awesome? Graphs. Let’s combine them!

William Lyon did just that with his article “Analyzing the Graph of Thrones,”which breaks down analysis of the GoT social graph. It’s a great read, in particular because it does an excellent job of explaining several graph metrics like “betweenness centrality” and “pivotal nodes” and other smart words. Then the author pulls it into python-igraph, a port of an R graph analysis library, to do stuff like calculate page rank and community detection. The examples are straightforward and comprehensible, and there’s tons to learn from here.

Power a Github Notification Bot for Issue Reviewers with Graph Based NLP

Our boy Christophe Willemsen over at GraphAware wrote up a really interesting blog about building a bot that automatically chooses and notifies reviewers for GitHub pull requests. He uses the APOC procedures library and the GraphAware Natural Language Processing plugin for Neo4j, which is totally going to available real soon now. It’s a good breakdown on how you would load external data into Neo4j and use NLP to analyze and make conclusions about your dataset.

• • •

Are you doing something cool with graphs at Graph Story? Let us know! We want to talk about what our customers are doing here in the newsletter.

Until next week,

Ed Finkler
CTO, Graph Story

GraphStory helps AgSmarts enable the next agricultural revolution: The Agri Internet of Things

Over the last 200 years, the world has witnessed the agriculture industry make tremendous strides in producing more crops with less labor and overall better agriculture practices. The amount of labor needed to grow 100 bushels of corn has gone from 80 hours in 1850 to 2 hours today. In the same period, the yield for one acre has gone from 40 bushels to over 160 in good years.

Even with these advances in agriculture, farmers must continue to innovate to be successful. Farmers manage their fields while needing to understand dozens of variables, such as changes in weather patterns to the impact of seeding patterns. In addition, farmers in California – as well as other areas of the US – have also met with the harsh realities of drastic drought conditions. To that point, water scarcity is only one of the effects of a rapidly changing climate that is affecting farming.

High Tech in Agricultural Progress

AgSmarts, a two-year old startup based in Memphis, TN, is focused on helping farmers by providing unprecedented and specific crop information that, in turn, lowers their operational expenses and optimizes crop yields. AgSmarts’ Precision Ag includes moisture-sensing technology, predictive analytics, and farm equipment automation that represent an innovative revolution in data-driven agriculture.

Farmers are furnished with smart sensors that connect wirelessly to the cloud and collect & analyze data – from real-time weather data, crop and other variables in their fields. This data helps the crops tell the story about the impact of farm management descisions and changing conditions and, ultimately, can provide direction in order to produce greater yields.


Big Data helps Agronomics

Wireless technologies and the internet of things have made it possible to create affordable field sensors that constantly measure critical data like temperature and soil moisture. Data collected by the sensors is uploaded to the cloud. AgSmart combines the sensor data with weather data, crop growth and many other data points and stores them in a graph database. Graph databases are optimized to quickly create insights from large datasets – turning data into actionable insights.

“Graph Story has been instrumental in getting our cloud application up and running in such a short time. Their hosted graph database gives us all the advantages of a scalable, lightning fast, modern big data solution without any of the hassles of maintaining it and worrying about scalability” says Clayton Plymill – CTO and co-founder of AgSmarts.

In partnering with AgSmarts, Graph Story has helped with the design and implementation of its groundbreaking application as well as hosting and support. Our service allows AgSmarts to focus on their customers and their core business as well as provides an affordable, scalable platform to help further their goals in providing amazing technology in agriculture.

To get started with the Graph Story platform, sign up for our free trial or contact us at contact us with any questions!


About AgSmarts: Based in Memphis, TN, AgSmarts is a Precision Ag technology company that offers remote wireless sensing, predictive irrigation and crop management analytics, and equipment automation that collectively represent a revolution in data-driven agriculture. AgSmarts’ platform combines hardware and software solutions into a versatile, powerful and cost effective suite of tools that producers, researchers and agronomic consultants can use today in the struggle to conserve natural resources, control operational costs and maximize crop yields. For more information about AgSmarts, please visit


Why use a Graph Database?

What do LinkedIn, Walmart and eBay as well as many academic and research projects have in common? They all depend upon graph databases as a core part of their technology stack.

Why have such a wide range of industries and fields found a common relationship through graph databases?

The short answer: graph databases offer superior and consistent speed when analyzing relationships in large datasets and offer a tremendously flexible data structure.

As many developers can attest, one of the most tedious pieces of applications dependent on relational databases is managing and maintaining the database schema.
While relational databases are often the right tool for the job, there are some limitations – particularly the time as well as the risk involved to make additions to or update the model – that have opened up
room to use alternatives or, at least, consider complimentary data storage solutions. Enter NoSQL!

When NoSQL databases, such as MongoDB and Cassandra, came along they brought with them a simpler way to model data as well as a high degree of flexibility – or even a schema-less approach – for the model.
While document and key-value databases remove many of the time and effort hurdles, they were mainly designed to handle simple data structures.

However, the most useful, interesting and insightful applications require complex data as well as allow for a deeper understanding of the connections and relationships between different data sets.

For example, Twitter’s graph database – FlockDB – more elegantly solves the complex problem of storing and querying billions of connections than their prior relational database solution. In addition to simplifying the structure of the connections, FlockDB also ensures extremely fast access to this complex data. Twitter is just one use case of many that demonstrate why graph databases have become a draw for many organizations that need to solve scaling issues for their data relationships.

Graph databases offer the blend of simplicity and speed all while permitting data relationships to maintain a first-class status.

While offering fast access to complex data at scale is a primary driver for graph database adoption, another reason they offer the same tremendous flexibility that is found in so many other NoSQL options. The schema-free nature of a graph database permits the data model to evolve without sacrificing any the speed of access or adding significant and costly overhead to development cycles.

With the intersection of graph database capabilities, the growth of graph database interest and the trend towards more connected, big data, graph databases increase the speed of applications as well as the overall development cycle – specifically how graph databases will grow as a leading alternative to relational databases.

Uncovering Open Source Community Stories with Neo4j

Every dataset has a story to tell — we just need the right tools to find it.

At Graph Story, we believe that graph databases are one of the best tools for finding the story in your data. Because we are also active members of several open source communities, we wanted to find interesting stories about those communities. So, we decided to look at package ecosystems used by developers.
The first one we tackled was Packagist, the community package repository for PHP. Nearly 20,000 maintainers have submitted over 60,000 packages to Packagist, which gives us a lot of interesting data to investigate.

How We Used Neo4j to Graph the Packagist Data

Collecting this data and getting it into Neo4j was relatively straightforward.

One HTTP endpoint on the Packagist site returns a JSON array of all the package names. We iterated over that, and made individual calls to another endpoint to retrieve a JSON hash for each package, which includes both base package data and information on each version of the package, including what packages a given version requires.

The data model for our initial version was pretty straightforward. We have three node labels:

  • Package
  • Maintainer
  • Version

and five relationship types:


This certainly isn’t a complete schema to represent everything within the Packagist ecosystem, but it let us do some interesting analyses:

  1. What packages get required the most by other packages?
  2. What maintainers have the most packages?
  3. What maintainers have the most requires of their packages?
  4. What maintainers work together the most (packages can have multiple maintainers)?
  5. What are the shortest paths between two given packages, or two given maintainers

Our Findings

You can see our results so far at

Some of what we found was expected: certain well-known open source component libraries get required the most, like doctrine/orm and illuminate/support.

It gets more interesting when examining maintainers, though. Some are high profile folks in the PHP community, like fabpot and taylorotwell, but some are people with whom we weren’t as familiar. It certainly made us re-examine what we thought we knew about the PHP community – it’s not always folks who are speaking at conferences that are making big contributions.

The shortest path analyses were interesting as well. There were a few packages that showed up in these paths over and over to tie together maintainers and packages, such as psr/log. “Keystone packages” might be a good term for these, because they seem to join and support the PHP open source community again and again.

A Cypher Example: Finding Top Maintainers by Packages

Here’s one example Cypher query we ran to find the top Packagist maintainers by package count:

MATCH (m1:Maintainer)<-[:MAINTAINED_BY]-(Package)
WITH m1,COUNT(*) AS count
WHERE count > 1
WITH m1,count
RETURN as name, count
LIMIT { limit }

See the results of this query and others on

Why We Used a Graph Database

Much of what we’ve done would be possible with an RDBMS or a document database, so why do it in a graph database – specifically Neo4j?

We found three major upsides while working on this project:

  1. It is so much easier to map out data and relationships. Making relationships in RDBMSes work, even in simple cases, is harder, and significantly more difficult to change down the road. Compared to popular document databases, Neo4j relationships are done in the database — we don’t have to maintain them with application logic.
  2. Discovering how people and packages are connected is much easier and faster than with RDBMSes and popular document databases. Cypher and the graph model makes it easy to get the data we want without complex SQL joins or a wrapper script in another language.
  3. Trying new queries to explore the data is so convenient with Neo4j’s web interface. It’s quick and easy to prototype and profile from there, and then copy and paste the Cypher into your app.

We’re obviously big believers in graph databases at Graph Story, but this is a fun project that highlights a lot of the advantages of Neo4j. We found a number of interesting stories in Packagist, and there are certainly more to uncover.

Easy Geocoding For Your Graph

Longitude west of Greenwich

At Graph Story we’re all about making the lives of developers easier, because we’re developers too. To that end, we’re announcing our newest feature to do just that: a geocoding service for your graph database. This allows Graph Story customers to efficiently geocode addresses and store them in their graph, without using a third-party service.

The service is exposed as an additional endpoint in the Neo4j HTTP API. The developer will make a POST request against that endpoint that sends the address information as JSON in the body. The service will geocode the address, create an :Address node in the Neo4j DB, and return the node data.

We can use any http client tool to send these requests. In the tried and true curl, we’d call the endpoint like so:

  -H "Content-Type: application/json" 
  -H "Accept: application/json" 
  --data "{ "streetAddress": "902 Cooper Street", "city": "Memphis", "state": "TN", "postalCode": "38104" }"

We can also use httpie, which makes sending JSON a lot easier, like so:

  streetAddress="902 Cooper Street" city=Memphis state=TN postalCode=38104

Either way, the request will look like this:

POST /graphstory/geo/geocode HTTP/1.1
Accept: application/json
Authorization: Basic REDACTED
Content-Length: 95
Content-Type: application/json
Host: HOSTNAME:7474

    "city": "Memphis",
    "postalCode": "38104",
    "state": "TN",
    "streetAddress": "902 Cooper Street"

The response will look like this:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Server: Jetty(9.0.5.v20130815)
Transfer-Encoding: chunked

    "data": {
        "node": {
            "bbox": [
            "city": "Memphis",
            "formattedAddress": "902 S Cooper St, Memphis, TN 38104",
            "gtype": 1,
            "lat": 35.12103275,
            "lon": -89.990982,
            "postalCode": "38104",
            "state": "TN",
            "streetAddress": "902 Cooper Street",
            "uuid": "9f21cd5b-151f-11e5-b1a9-d71b198494e6"
    "status": "success"

Additional notes:

  • If an :Address node created with the same request fields already exists, the existing node data will be returned – it won’t create duplicates
  • For authentication, just use you the username and password for Neo4j instance
  • Request fields are as follows
    • streetAddress (required)
    • city (required)
    • state (required)
    • postalCode (optional)

Keep in mind that this is an alpha feature, so things can and will change. Possible changes to anticipate:

  • The return format may change (probably the bbox and gtype values will go away).
  • New arguments to the endpoint, like sending the entire address as a string and letting our service parse it. What we change will be strongly influenced by your feedback, so if you have ideas or problems, please let us know!

For now we are enabling the geocoding service only for customers who request it. Drop us a line at and let us know you’d like it turned on, and we will get right on it. All we ask is that you let us know what you think!

Page 1 of 2

Powered by WordPress & Theme by Anders Norén