The script we wrote though already has a method to detect exactly when the replica has caught up [^1]. Had we enabled synchronous commit, we'd had the same kind of performance as now.
A few changes we could do to improve this even further:
Right now the algorithm waits a) 2.5 seconds for transactions to complete, and b) cancels the rest.
We could make a) the amount of time we wait more exact, by actually subscribing to active transactions and waiting for them to complete. This way in most cases we'd only have to wait up to 500ms.
We couldn't do that when we wrote this essay, because we didn't differentiate read connections from write connections. We do now [^2]
We could improve b) how many transactions we have to cancel, by having the function make "attempts" throughout the day. For example, the function could try to wait 500ms for transactions to complete, but if it's a particularily busy period and we have too many straggling transactions in process, the function could abort the migration and try again another time.
A few changes we could do to improve this even further:
Right now the algorithm waits a) 2.5 seconds for transactions to complete, and b) cancels the rest.
We could make a) the amount of time we wait more exact, by actually subscribing to active transactions and waiting for them to complete. This way in most cases we'd only have to wait up to 500ms.
We couldn't do that when we wrote this essay, because we didn't differentiate read connections from write connections. We do now [^2]
We could improve b) how many transactions we have to cancel, by having the function make "attempts" throughout the day. For example, the function could try to wait 500ms for transactions to complete, but if it's a particularily busy period and we have too many straggling transactions in process, the function could abort the migration and try again another time.
[^1]: https://github.com/instantdb/instant/blob/main/server/src/in...
[^2]: https://github.com/instantdb/instant/pull/743