In 2018, MariaDB was the second-fastest-growing relational database (behind Postgres) and is a leading example of commercially supported open source innovation in the database sector.
But you knew that already. What you maybe didn’t know was that the former CTO of MariaDB is now a part of the Neo4j team. Ivan Zoratti joined Neo4j last year as the Director of Product Management. (Neo4j 3.5 was the first release completely under his direction.)
I sat down with Ivan after the 3.5 release to learn more about the (leading) man behind the database. Here’s how it went:
Tell us about yourself. What sort of things have you worked on in the past?
Ivan: I’ve been working in tech for nearly 35 years now. I fell in love with tech the second I laid eyes on my first computer.
It all started when I was in high school in the mid-80s. It was a technical school in Italy that had an IT department with a Digital Equipment Corporation (DEC) mini-computer. After school, instead of playing football like my peers, I was in the computer room with the Digital Equipment books, learning about the PDP-11 and how to program it. From there, I kept going.
The first database I worked with was Rdb by Digital (now Oracle Rdb). Back in the 80s, it was one of the most advanced relational databases, even though it’s not widely used today.
Fifteen years later, I joined MySQL AB – the Swedish company behind the MySQL database – that was in 2005. That was a milestone for me, because ever since, I’ve pretty much always worked full time on open source products, particularly databases.
Can you go into more detail about your time at MySQL and MariaDB?
Ivan: So MySQL was a Swedish company with a headquarters in Silicon Valley (talk about weird déjà vu when I started at this job), and then in 2008, Sun Microsystems acquired MySQL AB.
At the time, I was the Director of Sales Engineering at MySQL, and with the acquisition I became the Director of Systems Engineering, covering all Sun software. At Sun, “software” meant everything except for Java (a completely separate department for obvious reasons) and virtualization (which fell under operating systems and hardware).
In 2010, Oracle acquired Sun Microsystems, and we were, of course, part of the package. After that, a bunch of us MySQLers got together and discussed what we might do with the MySQL database. We decided to quit Oracle and start another company called SkySQL.
I started out as the Head of Services and then became the CTO once we decided not just to provide services, but also build software. We later merged with Monty Program, the software company founded by Monty Widenius – the original founder of MySQL – and some of the other key members of the original MySQL engineering team. Monty Program was working on a fork of MySQL called MariaDB. With the merger, the new company became known as the MariaDB corporation.
For readers who might not be familiar with MariaDB, can you give us the 30-second summary?
Ivan: MariaDB is a fork of MySQL, but it’s always been identified as a drop-in replacement for MySQL. So you can replace your MySQL database with MariaDB and your application keeps working the same as before. The only difference are some behind-the-scenes improvements for DBAs and DevOps which aren’t always available in MySQL.
For example, MariaDB introduced multi-source and parallel replication before MySQL. In the MySQL world, replication is probably one of – if not the most – important features. You have a primary system and a set of secondary systems. They are originally defined as synchronous replication, meaning that you replicate data to the secondary systems, and whenever these secondary systems can accept the data, they are updated.
But then there were issues in terms of how quick you could update these systems. There were needs for synchronization without, of course, undermining all the advantage in performance when you have asynchronous systems. Because, of course, in synchronous systems, you have possible spikes of workload that you must manage.
To address this challenge, MariaDB added features like parallel replication where there were more than one thread running and executing commands inside the secondary systems. And that was a significant improvement in the replication strategy. MySQL eventually implemented similar parallel replication features and did them very, very well – but they were years behind MariaDB.
And you see this pattern over and over again. Oracle always eventually catches up to MariaDB – and sometimes (admittedly) does it better – but they’re always behind the curve. So you could say MariaDB is the pioneer of new features in RDBMS.
Why’d you join Neo4j? What brought you over to the Graph Side?
Ivan: I first heard about Neo4j about three years ago through an old colleague of mine, Anthony Flynn. He and I go way back. We worked together at MySQL and then also later during the formation of SkySQL.
After Anthony had joined Neo4j, he invited me to a local Neo4j meetup. I found the whole idea of a graph database really intriguing, and I was curious. I liked the idea of it. I thought, “Wow, there is something really good here. This is something very different compared to other databases.”
Coming from the relational world – where everything is pretty stable and innovation is always in small, slow steps – NoSQL databases were a much different approach to database management. Graph technology was really new to my mind, not in terms of structure as much as in terms of how you can actually implement and use it.
Shortly after that, I met Jim Webber, then Philip Rathle and later on, I met Emil and other Neo4j team members, and they were all awesome. That’s a box I always have to tick if I’m going to join a new company: There has to be a combination of really great people.
Around this time, I had been working at Bay Area startup even though I was based in the UK, so I was commuting every other month between the UK and the US. That’s when I started to talk more with Philip [VP of Products at Neo4j]. We had a lot of nice discussions, and when he offered me a job, I could see it was a great opportunity to work together, so I accepted!
How does it feel to cross over from the relational database world to the graph world?
Ivan: There’s a lot of friendliness and relationship-building in the graph community. There’s also a lot of passion about graphs and the way graph databases work. A lot of people in this community think graphs are the ultimate solution and that there is nothing else out there that could do any better.
I really admire that kind of passion and think it’s really important to have. I have a similar passion, but I’m also a pragmatic person. I think relational databases – as much as document databases or key-value stores – are good for some tasks and not good for others. I believe there’s a natural place for all of these products and database systems to perform the jobs they were designed to do. All of this database technology can and should naturally coexist and work well together.
The same goes for graph databases, and specifically Neo4j – because I believe it’s the best implementation of a graph database that you can find in the market today. There are some tasks you can do so quickly and easily with a graph database that you can only dream of doing if you only have an RDBMS. There are literally so many perfect use cases where Neo4j is the best fit, the right tool for the job.
Sometimes I need to completely clear my mind from the old relational approach and re-engage with the graph paradigm, which is something I do more and more. I still sometimes need to use the old-style relational approach, or even key-values. I’ve also had a chance to work with document stores in the past, so I’ve been lucky enough to be exposed to so many different technologies.
That exposure helps a lot in understanding the best way to approach things on a daily basis.
What are you most excited about with joining the Neo4j team?
Ivan: One of the best things about my job is that there is so much to love about this product, but there’s also so much more we can still do and build on, to go beyond the use cases you find today.
I look forward to taking the Neo4j database to another level, not just spanning its significant set of current solutions but to something that’s an order of magnitude bigger. The product has so much potential, and I want to see it expand its power with specific features for the enterprise and in the cloud.
The perennial value of Neo4j is the power to have a natural structure to your data that fits with so many existing and well-known graph algorithms – especially those used in AI and machine learning, for example – and a lot of other data businesses don’t have that kind of edge. That’s powerful.
In the future, Neo4j will be the graph database platform for many, many applications and services. When it comes to expanding the product, the possibilities are endless.
How can the Neo4j community connect with you further?
Ivan: I’m on a lot of different platforms, feel free to connect with me on any of them:
Any closing thoughts?
Ivan: For those of you who read my blog (or who are maybe checking it out for the first time), you’ve probably noticed that I haven’t blogged (yet) about Neo4j.
However, I have so many ideas that will become a part of the new version of Neo4j, and I really want to share them with everybody because I’m a strong believer in open source and the value of a developer community – not just in terms of open source code but in the exchange of ideas and discourse that focuses on achieving goals. Community discussion and sharing makes things even better.
I believe that by sharing ideas and information, and by interacting with people via comments and suggestions, we can all collectively make things even better. So in the near future, look out for more articles published by me – and more importantly, let me know what you think!