Den besten Tech Stack für Directory- und Marketplace-Websites

Die meisten „Best Tech Stack"-Artikel lesen sich, als hätte jemand einen Nachmittag auf Product Hunt verbracht und seine Erkenntnisse aufgeschrieben. Sie werden dir sagen, du sollst React und vielleicht Postgres verwenden, Stripe hinzufügen und fertig. Das hilft nicht, wenn du eine Directory-Website mit 137.000 Listing-Seiten bauen möchtest, die schnell laden müssen, Geo-Suche im Umkreis von 50 Meilen unterstützen und Benutzern ermöglichen, Ergebnisse mit natürlichsprachigen Abfragen zu finden.

Ich habe die letzten zwei Jahre damit verbracht, genau diese Websites zu bauen. Keine Spielzeugprojekte -- Production Directory- und Marketplace-Plattformen, die Hunderttausende von Datensätzen verarbeiten, Multi-Country-Zahlungsverarbeitung (einschließlich der spaßigen Grenzfälle wie Währungen ohne Dezimalstellen) und Suchsysteme, die Full-Text-, Semantic AI- und geografische Abfragen gleichzeitig kombinieren. Dieser Artikel führt dich durch jede Ebene des Stacks, den wir bei Social Animal nutzen, warum wir jedes Stück gewählt haben, und die Production-Daten, die diese Entscheidungen unterstützen.

Inhaltsverzeichnis

Best Tech Stack for Directory & Marketplace Websites in 2026

Warum Directory- und Marketplace-Websites architektonisch einzigartig sind

Directory- und Marketplace-Websites sehen an der Oberfläche einfach aus. Liste einige Dinge auf, lass Menschen suchen, verarbeite vielleicht eine Zahlung. Aber sobald du anfängst, einen mit echten Daten zu bauen, triffst du auf Probleme, auf die dich Standard-SaaS-Architekturen nicht vorbereiten.

Zunächst gibt es das Problem der Seitenzahl. Ein Verzeichnis mit 100.000+ Auflistungen benötigt 100.000+ Seiten. Du kannst sie nicht bei jeder Anfrage rendern, und du kannst sie nicht zur Build-Zeit statisch generieren (deine Builds würden Stunden dauern). Du brauchst etwas Intelligenteres -- Incremental Static Regeneration (ISR) oder on-demand Revalidierung.

Zweitens ist die Suche mehrdimensional. Benutzer möchten nach Text suchen („Familientherapeut"), nach Bedeutung („jemand, der bei Beziehungsängstlichkeit hilft") und nach Standort („innerhalb von 20 Meilen von Austin"). Die meisten Stacks bearbeiten eines davon. Alle drei gleichzeitig zu bearbeiten erfordert eine spezifische Datenbankarchitektur.

Drittens haben Marktplätze eine Zahlungskomplexität, die weit über einen einfachen Checkout hinausgeht. Du handelst mit Plattformprovisionen, Abonnement-Tiers, Multi-Currency-Preisgestaltung und regulatorischen Unterschieden zwischen Ländern. Wenn du etwas davon falsch machst, verlierst du entweder Geld oder brichst Gesetze.

Diese Einschränkungen prägen jede Entscheidung in unserem Stack. Lass uns durch jede Ebene gehen.

Der 10-Ebenen-Stack Überblick

Bevor wir tiefer eintauchen, hier ist das Gesamtbild:

Ebene Tool Warum
Frontend Next.js 15 (App Router) ISR für 100K+ Seiten, Server Components
Database Supabase PostgreSQL pgvector + PostGIS + Full-Text in einer DB
Auth Supabase Auth Row-Level Security, rollenbasierter Zugriff
Payments Stripe Connect Marketplace-Provisionen, Multi-Currency
Search Triple Pattern (tsvector + pgvector + PostGIS) Text + Semantik + Geo gleichzeitig
Media Supabase Storage + Next.js Image Optimierte Bereitstellung, einfache Uploads
Hosting Vercel Edge-Deployment, ISR-Unterstützung, Preview-URLs
Email Brevo API Transaktional + Marketing aus API Routes
AI Claude API Semantic Search, Content Enrichment, Chatbots
Monitoring Vercel Analytics + PostHog Traffic + User Behavior Tracking

Jede Ebene läuft hier in Production über mehrere Projekte. Lass mich dir zeigen, wie das wirklich aussieht.

Ebene 1: Frontend -- Next.js 15

Wir haben Directory-Websites mit Next.js und Astro gebaut. Beide sind ausgezeichnet. Aber für Directories und Marktplätze speziell gewinnt Next.js 15 mit dem App Router wegen einer Funktion: Incremental Static Regeneration.

Hier ist das echte Szenario. Eines unserer Directory-Projekte rendert 137.000 Listing-Seiten. Ein anderes verarbeitet 91.000. Du kannst nicht alle zur Build-Zeit statisch generieren -- der Build würde eine Ewigkeit dauern und du würdest Vercels Funktionsausführungslimits überschreiten. Und du kannst sie nicht bei jeder Anfrage rendern, weil deine Serverkosten absurd wären und deine Time to First Byte leiden würde.

ISR gibt dir das Beste aus beiden Welten. Der erste Besucher einer Seite löst ein Server-Render aus, das am Edge gecacht wird. Nachfolgende Besucher bekommen die statische Version. Du setzt ein Revalidierungsintervall (wir verwenden normalerweise 3600 Sekunden für Listing-Seiten), und der Cache aktualisiert sich im Hintergrund.

// app/listings/[slug]/page.tsx
export const revalidate = 3600; // Revalidate every hour

export async function generateStaticParams() {
  // Only pre-generate the top 1000 most-visited listings
  const { data } = await supabase
    .from('listings')
    .select('slug')
    .order('view_count', { ascending: false })
    .limit(1000);
  
  return data?.map((listing) => ({ slug: listing.slug })) ?? [];
}

export default async function ListingPage({ params }: { params: { slug: string } }) {
  const { data: listing } = await supabase
    .from('listings')
    .select('*, categories(*), reviews(*)')
    .eq('slug', params.slug)
    .single();
    
  // Server Component -- no client-side JS shipped for this
  return <ListingDetail listing={listing} />;
}

Server Components sind der andere große Gewinn. Listing-Detailseiten sind meist statischer Inhalt -- Name, Beschreibung, Fotos, Bewertungen. Es gibt keinen Grund, Reacts Runtime zum Client zu versenden dafür. Server Components rendern auf dem Server und senden reines HTML. Deine Listing-Seiten laden schnell und dein JavaScript-Bundle bleibt klein.

Wir verwenden Client Components sparsam: die Suchleiste, interaktive Karten, Buchungsformulare und alles, das Benutzerinteraktion benötigt. Alles andere bleibt auf dem Server.

Warum nicht Astro?

Astro ist fantastisch für Inhalts-lastige Directories, wo Interaktivität minimal ist. Wir haben es für Dokumentations-Websites und inhalts-fokussierte Projekte verwendet. Aber Marketplace-Websites benötigen authentifizierte Zustände, Real-Time-Funktionen und komplexe Formulare. Next.js handhabt diese natürlicher. Wenn dein Verzeichnis hauptsächlich schreibgeschützt ist (denk: ein statisches Business-Verzeichnis), ist Astro einen Blick wert -- schau dir unsere Astro-Entwicklungsfähigkeiten an.

Best Tech Stack for Directory & Marketplace Websites in 2026 - architecture

Ebene 2: Database -- Supabase PostgreSQL

Dies ist die am meisten vertretene Wahl im Stack und diejenige, bei der ich am zuversichtlichsten bin. Supabase gibt dir PostgreSQL mit all seinen Erweiterungen -- und für Directory/Marketplace-Websites sind drei Erweiterungen enorm wichtig: pgvector, PostGIS und PostgreSQLs integrierte Full-Text-Suche.

Über unsere Directory-Projekte verwalten wir 253.000+ Datensätze in Supabase. Das umfasst Listings, Benutzerprofile, Bewertungen, Buchungen und Abonnementdaten. PostgreSQL handhabt das mühelos -- es ist für Datensätze designt, die um Größenordnungen größer sind.

Die echte Einsicht ist diese: Indem du Full-Text-Suche, Vector-Embeddings und geografische Daten in derselben Datenbank behältst, vermeidest du die architektonische Komplexität, Daten über mehrere Services zu synchronisieren. Du brauchst nicht Elasticsearch für Text-Suche. Du brauchst nicht Pinecone für Vector-Suche. Du brauchst nicht einen separaten Geo-Service. Eine Datenbank. Eine Wahrheitsquelle.

-- A single query that combines text search, vector similarity, and geo proximity
SELECT 
  l.id,
  l.name,
  l.description,
  ts_rank(l.search_vector, plainto_tsquery('english', 'family therapist')) AS text_rank,
  1 - (l.embedding <=> $1::vector) AS semantic_similarity,
  ST_Distance(
    l.location::geography, 
    ST_MakePoint(-97.7431, 30.2672)::geography
  ) / 1609.34 AS distance_miles
FROM listings l
WHERE 
  l.search_vector @@ plainto_tsquery('english', 'family therapist')
  AND ST_DWithin(
    l.location::geography, 
    ST_MakePoint(-97.7431, 30.2672)::geography, 
    80467  -- 50 miles in meters
  )
ORDER BY 
  (text_rank * 0.3) + (semantic_similarity * 0.5) + ((1 - distance_miles/50) * 0.2) DESC
LIMIT 20;

Das ist eine Abfrage. Full-Text-Ranking, Semantic-Similarity-Scoring und geografische Distanzfilterung -- alles passiert in PostgreSQL. Versuche das über drei separate Services zu machen und behalte die Ergebnisse kohärent.

Für einen tieferen Einblick in Datenbankoptionen für Directories, schau dir unseren Headless CMS und Datenbankvergleich an.

Supabase Row-Level Security

RLS verdient eine eigene Erwähnung, weil es ein Problem löst, das Marketplace-Backends plagt: Datenzugriffskontrolle auf Datenbankebene. Anstatt Autorisierungsprüfungen in jedem API-Endpoint zu schreiben, definierst du Richtlinien auf der Datenbank selbst.

-- Therapists can only see their own client records
CREATE POLICY "therapists_own_clients" ON client_records
  FOR SELECT USING (
    auth.uid() = therapist_id
    OR auth.jwt() ->> 'role' = 'admin'
  );

Selbst wenn du einen Bug in deinem API-Code hast, der versehentlich eine Abfrage exponiert, verhindert RLS unbefugten Datenzugriff. Für Marketplace-Websites, die sensible Benutzerdaten verarbeiten, ist das unverzichtbar.

Ebene 3: Authentication -- Supabase Auth

Da wir bereits im Supabase-Ökosystem für die Datenbank sind, ist die Verwendung von Supabase Auth eine natürliche Wahl. Aber der echte Grund, warum wir es für Marktplätze verwenden, ist rollenbasierter Zugriff, der direkt in RLS integriert ist.

Eines unserer Marketplace-Projekte führt rollenbasierten Auth über drei verschiedene Benutzertypen durch: Admins, Service Provider und Clients. Jede Rolle sieht verschiedene Daten, hat verschiedene Berechtigungen und greift auf verschiedene Features zu. Ein anderes Projekt führt ein 4-Tier-Membership-System durch, bei dem jeder Tier progressiv mehr Features freischaltet.

Die Implementierung speichert die Rolle des Benutzers in seinen JWT-Metadaten, was bedeutet, dass RLS-Richtlinien darauf verweisen können, ohne zusätzliche Datenbankabfragen:

// Assigning role during signup
const { data, error } = await supabase.auth.signUp({
  email,
  password,
  options: {
    data: {
      role: 'therapist',
      tier: 'professional'
    }
  }
});

Supabase Auth unterstützt OAuth-Provider (Google, Apple, usw.), Magic Links und Email/Passwort -- alles direkt. Für B2C-Marktplätze ist Social Login praktisch erforderlich. Wir haben gesehen, dass Signup-Konversionsraten um 30-40% steigen, wenn Google OAuth neben Email/Passwort verfügbar ist.

Ebene 4: Payments -- Stripe Connect

Die Zahlungsverarbeitung ist dort, wo Marketplace-Projekte wirklich kompliziert werden. Es gibt einen großen Unterschied zwischen „akzeptiere eine Zahlung" und „akzeptiere eine Zahlung, nimm eine Plattformprovision, handle Rückerstattungen, verwalte Abonnements über 30 Länder und deal mit Währungen ohne Dezimalstellen".

Stripe Connect handhabt den Marketplace-Zahlungsfluss -- die Aufteilung zwischen Plattform und Service Provider. Eines unserer Projekte verarbeitet Provisionen bei jeder Transaktion und leitet automatisch die Plattformgebühr und die Provider-Cut weiter.

Aber die Abonnement-Seite ist dort, wo es interessant wird. Wir führen ein 4-Tier-Abonnement-System mit regionaler Preisgestaltung über 30+ Länder. Das bedeutet, separate Stripe Price-Objekte für verschiedene Währungsregionen zu unterhalten.

Der Zero-Decimal Currency Bug

Das ist eine Geschichte, die ich erzähle, weil sie uns (und unseren Kunden) echtes Geld sparte. Stripe handhabt die meisten Währungen in ihrer kleinsten Einheit -- also $10.00 USD ist 1000 (Cent). Aber einige Währungen wie Japanese Yen (JPY) und Korean Won (KRW) haben keine Dezimaleinheiten. ¥1000 ist einfach 1000, nicht 100000.

Wenn dein Code blind mit 100 multipliziert um zur kleinsten Einheit zu konvertieren, wirst du japanischen Benutzern das 100-fache des beabsichtigten Betrags berechnen. Wir haben das beim Testen gefangen, aber ich habe Production Marktplätze gesehen, die das nicht haben.

const ZERO_DECIMAL_CURRENCIES = [
  'BIF', 'CLP', 'DJF', 'GNF', 'JPY', 'KMF', 'KRW', 
  'MGA', 'PYG', 'RWF', 'UGX', 'VND', 'VUV', 'XAF', 'XOF', 'XPF'
];

function formatAmountForStripe(amount: number, currency: string): number {
  if (ZERO_DECIMAL_CURRENCIES.includes(currency.toUpperCase())) {
    return Math.round(amount);
  }
  return Math.round(amount * 100);
}

Regional Trial Exclusions

Ein weiterer Fallstrick: Wir mussten bestimmte südostasiatische Länder von kostenlosen Testangeboten ausschließen, weil die Betrugquoten die Tests in diesen Regionen wirtschaftlich unrentabel machten. Stripes API lässt dich das mit Kundensteuerstandort-Checks einrichten, aber du musst zuerst wissen, dass es ein Problem ist. Das ist die Art von Dingen, die du nur erfahren kannst, indem du einen Multi-Country Marketplace in Production leitest.

Ebene 5: Search -- Das Triple Search Pattern

Dies ist wahrscheinlich das wertvollste Architektur-Pattern in diesem Artikel. Die meisten Directory-Websites bieten grundlegende Text-Suche an. Gute fügen Standort-Filterung hinzu. Wir führen alle drei Suchtypen gleichzeitig durch und blenden die Ergebnisse.

Full-Text-Suche (PostgreSQL tsvector): Handhabt exakte und stammbaum-basierte Keyword-Matching. Wenn jemand nach „Klempner" sucht, matched es auch „Klempnerarbeit". Schnell, gut verstanden, in Postgres integriert.

Semantic Search (pgvector + Claude Embeddings): Handhabt bedeutungsbasierte Abfragen. „Jemand, der mir helfen kann, mich weniger ängstlich um meine Beziehung zu fühlen" enthält nicht das Wort „Therapeut", aber Semantic Search versteht die Absicht. Wir generieren Embeddings für jedes Listing mit Claudes API und speichern sie als Vektoren in pgvector.

Geographic Search (PostGIS): Handhabt Nähe-Abfragen. „Innerhalb von 25 Meilen von Downtown Chicago" wird eine räumliche Abfrage, die indexiert und schnell ist.

Das Blending ist wo es interessant wird. Wir gewichten jeden Suchtyp unterschiedlich, basierend auf der Abfrage:

interface SearchWeights {
  textWeight: number;
  semanticWeight: number;
  geoWeight: number;
}

function calculateWeights(query: string, hasLocation: boolean): SearchWeights {
  const isNaturalLanguage = query.split(' ').length > 4;
  
  if (hasLocation && isNaturalLanguage) {
    return { textWeight: 0.2, semanticWeight: 0.5, geoWeight: 0.3 };
  } else if (hasLocation) {
    return { textWeight: 0.4, semanticWeight: 0.2, geoWeight: 0.4 };
  } else if (isNaturalLanguage) {
    return { textWeight: 0.2, semanticWeight: 0.7, geoWeight: 0.1 };
  }
  return { textWeight: 0.7, semanticWeight: 0.2, geoWeight: 0.1 };
}

Kurze Keyword-Abfragen verlassen sich auf Full-Text-Suche. Längere natürlichsprachige Abfragen verlassen sich auf Semantic Search. Abfragen mit einer Standort-Komponente erhöhen das Geo-Gewicht. Eines unserer Directory-Websites führt dieses Triple-Pattern über 137.000+ Listings durch, und die Suchergebnisse sind merklich besser als Konkurrenten, die einfaches Text-Matching verwenden.

Ebene 6: Media -- Supabase Storage + Next.js Image

Directory-Websites sind bild-lastig. Listing-Fotos, Profilbilder, Logos -- es addiert sich. Wir verwenden Supabase Storage für Uploads und die Next.js <Image> Komponente für optimierte Bereitstellung.

Die Schlüsselkonfiguration besteht darin, Supabase Storage Buckets mit angemessenen Zugriffrichtlinien einzurichten (öffentlich für Listing-Fotos, privat für Benutzerdokumente) und dann die Next.js Image-Optimierung zu verwenden, um WebP/AVIF-Formate in den richtigen Dimensionen bereitzustellen:

<Image
  src={`${process.env.NEXT_PUBLIC_SUPABASE_URL}/storage/v1/object/public/listings/${listing.image_path}`}
  alt={listing.name}
  width={800}
  height={600}
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
  loading="lazy"
/>

Next.js handhabt Formatkonvertierung, Größenanpassung und Caching automatisch, wenn auf Vercel deployed. Wir haben Bild-Payload-Reduktionen von 60-70% gesehen, verglichen mit der direkten Bereitstellung von Original-Uploads.

Ebene 7: Hosting -- Vercel

Alle unsere Production Directory- und Marketplace-Websites laufen auf Vercel. Der Grund ist unkompliziert: Vercel ist dort, wo Next.js am besten läuft. ISR, Server Components, Edge Middleware, Preview Deployments -- alles funktioniert ohne Konfiguration.

Für Directory-Websites speziell ist das Edge-Netzwerk wichtig. Ein Benutzer in Tokio, der ein Verzeichnis durchsucht, sollte gecachte Listing-Seiten von einem nahen Edge-Node bekommen, nicht von einem Server in Virginia. Vercels Edge-Caching macht das automatisch für ISR-Seiten.

Preview Deployments sind auch riesig für Marketplace-Projekte mit mehreren Stakeholdern. Jeder Pull Request bekommt seine eigene URL. Der Client kann die neue Such-UI auf einer echten URL mit echten Daten überprüfen, bevor etwas in Production geht.

Vercels Pro-Plan mit $20/Monat pro Team-Mitglied deckt die meisten Directory-Projekte ab. Größere Websites (100K+ Seiten) könnten den Enterprise-Plan für höhere ISR-Limits und dedizierten Support benötigen.

Ebene 8: Email -- Brevo API

Email in Marketplace-Projekten fällt in zwei Kategorien: Transaktional (Buchungsbestätigungen, Passwort-Zurücksetzer, Zahlungsquittungen) und Marketing (Newsletter, Feature-Ankündigungen, Re-Engagement).

Wir verwenden Brevo (ehemals Sendinblue) für beide, aufgerufen aus Next.js API Routes:

// app/api/send-booking-confirmation/route.ts
import { NextResponse } from 'next/server';

export async function POST(request: Request) {
  const { to, bookingDetails } = await request.json();
  
  const response = await fetch('https://api.brevo.com/v3/smtp/email', {
    method: 'POST',
    headers: {
      'api-key': process.env.BREVO_API_KEY!,
      'content-type': 'application/json',
    },
    body: JSON.stringify({
      to: [{ email: to }],
      templateId: 12, // Booking confirmation template
      params: bookingDetails,
    }),
  });
  
  return NextResponse.json({ success: response.ok });
}

Brevos kostenloser Tier handhabt 300 Emails/Tag, was für frühe Marktplätze ausreicht. Ihre bezahlten Pläne beginnen bei $9/Monat für 5.000 Emails. Verglichen mit SendGrid oder Mailgun haben wir Brevos Zustellbarkeitsquoten als vergleichbar und die Preisgestaltung vorhersehbarer für wachsende Projekte gefunden.

Ebene 9: AI -- Claude API

AI ist kein Gimmick in unserem Directory-Stack -- es ist eine Kern-Infrastruktur-Komponente, die drei verschiedene Jobs handhabt.

Semantic Search Embeddings: Jedes Listing bekommt ein Embedding von Claude generiert, das seine Bedeutung erfasst. Das gibt die Semantic-Search-Ebene der oben beschriebenen.

Content Enrichment: Für Directories mit Benutzer-eingereichten Listings, variiert die Qualität wildly. Wir verwenden Claude, um Beschreibungen zu normalisieren, strukturierte Daten zu extrahieren (Stunden, Spezialitäten, Service-Bereiche) und SEO-freundliche Zusammenfassungen zu generieren.

Interaktive Features: Eines unserer Projekte führt, was wir einen „Oracle Council" nennen -- fünf verschiedene AI-Personas, die Benutzer konsultieren können für verschiedene Arten von Anleitung. Jede Persona hat ihren eigenen System Prompt, Persönlichkeit und Fachgebiet. Es klingt verspielt, aber es treibt signifikantes Engagement und ist eines der beliebtesten Features der Website.

Claude API Preisgestaltung stand 2025-2026: Claude 3.5 Sonnet kostet $3 pro Million Input-Token und $15 pro Million Output-Token. Für Embedding-Generierung auf einem 100K Listing Directory beträgt die einmalige Kosten ungefähr $50-80. Laufende Kosten für Such-Abfragen und Chatbot-Interaktionen typischerweise $100-300/Monat abhängig vom Traffic.

Ebene 10: Monitoring -- Vercel Analytics + PostHog

Du brauchst zwei Arten von Monitoring für Directory-Websites: Leistungs-Metriken und User Behavior Analytics.

Vercel Analytics gibt dir Web Vitals (LCP, CLS, INP), Real User Monitoring und Traffic-Daten. Es ist in das Vercel Dashboard integriert und erfordert Null-Konfiguration. Für Directory-Websites schauen wir eng auf LCP auf Listing-Seiten -- wenn sie über 2,5 Sekunden klettern, wissen wir, dass etwas mit unserer ISR-Konfiguration oder Bild-Optimierung falsch ist.

PostHog handhabt Product Analytics: welche Such-Abfragen geben Null-Ergebnisse zurück (also wissen wir, welche Inhalts-Lücken wir füllen müssen), welche Listing-Kategorien bekommen die meisten Ansichten, wo fallen Benutzer ab im Buchungs- oder Signup-Flow. Posthogs kostenloser Tier deckt bis zu 1 Million Events pro Monat, was die meisten frühen Marktplätze handhabt.

Die Kombination gibt dir beide „ist die Website schnell?" und „finden Benutzer, was sie benötigen?" -- zwei sehr verschiedene aber gleich wichtig Fragen.

Vollständige Stack-Vergleichstabelle

Ebene Unsere Wahl Alternative Warum wir unsere wählten
Frontend Next.js 15 Astro, Remix ISR für 100K+ Seiten
Database Supabase PostgreSQL PlanetScale, Neon pgvector + PostGIS in einer DB
Auth Supabase Auth Clerk, Auth.js Native RLS-Integration
Payments Stripe Connect Paddle, LemonSqueezy Marketplace-Splits, Multi-Currency
Search Triple Pattern (in-DB) Algolia, Elasticsearch Kein externer Sync, niedrigere Kosten
Media Supabase Storage Cloudinary, S3 Gleiches Ökosystem, einfachere Abrechnung
Hosting Vercel Netlify, AWS Amplify Beste Next.js ISR Unterstützung
Email Brevo API SendGrid, Resend Preis/Zustellbarkeits-Verhältnis
AI Claude API OpenAI, Gemini Beste Reasoning für Content-Aufgaben
Monitoring Vercel + PostHog Datadog, Mixpanel Kostenlose Tier decken frühes Wachstum

Was dieser Stack in Production kostet

Lass uns echte Zahlen für eine Directory-Website mit ~50K Listings und moderatem Traffic (50K monatliche Besucher) sprechen:

Service Plan Monatliche Kosten
Vercel Pro $20
Supabase Pro $25
Stripe Pay-as-you-go 2,9% + 30¢ pro Transaktion
Brevo Starter $9
Claude API Usage-based ~$150
PostHog Free Tier $0
Gesamte fixe Kosten ~$204/Monat

Das ist bemerkenswert bezahlbar für eine Production Marketplace-Plattform. Der Supabase Pro-Plan gibt dir 8GB Datenbankplatz, 250GB Bandbreite und 100GB Storage -- mehr als genug für ein Directory mit 50K Listings.

Während du über 100K Listings skalierst und in höherem Traffic, erwarte Kosten auf rund $500-800/Monat. Immer noch dramatisch günstiger als der alte Ansatz von dedizierten Servern, verwalteten Elasticsearch-Clustern und separaten Vector-Datenbanken.

Wenn du ein Directory- oder Marketplace-Projekt planst und Preisgestaltung genauer verstehen möchtest, schau unsere Pricing-Seite an oder kontaktiere uns für eine Projekt-spezifische Schätzung.

FAQ

Was ist die beste Datenbank für eine Directory-Website in 2026?

PostgreSQL über Supabase ist unsere Top-Empfehlung. Die Kombination von pgvector für Semantic Search, PostGIS für geografische Abfragen und integrierter Full-Text-Suche bedeutet, dass du alle drei Such-Dimensionen ohne externe Services handhabst. Mit 253K+ Datensätzen über unsere Production-Projekte handhabt es Directory-Skalierungs-Daten mühelos. Alternativen wie PlanetScale (MySQL-basiert) fehlt PostGIS-Unterstützung, was Geo-Suche erheblich schwerer macht.

Kann Next.js 100.000+ Seiten für eine Directory-Website handeln?

Ja, aber du brauchst ISR (Incremental Static Regeneration). Du generierst nicht alle 100K Seiten zur Build-Zeit. Stattdessen generierst du deine höchsten-Traffic-Seiten vor (vielleicht die Top 1.000-5.000) und lässt ISR den Rest on-demand generieren. Wir haben das mit 137K Seiten in Production gemacht. Der Schlüssel ist angemessene Revalidierungsintervalle zu setzen -- wir verwenden 3600 Sekunden (1 Stunde) für Listing-Seiten und kürzere Intervalle für Kategorie/Such-Seiten.

Wie funktioniert Semantic Search in einer Directory-Website?

Jedes Listing wird in einen numerischen Vektor (ein „Embedding") umgewandelt, das seine Bedeutung mit einem AI-Modell wie Claude erfasst. Wenn ein Benutzer mit natürlichsprache sucht -- „jemand, der Kindern mit ADHS hilft" -- wird diese Abfrage auch in einen Vektor umgewandelt. Die Datenbank findet Listings, deren Vektoren mathematisch nahe dem Abfrage-Vektor mit pgvectors Kosinus-Ähnlichkeits-Operator sind. Das funktioniert selbst wenn das Listing die exakten Worte aus der Such-Abfrage nicht enthält.

Ist Stripe Connect notwendig für einen Marktplatz, oder kann ich reguläres Stripe verwenden?

Wenn dein Marketplace Zahlungen zwischen Käufern und Verkäufern (oder Clients und Service Provider) beinhaltet, brauchst du Stripe Connect. Reguläres Stripe lässt dich nur Zahlungen auf deinem eigenen Account akzeptieren. Connect handhabt die Aufteilung -- nimmt eine Plattformprovision und leitet den Rest an den Service Provider. Es handhabt auch 1099-Reporting für US-basierte Verkäufer, das ist eine Compliance-Anforderung, die du nicht selbst bauen möchtest.

Wie viel kostet es, eine Directory-Website von Grund auf zu bauen?

Mit dem hier ausgelegten Stack beginnen deine laufenden Infrastruktur-Kosten rund $200/Monat für ein mittelgroßes Directory. Entwicklungs-Kosten variieren breit basierend auf Features, aber ein Production-ready Directory mit Suche, Benutzer-Accounts und Listing-Management typischerweise 8-16 Wochen zu bauen. Ein vollständiger Marktplatz mit Zahlungen, Buchungen und Abonnements addiert weitere 4-8 Wochen. Du kannst unsere Directory- und Marketplace-Entwicklungs-Fähigkeiten erkunden für mehr Spezifika.

Sollte ich Algolia oder Elasticsearch statt in-database Such verwenden?

Für die meisten Directory-Websites, nein. Die Komplexität der Daten-Synchronisierung zwischen deiner primären Datenbank und einem separaten Such-Service schafft Bugs, addiert Latenz und erhöht Kosten. Algolia kostet basierend auf Such-Operationen -- in Skalierung wird das schnell teuer (ihre Preisgestaltung beginnt bei $1/1.000 Such-Anfragen auf dem Build-Plan). PostgreSQL's integrierte Such-Fähigkeiten, besonders kombiniert mit pgvector, handhabt Directory-Skalierungs-Suche gut. Die Ausnahme: Wenn du Typo-Toleranz und facettiertes Filtern mit Sub-10ms Antwort-Zeiten über Millionen von Datensätzen brauchst, ist Algolia die Komplexität wert.

Wie unterscheidet sich das Bauen eines Directories von einem Marktplatz?

Ein Verzeichnis listet Dinge auf und lässt Benutzer sie finden. Ein Marktplatz addiert Transaktionen -- Zahlungen, Buchungen, Provisionen und oft zwei-seitige Interaktionen zwischen Providern und Consumern. Der Tech Stack ist weitgehend derselbe, aber Marktplätze addieren Stripe Connect (oder Äquivalent), komplexere Auth-Rollen und transaktionale Email-Flows. Das Datenbankschema wird auch komplexer mit Orders, Invoices und Payout-Tracking Tabellen.

Kann ich AI-Features zu einer bestehenden Directory-Website addieren?

Absolut. Die AI-Ebene in unserem Stack ist additiv, nicht grundlegend. Du kannst Semantic Search addieren, indem du Embeddings für deine bestehenden Listings generierst (ein einmaliger Batch-Job), sie in einer pgvector-Spalte speicherst und einen Semantic-Search-Endpoint neben deiner bestehenden Text-Suche addierst. Content Enrichment und Chatbot-Features können als unabhängige API Routes addiert werden. Der schwierigste Teil ist üblicherweise die Embedding-Generierung für einen großen bestehenden Datensatz -- budget ein paar Stunden Verarbeitungs-Zeit und $50-100 in API-Kosten für 100K Listings.