Your usecase is perfect for YugabyteDB. With the right partitioning you can have efficient writes and queries with linear scaling.
Regarding contacts table, you mean select * from contatcts where user_id=x
? If not explain it in a sql query ?
Adding a new column is instant cause it doesn’t need to rewrite the whole table. I’m guessing a column that can be null.
-
re performance
It will be better since you can use multiple nodes with more storage/memory/cpu.
It will worse for global transactions that span multiple servers.
It will be better for transactions that are inside 1 partition/server. -
re Do I need to split your database into two independent databases on different clusters or can all this be combined into one solution?
This can all be in 1 cluster. Doing a cluster-per-feature is mostly needed when access-patterns,requirements,sla,hot/cold data change a lot between features . I think you can use 1 cluster at first and slowly migrate only when necessary.
You can explain more your app, write-path and read-path so I can help on how best to use a schema that horizontally scales.