I look at graph/NoSQL databases like a prototyping tool. They allow you to work with semi-structured data before you have a solid understanding of the domain model. If you have a clear understanding of things, their properties and how they relate to each other, you would probably be better off reaching for Postgres/SQLite/etc.
Big picture, if someone else's money is involved (i.e. it's not my side project), I am going to select the oldest & most stable technology that will get the job done. Database engines are the last place you want to be playing in traffic if you are going to be on the hook for support. Save the "niche" curiosities for your personal time and you get the best of all worlds - a happy team, a happy customer and more frustration than you know what to do with.
I look at graph/NoSQL databases like a prototyping tool. They allow you to work with semi-structured data before you have a solid understanding of the domain model. If you have a clear understanding of things, their properties and how they relate to each other, you would probably be better off reaching for Postgres/SQLite/etc.
Big picture, if someone else's money is involved (i.e. it's not my side project), I am going to select the oldest & most stable technology that will get the job done. Database engines are the last place you want to be playing in traffic if you are going to be on the hook for support. Save the "niche" curiosities for your personal time and you get the best of all worlds - a happy team, a happy customer and more frustration than you know what to do with.
> Database engines are the last place you want to be playing in traffic if you are going to be on the hook for support.
This is a great line! I'm going to steal it if that's okay with you.
Yes, although I still find it easier to create one TEXT or JSONB column for prototyping.
The bad thing is that creating db/connecting to the dbms is still a big hassle.