Not at all. As my profile states I work as a BI consultant. If you want to consider the entirety of an organization&#x27;s ETL processing as a monolith, then overnight is really the longest execution time frame I&#x27;m allowed to talk about. I can also guarantee that if I were to propose a full 8 hours of ETL, I would be required to put up some serious justification.<p>That being said, my focus in my company is more on the front end. In this case there&#x27;s a range of acceptable timeframes, but we&#x27;ve had clients with a strict requirement that any report with exposure to VPs or higher has to have &lt;=2 second response time. Even outside of that organization, more than a minute for a report is usually pretty much a non-starter.<p>The problems I&#x27;m referring to have nothing to do with a BI guy implementing complicated logic; this is just a part of the job description. Let me quote the section where it becomes clear that there&#x27;s a huge problem.<p>&gt; The main database was IBM DB2 9.7 on RHEL and it had about 3 months (800GB) of data in it (we pruned it nightly). We had a &quot;reporting&quot; database that was postgres 9.3 or 9.4 (can&#x27;t remember). <i>It was the same schema</i> but was never pruned. It had about 15 billion rows total and about 5TB of data. About 700GB was indexes. The same query when ran on DB2 took 12 hours, on postgres (5x more data) it took 24 hours.<p>Emphasis is mine. They&#x27;re reporting on an OLTP schema. The reason that the query is many pages long, and that it takes 24 hours to run, is because the CTEs are being used as in-line ETL. Their &quot;reporting&quot; database is nothing of the sort, it&#x27;s just a replica of their operational system.<p>That poor BI guy is either out of his depth and doesn&#x27;t know how or is simply not allowed to build the appropriate solution. Both are problems, and both extend far beyond the BI guy.<p>Edit: Extra word word.