there's no excuse for putting sf and terra in the middle of everthing anymore, it's gone way too long - simply do not do vect() or st_read() on "/vsicurl/ http...path.to.parquet" - this avoids all the good tech and both read in full (BY DEFAULT, this amazes me so much, I actually forget ...)
Please, use {sedonadb} or {gdalraster},even {vapour} ,{lazysf} - all of these put avaliable tech *first*, those ridiculously popular legacy downstream packages aren't going to get better at this ...
I am excited about this tech and where it's going but I can't help try to point *away from* the thing that just didn't bring the tech *already* but obstinately blocked it for reasons unknown
https://sedona.apache.org/latest/blog/2026/03/01/sedonadb-030-release/#r-gdalogr-read-support here's some examples of less-amazing alternative: https://gist.github.com/mdsumner/fc16a9f98ed35dbfcd944124da02fcf5 supported A VERY LONG TIME by #GDAL
Apache Sedona is a cluster computing system for processing large-scale spatial data. Sedona extends existing cluster computing systems, such as Apache Spark, Apache Flink, and Snowflake, with a set of out-of-the-box distributed Spatial Datasets and Spatial SQL that efficiently load, process, and analyze large-scale spatial data across machines.
I do not want to be the fun police in that party but we never needed to read the whole table from a db connection for a very long time.
Still most folks are using dbreadtable (and that is fine) instead of using some basic SQL to do some filter ...
Michael Sumner
Olivier Leroy