Petabajty danych i tysiąc maszyn czytających jednocześnie — architektura, w której najdroższym zasobem bywa nie moc obliczeniowa, tylko przepustowość do dysku.
Rozdział 19 podzielił render na setki niezależnych zadań, licząc się równolegle na osobnych maszynach. Każda z tych maszyn potrzebuje tych samych danych źródłowych — opublikowanej geometrii z Rozdziału 6, tekstur, cache'y Alembic z Rozdziału 10. Skoro wszystkie czytają je z jednego, wspólnego miejsca w tym samym momencie, samo miejsce przechowywania danych staje się częścią infrastruktury, o którą trzeba zadbać równie starannie, co o samą moc obliczeniową farmy.
Depot Perforce z Rozdziału 6 i opublikowane assety nie mieszkają na dysku żadnej pojedynczej maszyny — leżą na dedykowanym, współdzielonym storage'u o wysokiej przepustowości, dostępnym jednocześnie dla każdej stacji roboczej i każdego węzła farmy. Problem pojawia się przy skali: setki maszyn odczytujących naraz te same duże pliki potrafią nasycić nawet bardzo szybkie łącze sieciowe. W praktyce oznacza to, że render bywa I/O bound, nie compute bound — maszyna kończy liczenie klatki szybciej, niż zdążyła wczytać wszystkie potrzebne jej dane, i spędza więcej czasu na czekaniu niż na samym liczeniu.
Dwie niezależne strategie zmniejszają to obciążenie, zamiast próbować je wytrzymać siłą. Pierwsza to cache lokalny: węzeł farmy, który raz przeczytał daną teksturę czy geometrię, trzyma jej kopię na własnym, szybkim dysku lokalnym, więc kolejne zadanie na tej samej maszynie nie odpytuje sieci ponownie. Druga to proxy — lekka, uboższa wersja danych (tekstura w niskiej rozdzielczości, uproszczona geometria) używana do pracy interaktywnej, podczas gdy pełne dane wczytywane są dopiero na etapie finalnego renderu. To dokładnie ta sama zasada leniwego wczytywania (payload), którą Rozdział 11 pokazał przy USD — odłóż koszt odczytu ciężkich danych na moment, w którym są naprawdę potrzebne, nie wcześniej.
Dane aktywnego showu, używane codziennie przez setki maszyn, leżą na najszybszym i najdroższym storage'u, jaki studio posiada. Show, który zakończył produkcję miesiąc temu, nie potrzebuje już tej samej przepustowości — jego dane migrują na tańszy, wolniejszy storage archiwalny, czasem nawet na taśmy. Ta hierarchia (tiering) nie jest szczegółem technicznym bez znaczenia dla artysty — to powód, dla którego otwarcie starego shotu z zakończonej produkcji bywa zauważalnie wolniejsze niż praca nad czymś, co jest w toku teraz.
Część VI domyka temat skalowania. Ostatnia część książki wraca do ludzi — kim jest osoba, która buduje i utrzymuje to wszystko, i jak z nią współpracować, kiedy coś nie działa.