The question of performance between an
UPDATE statement or a similar
DELETE statement is too broad of a question to say which one is faster. It'll depend on the specific query used in both cases among other factors such as the schema structure and architecture, including how the table is indexed.
To address your specific example, I'm going to assume you're actually referring to the feed, e.g. the
StatusFeed in Facebook, which is only the top N items, and is very ephemeral i.e. it changes on every refresh of the page (since I consider
Notifications not very ephemeral and always expect the same
Notifications to be waiting for me to view, regardless of how many times I refresh the page).
In such an example a traditional RDBMS could be used, like PostgreSQL, but might be a little overly architected of a choice for something that doesn't require much persistence. As Caius Jard points out, you would likely be better suited to use something designed for high-frequency and low-persistence like an in-memory solution, or possibly even a document data store since the schema is simple and there's not much relational logic needed to support such a use case.
If you were still fixed on (for the theory of it) trying to implement this with a traditional RDBMS then you'll likely generate less transactions and therefor have some slightly less overhead by doing only
UPDATES as opposed to
DELETES. But again, as far as which methodology will be faster overall or cause the least amount of contention, will very much dependent on how the schema is architected.