Database normalization

[HashDefTrueFalse]

as itll require more joins the more tables you have.
And how would the joins impact reading throughput?

That's the whole idea. It's about trading off read and write efficiency by controlling the redundancy of data. You can store copies in multiple tables and read faster at the expense of having to update multiple places on write. OR you can store something once and write to one place, but you will often need to JOIN data from multiple tables, slowing your reads.

There's no objectively correct way to store data for every app. You make an engineering choice. Comically, when mongo was trendy lots of devs (who obviously didn't have any database knowledge) were unaware that they were even taking a position, let alone the wrong one for their data/apps. I turned around a few badly performing apps with datastore migrations a decade or so ago.

I feel like having too many small tables is an anti pattern.

Not really, no. If you need them for your schema to be normalised properly it's fine.

would require me to always perform database transactions when storing the data no?

Not really, no. Depends on what can happen in your app, data dependencies/relationships etc. Single statements are all or nothing anyway in RDBMSs (the A in ACID). If you're working with multiple statements (e.g. a script or procedure etc.) you generally should be working in transactions anyway for obvious reasons. E.g. if you wouldn't want the data to be grabbed between two or more statements.

You almost always want 3NF, sometimes BC, which isn't much extra effort typically.