I'd prefer if we baselined as simple a matching algorithm as possible. In that case, the additional storage would be at most storing a subset of the columns of the Object tables from previous DRs (if they're not already available) as well as the storage for the match tables themselves, which should be no more than a few TB (worst case I can think of is 10 DRs, 3 potential matches, 8 byte ids and 4 byte match probabilities, 40G objects = 14 TB).

So a few hundred dollars in storage.

My main concern is that each DR will be deeper than the one before with more sources that will pop up. It seems that this cross matcher must, at minimum, include the flux in the cross match so that we don't make the obvious mistake of matching a bright star in DR1 that has some small proper motion with a faint galaxy in DR11 that only appeared in that data release. I don't think a truly naive cross matcher will be useful. John Swinbank does DRP team have an opinion on this?

That comment triggered a memory. I saw a talk at ADASS last year from Gaia where they used a classifier with their cross matcher (including the light curves) and got much more accurate matches.

http://www.adass2016.inaf.it/index.php/participant-list/14-talk/135-rimoldini-lorenzo

Wil O'Mullane do you know whether that talk was written up?

Concerning the talk - there are reports concerning the topic in the Gaia livelink(Docushare) though not that specific title.
The short ADASS write up is available https://arxiv.org/pdf/1702.04165.pdf
I can put you/or someone in touch with Laurent Eyer (CU7 leader) for more details I do not know Rimoldini directly. (Though his email is in the paper)

Pinging John Swinbank for DRP opinion on the cross-matching. For LCR-962 we need an estimate of the impact of this requirement on DRP team.

Kian-Tat Lim who puts this information in the sizing model? I assume for LCR-962 we declare that this has no impact on hardware budget.

I don't think there's a significant new algorithmic component here — we can reuse the matching algorithms we have to develop anyway for Object generation, which will be sensitive to position, flux, etc etc. There will be some extra effort to integrate those algorithms into a tool which can actually do the job, but that should be relatively modest.

I'm happy with that if our matcher is matching flux. I'd be happier if it matched the light curves (with the caveat that matching a DR10 to DR11 source will be much more accurate because of the light curve overlap than would a DR1 to DR11 match).

Closing this. LCR-962 is now up for a vote.