An API makes sense for this case when you won't be throwing away a lot of the raw data in favor of the processed/transformed data.

But doing a lot of these operations on-server makes sense when there's a significant volume of highly parallelizable transformations which need to be done on the data before it's usable.

Of course the best solution is likely to be a happy medium between the two, where simple low-level transformations are done on-server and the rest of the data preparation is done as the data is transferred to the client.

Not in data processing. There are cases where you have so much data that is better to bring computation to data rather than the other way around.

Not always! If computation involves math over set of records, then Postgres is great for that. Have the operation inside the db reduce connection pooling on the application level.

> you've set yourself up for scaling/sharding sooner than later.

OTOH, if you can pre-process the data (or shards) in the server (or servers), you won't need to move it across the network for processing.

Hard problems are hard and one of the reasons databases outlive their systems and developers is because moving that data is a Royal Pain.

I remember a friend telling me in a previous job me they loaded the database with stored procedures because it ran on the most powerful server when the product launched. And then the database server hit its capacity very quickly.