Rae Doughty

Before you pick a language, work out where the four boxes are going. Ingest and write to Postgres is an I/O shaped workload, and if your Python is spending its time waiting on the network and the database, a rewrite in anything compiled buys you far less than you expect. Profile it for an afternoon first.

In my case the honest answer turned out to be that we were spending most of our CPU in JSON deserialisation and in building one INSERT per row. Swapping the JSON library and moving to batched writes cut our box count enough that the rewrite got deferred by a year. If yours is genuinely CPU bound in parsing then Go will help a lot and Rust would help slightly more, but find out which world you are in before you spend six weeks.

Careful with the regret stories in threads like this, including mine, because you are hearing from whoever feels strongly this week. I moved from finance to analytics and month four was awful, month eight was fine, year two was clearly better than the alternative. If I had posted at month four you would be reading a warning. Give yourself a fixed review date twelve months out and refuse to evaluate it before then.

That is the most common answer for a first project, because scale-to-zero is usually the default on the free and cheap tiers - which is exactly right for a hobby project and surprising the moment somebody else is using it. Now you know what you are buying if you ever upgrade the plan.

Normal, and there are usually two separate sleeping things rather than one. Measure before you touch anything:

const t0 = performance.now()
// ... your handler
res.headers.set('Server-Timing', `db;dur=${tDb}, handler;dur=${tAll}`)

plus a module-scope const boot = Date.now() you log once, so you can tell a cold instance from a warm one.

Then force a cold one and read the split:

• most of the second is before your code runs: that is runtime and bundle init, and the fix is a smaller server bundle or paying for a warm instance.
• most of it is the first database call: your database is probably scaling to zero and waking up, which on managed Postgres with auto-suspend is commonly 500ms to a second. Turning off auto-suspend or picking a plan that stays warm fixes that half.

Guessing between those two costs a weekend. Measuring costs ten minutes.

the counter document approach saved us roughly an order of magnitude on a dashboard that showed six totals. six queries reading everything, replaced by one document read.

Real name, real company, real sentence, or leave it empty. Anonymous initials under a stock photo are worse than nothing and everybody can spot them.

I bought the AWD and kept the all seasons on it, exactly the trade you are considering. Felt invincible for about six weeks. Then I came down a gentle slope toward a stop sign at maybe twenty five, touched the brakes, and slid through the junction into the kerb hard enough to bend a control arm and a wheel. The repair was several times what a set of winters on steels would have cost, and my premium went up for three years on top. I have run winters on everything since.

Calculator gets you within a few centimetres. Your elbows and a week of small adjustments get you the rest. Raise the monitor when you stand.

The race you described is real and faster than people expect. I instrumented ours after chasing exactly this bug: our workers were picking jobs off Redis in single digit milliseconds, and the transaction that created the row took a good deal longer than that under load because of a trigger nobody remembered writing. So the job genuinely arrived before the data existed, hundreds of times a day, and every one of those became a not-found in the logs that we had learned to ignore. The gap is not theoretical, and it gets worse under exactly the load where you least want mysterious failures.

It works right up until you have a job whose absence nobody notices, which is exactly the class of bug the outbox exists for. Payments and emails, I would not do it. Cache invalidation, absolutely.

Disagreeing on the on-call part. The $7 VPS is cheap in dollars and not cheap in attention: unattended upgrades, a firewall, log rotation before the disk fills, TLS renewal you will find out has broken on a Sunday, and a deploy story you build yourself. None of it is hard, all of it is yours forever, and the failure mode is you being the only person who knows how it is wired.

Workers deletes that entire column for about $40/month. Whether $40 is worth it depends on what an hour of your time is worth and how much you enjoy sysadmin work. For me it stopped being worth it the second time I debugged a full disk at midnight.

Whatever you pick, do not run it as a coupon code that spreads. Attach it to the account at checkout based on the card, or it will end up on a deals site within a month.

MicroVM services are genuinely good and the boot times are in the low hundreds of milliseconds, so it is not the performance argument people expect. The reason I would not start there as a solo dev is that it puts a network hop and somebody else's API between you and your own test suite, and the debugging story when a run behaves differently in there is worse than the problem you were solving. Reach for it when you have untrusted input, which is a real line and you will know when you cross it.

This is the version I'd recommend to anyone with a services background. A productised implementation is a real business and it doesn't feel like giving up.