3 bolded the main point to keep with the same style, changed to a more standard abbreviation of versus
source | link

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even if we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.
  6. Hardware choices and trade-offs will dramatically affect the quality of the result.Hardware choices and trade-offs will dramatically affect the quality of the result. E.g. core cache v'svs RAM v'svs IO bandwidth. Everyone has an opinion and all can be right or wrong.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even if we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.
  6. Hardware choices and trade-offs will dramatically affect the quality of the result. E.g. core cache v's RAM v's IO bandwidth. Everyone has an opinion and all can be right or wrong.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even if we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.
  6. Hardware choices and trade-offs will dramatically affect the quality of the result. E.g. core cache vs RAM vs IO bandwidth. Everyone has an opinion and all can be right or wrong.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

2 added 186 characters in body
source | link

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even isif we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.
  6. Hardware choices and trade-offs will dramatically affect the quality of the result. E.g. core cache v's RAM v's IO bandwidth. Everyone has an opinion and all can be right or wrong.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even is we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even if we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.
  6. Hardware choices and trade-offs will dramatically affect the quality of the result. E.g. core cache v's RAM v's IO bandwidth. Everyone has an opinion and all can be right or wrong.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

1
source | link

Personally, I don't think this type of question is a good fit for our site for several reasons.

  1. Bigger/more hardware will almost always lead to better performance. As such the answer "As much as your budget will allow" is always a valid answer.
  2. Too many implicit assumptions. You can't possibly fully describe all the details of your system to us so we are forced to make assumptions. These assumptions may lead to recommendations that are completely inappropriate for you and/or people who read the answers later.
  3. Profiling your system is the only accurate way to know what your true load is, and how well your current hardware is performing. We can't do that, and even is we could that is obviously too narrow in scope to help a significant number of future readers.
  4. There are always going to be ways to distribute/reduce the load to help undersized hardware. For example in your question you state "300 inserts per minute peak". If your hardware couldn't support that load you could put a queuing mechanism in front of the database so the peak insert rate was limited to a manageable level. Similarly expensive queries can be cached for a time reducing load, etc.
  5. In case it wasn't clear from points above: By their very nature the answer is going to be too personalized, or too broad to be helpful. Everyone's load/requirements/budget/etc. are their own unique snowflake.

I'm making this a community wiki to encourage anyone that sees a reason I haven't mentioned to add it to the list.

    Post Made Community Wiki by Erik