InfoQ interviews 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

Read the full article.