Berlin Tech-Szene 2026: Welchen Stack erfolgreiche Startups wirklich nutzen

Geh in irgendeinen Coworking-Space in Kreuzberg oder entlang der Spree, und Du triffst eine CTO mitten in einer Einstellungsdiskussion, die ungefähr so klingt: "Wir hätten fast Rails gewählt, weil die Gründer das in ihrer letzten Firma genutzt haben, aber der Architekt, den wir eingestellt haben, hat dagegengehalten. Er sagte, die Hälfte der erfahrenen Backend-Leute, die wir in Berlin interviewen würden, würden es nicht anfassen." Einen Monat später lieferten sie ihr MVP auf Symfony und Next.js aus. Es ist nicht der Stack, den das Seed-Deck vorhersagte. Es ist der Stack, der tatsächlich zum Berliner Talentmarkt, zum regulatorischen Umfeld und zur Unit Economics eines europäischen SaaS-Geschäfts im Jahr 2026 passt.

Dieses Muster ist gerade überall in der Berliner Tech-Szene zu sehen. Die aus Y-Combinator-Essays und US-Engineering-Blogs kopierten Defaults werden still durch Entscheidungen ersetzt, die für Unternehmen mehr Sinn ergeben, die in Deutschland gebaut werden, an europäische Unternehmen verkaufen und aus dem Talentpool einstellen, der hier existiert, statt aus dem in San Francisco. Dieser Beitrag betrachtet die Landschaft des Berliner Tech-Stacks 2026 quer durch Backend, Frontend, Infrastruktur und Daten, mit Kommentaren dazu, was erfolgreiche Startups tatsächlich nutzen und warum bestimmte Muster immer wieder gewinnen.

Die strukturellen Kräfte hinter dem Berliner Tech-Stack 2026

Bevor wir konkrete Technologien betrachten, hilft es zu verstehen, was die Entscheidungen tatsächlich treibt. Der Berliner Stack konvergiert nicht auf bestimmte Werkzeuge, weil sie am modischsten sind. Er konvergiert, weil eine Handvoll struktureller Kräfte sie selektiert.

Die DSGVO ist kein Häkchen, sondern eine Einschränkung der Architektur. Ein Berliner Startup, das deutschen Mittelstand, europäische Versicherer oder regulierte Branchen bedient, kann nicht beiläufig jedes Event durch einen US-basierten Analytics-Anbieter leiten. Das schiebt Entscheidungen Richtung EU-gehostete Infrastruktur, Open-Source-Observability und selbst gehostete Analytics wie Plausible oder Matomo. Die Architekturen, die in Berlin gewinnen, sind die, bei denen das Rechtsteam in einem einzigen Absatz beschreiben kann, wo jedes Stück Kundendaten liegt.

Die Talentverfügbarkeit biegt den Stack. Berlin hat einen tiefen Pool an erfahrenen PHP/Symfony-, TypeScript/React- und Go-Entwicklern. Der Pool an Ruby-on-Rails-Experten, Elixir-Ingenieuren oder Scala-Spezialisten ist deutlich dünner. Technologieentscheidungen, die in einem Blogpost großartig klingen, aber eine zwölfwöchige Einstellungsverzögerung erzeugen, werden von pragmatischen Gründern still verworfen. Der Berliner Startup-Technologie-Stack spiegelt wider, was Du tatsächlich in sechs Wochen besetzen kannst, nicht was theoretisch optimal ist.

Cloud-Kosten beißen in Europa stärker. Mit einem schwächeren Euro und Unternehmenskunden, die sich gegen monatliche Gebühren wehren, sind Berliner Startups kostenbewusster als ihre US-Pendants. Das heißt, Hetzner, Scaleway und OVH werden ernst genommen. Es heißt, Kubernetes wird nicht vorausgesetzt. Es heißt, Postgres wird meist gegenüber proprietären Managed-Datenbanken bevorzugt, sofern es nicht einen konkreten, messbaren Grund gibt, extra zu zahlen.

Kunden sind große Unternehmen mit Einkaufsabteilungen. Berlins B2B-SaaS-Szene verkauft an Unternehmen, die IT-Sicherheitsfragebögen und AVVs durchlaufen. Das filtert Architekturen heraus, die Auditoren schwer zu erklären sind, und begünstigt solche mit klaren Grenzen, gutem Logging und langweiligen, gut verstandenen Komponenten.

Backend: PHP/Symfony-Renaissance, TypeScript/Node stabil, Go in der Infrastrukturschicht

Die größte Überraschung für jeden, der Berlin mit der Bay Area vergleicht, ist, wie viel ernsthafte neue Backend-Arbeit in PHP passiert - konkret Symfony 7 auf PHP 8.3 oder 8.4. Vor einem Jahrzehnt hätte es Stirnrunzeln ausgelöst, ein neues Startup in Berlin auf PHP zu starten. 2026 ist es oft der schnellste Weg von null zu einer produktionsreifen B2B-Anwendung.

Die Gründe sind nicht romantisch. PHPs typisiertes Ökosystem, Symfonys Dependency Injection und Messenger-Komponente, Doctrines ausgereifte ORM und die Verfügbarkeit erfahrener Ingenieure ergeben zusammen einen Stack, den ein kleines Team schnell ausliefern und jahrelang pflegen kann. Unternehmen, die vor fünf Jahren auf Rails gebaut haben, stellen fest, dass ihre Ruby-Einstellungspipeline ausgetrocknet ist, während Symfony-Kandidaten reichlich vorhanden sind. Viele sind nun in einem über mehrere Quartale laufenden Programm zur Legacy-Code-Optimierung, um zu migrieren.

TypeScript auf Node.js ist das zweite große Cluster, besonders für Startups, deren Gründer aus dem Frontend kommen. NestJS ist beliebt bei Startups, die meinungsstarke Struktur wollen. Fastify und schlichtes Express halten sich für kleinere Services. Das typische Muster ist eine TypeScript-API hinter einem Next.js-Frontend, die Typen über ein Monorepo teilt.

Go taucht zunehmend in den Infrastruktur- und Data-Engineering-Schichten auf. Stream-Prozessoren, Kommandozeilen-Tools, Webhook-Relays, durchsatzstarke API-Gateways und Kubernetes-Operatoren werden oft in Go geschrieben, sogar bei Unternehmen, deren Hauptanwendung PHP oder TypeScript ist. Das Muster lautet "TypeScript oder PHP für das Produkt, Go für die Rohre".

Rust erscheint bei einer Handvoll Berliner Startups mit konkreten Performance-Anforderungen - Videoverarbeitung, hochfrequente Finanzdaten, Echtzeit-Collaboration-Backends - bleibt aber eine Minderheitenwahl. Elixir, Kotlin auf der JVM und Python tauchen dort auf, wo das Team tiefe Expertise hat, sind aber keine Standard-Defaults.

Eine typische Berliner Symfony-Anwendung im Jahr 2026 sieht ungefähr so aus:

// Symfony 7 / PHP 8.3 controller - the boring, productive default
#[AsController]
final class TenantApiController
{
    public function __construct(
        private readonly TenantRepository $tenants,
        private readonly EventBusInterface $bus,
    ) {}

    #[Route('/api/tenants/{id}', methods: ['GET'])]
    public function show(
        #[MapEntity] Tenant $tenant,
        #[CurrentUser] User $user,
    ): JsonResponse {
        $this->denyAccessUnlessGranted('view', $tenant);

        return $this->json(
            TenantDto::fromEntity($tenant),
            context: ['groups' => ['tenant:read']],
        );
    }
}

Dieser Code ist unspektakulär, und genau das ist der Punkt. Er ist typsicher, getestet, leicht zu besetzen und liefert immer noch in Produktion für Unternehmen, die mittlerweile in der Series B sind.

Frontend: Next.js dominant, React Server Components setzen sich

Im Frontend hat Next.js den Default-Platz praktisch für sich entschieden. Unter den 2025 bis 2026 gestarteten oder relaunchten Berliner Startups ist der Next.js App Router mit React 19 Server Components das mit Abstand häufigste Muster. Das ist nicht einzigartig für Berlin, aber das Adoptionstempo hier war auffällig.

Die Gründe sind praktisch. Die meisten Berliner Startups haben Marketing-Seiten, Blog-Inhalte und Dashboards, die alle koexistieren müssen. Next.js deckt alle drei ab, ohne das Team zu zwingen, drei verschiedene Deployment-Pipelines zu betreiben. Die Fähigkeiten zu Static Export und ISR bedienen die SEO-kritischen Flächen, während die Server Components das Datenladen für authentifizierte Dashboards vereinfachen.

Reine SPA-Architekturen sind in Berlin rückläufig. Die Kombination aus Core-Web-Vitals-Druck, SEO-Anforderungen für B2B-Content-Marketing und der Verfügbarkeit guter Server-Rendering-Tools macht reines Client-React zu einer schwereren Wahl. Teams greifen weiterhin für bestimmte Anwendungen zu Client-lastigen SPA-Mustern - interne Admin-Dashboards, Design-Tools, datenintensive Canvases - aber nicht für öffentlich sichtbare SaaS-Produkte.

TypeScript wird vorausgesetzt. Eine neue React-Codebasis in Berlin, die nicht den TypeScript-Strict-Mode nutzt, ist selten und wird von erfahrenen Bewerbern im Interview generell als Warnsignal gewertet. Tailwind CSS hat styled-components und CSS-Module für neue Arbeit weitgehend verdrängt. Zustand und TanStack Query sind der Default-State/Daten-Stack, wobei Redux zunehmend Legacy-Codebasen vorbehalten ist. Shadcn/UI ist beliebter als schwerere Komponentenbibliotheken, weil Teams den Code in ihrem Repo wollen statt einer unlesbaren Black Box.

Vue.js hält eine stabile Minderheitenposition, besonders in Teams aus dem Nuxt-Ökosystem. SvelteKit wächst, ist aber noch Nische. Angular ist außerhalb von Enterprise-Produkten, die in bestehende Angular-Bestände verkauft werden, selten geworden.

Infrastruktur: Hetzner und Scaleway nehmen AWS (manchmal) die Butter vom Brot

Hier weicht Berlin am sichtbarsten vom US-Default-Stack ab. In der Bay Area ist der Default zu AWS fast reflexhaft. In Berlin lautet der Default öfter "was ist das kleinste, günstigste Ding, das die Compliance- und Performance-Latte erfüllt?".

Hetzner ist wirklich beliebt geworden. Für zustandslose Anwendungen mit vorhersehbaren Lasten kann eine Handvoll CPX51-Server mit Docker Compose oder einem kleinen k3s-Cluster die Last eines Series-A-SaaS zu einem Bruchteil der AWS-Preise stemmen. Scaleway spielt eine ähnliche Rolle für Startups, die eine etwas Cloud-ähnlichere Erfahrung mit europäischem Hosting wollen. OVH bleibt stark am kostensensiblen Ende des Markts.

AWS, Azure und GCP werden weiter genutzt, aber öfter für spezifische Workloads - Data-Pipelines auf GCP, regulierte Workloads auf Azure, globales CDN und Lambda auf AWS - statt als alles umfassende Plattform. Multi-Cloud ist in Berlin kein Marketing-Schlagwort; es ist oft einfach ein Zufall, wo verschiedene Fähigkeiten am günstigsten sind.

Die Kubernetes-Adoption ist selektiver als in den USA. Das Berliner Muster lautet: mit Docker Compose oder einer Managed-Plattform wie Fly.io oder Railway starten, zu einem kleinen Managed-k3s- oder EKS-Cluster aufsteigen, wenn Du es wirklich brauchst, und Kubernetes widerstehen, bis die Kosten des Nichthabens den Betriebsaufwand übersteigen. Teams, die in Berlin ernsthaftes Kubernetes betreiben, sind überproportional jene, deren Produkt von der Abstraktion profitiert - Plattformunternehmen, B2B-Infrastruktur-Tools, Workloads mit hoher Variabilität.

CI/CD ist nahezu universell GitHub Actions oder GitLab CI. Selbst gehostetes GitLab ist in compliance-sensiblen Branchen immer noch überraschend verbreitet. Argo CD und Flux tauchen in Kubernetes-Shops auf; einfachere Teams pushen einfach mit docker compose pull über SSH und schlafen nachts ruhig.

Daten, Observability und der leise Aufstieg des langweiligen Stacks

Postgres ist die Default-Datenbank. Das war nicht immer so - MySQL hatte in der älteren, PHP-lastigen Berliner Szene eine starke Position - aber neue Projekte 2026 defaulten fast ohne Diskussion auf Postgres. Es verarbeitet JSON gut genug, um die meisten Ad-hoc-MongoDB-Nutzungen zu ersetzen, die Volltextsuche ist stark genug, um ein Elastic-Deployment hinauszuzögern, und die betriebliche Reife ist schwer zu schlagen. TimescaleDB taucht auf, wo Zeitreihendaten zählen; ClickHouse erscheint in analytics-lastigen Startups, die mit Postgres bei Event-Daten an Grenzen stoßen.

Redis ist allgegenwärtig für Caching, Rate-Limiting und Symfony-Messenger-Transports. RabbitMQ ist der Standard-Schwergewichts-Message-Broker, wobei Kafka Teams mit echtem Streaming-Bedarf vorbehalten ist. S3-kompatibler Objektspeicher wird meist über Hetzner Object Storage, Scaleway Object Storage oder AWS S3 konsumiert - Teams schreiben selten Code, der an einen bestimmten Anbieter gebunden ist.

Observability hat sich entschieden Richtung OpenTelemetry und das selbst hostbare Grafana-Ökosystem verschoben. Grafana Loki für Logs, Tempo für Traces, Prometheus für Metriken, Alertmanager für Paging. Sentry ist für Error-Tracking weiterhin verbreitet, oft selbst gehostet. Datadog und New Relic werden von finanzierten Startups genutzt, die die schlüsselfertige Erfahrung schätzen, aber die Preissensibilität europäischer Käufer führt dazu, dass die Self-hosted-Option häufiger gewinnt als in vergleichbaren US-Unternehmen.

Privacy-first-Analytics haben die Berliner Marketing-Seite für sich entschieden. Plausible, Matomo und Umami sind weit verbreiteter als Google Analytics, teils aus DSGVO-Gründen und teils, weil das Berliner Publikum zunehmend Tracker-blockierende Browser nutzt, was GA-Daten ohnehin unzuverlässig macht.

Was das bedeutet, wenn Du Deinen Stack wählst

Wenn Du eine Berliner Gründerin bist, eine CTO bei einem deutschen Mittelständler oder eine internationale Gründerin, die hier ein Team aufbauen will, sind die praktischen Implikationen der Landschaft des Berliner Tech-Stacks 2026 unkompliziert.

Kämpfe nicht gegen den Talentmarkt. Wenn Du einen Stack wählst, der Dich zwingt, um die 40 Leute in Berlin zu konkurrieren, die Elixir gut beherrschen, wirst Du mehr Zeit mit Einstellen als mit Ausliefern verbringen. PHP/Symfony, TypeScript/Next.js und Go sind die drei tiefsten Pools; auf einem von ihnen zu bauen verkürzt Deinen Einstellungszyklus dramatisch.

Nimm Kosten und Compliance vom ersten Tag an ernst. Die Architekturen, die in Berlin funktionieren, sind die, bei denen ein Wechsel zu Hetzner oder Scaleway eine realistische Option ist, bei denen die Datenflüsse für einen AVV dokumentierbar sind und bei denen der Observability-Stack nicht jede Logzeile an ein US-gehostetes SaaS schickt. Das sind keine trivialen nachträglichen Migrationen; es sind Designentscheidungen.

Bevorzuge langweilige Komponenten für die Teile des Systems, die Dich nicht differenzieren. Postgres, Redis, Symfony oder Next.js, Grafana-Observability, GitHub-Actions-CI. Spar das interessante Technologiebudget für das eigentliche Produkt. Dieses Muster erscheint in nahezu jedem erfolgreichen Berliner Stack und fehlt in den meisten gescheiterten.

Für Gründer, die diese Abwägungen konkret bewerten - zwischen Symfony und Node.js wählen, entscheiden, wann Kubernetes einzuführen ist, oder einen geerbten Stack prüfen, der ohne diese Einschränkungen zusammengesetzt wurde - spart eine zweite Meinung von einer erfahrenen Berliner Ingenieurin oft eine Kurskorrektur über mehrere Quartale. Wolf-Tech unterstützt Gründer und CTOs durch Tech-Stack-Strategie, Custom Software Development und Code-Quality-Audits auf Basis von über 18 Jahren Softwareentwicklung für den europäischen Markt. Wenn Du eine Außensicht auf Deinen aktuellen oder geplanten Stack willst, kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung.