Defending it out loud

A challenge is a request for your reasoning, not an accusation. The strongest reply names the condition: "Postgres would be better if the access patterns were unpredictable; ours are three queries that have not changed in a year, and here they are." That answers the question, shows the boundary of your claim, and invites the reviewer to attack the premise, which is exactly where you want the conversation.

Concede quickly when the objection is good. Reviewers remember whether you update on evidence, and a design improved during review is the normal successful outcome, not a defeat. What damages you is defending a position after the argument against it has landed: everyone in the room can see it, and it makes your earlier claims retroactively less believable.

"I do not know" is a complete answer when it is followed by a plan. "I do not know how it behaves above a thousand writes a second; I would load-test that before committing, and here is the number that would change the design" is a strong answer. Guessing confidently is the weak one, and it is the habit that working with fluent models most encourages, which is why the whole of this phase has had one playing the sceptic.