> You say "put your code in a container", but... wouldn't you basically have to put all your gigabytes of data into a container? The bottleneck to the types of

> You say "put your code in a container", but... wouldn't you basically have to put all your gigabytes of data into a container? The bottleneck to the types of analytic applications you're describing seems unlikely to be the custom backend code, and far more likely to be whatever database is powering the application, which means that each interactive instance really needs to spin up a complete copy of the dataset to gain any performance benefit for these on-demand analytic workloads. You're right that it does depend a lot on the needs of a specific application. If a bunch of users are accessing the same dataset, and can constantly access the subset of data they need with low latency through a global index, and there isn't much need to do computation interactively at runtime, then a standard architecture is probably a better fit. Where this approach is useful is if every user needs access to a different subset of the data (e.g. if the underlying dataset is petabytes, and each user needs to interactively explore a different gigabytes-big subset of it). Or if there is a lot of derived compute on top of it, for example, a graph visualization that needs to be updated when the user changes the subset of data in focus. > I'm wondering if your competition isn't actually AWS WorkSpaces The general approach of "run and render elsewhere and stream the pixels back" is definitely our competition in the sense that it's something companies currently do. What we provide is a way of moving the client/server boundary to wherever makes sense for your app: if it makes sense to render server-side and stream pixels, you can do that (although we don't yet support UDP, which would be useful in this case); if it makes sense to do data aggregation server-side but render through WebGL, that's also an option.