I opened a fresh terminal last week to start a small internal dashboard for tracking our team's deploys. Nothing huge. A couple of tables, a chart, a status light per service. Before I typed a single line of real code, I had four browser tabs open arguing about which runtime to use, two about the "right" package manager in 2026, and one very confident blog post explaining why the database I was about to pick was already obsolete.
I closed the laptop and made tea.
The promise is always the same
Almost every serious tool is fine. Most of them are genuinely good. That is the problem. When everything is good, marketing can't say "this is good," so it reaches for the superlative. Fastest. Most loved. The future of the stack.
It is the sheer volume of it, all at once, in every category, that wears me down. Here is my week.
JavaScript runtimes: pick a lane, any lane
I wanted to run some JavaScript. Used to be a one-line decision. Now there are three serious answers and each one has a personality.
Node is the boring grown-up that runs most of the internet and supports basically every package on npm. Deno shows up with native TypeScript, a strict permissions model, and a built-in formatter, linter, and test runner, so you stop gluing twelve tools together. Bun bundles the runtime, package manager, bundler, and test runner into one binary and tells you it is dramatically faster at almost everything.
And it can be. In an Express-style HTTP test Bun sustained roughly 52,000 requests per second where Node plateaued around 13,000, about four times faster (Strapi). Impressive number. Then you read the same writeup's more realistic test, with routing, validation, and an actual database in the loop, and the gap collapses to about 12,400 versus 12,000 requests per second. Less than three percent.
So which one is fastest? All of them, depending on which benchmark you were shown. The pattern most teams quietly land on is unglamorous: existing services stay on Node, brand-new services try Bun, and security-sensitive work leans Deno (daily.dev).
Package managers: an 18x number that means almost nothing
Fine. I picked a runtime. Now how do I install dependencies? There are four contenders and they will all tell you the others are slow.
The numbers are real and they are genuinely big. On a typical React and TypeScript project, a cold install clocks in at roughly 0.8 seconds with Bun, about 5 seconds with pnpm, and a leisurely 14 seconds with npm, which works out to Bun being around 18x faster than npm (DeployHQ). Bun is written in Zig and makes a fraction of the system calls npm does, about 165,000 against nearly a million on the same install (Bun). That is a legitimately clever engineering story, and pnpm's own benchmarks back up that it crushes npm on most graphs (pnpm).
Here is my tired confession. I install dependencies maybe a few times a day. The difference between one second and fourteen, summed over a normal day, is not what is slowing me down. What slows me down is reading three "showdown" posts to feel allowed to pick one.
The speed crown also moves. A year ago the install-speed story was pnpm's. Then Bun shipped a binary lockfile and a native installer and took the headline. Whatever you standardized on last quarter is now, by some post's reckoning, the slow one. I spent a weekend moving forty-odd internal services off Yarn onto pnpm, and then a few months later half of them onto Bun, chasing exactly this. The only things that actually changed were the lockfile format and my mood. I will not be doing it a third time.
| Category | The pitch you'll hear | What's usually true |
|---|---|---|
| JS runtime | "Blazing fast, all-in-one" | Real wins in micro-benchmarks, small gap under real load |
| Package manager | "Up to 18x faster installs" | True on cold installs, rarely your bottleneck |
| OLAP database | "Fastest analytics engine" | Depends entirely on data size and query shape |
| AI model | "New state of the art" | True for a few weeks, on specific benchmarks |
| ...and the next category | "...also the fastest and the future" | "...and the one after that, and the one after that" |
Databases: the fastest, according to whose benchmark?
This is where it gets funny, because the superlatives start colliding with each other.
ClickHouse will tell you, with receipts, that it is the strongest general-purpose real-time analytics database, winning or tying 32 of 43 queries on ClickBench with a median hot-cache latency around 148 milliseconds (ClickHouse). DuckDB will tell you it is the SQLite of analytics, runs in-process, and is plenty fast for the data that actually fits on one machine. Both are correct. ClickBench is also, as one analytics vendor pointed out a little dryly, created by ClickHouse, so it is fair to assume it favors ClickHouse's engine (Tinybird).
That is not a scandal. Every vendor benchmarks on the workload that flatters them. It just means "fastest database" is a sentence with an invisible footnote attached.
Then there is the vector database category, which spent two years insisting you needed a dedicated, purpose-built, blazing-fast vector store for your AI app. Meanwhile pgvector quietly let people store embeddings right next to their relational data and run similarity search in under 20 milliseconds even at a million vectors (Encore). The counter-movement now has its own slogan, "you probably don't need a vector database," which is, of course, also a marketing position. Even the backlash to the hype is hype.
I find this strangely comforting. If "just use Postgres" can become a movement, then boring and reliable still gets a turn now and then.
Observability: same play, different category
Logs and metrics fell into the same pattern while I wasn't looking. Every storage backend and pipeline in this space promises lower cost, higher ingest, and faster queries than whatever you are running today. One project pitches column-oriented storage that makes your old setup look wasteful. Another pitches a unified store so you stop running three systems for logs, metrics, and traces. A third pitches an agent that is somehow lighter than the lightweight agent you already deemed lightweight.
I do not doubt the numbers. I doubt my ability to act on them. By the time I have evaluated one observability stack, the team behind a competing one has published a benchmark showing it ingests more events per second on a cheaper instance. The category never settles long enough for me to feel finished, so I have mostly stopped trying to feel finished.
AI models: state of the art, valid until next Thursday
You knew this one was coming.
Skim any leaderboard and a fresh "new SOTA" announcement lands before you have finished reading the last one (Vellum, llm-stats). One model tops SWE-bench, another tops reasoning, a third wins competitive coding, and last month's leaderboard is already a museum piece.
I genuinely like a lot of these tools. But the cadence has broken my brain a little. I will spend an afternoon getting a workflow tuned around one model, feel good about it, and the next morning a thread informs me that choice is now embarrassing because something launched overnight that scores two points higher on a benchmark I will never personally run. The fear of missing the better tool has quietly replaced the joy of using a good one.
Why everyone shouts at once
Most categories are crowded with good options, so a real, defensible edge on one benchmark is the only honest hook left. Launch posts and comparison content are how projects get attention, so the loudest, most quantified claim wins the feed. And I reward it. I clicked the "18x faster" headline, then rewrote half a build pipeline around the tool behind it, then watched it save me about nine seconds a day. I am exactly the reader this all works on.
The benchmarks are not lies. They are narrow truths presented at full volume. "Fastest on this query, on this hardware, with a warm cache" becomes "fastest," because the qualifier does not fit on the banner and would dull the punch anyway.
There is also a timing trap in here. A launch is a single moment, but a tool lives in your codebase for years. Marketing optimizes for the moment, when attention is cheap and the demo is rehearsed. You optimize for the years, when the docs have to be searchable, the error messages have to make sense, and someone new has to read the code. The loudest tool on launch day is not reliably the one you are happiest with eighteen months later.
How I actually pick now (the only useful part)
I promised this rant would earn its keep, so here is what I do now, mostly out of self-defense.
I start from the boring default and make the shiny thing argue its way in. Node, Postgres, npm, the model already wired up. The well-worn option has Stack Overflow answers from 2019 that still work, and I will take that over a leaderboard win most days. I only go shopping when something is actually, measurably slowing me down. Not "a blog post says I could be faster." Real pain I have felt. If installs are not my bottleneck, I genuinely do not care that another installer is quicker.
When I do read a benchmark, I read the workload before the number. If I cannot tell what was measured, I assume it was measured to win, because it usually was. And I try to pick for the unglamorous middle of a project rather than the demo: the migrations, the 2am debugging, the new hire who has to understand the code. Launch day is the least important week of a tool's life with me.
The thing that actually saves my sanity is just stopping. When a choice is good enough, I commit and close the tabs. I have shipped with the slightly slower option plenty of times and never once sat there at 2am wishing I had picked the faster one. It just never comes up.
So, honest question
I want to know how you do it, because I am clearly still figuring it out.
When you start something new and every option in the category swears it is the fastest and the future, how do you actually choose? Do you default to boring on purpose? Trust one person's taste over benchmarks? Pick the thing with the best docs and never look back? Or do you, like me, occasionally close the laptop and make tea?
Tell me in the comments. Bonus points for the most over-the-top "we're the best" tagline you've seen lately. I collect them now. It's a coping mechanism.
Top comments (0)