Will different tables for different Users help in performence I have this Posts table. Somehow Read/Write ratio is 50:50. And we have to write very frequently.

Now suppose I am going to update 1000 post 500 users each, every minute. I think this will overcrowd the post table. So I am thing to have n different table for Posts like Posts_a, Posts_b, Posts_c.. and so on.

And I will have a posts_table field in the users meta data. 

Now I want to know if that is a proper solution.
You only need 2 tables:


Users (user_id (PK), username, password, email, created_at)
Posts (post_id (PK), user_id (IX), subject, body, created_at)


Updates to either table would be done using the PK so they will be very fast. A simple JOIN can be used to retrieve posts of a particular user based on username, or a simple SELECT if the user_id is already cached.

Later on, any new features would be another table, referencing data in the aboves. Let's say you wanted to add a feature that tracked 'Post Likes'. Create a table 'post_likes' (post_id (PK), user_id (PK), created_at). Each time a user likes someone else's post, insert to this table.

Or allowed people to 'subscribe' to a particular user. 'user_subscribe' (subscribee_id (PK), subscriber_id (PK)). When user #14 makes a new post, 

SELECT 
  u.email 
FROM user u 
LEFT JOIN user_subscribe us ON u.user_id = us.subscribee_id 
WHERE 
  u.user_id = 14


then email all those people of the new post.

Until your "posts" table reaches the ~500-700GB range, you should be fine with this. After that, we can discuss proper sharding.