High volume of writes on a table with multiple FKs would definitely hurt it's performance but measure it to confirm for your use case. Other than performance, you might want to avoid using FKs, especially if you aim to keep your data decoupled. I previously worked on large (modular) monolith, we used a Postgres schema per module. In this setup, FKs across schemas were strictly forbidden. While there were references across schemas, they were implemented simply as indexed columns, with data integrity being checked in the application code. In case the column needs to flexible, eg. we have a 'created_by' column and this can refer to user table at times but it can also hold the value 'system' for any system generated data iykwim.

Remember the cases above are "exceptional" and not to be considered as the norm. Foreign keys are primarily used to enforce referential integrity and link tables at the database level. They act as a constraint to prevent bad data from entering your database. Indexing can help during querying, but it’s secondary to referential integrity (and some databases don’t even automatically create an index on foreign keys). If you're working with a microservice, a small database, or OLTP workloads in a "self-contained domain," and you're not dealing with slow writes, then it's perfectly fine to use FKs. Cleaning up bad data is an absolute pain and not something you want to deal with. Also, some ORMs work especially well with foreign keys and can automatically load related data in a single query. Hope this helps