In Current Musicbrainz system if I have one track with a puid that I want to identify I normally end up querying by Puid and then seperately by the user entered metadata, because I need both methods to get all potential matches i.e. http://musicbrainz.org/ws/1/track/?type=xml&query=track:gigantic http://musicbrainz.org/ws/1/track/?type=xml&puid=0df59361-73bf-8172-e7e5-0e31a4b66b03 Id rather do http://musicbrainz.org/ws/1/track/?type=xml&query=track:gigantic OR puid:0df59361-73bf-8172-e7e5-0e31a4b66b03 but that doesn't work because if you specify puid option it goes to the database and everything else is ignored. In NGS the situation is no better because puid are no longer a query parameter, but a resource type of ther own so still end up with two queries. http://test.musicbrainz.org/ws/2/recording/?query=gigantic http://test.musicbrainz.org/ws/2/puid/0df59361-73bf-8172-e7e5-0e31a4b66b03 The new puid entity for when somebody just wants to look up a puid is fine but I think we can do better for fixing the search issue. The only solution to allow the OR query is to add puids to the search server recording index and allow searching by them. The reason this wasn't done before was that it would mean a larger percentage of ws queries would go to the search server rather than the dbserver and the sheer volume would slow down all ws queries. But this is just a question of load balancing, an individual query against the search server should be quicker than a db lookup because search is readonly and is optimized for searching whereas the db is not, and the search server can easily be replicated onto any number of machines to get the required performance. So I suggest we look at this again when we have some time