See

The way we've designed clearing up after a DROP TABLE is fundamentally incompatible with a hard split between KV and SQL, unless we add a way for the SQL layer to figure out the zone config for a given table from the KV backend. The other way to do this is to push the responsibility for cleaning up into KV, which is a bigger change but is "better" in the sense that it doesn't rely on the SQL tenant process running (which often won't be the case after the TTL).

We should be able to hard-code a value here instead for the time being.

Similar in opt:

We have a pretty hard dependency on reasoning about the physical location of data. Here there seems no way around it, we need to be able to resolve table ID to localities, and this becomes a blocker the moment we go geo-distributed.

cc @nvanbenschoten