$15 is not exactly zero, is it? If you don't need more than 1GB, why pay anything for more than 1GB?

I recall running LAMP stacks on something like 128MB about 20 years ago and not really having problems with memory. Most current website backends are not really much more complicated than they were back then if you don't haul in bloat.

It is. With 10k MRR it represents 0.15% of the revenue. Having the whole backend costing that much for a company selling web apps is like it’s costing zero.

You probably don't make 10k MMR on day one. If you make many small apps, it can make sense to learn how to run things lean to have 4x longer runway per app.

The runway is going to be your time and attention span, not $10/mo.

I don't know what you value your time or opportunity cost as... but the $10/mo doesn't need to save very many minutes of your time deferring dealing with a resource constraint or add too much reliability to pay off.

If resource limitations end up upsetting one end user, that costs more than $10.

This assumes you have to spend any time or attention worrying. 1GB is plenty of memory for backend type stuff.

And most VPSs allow increasing memory with a click of a button and a reboot.

Overspending for the sake of overspending is not smart in life or business.

Saving 15 USD on 10k+ USD MMR is ridiculous.

Given how much revenue depends on the experience of a web app and loading times, I’d be happy to pay 100$ a month on that revenue if I don’t have to sacrifice a second of additional loading time no matter how clever I was optimizing it.

That 1 second of loading time probably has more to do with heavy frontends and third-party scripts, than the backend server's capacity.

$100 is peanuts to most businesses, of course. But even so, I'd rather spend it on fixing an actual bottleneck.

Not all businesses depend on milliseconds being shaved off the loading times

For example: Ticketmaster makes a ton of money and their site is complete dogshit.

Saving 15 USD on 0 USD MMR while still building the business is priceless. Virtually infinite runway.

Only if your time is worthless and someone else is paying your living expenses.

There’s a happy medium and $5 for 1GB RAM just isn’t it.

Be sure to inform the author of the article who is currently making money on his 1GB VPS that he hasn’t found a happy medium

Not a very strong argument now is it?

if the project already has positive revenue then arguably the ability to capture new users is worth a lot, which requires acceptable performance even when a big traffic surge is happening (like a HN hug of attention)

if the scalability is in the number of "zero cost" projects to start, then 5 vs 15 is a 3x factor.

NVME read latency is around 100usec, a SQLite3 database in the low terabytes needs somewhere between 3-5 random IOs per point lookup, so you're talking worst case for an already meaningful amount of data about 0.5ms per cold lookup. Say your app is complex and makes 10 of these per request, 5 ms. That leaves you serving 200 requests/sec before ever needing any kind of cache.

That's 17 million hits per day in about 3.9 MiB/sec sustained disk IO, before factoring in the parallelism that almost any bargain bucket NVME drive already offers (allowing you to at least 4x these numbers). But already you're talking about quadrupling the infrastructure spend before serving a single request, which is the entire point of the article.

Rereading this, I have no idea where 3.9 MiB/sec came from, that 200 requests/sec would be closer to 8 MiB/sec

You won't get such numbers on a $5 VPS, the SSDs that are used there are network attached and shared between users.

Not quite $5, but a $6.71 Hetzner VPS

    # ioping -R /dev/sda

    --- /dev/sda (block device 38.1 GiB) ioping statistics ---
    22.7 k requests completed in 2.96 s, 88.8 MiB read, 7.68 k iops, 30.0 MiB/s
    generated 22.7 k requests in 3.00 s, 88.8 MiB, 7.58 k iops, 29.6 MiB/s
    min/avg/max/mdev = 72.2 us / 130.2 us / 2.53 ms / 75.6 us

> There are zero reasons to limit yourself to 1GB of RAM

There is a good reason: teaching yourself not to over-engineer, over-provision, or overthink, and instead to focus on generating business value to customers and getting more paying customers. I think it’s what many engineers are keen to overlook behind fun technical details.

> There is a good reason: teaching yourself not to over-engineer, over-provision, or overthink, (...)

This is specious reasoning. You don't prevent anything by adding artificial constraints. To put things in perspective, Hetzner's cheapest vCPU plan comes with 4GB of RAM.

If I give you a box with 1 GiB of RAM, you are literally forced to either optimize your code to run in it, or accept the slowdown from paging. How is this specious?

> If I give you a box with 1 GiB of RAM, you are literally forced to either optimize your code to run in it, or accept the slowdown from paging. How is this specious?

It is specious reasoning. Self-imposing arbitrary constraints don't make you write good, performant code. At most it makes your apps run slower because they will needlessly hit your self-impose arbitrary constraints.

If you put any value on performant code you just write performance-oriented code, regardless of your constraints. It's silly to pile on absurd constraints and expect performance to be an outcome. It's like going to the gym and work out with a hand tied behind your back, and expect this silly constraints to somehow improve the outcome of your workout. Complete nonsense.

And to drive the point home, this whole concern is even more perplexing as you are somehow targeting computational resources that fall below free tiers of some cloud providers. Sheer lunacy.

Constraints provide feedback. Real-world example from my job: we have no real financial constraints for dev teams. If their poor schema or query design results in SLO breaches, and they opt to upsize their DB instead of spending the effort to fix the root problem, that is accepted. They have no incentive to do otherwise, because there are no constraints.

I think your analogy is flawed; a more apt one would be training with deliberately reduced oxygen levels, which trains your body to perform with fewer resources. Once you lift that constraint, you’ll perform better.

You’re correct that you can write performant code without being required to do so, but in practice, that is a rare trait.

The gym analogy fails. Isolation exercises are almost exactly what you described. They target individual muscles to maximize hypertrophy, i.e. "improve the outcome of your workout."

Why not a box with 128MB of RAM then?

Aside from the perfect solution fallacy, pragmatically it's because most operating systems require more than that to run. Debian's current recommended minimum is 512 MB, though they note that with swap enabled, as little as 350 MB is possible. If you wanted to run something more esoteric like Damn Small Linux, it's possible with as little as 64 MB last I checked.

In any case, this is for the OS itself - the webserver, application, database, etc. will all of course require their own. For a well-optimized program with a well-optimized schema, 1 GB is a reasonable lower bound.

Oh I'm well aware of the existence of operating systems that run in 32MB of RAM or less. So - why not? I think a well-optimised application server (especially one that uses SQLite as a datastore like the article proposes) can fit just fine in 128MB of RAM total, or 256MB if we're being generous. A whole gigabyte of memory seems rather extravagant, no? You could run half a dozen properly optimised apps on such a box.

Or better yet, go with a euro provider like Hetzner and get 8GB of RAM for $10 or so. :)

Even their $5 plan gives 4GB.

They also have servers in the US (east and west coast).

I don't think they offer their cheapest options (CX*) outside of Germany/Finland though. Singapore and USA are a bit pricier.

I've been using Linode for years and just yday went to use Hetzner for a new VPS and they wanted my home address and passport. No thanks.

I think we have to re-think and re-evaluate RAM usage on modern systems that use swapping with CPU-assisted page compression and fast, modern NVMe drives.

The Macbook Neo with 8GB RAM is a showcase of how people underistimated its capabilities due to low amount of RAM before launch, yet after release all the reviewers point to a larger set of capabilities without any issues that people didn't predict pre-launch.

$5 VPS disks are nowhere near macbooks, they are shared between users and often connected via network. They don't seat close to CPU.

Also, macOS is generally exceptional at caching and making efficient use of the fast solid state chips.

Memory compression sounds like going back to DOS days. I think we're better off with writing tighter more performant code with no YAGNI. Alas, vibe coding will probably not get us there anytime soon.

Apple laptop CPUs have hardware memory compression and exceptionally high memory bandwidth for a CPU, and with their latest devices, very high storage bandwidth for a consumer SSD, so the equation is very different from the old DOS days.

It doesn't look like they think about how to make it fit though. They just use a known good go template

Hetzner, OVH and others offer 4-8gb and 2-4 cores for the same ~5$

Where can you get 8GB for $20?

> There are zero reasons to limit yourself to 1GB of RAM. By paying $20 instead of $5 you can get at least 8gb of RAM.

In my head, I call this the 'doubling algorithm'.

If there's anything that's both relatively cheap and useful, but where "more" (either in quality or quantity) has additional utility, 2x it.

Then 2x it again.

Repeat until either: the price change becomes noticeable or utility stops being gained.

Tl;dr -- saving order-of single dollars is rarely worth the tradeoffs.

The reason would be YAGNI. Apparently 1GB doesn’t constitute an actual limit for OP’s use case. I’m sure he’ll upgrade if and when the need arises.

> "There are zero reasons to limit yourself to 1GB of RAM"

> Immediately proposes alternative which is literally 4x the cost.

While I agree that the $15 difference won’t make any financial difference, I look at the numbers from another angle. The main idea here, as per my understanding, is to reduce the hosting cost as much as possible.