With a 2025 tech stack, yes. With a 2005 tech stack, no. Don't use any containers, no[/limited] server-side dynamic script languages, no microservices or anything like that.

Considering the content is essentially static, this is actually viable. Search functions might be a bit problematic, but that's a solvable problem.

Of course you pay with engineering skills and resources.

▲

stackskipton 5 hours ago | parent | next [-]

SRE here, Containers are not causing any performance problem.

	▲	grim_io 3 hours ago \| parent [-]
		Maybe the perception comes from all the Mac and Windows devs having to run a Linux VM to use containers.

▲

eirpoeior 5 hours ago | parent | prev [-]

Is there any feasible way to implement search client-side on a database of this scale?

I guess you would need some sort of search term to document id mapping that gets downloaded to the browser but maybe there's something more efficient than trying to figure out what everyone might be searching for in advance?

And how would you do searching for phrases or substrings? I've no idea if that's doable without having a database server-side that has the whole document store to search through.

	▲	ffsm8 5 hours ago \| parent \| next [-]
		Theoretically, just thinking about the problem... You could probably embrace offline first and sync to indexeddb? After that search would become simple to query. Obviously comes with it's own challenges, depending on your user base (e.g. not a good idea if it's only a temporary login etc)
	▲	namibj 5 hours ago \| parent \| prev [-]
		There are several implementations of backing an Sqlite3 database with a lazy loaded then cached network storage, including multiple that work over HTTP (iirc usually with range requests). Those basically just work.