I actually disagree with the comment from @Kevin, using or not using nodes can make a huge performance difference, for multiple reasons.
Yes, node is a pretty standard content entity, but..
- It is revisionable
- It is translatable
- It has a bunch of standard base fields like promote, sticky that are likely not relevant for your use case
- Any data that actually is relevant needs to be stored in configurable fields, which results in additional tables.
So if you need 20 additional fields to store stuff, you end up with 4 base tables and 40 additional tables, so 44 tables in total.
If you don't need revisions and translations and assuming you only have single-value fields, you can do that with a single table instead with a custom entity type and base fields. If you need revisions then it's 2. And each multi-value field does require 2 additional tables but usually there are not that many of those.
With millions of records, it's definitely worth thinking about if creating a custom entity type is worth it and sounds like for that case, the answer is probably yes.
It's worth pointing out that there's still a decent amount of modules (even in core), that currently only work with nodes, e.g. book or diff. So make sure that you don't need any of that or be prepared to re-implement that functionality.