(For context for other readers: the screenshot you're including here is from Chrome's DevTools panel — choose the "Application" tab and then "Interest groups" from the left panel.)

@anderagakura The list that appears in DevTools is a record of all Interest Group events. So each time an IG is joined or loaded, we add an entry to that list. The "Event time" column is just telling you at what time that event was logged. An IG will appear multiple times if we load it multiple times, which can happen if there are multiple auctions.

If you click on one of these rows, you'll see the current value of the IG. It's only stored once, even though the log shows that we loaded it from the database multiple times.

@michaelkleber So, your answer brings my next point which is : At high scale (I mean more IGs), would not it be a risk of memory leak for the browser during the user journey?

@anderagakura The list that appears in DevTools is a record of all Interest Group events. So each time an IG is joined or loaded, we add an entry to that list. The "Event time" column is just telling you at what time that event was logged. An IG will appear multiple times if we load it multiple times, which can happen if there are multiple auctions.

Of course, when I click I definitely see the value of the IG but how do we know it's only stored once if we see the IG multiple times?

If you click on one of these rows, you'll see the current value of the IG. It's only stored once, even though the log shows that we loaded it from the database multiple times.

At high scale (I mean more IGs), would not it be a risk of memory leak for the browser during the user journey?

I'm not sure what potential memory leak you are worried about.

Of course, when I click I definitely see the value of the IG but how do we know it's only stored once if we see the IG multiple times?

I don't believe our tooling has a way to see the list of currently-stored IGs per owner, but @morlovich please let me know if I'm wrong.

There is no UI for that, no, though you can peek at at the database file with sqlite. Probably best not to do it while Chrome is running. e.g. for a source build (packages would use coming like google-chrome) on Linux:
$ sqlite3 ~/.config/chromium/Default/InterestGroups

And you can do stuff like:
SELECT owner, COUNT(*) from interest_groups GROUP BY owner;

...at any rate the interest groups table has PRIMARY KEY(owner,name).
(join_history is far less obvious, and has explicit GC stuff I don't know much about)

Probably best not to do it while Chrome is running

SQLLite hasn't permitted opening the db (with Chrome running) since it has some exclusive lock.

@morlovich You already know but I confirm that every IG is counted. The result is 2 per IG because it's based on a new scenario on my side. Btw, I ran it on Mac

@morlovich The data type of the column storage_size from the table interest_groups is INTEGER. Could you please tell me if the data type of the value is ko or o?

I don't understand your question fully, but that's in bytes if you mean that

Just a minor thing for future IG detail searchers:

• The sqlite trick worked for me in this location /Users/ifoster/Library/ApplicationSupport/Google/Chrome/Default
• If you're having trouble finding it go to the Chrome directory, join some IGs, look for last updated directory with ls or some such, that worked for me.
• Finally, I did find the lock that @dmdabbs pointed out so it makes it a bit tough, but you don't have to restart the sqlite session, which made it a bit easier.