разделять стоит, и вот почему это не просто "красиво на схеме".

User - это identity: email, password hash, is_active, created_at. Эта таблица почти не меняется, к ней идут все запросы на аутентификацию, её надо держать маленькой и быстрой. Profile - это всё социальное: фото, виды спорта, bio, предпочтения. Меняется часто, может быть неполным, может кэшироваться отдельно.

в Django это классически решается через AbstractUser + OneToOneField на Profile. Создал юзера - профиль пустой, заполняешь потом. В FastAPI то же самое через две модели SQLAlchemy.

если всё в одну таблицу - начнёшь добавлять поля в User, и через полгода у тебя там 40 колонок, половина nullable, и SELECT * на каждый запрос авторизации тянет всё это богатство

Не знаю о масштабности вашего проекта, но на своей практике приходилось ходить от одной реализации системы контроля доступа к другой, эти модели могут от итерации к итерации меняться, и на самом деле даже внутри одного контроля доступа могут со временем обрастать дополнительной логикой за короткое время (например доп флоу mfa, который ни на что не влияет зачастую помимо авторизации, но er схема уже неактуальна становится), а сам по себе контроль доступа не дает ничего такого, чтобы от него шла бизнес логика, в любом другом случае будет ощущение, что кор логика неправильно описана. Поэтому эта сущность зачастую в моем проектировании опускается в описании кор логики, но если есть проверенный и долгосрочный план использовать конкретный инструмент, что очень на самом деле рискованно, то имеет большой смысл описать его сразу, тем самым оправдать нагрузку при чтении схемы.

Пользователь это скорее системная информация , такая как login , password, email, phone, uid которая нужна для 1. Авторизации 2. Восстановления пароля/ логина если он был потерян 3. Содержащая uid -для связи с профилем и всм остальным, мы же не ограничиваемся профилем, мы будем собирать и разную всякую другую информацию о пользователе , статистику какую-то , какие предпочтения в знакомствах и т.д. uid это наш главный связующий индекс который должен быть хорошо защищён от подделки и т.д. лучше если система при каждом сеансе работы с пользователем будет генерировать новый uid, а профайл это фотки няшные , ссылки на инстограмчик, тележку , мыло, (если оно воткта вот всё открыто юзером),пожелания(грёзы и мечты) , может какая-то маленькая апликущечка , в стиле "в это окошко можно отправить сообщение мне в телегу/вацап прямо сейчас."

В чём плюсы разделения user/профайл , 1. снижение уровня связности , хорошая рефаторингуемрсть кода, чем меньше связей , тем меньше проблем может возникнуть при изменении в одном блоке кода , в других блоках кода. 2. (вытекает из первого)Возможность связать юзера с другим профайлом, из другого приложения через какой-то proxy, не затрагивая при этом собственный код профиля юзера , возможность использовать разные БД для хранения сущностей user /profile , то есть user можем хранить в таблице кликхауса какого нибудь а подробности профайла в postgresql (а вот тут мы начинаем плодить сущности без нужды да).

Трудности если всё объединить в user , это все что выше перечисленно как плюсы , только со знаком минус.

Инкапсуляция наше всё!

В двдцать6году важнее стратегия продвижения сервиса, финансирование и кадры, чем код программы, которую, возможно, проще купить почти готовую.

Разделять однозначно — и вот почему это важно даже для небольшого приложения.

User = учётная запись: email, пароль, роль, статус (активен/заблокирован). Это про аутентификацию и авторизацию.

Profile = публичное лицо: имя, фото, спортивные интересы, локация. Это про то, что видят другие.

Проблемы при объединении в один User: 1. Privacy: нужно показывать профиль другим пользователям — придётся аккуратно фильтровать поля, чтобы не утечь email/хэш пароля 2. Разные жизненные циклы: можно иметь аккаунт без заполненного профиля (только зарегился) — в одной таблице это null-поля 3. Масштабирование: таблица User нагружена каждым запросом к профилю; Profile можно кешировать агрессивнее 4. Гостевой просмотр: профили часто нужно отдавать без аутентификации — легче сделать если это отдельная сущность

Правило из практики: если есть сомнения — разделяй. Слить две таблицы в одну потом легко, а разбить одну на две — больно.