@matt, correct, you only pay for the time that you use each warehouse, not that they exist. So you can have as many warehouses as you want, and if they aren’t running you won’t be billed anything.
The consideration comes with when and how much they are being utilized. For example, let’s consider your data loading usage (Stitch) and your dbt usage (Sinter or Airflow).
You can give each of them their own small warehouse to ensure they don’t compete with each other. Or you can put them on the same warehouse. Which to choose?
Let’s say they both are scheduled to run at the top of the hour. Stitch runs for 15 minutes and dbt runs for 10 minutes. If you put them on separate warehouses you will be billed:
stitch_wh: 15 mins X 24 hours = 360 mins/day
sinter_wh: 10 mins X 24 hours = 240 mins/day
Total: 600 mins/day
However, do they need to be on separate warehouses? If they each only use 20% compute, then you could put them on the same warehouse and they would still only use 40% of the compute (meaning you could probably put your BI tool on there too).
In this scenario, they both still run at the top of the hour, and both still take the same amount of time to complete, but you are only running one warehouse and since they run concurrently you are only billed for the max 15/mins per hour that Stitch uses (Sinter’s 10mins overlaps with this), so:
shared_wh: 15 mins * 24 hours = total 360 mins/day (much cheaper)
Of course, if Sinter’s run is scheduled for half-past the hour, because you want to run it AFTER your Stitch load, then they would not run concurrently, and your billed minutes would be the same with one warehouse as it is for two (in this case it’s really no benefit either way, since they wouldn’t compete even on a shared warehouse).
So when scaling, yes, warehouse strategy can become complicated. You may need to consider the number of concurrent queries, the amount of compute needed, the priority of the job or the importance of how fast it’s completed, etc.
If you have a simple setup my recommendation is just put it all on a small warehouse. Make sure each piece of the system uses its own Snowflake user, then once you start to hit performance issues you can dig into usage per user and consider moving one or more users to separate warehouses.