When structuring data you generally want it to be in 3rd normal form or higher. The normal forms the higher you go the less duplication you have in your data, b

When structuring data you generally want it to be in 3rd normal form or higher. The normal forms the higher you go the less duplication you have in your data, but then the more joins you will do and that could reduce performance. > A good example (but not only!) is login. You can have just user session, or session+token in DB, or session + devices (1 active token/device), etc. So maybe seeing business problems and how the DB was structured to help would be the best here. I think you're overthinking it a bit, besides I don't know if you're saying it but in case you are, you don't want to mix login information (like user account, name, login password etc) with a session. Those things are separate and have different requirements. For example let's say your site became so popular that you have scaling problems. It is perfectly fine to take the session and put it in nosql store, or (maybe even better) in a cache. This data is accessed on key/value basis and also while not great it won't kill you if the data disappears due to some outage (users just get log out). As to what you store there, session + device or session + token in DB is purely based on your need. Frankly I don't know what you mean by token in DB, in fact I'm not sure what do you mean session + device either. Sessions generally is a randomly generated ID that tied to a session, if user connects from a different device they will have another session anyway. I don't think this particular thing is something that relational database dictates. But you generally wouldn't want to place sessions in user table. Those two things are completely different even when they seem to be related. You should have separate users table and separate session table (most frameworks handle sessions for you, so you might not even need to think too much about it) > Oh maybe that's the reason I found those so tricky. I don't explicitly care about VCS, but I definitely care about migrations going wrong, and hopefully being able to revert if it goes wrong. Maybe if I get myself comfortable enough with manual migrations this is not such a huge topic though. In PostgreSQL (it might not be true in other databases) DDL (Data Modification Language) can be inside of a transaction. So you can start a migration with "BEGIN" and then check if what you did worked fine before you say "COMMIT". Note though, when I said developers want to have it version controlled. They do that to avoid any mistakes. Such as forgetting the BEGIN, or accidentally pasting wrong thing to the shell. So if you have a production data you absolutely should use them. But if I were you I would first try to learn it by doing it by hand on a test database. If you understand what is actually done the migrations don't seem that magical.