# InfoQ picked up the argument

Canonical: https://brew.new/browse/templates/email/pt1_k97st4fw9xsqg67kgqgkdas9ax8e3m68

Brand: harperdb.io
Category: newsletter

![Preview of InfoQ picked up the argument](https://cdn.brew.new/email-preview-73a5c321e38418fb-tracking_r57qj5ps86b23a4nffce5g6hdx8dj2zc-1788998245991.png)

## Email content

Hi there,

InfoQ recently published the story, “Harper Argues against the Multi-System Stack.”

That got my attention, because it puts a question I’ve been asking for years in front of a much bigger audience.

Why does all of this have to be separate?

After all, nobody “designed” the modern application stack. It accumulated.

A database solved one problem. A cache solved another. Then a queue. A serverless runtime. A real-time service.

Every decision made sense on its own.

And somewhere along the way, all of those separate systems became the default.

At Harper, we’ve spent years challenging that assumption.

To test it, we built the same application two ways — once on Harper, once using Vercel with Neon and Upstash — then benchmarked a live, personalized workload.

InfoQ Article

Harper was up to ~14x faster on the live, personalized paths we tested.

But what interests me most isn’t the number. It’s the architectural question underneath it.

What if the stack we inherited doesn’t need to be a “stack” at all?

I’ve been asking that question for a long time.

Maybe this is the moment you start asking it too.

Read the InfoQ article →

Aleks @ Harper

Harper, 2420 17th Street, Suite 270, Denver, Colorado 80202, United States

Unsubscribe

Manage preferences

[Open and remix this design](https://brew.new/browse/templates/email/pt1_k97st4fw9xsqg67kgqgkdas9ax8e3m68)

[Browse email designs](https://brew.new/browse/templates)