Only if the majority of your posts will be deleted. Which I assume won't be the case. If you have lots of posts, and lots of code querying them, you want access to them as fast as possible. The access will be faster if the database can cache more. Databases cache by page. If a row is retrieved, the entire page the row will be in is fetch from disk, and kept in cache. The smaller your row, the more rows can fit in a database. The amount of pages that can be cached is limited by the environment. So, if you have more rows per page, then you have more cached rows for a given fixed number of pages that can be cached.

In other words, approach A wastes memory. And that can hurt performance. (Of course, it may not. Unless you measure you won't know. And maybe the difference in performance is insignificant. And even if A has better performance, it has to make a huge difference before I choose such a dirty design - it's feels worse than running without strict and warnings).

I wouldn't even have a 'deleted' column in the post_tbl table. This information can be deduced from the post having an entry in the removed_tbl table.