instant

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 transa

In the "stop the world approach", I imagined our algorithm to be a bit more manual: for example, we would turn the switch on manually, wait, and then turn it back on. You make a good point though, that with enough effort it could also be a few seconds. I updated the essay to reflect this: https://github.com/instantdb/instant/pull/774/files

> you’d modify the config to point to the new servers, issue PAUSE to PgBouncer to gracefully drain connections, then RELOAD to pick up the new config, then RESUME to accept new traffic. The function we wrote effectively executes these steps [1]. I think it would look similar if we had used PgBouncer. I could see it be an option though if we couldn't scale down to "one big machine". [1] https://github.com/instantdb/instant/blob/main/server/src/in...