You're looking at this from the entirely wrong perspective. This isn't a stupid request from a client who doesn't know anything about technology. It's a design constraint that you think introduces risk into the project.
So you do whatever you do when you encounter risk in a project: Define it, assess it, and recommend a mitigation strategy.
- Define the risk. Saying it will cause "performance problems" and "will not be easily scalable" is not defining the risk. You need to specify exactly what you mean. What isn't going to perform, and why? What changes in scale will will encounter these problems?
- Assess the risk. Okay, so you think there's a problem. How bad is it? How certain can you be that these performance problems will actually happen? What will the impact be on the users if they do? You say the program can't scale: is the growth in scale that will expose the design defect even in the cards? Most importantly, how do you know this? Here is where taking the time to build and benchmark a prototype can save you a lot of pointless argument.
- Recommend a mitigation strategy. What's the right way to implement this? Why is it the right way? Again, how do you know this? Again, prototyping is your friend.
A couple of things will come out of doing this exercise.
First, you may discover that while you're right about every particular, when you put them all together it doesn't matter. Yes, this program's not going to perform well or scale well, but if none of its projected use cases are going to run into those problems, it could easily not be worth solving them.
Second, there's a world of difference between telling someone "This isn't going to perform, I just know it" and telling him "I benchmarked the use cases that we expect, and it looks like this approach is going to result in four- or five-second response time per user transaction."
Third, if you know what conditions will make the software fail, and you articulate these concerns to the client, and the client says "We really just want it to work this way," you've discharged your responsibility. If this fails because the client chooses not to mitigate the risk you've identified, nobody can point to you and say it was the programmer's fault.
Above all, evidence trumps opinion. You've framed this entire question as a case of your opinion versus the client's. That's a losing proposition. What you need to do is frame it as "here's a problem that we need to solve." And to frame the question that way, you have to demonstrate the existence of the problem, and for that, you need evidence.
Ultimately, it's the client who decides whether or not a risk should be mitigated, not you. It's up to you to give him the best information you can to support his decision. And you need to make it clear, without being a dick about it, that it's his decision.
I've found, on more than one occasion, that a simple email focuses the attention perfectly:
I've been reviewing the design, and I think there's a risk here that we need to discuss. [Approach A] is really sensitive to transaction volume, and I'm worried that we're going to have enough users that we're going to run into trouble with it.
I ran a little test using [Approach B], and it's a lot less sensitive; in my simple prototype, I was able to get X transactions per second out of it. This makes sense, because [technical comparison of how the two approaches handle things].
I'm especially worried about this because [describe how program will fail if it performs poorly].
This seems like a significant problem to me. If it were me, I'd use [Approach B], because [describe how this approach will mitigate the risk].
But you're much more familiar with [Approach A] than I am, and I'll happily defer to your guidance on this matter. What do you think we should do?
This message very clearly says "If you disregard what I'm telling you, here's how the project is going to fail, and I'm going to have documentation demonstrating that you told me to do it that way." It also doesn't actually say that.