Originally from the User Slack
@Tushar_Vaswani: Hey guys,
I am new to the nosql world and scylladb.
I was looking out for migrating our codebase from sql to nosql.
But I have two questions:
- My model is relational so a lot of people recommended that I stick with SQL but at the same time I have seen some companies that too have relational data still use NoSQL. A prime example of this is discord. So I just wanted to know if I am making a correct decision because the argument makes sense but examples of some companies contradict
- If let’s say I decided to finally switch and get the things working now one more problem that I am thinking about is updating the denormalized data. For example let’s take that common user and comments example if I put the user name in the comments table then if the user changes his name I have to somehow update all comments to have a new user name which looks kinda inefficient to me considering he made so many comments. I am assuming discord also has a messages table and a users table and now if someone updates the user name then they have to apply that in the messages table. But if the user had like 100k messages in their lifetime that looks like a lot of updates which makes me think if it’s efficient at all to do this. If not then how a platform like them handles this.
Also btw I wanna switch to scylladb. That’s what I mean by NoSQL here
@Robert: Long story to tell, but about point 2.:
You can use some unique identifier which can’t be changed and that solves a problem of user name change. When username = A he wrote 1-100 messages, when was = B he wrote 101-200 messages. Other hand there is a static field in Scylla which You can be use to update and it of curse finally end like update in the all the rows (for whole partition) - so don’t need to update 100k records to change just 1 field. But also it’s not a good idea to have just 1 partition to handle 100k message, should be split by some date etc. so like 12 update to update whole year of messages per user. Btw. if it’s a common situation that users changes a name - also worth to think about that…
Another way is to do a client-side join, so have 2 tables and if one is a small load it every 15min (invalidate) to memory and handle the mapping and do a “SQL join” on the application side.
Of course can be a lot of different way to solve issue like that, but it mostly depends on Your business needs, what You want to achieve etc. If no-one in Your company is if fight (production) familiar with Scylla I would suggest to looking for some consultant to help with design, modeling, coding, best practice etc.
@Tushar_Vaswani: thanks for explaining in detail @Robert. Now I am getting some idea about how it really is done.
Looks like NoSQL world is not ideal and straightforward like SQL world. You just have to accept tradeoffs and move on for finding solutions.
@Robert: SQL could solve all bad modeling by multiple indexes - even query like multiple Cartesian cross will be finally executed by rbdms 
@Tushar_Vaswani: yes although that makes it easier
@Robert: easier means in that case sh.tty
@Krasimir_Popov: I think you can’t just switch it is never that straight forward, it depends on many moving parts, I would suggest you just add ScyllaDB as a second database and move data there that your application access frequently and needs speed and performance. Like that your team and you will gather expertise over the time and you can make informed decision if you can go without the SQL database or you keep both or you go back to SQL 
@Tushar_Vaswani: Got it also any recommendation for updates issue?
@Krasimir_Popov: uuid for example
@avi: It depends on you data and performance scale. If it works with PostgresQL and will continue to work for the foreseeable future, don’t change it.
If you need to manage many terabytes and/or have high performance needs, then the migration will be worthwhile.
@Tushar_Vaswani: makes sense yeah postgres works fine dont have large scale rn. Like just a million rows max in the biggest table we have.
but still just for knowledge purpose what would have been a possible solution for the updates?
@avi: Materialized views
@Guy: I’d also look into this lesson about denormalizing data in ScyllaDB University: Materialized Views, Secondary Indexes, and Filtering