You should do some kind of capacity planning, see how you compare to others who host HA on a RPI. And of course ignore the outliers, guys who scream their heads off because the Pi is so slow. So many things can influence performance, like are they (still) running on SD cards, or are they using a SSD?
Maybe a good question to start would be how many integrations you have, or plan to have in future. “In future” is relative though, because with Moore’s Law you will upgrade your hardware at some point anyway.
But you must see it in perspective… controlling lights that you switch on when it gets dark and off when you go to bed, or a garage door that triggers twice a day (or maybe more after Corona), pushes up the integration count, but does not exactly count as a heavy load.
Be critical of what you really need, and discard the rest. Have a look here for an analytical approach to include/exclude sensors from the database.
Below is the list of HA-related containers that are part of the supervised install:
(I removed some columns that are not adding value here)
docker ps
IMAGE NAMES
homeassistant/armv7-hassio-multicast:3 hassio_multicast
homeassistant/armv7-hassio-cli:2021.03.0 hassio_cli
homeassistant/armv7-hassio-audio:2021.02.1 hassio_audio
homeassistant/armv7-hassio-dns:2021.01.0 hassio_dns
homeassistant/raspberrypi4-homeassistant:2021.3.4 homeassistant
homeassistant/armv7-hassio-supervisor hassio_supervisor
homeassistant/armv7-hassio-observer:2020.10.1 hassio_observer
Back to the install question…
You will definitely need MQTT, and most likely Node-Red. Let’s just start with these two for now. You will either have to load them as add-ons within HA, or else run them as containers outside HA. Both options are perfectly acceptable (I run them outside). So whether you choose install method 1, 2, or 3, the net effect may be exactly the same - they run in a container each.
That raises the next question, convenience versus flexibility. Option 1 offers convenience but no flexibility - you can only do it one way (add-on), and can only use what is available. Option 2 you can only run them outside HA, because it does not support add-ons. (any other options?). With option 3 you can choose whether you want to run them as HA add-on or as container managed outside HA. With 2 and 3 you have the ability to grow, to add additional containers as your needs change. As example, I now wanted to host my own Mumble (Murmer) server as part of a VOIP intercom setup. I had the freedom to either run it in a container, or install the service directly on the Debian host. With option 1 you’re screwed.