Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Neo4j 2.0 Comes with a New Browser and a Schema

Neo4j 2.0 Comes with a New Browser and a Schema

Leia em Português

This item in japanese

Lire ce contenu en français


Neo Technology has announced the general availability of Neo4j 2.0, coming with a new graph browser, node labels, an optional schema and an improved Cypher.

The most notable improvement in Neo4j 2.0 is the new browser UI enabling users to visualize and edit data in graph or tabular form. Below is a snapshot of a demo movie database, outlining one particular actor and his relationship with some of the movies he played in (shown in gray) and other actors (shown in red):


The nodes can have labels now, and it is a way to mark nodes as belonging to a certain group. A node can have multiple labels.

In what it seems like a return to the relational databases, Neo4j 2.0 supports the addition of an optional schema. This is meant to include meta-information that improves query execution.

The Cypher query language has been improved with OPTIONAL MATCH and MERGE clauses, literal node patterns and the ability to return literal maps and collections.

We have interviewed Michael Hunger, Head of Spring Integration and Developer Advocate at Neo Technology, to find out about Neo4j 2.0 compatibility issues, the use of schema, and the roadmap ahead.

InfoQ: Are there any compatibility issues between Neo4j 2.0 and previous versions?

MH: Yes, Neo4j is a major breaking change with enhanced data model adding the label concept and optional schema information.

Also the query language Cypher has undergone quite an evolution since 1.9 and for users of the embedded API transactions became mandatory also for reads and many deprecated things have been removed.

See also:

InfoQ: How does the new introduced schema make queries faster?

MH: The optional schema information (labels) allow for indexes and unique constraints which are automatically used in queries to transform filter conditions into index lookups. Also using labels as part of the queries allows the database only to scan subsets of the whole database when looking for non-indexed information. And as the third aspect, label information is inlined in the node-records, so testing existing nodes against labels is a instant operation and doesn't require further lookups to properties or relationships.

InfoQ: What happens when the database changes? Does one have to manually update the schema too?

MH: The indexes and constraints are keeping up to data with data changes.

For, e.g. additions of new labels you have to provide the new index/constraints definition then as well. But existing data that is augmented with new labels is automatically indexed behind the scene.

InfoQ: What's on Neo4j's roadmap?


- continuous improvements in user experience

- performance (read, write, query language)

- increase the (artificial) limits on nodes, relationships

- better import / export

- BI / Integration

- operational improvements 

- some development big data / graph compute

- simplified installation experience

- improved remoting / drivers

Rate this Article