If you have an existing data warehouse, then use that as the source for your QV documents. No need to rip out and replace the existing ETL.
If you don't have an existing warehouse, then its not so easy to decide. If your only use for the warehouse is to feed QV documents, then you can create a 2 or 3 tier ETL, storing intermediate and final QVDs on a properly structured and secured file server. You would need to build QVW generators to extract the data from the source system, and to tramnform the data into the form required for your QV documents. The ETL and the final document loads would then need to be scheduled in QV Server/QV Publisher or some sort of external scheduling tool.
If you need the robustness and governance of a database server, or you need to feed other reporting tools, then you may be better off creating a SQL based warehouse.
As far as scaling is concerned, "a lot of data" is not very specific, but is fairly straightforward to create QVDs with 10s or 100s of million rows and you can also use incremental logic using monthly, quarterly or annual QVDs to partition the data if required. The data set size is therefore not necessarily a constraint.
Logic will get you from a to b. Imagination will take you everywhere. - A Einstein
