Account service needs migrating, to AWS cause thats where everything is going.

Manager has got it in her head that a document store would be ideal for this.
My knee jerk reaction was a big No, i was told we'd discuss this at a later time.

My main argument here is that data is inheritly relational, and now i'm looking for more.

Any ideas why a documentstore is not a good fit for accounts?
Thanks!

inherently relational...

Interesting.

Is it?

Mostly it's not relational, it's hierarchical.

(Note that I'm not talking about the type of database, rather the type of relationship).

An organigramm is always a tree like structure, which isn't representable easily in any form of database.

Nested sets as one solution or - in general - parent / child associations can be modeled in a document oriented or relational form.

Or DIT / LDAP, which is a hierarchical database.

The question is more of "what is the goal".

A document oriented store has integrated the possibility for extensive searching, something you can do in SQL if the RDBMs supports fulltext / NGRAMs, but which makes less fun.

If you want to go fully nested, with e.g. a complex permission system with group / user permissions, I'd rather tend to relational or hierarchical. Nested sets in document store become very inefficient with increased depth.

I'd *always* build a prototype and demand a very clear specification and test it out.

Nested sets are mostly specialized solutions with little room for adaption - when it's written, it's not possible to change it without tearing everything down.