Why we ship edge-first by default

Every new Uplix Orbit project ships to the edge from day one. It's not for the buzzword — it's because latency, cost, and developer experience finally line up in a way they didn't three years ago.

It means the app's request handler runs in the network point of presence closest to the user, not in a single region thousands of miles away. It means static assets are served from the same POP. It means the database has a read replica within 50ms of every user, and writes are still transactional.

TanStack Start deployed to Cloudflare Workers. Postgres via a pooled edge proxy for OLTP. KV for hot reads, R2 for large assets, and Durable Objects for anything that needs a strongly consistent single-writer. Auth handled at the edge with signed cookies. Analytics and logs streamed to a warehouse asynchronously.

For our last five launches, first-byte latency dropped from an average of 340ms to 42ms. Bundle sizes stayed roughly the same, but hydration times dropped because HTML arrived faster. Infrastructure bills fell 40–70% because we stopped paying for idle regional servers.

Long-running jobs, heavy image processing, PDF generation with headless Chrome, and legacy Node-only libraries still belong on a real server. We keep those in a small worker pool behind a queue and treat them as background infrastructure — the user-facing app never waits on them.

If you're on a monolith today, don't rewrite. Move the read-heavy pages to the edge behind a reverse proxy first. Then move auth. Then move the writes once you've validated the database story. Full migrations take a quarter, not a year.

Edge Postgres providers are becoming genuinely production-ready. WebAssembly at the edge is unlocking use cases that were impossible last year. And every framework worth using now treats edge deployment as a first-class target. The bar has moved.