The documentation that I’ve been able to find notes that ETS tables are not garbage collected.
I realize that to full free the memory I’d need to delete the table.
But, if I perform many updates on keys in the tables, does that generate additional garbage that remains until the full table is deleted – such that I’d need to occasionally create a copy of an existing table and flip to it?
Side question: since data is copied out of ETS into the requesting process, I assume I should make sure that any data stored in ETS is small at the key level? (as in, I shouldn’t store a 10MB map against a single ETS key).
No. Any data which is not needed anymore due to update/delete of table rows will be immediately released. This is why ETS can in some cases work better than regular data structures, because it doesn’t put any pressure on the garbage collector, and can therefore give you a more consistent latency (i.e. less variations due to unexpected GCs). I blogged about that technique here.
In general I’d recommend carefully choosing keys, and not storing needless data there, precisely because of the reason you mention. More generally, ETS or not, I wouldn’t expect a lookup by a 10MB key to perform well As usual, measuring is the best way to verify if performance is satisfactory
I was considering using ETS tables to implement something like in-memory indexes to other data – and wanted to make sure I wasn’t going to get into too much trouble
As usual, measuring is the best way to verify if performance is satisfactory 
