Really the only thing we run into trouble with is `count(id)` where `id` is the pk of the table. This is surprisingly slow when you get above a couple hundred m

Really the only thing we run into trouble with is `count(id)` where `id` is the pk of the table. This is surprisingly slow when you get above a couple hundred million rows. We're 3rd normal form, with proper fk's and indexes. I _highly_ recommend having someone or some team in charge of db architecture. Use the "remarks" column to make a data dictionary that's stored right in the table. Have an _exact_ specication for table names (plural nouns), column names (agent_id (always a fk), agent_name), index names (udx-agents-agent_name), fk names (fk-leads->agents). But, here in lies the rub: ALWAYS implement today's requirements, not next-years. If your app can be powered by a single mysql instance, _just do it_. You'll be in a much better position to scale later that if you pick some excessive technology you _think_ you might need in the future.