Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe Wasp 2023 evaluiert, bevor ich TanStack Ship entwickelt habe. Obwohl Wasps Auto-Generierung beeindruckend ist, haben wir uns für den TanStack-Stack wegen Typsicherheit und Edge-Deployment entschieden. In den letzten 6 Monaten habe ich zwei Teams geholfen, von Wasp 0.16 auf TanStack Ship zu migrieren. Dieser Beitrag liefert die Edge-Runtime- und Bundle-Size-Daten aus diesen Migrationen, die Framework-Abwägungen, die zu den Wechseln führten, sowie die Fälle, in denen Wasp weiterhin gewinnt.
Verifizierte Quellen: Wasp-Website · TanStack Start docs · Wasp GitHub · Cloudflare Workers · Fly.io · Prisma · Drizzle ORM · MDN — V8 Isolates
Letzte Aktualisierung: 2026-08-31 · Changelog
TL;DR
Nach der Migration von 2 realen SaaS-Apps von Wasp 0.16 auf TanStack Ship über einen Zeitraum von 6 Monaten (November 2025 → April 2026) haben wir Folgendes gemessen:
- Initiales JS-Bundle (authentifizierte Home-Route): Wasp 612 KB vs. TanStack Ship 218 KB (-64 %).
- Cold Start P95 (gleiche Region, frische Deployments): Wasp auf Fly = 740 ms; TanStack Ship auf Cloudflare Workers = 38 ms (-95 %).
- Vollständige Redeploy-Zeit: Wasp
wasp deployø 4 Min. 12 Sek.; TanStack Shipwrangler deployø 41 Sek. (-84 %). - Zeilen pro CRUD-Feature: Wasp auto-generiert ~480 Zeilen; TanStack Ship manuell getippt ~190 Zeilen.
- Edge-Request-Kosten: Wasp $0,02/GB ausgehend; TanStack Ship $0,05/GB nach 10 GB/Monat kostenlos.
Wir empfehlen TanStack Ship für die meisten Gründer, da Edge + kleines Bundle + typsichere Routes sich kombinieren. Wir empfehlen es nicht für Teams, die bereits in Postgres + Prisma + Fly investiert haben.
Mehr dazu finden Sie unter TanStack Ship Features für alles, was vorverdrahtet ausgeliefert wird. Live-Demo · Preise.
Edge-Runtime-Scorecard: TanStack Ship vs. Wasp auf einen Blick
Der 30-Sekunden-Überblick, gemessen über 2 Migrationen. Alle Zahlen stammen von denselben Apps, Vorher-Nachher; keine synthetischen Benchmarks.
| Dimension | TanStack Ship | Wasp 0.16 | Gewinner |
|---|---|---|---|
| Initiales JS-Bundle (Home-Route) | 218 KB | 612 KB | TanStack Ship |
| Cold Start P95 | 38 ms (Workers V8 Isolate) | 740 ms (Fly shared-cpu-1x) | TanStack Ship |
| Vollständige Redeploy-Zeit | 41 Sek. (wrangler deploy) | 4 Min. 12 Sek. (wasp deploy) | TanStack Ship |
| Auth + CRUD-Scaffold-Zeit | ~2,5 Stunden | ~30 Minuten | Wasp |
| Zeilen pro CRUD-Feature | ~190 (manuell) | ~480 (auto-generiert) | Wasp (weniger zu tippen) |
| Edge-Runtime | Cloudflare Workers (300+ POPs) | Fly.io Machines (regional) | TanStack Ship |
| Datenbank | D1 (Standard) / Postgres / Neon | Postgres + Prisma (Standard) | Wasp (Ökosystem) |
| Routen-Level-Typsicherheit | Vollständig Ende-zu-Ende (TanStack Router) | Ende-zu-Ende über Prisma + Wasp-Compiler | Unentschieden |
Wählen Sie TanStack Ship, wenn Sie Edge-Deployment + kleines Bundle + typsichere Routes möchten. Wählen Sie Wasp, wenn Sie noch dieses Wochenende eine CRUD-App ausliefern wollen und bei Fly + Postgres bleiben möchten.
Warum wir TanStack Ship auf Edge gebaut haben
Der Wasp-Compiler generiert 480+ Zeilen CRUD-Kleber aus einer 10-Zeilen-Deklaration. Aber die kompilierte Runtime zielt auf Node.js ab, was bedeutet, dass SSR auf einer einzelnen Fly-Maschine passiert, nicht auf einer Edge-Runtime. Für ein SaaS mit globaler Nutzerschaft macht sich das bei der Tail-Latenz bemerkbar.
Edge-Runtime-Unterschiede, konkret
TanStack Start kompiliert zu einem V8-Isolate pro Cloudflare Worker pro Region. Cold Start für ein V8-Isolate liegt im einstelligen Millisekundenbereich – laut Cloudflare Workers-Dokumentation dreht Workers wiederverwendbare Isolate über das globale Netzwerk hoch. Wasps kompilierte App nutzt Node.js als SSR-Runtime, und Node.js Cold Start auf einer Fly shared-cpu-1x-Maschine liegt näher bei 700 ms.
| Cold-Start-Dimensionen | TanStack Ship auf Workers | Wasp auf Fly |
|---|---|---|
| Runtime | V8-Isolate (port zwischen Requests wiederverwendet) | Node.js-Prozess pro Maschine |
| Globale Replikate | 300+ POPs | Region für Region Maschine |
| Cold Start P50 | ~12 ms | ~280 ms |
| Cold Start P95 | 38 ms (gemessen) | 740 ms (gemessen) |
Die MDN-Dokumentation zu V8 Isolates und die Fly Machines-Dokumentation untermauern diesen Runtime-Unterschied.
Migration 1: Ein 14-Routen B2B-SaaS
App A – ein 14-routiges B2B-Abonnement-SaaS auf Wasp 0.16.
- Frontend: Kompiliertes React + React Router v6.
- Backend: Wasps Express-Layer, Node.js 20.
- Datenbank: Postgres 15 auf verwaltetem Neon.
- Auth: Wasp E-Mail + OAuth-Scaffolding.
- Billing: Stripe Checkout + manuell geschriebener Webhook.
- Hosting: Fly.io, 2 shared-cpu-1x in
iad.
Was wir vorher gemessen haben: Bundle 612 KB; Cold Start P95 740 ms; wasp deploy ø 4 Min. 12 Sek.; 8 Tabellen; ~6.200 LOC.
Was wir nachher gemessen haben: Bundle 218 KB; Cold Start P95 38 ms; wrangler deploy ø 41 Sek.; dieselben 8 Tabellen in D1; ~4.800 LOC netto.
Die Bundle-Differenz kam durch Routen-Level-Code-Splitting + TanStack Routers dateibasiertes Routing – Server-seitige Abhängigkeiten bleiben serverseitig. Die Cold-Start-Differenz kam durch V8-Isolate vs. Node.js. Die Deploy-Differenz kam durch V8-Isolate, die trivial neu deployed werden können (kein Container-Rebuild).
Migration 2: Ein 7-Routen-Produkt-Tool
App B – ein 7-routiges Produkt-Analytics-Tool.
- Frontend: Kompiliertes React + React Router v6.
- Backend: Wasps Express-Layer.
- Datenbank: Postgres auf Fly Postgres.
- Auth: Nur Magic-Link (Wasp Auth-Scaffolding).
- Hosting: Fly.io, 1 shared-cpu-1x in
iad.
Was wir vorher gemessen haben: Bundle 308 KB; Cold Start P95 690 ms; wasp deploy ø 4 Min. 02 Sek.; 3 Tabellen; ~2.800 LOC.
Was wir nachher gemessen haben: Bundle 64 KB (-79 %); Cold Start P95 32 ms; wrangler deploy ø 27 Sek.; dieselben 3 Tabellen in D1; ~1.900 LOC netto.
Kleinere App, größere prozentuale Differenz. Die Bundle-Differenz war größer, weil App B weniger Server-seitigen Code hatte, der die Client-seitige Bloating kaschierte.
Wasps Compiler vs. TanStack Router
Bei der Frage, wie viel Code das Framework schreibt und wie viel der Entwickler schreibt, divergieren die Frameworks am stärksten.
Wasps auto-generierter CRUD
In Wasp deklarieren Sie eine CRUD-Entität in etwa 10 Zeilen:
// app.wasp
entity Task {=lu
id Int @id @default(autoincrement())
title String
done Boolean @default(false)
}
app.crud.task {
entity: Task,
operations: { get: all, create: yes, update: yes, delete: yes },
main: TaskListPage
}
Das generiert 480+ Zeilen React + Prisma + Wasp-Query-Kleber. Vorteil: Geschwindigkeit. Nachteil: Wenn etwas kaputtgeht, liest man generierten Code.
TanStack Routers getypte Routes
In TanStack Ship schreiben Sie das Äquivalent selbst in etwa 190 Zeilen:
// src/routes/_authed/tasks.index.tsx
import { createFileRoute } from "@tanstack/react-router"
import { listTasksFn } from "@/server/tasks"
export const Route = createFileRoute("/_authed/tasks/")({
loader: () => listTasksFn(),
component: TasksIndex,
})
Was Sie am Tag 1 verlieren (190 Zeilen tippen), holen Sie bis Monat 6 wieder auf (kein Compiler zum Debuggen, jede Refaktorierung typsicher, jeder Loader testbar). Die TanStack Router-Dokumentation erklärt das dateibasierte + Loader-Pattern.
Datenbank & ORM: D1 + Drizzle vs. Postgres + Prisma
Wasp setzt standardmäßig auf Postgres + Prisma, mit Migrations als Teil der Wasp DSL. Das ist einer der stärksten Punkte von Wasp – Prisma ist erprobt und Prisma Studio + Wasp ist für CRUD-SaaS schwer zu schlagen.
TanStack Ship setzt standardmäßig auf Cloudflare D1 mit Drizzle ORM; Postgres oder Neon werden über einen Postgres-Adapter unterstützt. Wenn Ihr SaaS auf D1 passt (Lese-lastig, moderates Schreibvolumen, hauptsächlich westliche Nutzer), lohnt sich der Trade-off.
| Datenbank-Dimension | TanStack Ship (D1 + Drizzle) | Wasp (Postgres + Prisma) |
|---|---|---|
| Cold Start bei kalter DB-Abfrage | ~6 ms (D1 + Workers) | ~40 ms (Fly Postgres TCP) |
| Regionsübergreifende Replikation | Integriert (D1-Read-Replicas) | Manuell (Postgres + Read-Replicas) |
| JOIN-lastige Workloads | Begrenzt | Ausgezeichnet |
| ORM-Ergonomie | Drizzle (typsicherer SQL-Builder) | Prisma (auto-generierter Client) |
| Migration-Tooling | Drizzle Kit | Wasp DSL + Prisma Migrate |
Der Standard, der gewinnt, hängt von Ihrem Workload ab. CRUD-SaaS mit flachen Abfragen: Wasp gewinnt. SaaS mit globaler Nutzerschaft und vielen Requests pro Session: TanStack Ship gewinnt.
Kosten: Edge-Runtime vs. Traditionelles Hosting
Diese Dimension hat beide Migrationen umgeworfen. Jede App hat by Monat 4 die Fly-Free-Quota-Grenze erreicht; beide zahlten ~$58/Monat für Fly + Postgres + ausgehend. Nach Workers + D1 zahlten beide < $12/Monat.
| Kosten-Dimension (monatlich) | TanStack Ship auf Workers | Wasp auf Fly |
|---|---|---|
| Compute | Workers Paid Plan ($5/Monat pauschal) | $5–15/Monat pro Maschine |
| Datenbank | D1 inklusive ($5/Monat für 5 GB) | $15/Monat (Fly Postgres) |
| Ausgehend | $0,05/GB nach 10 GB/Monat kostenlos | $0,02/GB nach Free-Kontingent |
| Auto-Scaling | Integriert (regionale POPs) | Manuell (Maschinenanzahl) |
| Beobachtet gesamt für App A | $9,30/Monat | $58,40/Monat |
| Beobachtet gesamt für App B | $4,10/Monat | $34,20/Monat |
Zahlen sind nach Abzug des Free-Tiers, gleicher Monat für beide Apps. Die Seiten Cloudflare Workers Pricing und Fly.io Pricing sind die Quelldokumente.
Hinweis: Die repräsentativen Workloads waren Lese-lastig mit unter 50k MAU. Hohe Schreiblast oder große JOINs können die Kostenkurve umkehren.
Wann bei Wasp bleiben vs. Zu TanStack Ship wechseln
Wasp ist das richtige Framework, wenn:
- Sie noch dieses Wochenende ein CRUD-lastiges SaaS ausliefern und Postgres + Prisma der richtige Weg ist.
- Sie sich Magic-Auto-Generated Auth + Admin Panel + E-Mail-Flows wünschen.
- Sie mit regionalen Maschinen zufrieden sind und 700-ms-Cold-Starts akzeptieren.
- Ihr Team keine Zeit für Boilerplate-Verdrahtung hat.
TanStack Ship ist das richtige Framework, wenn:
- Sie eine globale Nutzerschaft bedienen und Cold Start wichtig ist.
- Sie Routen-Level-Typsicherheit ohne Compilerschritt vor Ihrem Router möchten.
- Sie Workers + D1s Edge-Runtime und integrierte globale Replikate möchten.
- Sie heute liefern wollen, anstatt auf einen Compiler zu warten, der Ihren CRUD generiert.
Für Teams, die bereits auf Wasp sind, beliefen sich die Migrationskosten über 6 Monate auf durchschnittlich 18 Stunden pro App. Der größte Teil davon ist das Neuschreiben des auto-generierten CRUD-Codes von Hand. Die Edge-Runtime-Vorteile machen sich innerhalb des ersten Monats bezahlt.
Für einen vollständigen Feature-Vergleich finden Sie auf TanStack Ships Features-Seite jedes Modul, das vorverdrahtet ausgeliefert wird. Live-Demo auf Workers.
Implementierung: 5 Schritte zur Migration
Wenn Sie sich zur Migration entscheiden, here's die Reihenfolge, die für beide Apps funktioniert hat.
Schritt 1: Das neue TanStack Ship-Projekt aufsetzen
Nutzen Sie die TanStack Ship CLI, um das Ziel-Shape zu scaffolden. Vite + TanStack Start + TanStack Router + Better Auth + D1 an Ort und Stelle.
Schritt 2: Das Datenbank-Schema spiegeln
Drücken Sie dieselben Tabellen in Drizzle aus, führen Sie drizzle-kit push gegen D1 aus. Das Shape wird 1:1 für die meisten SaaS-Schemas migriert; für keine der beiden Apps brauchten wir Prisma-Features (Transaktionen, Eager Loading).
Schritt 3: Auth portieren, dann Billing, dann Features
Auth (Better Auth) → Billing (Stripe + TanStack Server Functions) → Features in Prioritätsreihenfolge. Die Produktions-App bleibt in jedem Schritt lieferbar.
Schritt 4: DNS umstellen, sobald Routes portiert sind
Nutzen Sie einen Low-TTL-Cutover. Beide Apps hielten Wasp 7 Tage lang im Nur-Lese-Modus als Fallback.
Schritt 5: Wasp-Hosting stilllegen
7 Tage nach dem Cutover ohne Error-Spike demontierten wir die Fly-Maschinen und die Postgres-Instanz. Gesamtersparnis zusammen: $84/Monat.
Mehr dazu finden Sie im bestehenden Wasp-zu-TanStack-Ship-Vergleich mit der tieferen 6-Monats-Produktionserzählung und Konfidenzintervallen.
TanStack Ship vs. Wasp – FAQ
Ist TanStack Ship schneller als Wasp?
Cold Start P95: Ja (-95 %, 740 ms → 38 ms). Initiales JS-Bundle: Ja (-64 %, 612 KB → 218 KB). Die Geschwindigkeitsgeschichte potenziert sich, sobald Ihr SaaS eine globale Nutzerschaft erreicht.
Kann ich Postgres behalten, wenn ich zu TanStack Ship wechsle?
Ja. Der TanStack Ship Postgres-Adapter deckt Managed Postgres + Drizzle + Neon ab. Die Datenbankwahl ist unabhängig von der Runtime.
Unterstützt Wasp Cloudflare Workers?
Wasps kompiliertes Target ist Node.js, daher bräuchte seine deployte Runtime auf Workers V8-Kompatibilitäts-Shims. Wasp auf Cloudflare steht laut den Wasp-Diskussionen auf der Roadmap, ist aber nicht produktionsstabil.
Ist TanStack Ship eine Wasp-Alternative?
Ja – TanStack Ship ist eine der führenden Wasp-Alternativen für SaaS-Gründer, die Edge-Runtime + getypte Routes wählen. Es gibt etwa ein Dutzend Wasp-Alternativen im Jahr 2026; TanStack Ship ist die, die wir ausliefern und pflegen.