It's almost always the DBMS that's the bottleneck when websites drop from traffic. As long as you don't do anything fancier than primary key look-ups you're probably fine though.

I survived handling the search search traffic generated by this thread[1] on PC hardware off a residential broadband connection without any sort of degradation. Only time I've gone offline from traffic was when Elon Musk tweeted a link to one of my blog posts, and that was just a short temporary blip.

[1] https://news.ycombinator.com/item?id=28550764

▲

allthetime 4 hours ago | parent | next [-]

For a “personal website” or any relatively simple static content site, the DB should not be getting hit much at all. Cache is your friend. For my sites I have a map of all relevant queries and when we do updates we run the relevant queries one time and cache them to both memory and file system.

	▲	marginalia_nu 4 hours ago \| parent [-]
		Should being the operative word. In practice it's both easy and common to have a database do unnecessary work when generating a page, a problem that often only rears its head when under unusual load.

▲

jerf 4 hours ago | parent | prev [-]

Yeah, IIRC my django site was 3 queries, all correctly indexed, for a main page hit, and 2 for the actual posts. I don't recall the exact perf numbers, but I'm pretty sure it was easily in the 50/rps range for a small dual-CPU host... which doesn't sound like much in "requests per second" but is enough to cover a front-page-HN'ing just fine. And that "rps" was just the database-backed pages, all the static content was served over nginx, so that 50rps is a "real", 50 humans per second rps, not something getting consumed by only two or three humans.