[DasIch]

A foreign key doesn't necessarily imply an index. If you are using postgres, you would have to add an index in addition to the foreign key, if you want one.

On delete cascade, depending on how many rows it cascades to, can be problematic because it's a very long running blocking operation. That's something one might want to do as a background operation and in batches. Although that won't make it faster.

[sroussey]

Faster in aggregate throughput can often be different from faster for a specific operation.

Personally, I find delete on cascade dangerous. I mean, lots of fun for a pen tester, sure…

[Yoric]

> Personally, I find delete on cascade dangerous. I mean, lots of fun for a pen tester, sure…

Intriguing. Can you tell me more?

[Yoric]

> A foreign key doesn't necessarily imply an index. If you are using postgres, you would have to add an index in addition to the foreign key, if you want one.

Sure, I meant an index in which the key is primary. But, on second thought, that's probably me misreading the GP's message.

> On delete cascade, depending on how many rows it cascades to, can be problematic because it's a very long running blocking operation. That's something one might want to do as a background operation and in batches. Although that won't make it faster.

That can definitely be a problem (just like destructor deallocation stampedes in C++ or Rust). Still less risky than cascading manually and asynchronously, I suspect.