All tables have those 4 columns as part of the spec (DB Naming convention - Round 2 - #8 by manassehkatz). Their purpose is audit related. My personal preference would be to make them not nullable for the member table rather than delete them entirely.
@misha130 One more suggestion: a dummy member could be created and the member foreign keys can initially be set to the dummy user, and then changed to the new user. If both SaveChanges() calls happen inside a transaction it should guarantee the correct member_id is set, but you’d need that dummy user created beforehand. I don’t think that would trigger the circular reference error.
If you don’t like that idea, I think you’ve identified a valid justification for allowing the created_by, and last_modified_by keys to be nullable, so I’d suggest to assume their NOT NULL status has been removed on the member table. I’ll set that in pgModeler and announce it in the next round and see if there’s any disagreement. The keys could still be set in a second SaveChanges call within a transaction so any error on setting the keys would roll back the entire creation attempt.