The relevant limits for building something that is boing to bulk read data over the soap api would be

1. Total API requests, there is a limit to the # of API calls you make in a 24 hour period, make sure you're fetching as much data as you can handle in one go (e.g. set the batchsize header of QueryOptions to 2000)

2. Concurrent API requests, there limits to the number of concurrent API calls you can make, don't go crazy trying to do the load over lots of threads.

3. Number of Query Cursors, queries that return more rows that can be returned in a single call create a query cursor, (this cursor is then used to page through the remaining rows via the queryMore call). There's a fairly small limit on these (10 i think per user), fully process one query before moving onto the next one.

25k rows is not a lot, so you shouldn't have any issues.

The relevant limits for building something that is boing to bulk read data over the soap api would be

1. Total API requests, there is a limit to the # of API calls you make in a 24 hour period, make sure you're fetching as much data as you can handle in one go (e.g. set the batchsize header of QueryOptions to 2000, which is the maximum). One API request == One HTTP round trip, so calling login, query, queryMore, queryMore counts as 4.

2. Concurrent API requests, there limits to the number of concurrent API calls you can make, don't go crazy trying to do the load over lots of threads.

3. Number of Query Cursors, queries that return more rows that can be returned in a single call create a query cursor, (this cursor is then used to page through the remaining rows via the queryMore call). There's a fairly small limit on these (10 i think per user), fully process one query before moving onto the next one.

25k rows is not a lot, so you shouldn't have any issues, if you can get 2k rows per chunk (which'll depend on the number and type of fields selected) then this can be done in 14 API calls (login, query, queryMore x12)