I have already provided you a link to SDLC and ELISHEVA has begun to expand on phases that come earlier in the process - before writing code, such as plan, design, and specification. All of those things feed into a decision for architecture by fleshing out your requirements. In plain English, what you need to know is that you aren't prepared to start writing code without the real possibility of painting yourself into a corner, failing or perhaps creating a monster.

So without trying to learn the entire SDLC in a day, what you need to do is specify your requirements. Your prototype was too slow - what is fast enough? You said "This means I'm going to have a lot more data and I'm going to search it in a lot more ways" - do you know all the ways you might want to search that data? Do you need to support things like concurrent users (how many) and maintain integrity (ACID transactions)?

What I am getting at is once you know what requirements your solution must meet, you may not have so many choices. Also, unless you have a clear idea of what your performance requirements are, you should base your decision on things you do have specific requirements for (reliability, scalability, maintainability, flexibility, existing expertise, etc).

Finally, if you do come up with specific performance requirements and still can't figure out how to test/benchmark them, come back and see us - that's what we are here for.