but that is less of a cost than having to add "deleted=False" predicates in all of your queries. Maybe or maybe not. You can use a view. Or you may be usi

but that is less of a cost than having to add "deleted=False" predicates in all of your queries. Maybe or maybe not. You can use a view. Or you may be using an ORM that lets you set a default scope (essentially, a default WHERE clause - ActiveRecord lets you do this) It also depends on if you're designing an app for this from the ground up or if you're trying to retrofit an existing app with 90 million different hardcoded queries. Also depends on what you want to do with the deleted records. Do you want to do things with them? Maybe after a user is deleted, you want them to be able to log in, but you would prefer them to see a "sorry - your account has been deleted" message instead of "user not found." Maybe you want your support staff to be able to look at deleted users. Etc. Now you need to update your app logic so that it's flexible enough to look at "users_deleted" and "users". Which may be at least as onerous as messing with the WHERE clause on every single query. To be clear, I don't hate the "another table" solution. It's the right choice in a lot of situations IMO.