The 5-Minute Interview: Wouter Crooy, Technical Lead at albumprinter(Albelli)

“Neo4j stood out of the NoSQL movement as having all the advantages of traditional relational databases,” said Wouter Crooy, Technical Lead at albumprinter.

While relational databases work well for some use cases, albumprinter relies on a polyglot persistence architecture to provide customers with a way to easily manage and create products from their personal photo collections.

In this week’s five-minute interview (conducted at GraphConnect in San Francisco), we discuss how the albumprinter team developed their graph recommendation engine — as well as exciting plans for the company’s future.

Talk to us about how you use Neo4j at albumprinter.

Wouter Crooy: We are a photo products company that creates moments that last, with products ranging from wall decor to cars. We saw a gap in the market for organizing photos and decided to start a company that would help our customers find and sort their photos and make products. We chose Neo4j because with a graph database, we can create relationships between photos. We do that based on the metadata we store in the Neo4j database.

What made Neo4j stand out?

Crooy: Neo4j stood out of the NoSQL movement as having all the advantages of traditional relational databases. It’s a reliable asset, we can continue working in transactions, and it combines the benefits of both NoSQL and relational databases. It also provides us with a database that is tight and reliable, which is especially important as a company that works with customer data.

What are some of the most surprising results you’ve had working with Neo4j?

Crooy: We rely on polyglot persistence for our architecture, so we have multiple databases and use the one most suitable for each particular use case. Our scalability is cloud-based, and the ability to backup data is incredibly important for us.

One of the most surprising things we found along our journey was that we had to abandon the traditional relational model of storing data in tables and records, which was helped by the fact that we had a large domain model to store in the database. On our scale, we needed to relearn the way to normalize data. In a traditional database, you have multiple tables that you have to constantly debug. Now we need to debug the nodes by making sure they have fewer properties, and we had to learn how to “walk the graph.”

Knowing everything you know now, if you had to go back in time and start over with Neo4j, is there anything you would do differently?

Crooy: We would go back and optimize our data model. On the performance side, we were on the edge of what was possible, and there are definitely things to improve. So even though what we did with Neo4j was ultimately what we needed, there’s always stuff to learn that could have made our product better.

Anything else you’d like to add?

Crooy: It has been an exciting journey, and thanks to Neo4j, we had a short time to market when it came to creating all of these features. We are really happy with it.

Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at content@neo4j.com