Assuming...
.you dont need to version more than one table
.you don't need to query the table by date
you can create a primary table and a detail table. the primary table will store the user ids and the user detail table will store all the information. The approach I'm showing below gets tedious quickly for large schemas, and very tedious for many to many relationships.

To use this database approach, on inserts, ie new user, a user and user detail are created. To update a user, you create a new userDetail. To query for a user entity, you get the most recent userDetail for a given userId.
If the user detail has an address entity that also needs to be under version control, you need to add a primary and detail table for the address entity as well. This approach gives you a lot of tables. I'm running a modified version of this where the user detail has a start_date and end_date that get updated so that I can easily query for what records were with at date x. (I'm running a very small db) for performant large databases, this is probably a horrible idea.
see the wiki for temporal validity for a bit more insight into what you may be trying to do.
here's an example of data history gone mad using this approach

In short, I'd recommend this approach if used sparingly. I'm kind of noob though so I'm going to put a disclaimer that a noob reccomends this approach as okay. Let me know if you need any clarification.