Graph databases are fantastic pieces of technology. I’ve already dived into the world of graph databases in previous articles, so if you’re looking for a primer, those would be a good start. But today, I want to cut through the hype and share some insights we’ve gained—along with a few pitfalls to avoid.
We kicked off our journey with a Ruby on Rails monolith, a solid choice that served us exceptionally well. Particularly in the unpredictable landscape of b2b e-commerce, where our product catalog is a kaleidoscope of variety—think T-shirts, Power Banks, Beach Flags, and more. These products don’t exactly fit neatly into a single MySQL table. Plus, it wasn’t just about storing these unique products; we were aspiring for more. We wanted to create a labyrinth of richer and highly connected data. Imagine being able to connect a coffee mug to its producer, to the manufacturing process, all the printing possibilities and perhaps even to customer reviews, all interconnected. To achieve this, we needed to delve into intricate joins and queries, a route which not the best for optimal performance to say the least.
Enter graph databases. They arrived with the promise of eliminating those headaches, especially when dealing with highly interconnected data. In theory, graphs pre-calculate all relationships, making data retrieval faster and more efficient. So, naturally, we were excited. Maybe too excited. We got swept up in the enthusiasm and started envisioning migrating our entire system to Neo4j, the shining star of graph databases.
But this is precisely where we should’ve pumped the brakes. The team was buzzing with excitement, visualizing a Neo4j-powered future while the tangible benefits kept getting pushed to the back burner. Let’s face it, tech has a thing for the new and shiny. Swept up in the wave of enthusiasm, we even toyed with the idea of moving unrelated features to Neo4j—a common pitfall in the development world where the allure of a clean rewrite often overshadows the grunt work of debugging and refactoring. Personally, I had my reservations about going all-in without fully understanding the Neo4j landscape. But, without any prior experience in the technology, I too got caught up in the collective optimism.
And then came the practical hurdles. For Ruby on Rails, there was no official Neo4j gem. We resorted to a community driver that, frankly, didn’t hold a candle to pg or mysql2. We stumbled into quirks and unexpected issues, turning what should’ve been straightforward development work into a maze of workarounds.
So, we stepped back and reassessed. With the benefit of hindsight and hard-learned lessons, we were better equipped to make a decision. Graph databases excelled where our data was deeply interconnected, but they weren’t the catch-all solution we had initially envisioned. We opted for a more balanced approach, using graphs where they made sense and sticking with traditional databases for everything else. The result? A hybrid system, held together by some judiciously applied “glue code,” that’s robust and scalable.
To wrap it up: be wary of the allure of new technologies. They’re tools, not magic wands. It’s easy to get caught in the siren song of a new tech stack. Graph databases have their place, but so does the code that’s been tried and tested in your existing setup. Before jumping headlong into something new, ask if it really solves a problem, or if you’re just trading old challenges for new ones. Make your choices with your eyes wide open, and perhaps the time you save can be better spent on innovations that genuinely drive your business forward.
Hope it helps. Cheers!
Here are the links to the previous articles:
Thinking in Graphs: A Transition from Relational Databases Data Modeling in Graph Databases: Building Intuitive and Scalable Structures