I would create something as:

“users”: id, email …
“followings”: id, user_id, follower_id

unique constraing on user_id and follower_id. Both user_id and follower_id are referencing users table. Just that the one is user being followed, the other one is user who is following that user.

I’ve often used actual SQL, I would here too except I wanted to give Ecto a try and I seem to quite like it, though I do have to fragment stuff up a lot due to Ecto limitations, so I’ve not seen that it was required by poorly made ORM’s (thankfully Ecto is comparatively not poorly made ^.^), I’ve tried to follow SQL tenents, even with my Ecto work (which is why almost none of my models have an ‘id’ field, well they often do, but not as Ecto would expect it to be so I have to @primacy_key false quite a whole lot).

(How do you reply to a post as a new topic?)

I’ve always written a join table like followings as:

followings: user_id follower_id

With no base ‘id’ column as I’ve found them useless on join tables, I then make user_id and follower_id a combined primary key with indexes on user_id or follower_id depending on which direction (or both) I expect to be accessing it from. Is there actually a good reason to put an ID column on a pure many-to-many join table I am curious?