I don't think that's being pessimistic. I think it reflects dask's documentation. Some items I looked up because I remember from the past: > If your data fits

I don't think that's being pessimistic. I think it reflects dask's documentation. Some items I looked up because I remember from the past: > If your data fits comfortably in RAM and you are not performance bound, then using NumPy might be the right choice. Dask adds another layer of complexity which may get in the way. from https://docs.dask.org/en/latest/array-best-practices.html#use-numpy https://docs.dask.org/en/latest/array-best-practices.html#us... > In many workloads it is common to use Dask to read in a large amount of data, reduce it down, and then iterate on a much smaller amount of data. For this latter stage on smaller data it may make sense to stop using Dask, and start using normal Python again. https://docs.dask.org/en/latest/best-practices.html#stop-using-dask-when-no-longer-needed https://docs.dask.org/en/latest/best-practices.html#stop-usi... So, dask even says not to use it for small data sets. And in their comparison to spark, they say spark has a lot more features.