Is a relational DB too limiting?

[vbilgin]

On a whim, I recently started looking at graphs and graph databases such as Neo4j. As I was reading up on the topic, a question started to come together in my mind: why doesn't SN move to a graph DB or a hybrid DB for its back-end?

I realize from a practical perspective that moving even from one relational DB to another is not an easy task. The change to RaptorDB has been slow going, which is expected, of course.

But from a technical architecture perspective, a graph DB seems to make a lot more sense. I can understand why SN started off with an RDB back when it was little more than a ticket management system. Back then, there were fewer records and fewer relationships between those records. I'm not overly familiar with early SN but I have to assume there was also less logic involved. An RDB makes total sense in that context. But now, even at zboot, an instance has orders of magnitude more records, relationships, and logic. Most importantly, relationships between all of these are really first-class citizens, though they aren't treated as such in the current DB.

References are a thing, of course, and are incredibly important, but in my opinion, the structure of an RDB and the referencing used in SN are too limiting. For example, a Business Rule record references a table on which the BR takes action. From this, we can easily see the basic relationship of [sys_script --acts on--> <table_name>]. But what happens when the action this BR takes ends up triggering another BR? Or it triggers some action to occur when a Scheduled Script Execution runs? These cascading effects are pretty common, at least in my experience. In the current RDB, it's basically impossible to model these relationships because you can't account for them in the DB's schema.

With a graph DB, however, relationships like this are treated as first-class citizens and can be modeled with ease. They can even be added dynamically since a graph's schema can evolve over time.

That's for the logical side of the platform but the data side can be modeled in a graph as well. Take a sys_user record for example: a user's relationship to various things such as CIs, groups, roles, and HR Profiles could easily be represented in a graph DB.

I'll admit that it's harder (and slower) to use a graph DB for transactional data. Auditing especially would not be as easy and versioning/update sets would be a pain, in theory. That's where a hybrid approach might work best: use a graph DB for anything related to logic (BRs, Client Scripts, Workflows, Flows, etc.) and leave the actual business/transactional data to an RDB. Then you'd just need to have a middle man between the two.

In any case, I'm posting this mainly to start a high-level theoretical discussion with any technical folks interested in hashing it out. Let me know your thoughts or if I'm off base with my thinking!

And if anyone from ServiceNow sees this (especially from the RaptorDB team), I'd love to know if a graph DB was ever on the table or evaluated.

Thanks!

PS. Feel free to move this post to another forum if it's not suited for this one.