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 ungefaehr so klingt: "Wir haetten fast Rails gewaehlt, weil die Gruender das in ihrer letzten Firma genutzt haben, aber der Architekt, den wir eingestellt haben, hat dagegengehalten. Er sagte, die Haelfte der erfahrenen Backend-Leute, die wir in Berlin interviewen wuerden, wuerden es nicht anfassen." Einen Monat spaeter 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 tatsaechlich zum Berliner Talentmarkt, zum regulatorischen Umfeld und zur Unit Economics eines europaeischen SaaS-Geschaefts im Jahr 2026 passt.

Dieses Muster ist gerade ueberall in der Berliner Startup-Szene zu sehen. Die aus Y-Combinator-Essays und US-Engineering-Blogs kopierten Defaults werden still durch Entscheidungen ersetzt, die fuer Unternehmen mehr Sinn ergeben, die in Deutschland gebaut werden, an europaeische 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, warum bestimmte Muster immer wieder gewinnen.

Die strukturellen Kraefte hinter dem Berliner Tech-Stack 2026

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

Die DSGVO ist kein Haekchen, sondern eine Einschraenkung der Architektur. Ein Berliner Startup, das deutschen Mittelstand, europaeische Versicherer oder regulierte Branchen bedient, kann nicht beilaeufig 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 Stueck Kundendaten liegt.

Die Talentverfuegbarkeit 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 duenner. Technologieentscheidungen, die in einem Blogpost grossartig klingen, aber eine zwoelfwoechige Einstellungsverzoegerung erzeugen, werden von pragmatischen Gruendern still verworfen. Der Berliner Startup-Technologie-Stack spiegelt wider, was Du tatsaechlich in sechs Wochen besetzen kannst, nicht was theoretisch optimal ist.

Cloud-Kosten beissen in Europa staerker. Mit einem schwaecheren Euro und Unternehmenskunden, die sich gegen monatliche Gebuehren wehren, sind Berliner Startups kostenbewusster als ihre US-Pendants. Das heisst, Hetzner, Scaleway und OVH werden ernst genommen. Es heisst, Kubernetes wird nicht vorausgesetzt. Es heisst, Postgres wird meist gegenueber proprietaeren Managed-Datenbanken bevorzugt, sofern es nicht einen konkreten, messbaren Grund gibt, extra zu zahlen.

Kunden sind grosse Unternehmen mit Einkaufsabteilungen. Berlins B2B-SaaS-Szene verkauft an Unternehmen, die IT-Sicherheitsfragebogen und AVVs durchlaufen. Das filtert Architekturen heraus, die Auditoren schwer zu erklaeren sind, und beguenstigt solche mit klaren Grenzen, gutem Logging und langweiligen, gut verstandenen Komponenten.

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

Die groesste Ueberraschung fuer 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 haette es Stirnrunzeln ausgeloest, ein neues Startup in Berlin auf PHP zu starten. 2026 ist es oft der schnellste Weg von null zu einer produktionsreifen B2B-Anwendung.

Die Gruende sind nicht romantisch. PHPs typisiertes Oekosystem, Symfonys Dependency Injection und Messenger-Komponente, Doctrines ausgereifte ORM und die Verfuegbarkeit erfahrener Ingenieure ergeben zusammen einen Stack, den ein kleines Team schnell ausliefern und jahrelang pflegen kann. Unternehmen, die vor fuenf Jahren auf Rails gebaut haben, stellen fest, dass ihre Ruby-Einstellungspipeline ausgetrocknet ist, waehrend Symfony-Kandidaten reichlich vorhanden sind. Viele sind nun in einem ueber mehrere Quartale laufenden Programm zur Legacy-Code-Optimierung, um zu migrieren.

TypeScript auf Node.js ist das zweite grosse Cluster, besonders fuer Startups, deren Gruender aus dem Frontend kommen. NestJS ist beliebt bei Startups, die meinungsstarke Struktur wollen. Fastify und schlichtes Express halten sich fuer kleinere Services. Das typische Muster ist eine TypeScript-API hinter einem Next.js-Frontend, die Typen ueber 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 fuer das Produkt, Go fuer 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 ungefaehr 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 unspektakulaer, und genau das ist der Punkt. Er ist typsicher, getestet, leicht zu besetzen und liefert immer noch in Produktion fuer 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 fuer 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 haeufigste Muster. Das ist nicht einzigartig fuer Berlin, aber das Adoptionstempo hier war auffaellig.

Die Gruende sind praktisch. Die meisten Berliner Startups haben Marketing-Seiten, Blog-Inhalte und Dashboards, die alle koexistieren muessen. Next.js deckt alle drei ab, ohne das Team zu zwingen, drei verschiedene Deployment-Pipelines zu betreiben. Die Faehigkeiten zu Static Export und ISR bedienen die SEO-kritischen Flaechen, waehrend die Server Components das Datenladen fuer authentifizierte Dashboards vereinfachen.

Reine SPA-Architekturen sind in Berlin ruecklaeufig. Die Kombination aus Core-Web-Vitals-Druck, SEO-Anforderungen fuer B2B-Content-Marketing und der Verfuegbarkeit guter Server-Rendering-Tools macht reines Client-React zu einer schwereren Wahl. Teams greifen weiterhin fuer bestimmte Anwendungen zu Client-lastigen SPA-Mustern - interne Admin-Dashboards, Design-Tools, datenintensive Canvases - aber nicht fuer oeffentlich 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 fuer neue Arbeit weitgehend verdraengt. 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 haelt eine stabile Minderheitenposition, besonders in Teams aus dem Nuxt-Oekosystem. SvelteKit waechst, ist aber noch Nische. Angular ist ausserhalb von Enterprise-Produkten, die in bestehende Angular-Bestaende 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 oefter "was ist das kleinste, guenstigste Ding, das die Compliance- und Performance-Latte erfuellt?".

Hetzner ist wirklich beliebt geworden. Fuer 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 aehnliche Rolle fuer Startups, die eine etwas Cloud-aehnlichere Erfahrung mit europaeischem Hosting wollen. OVH bleibt stark am kostensensiblen Ende des Markts.

AWS, Azure und GCP werden weiter genutzt, aber oefter fuer 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 Faehigkeiten am guenstigsten 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 uebersteigen. Teams, die in Berlin ernsthaftes Kubernetes betreiben, sind ueberproportional jene, deren Produkt von der Abstraktion profitiert - Plattformunternehmen, B2B-Infrastruktur-Tools, Workloads mit hoher Variabilitaet.

CI/CD ist nahezu universell GitHub Actions oder GitLab CI. Selbst gehostetes GitLab ist in compliance-sensiblen Branchen immer noch ueberraschend verbreitet. Argo CD und Flux tauchen in Kubernetes-Shops auf; einfachere Teams pushen einfach mit docker compose pull ueber 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 aelteren, 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 hinauszuzoegern, und die betriebliche Reife ist schwer zu schlagen. TimescaleDB taucht auf, wo Zeitreihendaten zaehlen; ClickHouse erscheint in analytics-lastigen Startups, die mit Postgres bei Event-Daten an Grenzen stossen.

Redis ist allgegenwaertig fuer 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 ueber 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-Oekosystem verschoben. Grafana Loki fuer Logs, Tempo fuer Traces, Prometheus fuer Metriken, Alertmanager fuer Paging. Sentry ist fuer Error-Tracking weiterhin verbreitet, oft selbst gehostet. Datadog und New Relic werden von finanzierten Startups genutzt, die die schluesselfertige Erfahrung schaetzen, aber die Preissensibilitaet europaeischer Kaeufer fuehrt dazu, dass die Self-hosted-Option haeufiger gewinnt als in vergleichbaren US-Unternehmen.

Privacy-first-Analytics haben die Berliner Marketing-Seite fuer sich entschieden. Plausible, Matomo und Umami sind weit verbreiteter als Google Analytics, teils aus DSGVO-Gruenden und teils, weil das Berliner Publikum zunehmend Tracker-blockierende Browser nutzt, was GA-Daten ohnehin unzuverlaessig macht.

Was das bedeutet, wenn Du Deinen Stack waehlst

Wenn Du eine Berliner Gruenderin bist, eine CTO bei einem deutschen Mittelstaendler oder eine internationale Gruenderin, die hier ein Team aufbauen will, sind die praktischen Implikationen der Landschaft des Berliner Tech-Stacks 2026 unkompliziert.

Kaempfe nicht gegen den Talentmarkt. Wenn Du einen Stack waehlst, 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 verkuerzt 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 Datenfluesse fuer einen AVV dokumentierbar sind und bei denen der Observability-Stack nicht jede Logzeile an ein US-gehostetes SaaS schickt. Das sind keine trivialen nachtraeglichen Migrationen; es sind Designentscheidungen.

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

Fuer Gruender, die diese Abwaegungen konkret bewerten - zwischen Symfony und Node.js waehlen, entscheiden, wann Kubernetes einzufuehren ist, oder einen geerbten Stack pruefen, der ohne diese Einschraenkungen zusammengesetzt wurde - spart eine zweite Meinung von einer erfahrenen Berliner Ingenieurin oft eine Kurskorrektur ueber mehrere Quartale. Wolf-Tech unterstuetzt Gruender und CTOs durch Tech-Stack-Strategie, Custom Software Development und Code-Quality-Audits auf Basis von ueber 18 Jahren Softwareentwicklung fuer den europaeischen Markt. Wenn Du eine Aussensicht auf Deinen aktuellen oder geplanten Stack willst, kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io fuer eine kostenlose Beratung.