TileDB should support attaching axes labels (dataframes in their full generality), so that the user can slice the array based on arbitrary axes label predicates.

TileDB currently performs only slicing. It should allow other computations, such as filters, group-by queries and joins. This will help high-level application push compute closer to storage.

It would be great if TileDB implemented LERC (Limited Error Raster Compression) [ https://github.com/Esri/lerc ] as possible compressor for dense arrays.

Enable the use of TileDB from Rust.

TileDB does not allow arrays to change size. Appending new data and removing old data along a specific dimension (ex. time) is useful for realtime applications.

Enable use of TileDB from Julia ( www.julialang.org ).

Working on nested arrays is a crucial task in most scientific fields. I think TileDB could perfectly leverage its strengths to support the community working in that field: https://youtu.be/jvt4v2LTGK0?t=1366 Working with Data Management in TileDB and Data Wrangling in awkward-array ( https://github.com/scikit-hep/awkward-1.0 ) or other libraries with arrow support would be extremely beneficial workhorse. Any updates on when Arrow will be supported?

It would be super cool to have a distributed database with co-located processing on top of TileDB. Apache Ignite is such a distributed database engine but it currently only supports table-based data. My dream is a distributed array database that allows: fast selection along dimensions (-> secondary indices) fast distributed joins co-located processing

Would it be possible to leverage GPUs and BlazingSQL with TileDB?

Support array caching as described in this post: https://forum.tiledb.com/t/tiledb-cache-management/320 Several use case: Allow cache reuse between client sessions. Faster array metadata first byte. limit S3 egress cost Allow offline work or on bad connection with cached objects when prototyping Currently using minio gateway is a good workaround though so it might not be a high priority request.