La mejor pila de tecnología para sitios web de directorios y mercados en 2026

La mayoría de artículos sobre "la mejor pila de tecnología" parecen escritos por alguien que pasó una tarde navegando Product Hunt y escribió sus hallazgos. Te dirán que uses React y quizás Postgres, añadan Stripe, y listo. Eso no es útil cuando intentas construir un sitio de directorios con 137,000 páginas de listados que necesitan renderizarse rápido, soportar búsqueda geográfica dentro de un radio de 50 millas, y permitir a los usuarios encontrar resultados usando consultas en lenguaje natural.

He pasado los últimos dos años construyendo exactamente estos tipos de sitios. No proyectos de juguete -- plataformas de directorios y mercados en producción que manejan cientos de miles de registros, procesamiento de pagos multi-país (incluyendo los casos límite divertidos como monedas sin decimales), y sistemas de búsqueda que combinan búsqueda de texto completo, búsqueda semántica con IA, y consultas geográficas simultáneamente. Este artículo recorre cada capa de la pila que utilizamos en Social Animal, por qué elegimos cada pieza, y los datos de producción que respaldan esas decisiones.

Tabla de Contenidos

Best Tech Stack for Directory & Marketplace Websites in 2026

Por qué los sitios de directorios y mercados son arquitectónicamente únicos

Los sitios web de directorios y mercados se ven simples en la superficie. Lista algunas cosas, deja que la gente busque, quizás procesa un pago. Pero en el momento en que empiezas a construir uno con datos reales, te encuentras con problemas para los que las arquitecturas SaaS estándar no te preparan.

Primero, está el problema del número de páginas. Un directorio con 100K+ listados necesita 100K+ páginas. No puedes renderizarlas todas en el servidor en cada solicitud, y no puedes generarlas todas estáticamente en el momento de la compilación (tus compilaciones tomarían horas). Necesitas algo más inteligente -- Incremental Static Regeneration (ISR) o revalidación bajo demanda.

Segundo, la búsqueda es multidimensional. Los usuarios quieren buscar por texto ("terapeuta familiar"), por significado ("alguien que ayuda con la ansiedad en las relaciones"), y por ubicación ("dentro de 20 millas de Austin"). La mayoría de las pilas manejan una de estas. Manejar las tres simultáneamente requiere una arquitectura de base de datos específica.

Tercero, los mercados tienen complejidad de pagos que va mucho más allá de un simple checkout. Estás lidiando con comisiones de plataforma, niveles de suscripción, precios multimoneda, y diferencias regulatorias entre países. Si cometes un error en cualquiera de esto, estás perdiendo dinero o rompiendo leyes.

Estas restricciones moldearon cada decisión en nuestra pila. Caminemos a través de cada capa.

Descripción general de la pila de 10 capas

Antes de profundizar, aquí está la imagen completa:

Capa Herramienta Por qué
Frontend Next.js 15 (App Router) ISR para 100K+ páginas, Server Components
Base de datos Supabase PostgreSQL pgvector + PostGIS + búsqueda de texto completo en una BD
Autenticación Supabase Auth Row-Level Security, acceso basado en roles
Pagos Stripe Connect Comisiones de mercado, multimoneda
Búsqueda Patrón triple (tsvector + pgvector + PostGIS) Texto + semántica + geo simultáneamente
Medios Supabase Storage + Next.js Image Entrega optimizada, uploads simples
Hosting Vercel Despliegue en el perímetro, soporte ISR, URLs de vista previa
Email Brevo API Transaccional + marketing desde rutas API
IA Claude API Búsqueda semántica, enriquecimiento de contenido, chatbots
Monitoreo Vercel Analytics + PostHog Seguimiento de tráfico + comportamiento de usuarios

Cada capa aquí se ejecuta en producción en múltiples proyectos. Déjame mostrarte cómo se ve eso realmente.

Capa 1: Frontend -- Next.js 15

Hemos construido sitios de directorios tanto con Next.js como con Astro. Ambos son excelentes. Pero para directorios y mercados específicamente, Next.js 15 con el App Router gana por una característica: Incremental Static Regeneration.

Aquí está el escenario real. Uno de nuestros proyectos de directorios renderiza 137,000 páginas de listados. Otro maneja 91,000. No puedes generar estáticamente todas estas en el momento de la compilación -- la compilación tomaría una eternidad y superarías los límites de ejecución de funciones de Vercel. Y no puedes renderizarlas todas en el servidor en cada solicitud porque tus costos de servidor serían absurdos y tu Time to First Byte sufriría.

ISR te da lo mejor de ambos mundos. El primer visitante a una página dispara un renderizado de servidor, que se almacena en caché en el perímetro. Los visitantes posteriores obtienen la versión estática. Estableces un intervalo de revalidación (típicamente usamos 3600 segundos para páginas de listados), y el caché se actualiza en el fondo.

// app/listings/[slug]/page.tsx
export const revalidate = 3600; // Revalidar cada hora

export async function generateStaticParams() {
  // Solo pre-generar los 1000 listados más visitados
  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 -- sin JavaScript del cliente enviado para esto
  return <ListingDetail listing={listing} />;
}

Los Server Components son la otra gran victoria. Las páginas de detalle de listados son en su mayoría contenido estático -- nombre, descripción, fotos, reseñas. No hay razón para enviar el tiempo de ejecución de React al cliente para eso. Los Server Components se renderizan en el servidor y envían HTML puro. Tus páginas de listados se cargan rápido y tu paquete de JavaScript se mantiene pequeño.

Usamos componentes de cliente escasamente: la barra de búsqueda, mapas interactivos, formularios de reserva, y cualquier cosa que necesite interacción del usuario. Todo lo demás permanece en el servidor.

¿Por qué no Astro?

Astro es fantástico para directorios con mucho contenido donde la interactividad es mínima. Lo hemos usado para sitios de documentación y proyectos enfocados en contenido. Pero los sitios de mercados necesitan estados autenticados, características en tiempo real, y formularios complejos. Next.js maneja estos más naturalmente. Si tu directorio es principalmente de solo lectura (piensa: un directorio de negocios estático), Astro vale la pena considerar -- consulta nuestras capacidades de desarrollo de Astro.

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

Capa 2: Base de datos -- Supabase PostgreSQL

Esta es la opción más opinada en la pila, y aquella en la que tengo más confianza. Supabase te da PostgreSQL con todas sus extensiones -- y para sitios de directorio/mercado, tres extensiones importan enormemente: pgvector, PostGIS, y la búsqueda de texto completo integrada de PostgreSQL.

En nuestros proyectos de directorios, estamos manejando 253,000+ registros en Supabase. Eso incluye listados, perfiles de usuarios, reseñas, reservas, y datos de suscripción. PostgreSQL maneja esto sin sudar -- está diseñado para conjuntos de datos órdenes de magnitud más grandes.

La insight real es esta: al mantener búsqueda de texto completo, incrustaciones de vectores, y datos geográficos en la misma base de datos, evitas la complejidad arquitectónica de sincronizar datos entre múltiples servicios. No necesitas Elasticsearch para búsqueda de texto. No necesitas Pinecone para búsqueda vectorial. No necesitas un servicio geo separado. Una base de datos. Una fuente de verdad.

-- Una sola consulta que combina búsqueda de texto, similitud vectorial, y proximidad geo
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 millas en metros
  )
ORDER BY 
  (text_rank * 0.3) + (semantic_similarity * 0.5) + ((1 - distance_miles/50) * 0.2) DESC
LIMIT 20;

Esa es una consulta. Clasificación de texto completo, puntuación de similitud semántica, y filtrado de distancia geográfica -- todo sucediendo en PostgreSQL. Intenta hacer eso entre tres servicios separados y mantener los resultados coherentes.

Para un análisis más profundo de opciones de base de datos para directorios, consulta nuestra comparación de CMS headless y base de datos.

Supabase Row-Level Security

RLS merece su propia mención porque resuelve un problema que aqueja a los backends de mercados: control de acceso de datos a nivel de base de datos. En lugar de escribir verificaciones de autorización en cada punto final de API, defines políticas en la base de datos misma.

-- Los terapeutas solo pueden ver sus propios registros de clientes
CREATE POLICY "therapists_own_clients" ON client_records
  FOR SELECT USING (
    auth.uid() = therapist_id
    OR auth.jwt() ->> 'role' = 'admin'
  );

Incluso si tienes un error en tu código API que accidentalmente expone una consulta, RLS previene acceso de datos no autorizado. Para sitios de mercados que manejan datos de usuarios sensibles, esto es innegociable.

Capa 3: Autenticación -- Supabase Auth

Dado que ya estamos en el ecosistema Supabase para la base de datos, usar Supabase Auth es un ajuste natural. Pero la razón real por la que la usamos para mercados es la autenticación basada en roles que se integra directamente con RLS.

Uno de nuestros proyectos de mercados ejecuta auth basada en roles entre tres tipos de usuario distintos: admins, proveedores de servicios, y clientes. Cada rol ve datos diferentes, tiene permisos diferentes, y accede a características diferentes. Otro proyecto ejecuta un sistema de membresía de 4 niveles donde cada nivel desbloquea progresivamente más características.

La implementación almacena el rol del usuario en sus metadatos JWT, lo que significa que las políticas RLS pueden referenciarlo sin consultas de base de datos adicionales:

// Asignando rol durante el registro
const { data, error } = await supabase.auth.signUp({
  email,
  password,
  options: {
    data: {
      role: 'therapist',
      tier: 'professional'
    }
  }
});

Supabase Auth soporta proveedores OAuth (Google, Apple, etc.), enlaces mágicos, y email/contraseña -- todo listo para usar. Para mercados B2C, el inicio de sesión social es prácticamente requerido. Hemos visto tasas de conversión de registro aumentar 30-40% cuando OAuth de Google está disponible junto con email/contraseña.

Capa 4: Pagos -- Stripe Connect

El procesamiento de pagos es donde los proyectos de mercados se vuelven genuinamente complicados. Hay una gran diferencia entre "aceptar un pago" y "aceptar un pago, tomar una comisión de plataforma, manejar reembolsos, gestionar suscripciones en 30 países, y lidiar con monedas sin decimales."

Stripe Connect maneja el flujo de pagos de mercado -- la división entre plataforma y proveedor de servicios. Uno de nuestros proyectos procesa comisiones en cada transacción, enrutando automáticamente la tarifa de plataforma y la parte del proveedor.

Pero el lado de suscripción es donde se vuelve interesante. Ejecutamos un sistema de suscripción de 4 niveles con precios regionales en 30+ países. Esto significa mantener objetos de Precio Stripe separados para diferentes regiones de moneda.

El bug de moneda sin decimales

Esta es una historia que comparto porque nos ahorró (y a nuestro cliente) dinero real. Stripe maneja la mayoría de monedas en su unidad más pequeña -- así que $10.00 USD es 1000 (centavos). Pero algunas monedas como Yen Japonés (JPY) y Won Coreano (KRW) no tienen unidades decimales. ¥1000 es solo 1000, no 100000.

Si tu código ciegamente multiplica por 100 para convertir a la unidad más pequeña, cobrarás a usuarios japoneses 100x la cantidad prevista. Capturamos esto en las pruebas, pero he visto mercados de producción que no.

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);
}

Exclusiones de prueba regional

Otro gotcha: tuvimos que excluir ciertos países del Sudeste Asiático de ofertas de prueba gratuita porque las tasas de fraude hicieron que los períodos de prueba fueran económicamente inviables en esas regiones. La API de Stripe te permite configurar esto con verificaciones de ubicación fiscal del cliente, pero tienes que saber que es un problema primero. Este es el tipo de cosa que solo aprendes al ejecutar un mercado multi-país en producción.

Capa 5: Búsqueda -- El patrón de búsqueda triple

Este es probablemente el patrón arquitectónico más valioso en este artículo. La mayoría de sitios de directorios ofrecen búsqueda de texto básica. Los buenos añaden filtrado de ubicación. Ejecutamos los tres tipos de búsqueda simultáneamente y mezclamos los resultados.

Búsqueda de texto completo (PostgreSQL tsvector): Maneja coincidencia de palabras clave exactas y radicalizadas. Cuando alguien busca "plomero," también coincide "plomería." Rápido, bien entendido, integrado en Postgres.

Búsqueda semántica (pgvector + incrustaciones de Claude): Maneja consultas basadas en significado. "Alguien que pueda ayudarme a sentir menos ansiedad sobre mi relación" no contiene la palabra "terapeuta," pero la búsqueda semántica entiende la intención. Generamos incrustaciones para cada listado usando la API de Claude y las almacenamos como vectores en pgvector.

Búsqueda geográfica (PostGIS): Maneja consultas de proximidad. "Dentro de 25 millas del centro de Chicago" se convierte en una consulta espacial que está indexada y es rápida.

La mezcla es donde se vuelve interesante. Ponderamos cada tipo de búsqueda de manera diferente dependiendo de la consulta:

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 };
}

Las consultas de palabras clave cortas se apoyan en búsqueda de texto completo. Las consultas más largas de lenguaje natural se apoyan en búsqueda semántica. Las consultas con un componente de ubicación aumentan el peso geo. Uno de nuestros sitios de directorios ejecuta este patrón triple en 137K+ listados, y los resultados de búsqueda son notablemente mejores que competidores usando coincidencia de texto básica.

Capa 6: Medios -- Supabase Storage + Next.js Image

Los sitios de directorios tienen mucho contenido de imágenes. Fotos de listados, fotos de perfil, logos -- se suma. Usamos Supabase Storage para uploads y el componente <Image> de Next.js para entrega optimizada.

La configuración clave es establecer depósitos de Supabase Storage con políticas de acceso apropiadas (público para fotos de listados, privado para documentos de usuarios) y luego usar la optimización de Next.js Image para servir formatos WebP/AVIF en las dimensiones correctas:

<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 maneja conversión de formato, redimensionamiento, y almacenamiento en caché automáticamente cuando se despliega en Vercel. Hemos visto reducciones de carga útil de imagen de 60-70% comparado con servir uploads originales directamente.

Capa 7: Hosting -- Vercel

Todos nuestros sitios de directorios y mercados de producción se ejecutan en Vercel. La razón es directa: Vercel es donde Next.js se ejecuta mejor. ISR, Server Components, middleware de perímetro, despliegues de vista previa -- todo funciona sin configuración.

Para sitios de directorios específicamente, la red de perímetro importa. Un usuario en Tokio buscando un directorio debe obtener páginas de listados almacenadas en caché desde un nodo de perímetro cercano, no desde un servidor en Virginia. El almacenamiento en caché de perímetro de Vercel hace esto automático para páginas ISR.

Los despliegues de vista previa también son enormes para proyectos de mercado con múltiples partes interesadas. Cada solicitud de extracción obtiene su propia URL. El cliente puede revisar la nueva UI de búsqueda en una URL real con datos reales antes de que algo vaya a producción.

El plan Pro de Vercel a $20/mes por miembro del equipo cubre la mayoría de proyectos de directorios. Los sitios más grandes (100K+ páginas) pueden necesitar el plan Enterprise para límites de ISR más altos y soporte dedicado.

Capa 8: Email -- Brevo API

El email en proyectos de mercado se divide en dos categorías: transaccional (confirmaciones de reserva, resets de contraseña, recibos de pago) y marketing (boletines, anuncios de características, re-engagement).

Usamos Brevo (anteriormente Sendinblue) para ambas, llamadas desde rutas API de Next.js:

// 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, // Plantilla de confirmación de reserva
      params: bookingDetails,
    }),
  });
  
  return NextResponse.json({ success: response.ok });
}

El nivel gratuito de Brevo maneja 300 emails/día, lo cual es suficiente para mercados en fase inicial. Sus planes pagos empiezan en $9/mes por 5,000 emails. Comparado con SendGrid o Mailgun, hemos encontrado tasas de entregabilidad de Brevo comparables y precios más predecibles para proyectos en crecimiento.

Capa 9: IA -- Claude API

La IA no es un capricho en nuestra pila de directorios -- es un componente de infraestructura central que maneja tres trabajos distintos.

Incrustaciones de búsqueda semántica: Cada listado obtiene una incrustación generada por Claude que captura su significado. Esto potencia la capa de búsqueda semántica descrita arriba.

Enriquecimiento de contenido: Para directorios con listados enviados por usuarios, la calidad varía enormemente. Usamos Claude para normalizar descripciones, extraer datos estructurados (horas, especialidades, áreas de servicio), y generar resúmenes amigables con SEO.

Características interactivas: Uno de nuestros proyectos ejecuta lo que llamamos un "Consejo Oráculo" -- cinco personas de IA distintas que los usuarios pueden consultar para diferentes tipos de orientación. Cada persona tiene su propio mensaje del sistema, personalidad, y área de expertise. Suena fantasioso, pero impulsa compromiso significativo y es una de las características más populares del sitio.

Precios de Claude API a partir de 2025-2026: Claude 3.5 Sonnet cuesta $3 por millón de tokens de entrada y $15 por millón de tokens de salida. Para generación de incrustaciones en un directorio de 100K listados, el costo único es aproximadamente $50-80. Los costos continuos para consultas de búsqueda e interacciones de chatbot típicamente se ejecutan $100-300/mes dependiendo del tráfico.

Capa 10: Monitoreo -- Vercel Analytics + PostHog

Necesitas dos tipos de monitoreo para sitios de directorios: métricas de rendimiento y análisis de comportamiento de usuarios.

Vercel Analytics te da Web Vitals (LCP, CLS, INP), monitoreo de usuarios reales, y datos de tráfico. Está integrado en el panel de Vercel y requiere cero configuración. Para sitios de directorios, observamos LCP cercanamente en páginas de listados -- si se cuela por encima de 2.5 segundos, sabemos que algo está mal con nuestra configuración de ISR u optimización de imágenes.

PostHog maneja análisis de producto: qué consultas de búsqueda retornan cero resultados (así sabemos qué brechas de contenido llenar), qué categorías de listados obtienen la mayoría de vistas, dónde los usuarios se descartan en el flujo de reserva o registro. El nivel gratuito de PostHog cubre hasta 1 millón de eventos por mes, lo cual maneja la mayoría de mercados en fase inicial.

La combinación te da tanto "¿es el sitio rápido?" como "¿están los usuarios encontrando lo que necesitan?" -- dos preguntas muy diferentes pero igualmente importantes.

Tabla de comparación de pila completa

Capa Nuestra opción Alternativa Por qué elegimos la nuestra
Frontend Next.js 15 Astro, Remix ISR para 100K+ páginas
Base de datos Supabase PostgreSQL PlanetScale, Neon pgvector + PostGIS en una BD
Autenticación Supabase Auth Clerk, Auth.js Integración RLS nativa
Pagos Stripe Connect Paddle, LemonSqueezy Divisiones de mercado, multimoneda
Búsqueda Patrón triple (en BD) Algolia, Elasticsearch Sin sincronización externa, menor costo
Medios Supabase Storage Cloudinary, S3 Mismo ecosistema, facturación más simple
Hosting Vercel Netlify, AWS Amplify Mejor soporte Next.js ISR
Email Brevo API SendGrid, Resend Proporción precio/entregabilidad
IA Claude API OpenAI, Gemini Mejor razonamiento para tareas de contenido
Monitoreo Vercel + PostHog Datadog, Mixpanel Niveles gratuitos cubren crecimiento inicial

Qué cuesta esta pila en producción

Hablemos números reales para un sitio de directorios con ~50K listados y tráfico moderado (50K visitantes mensuales):

Servicio Plan Costo mensual
Vercel Pro $20
Supabase Pro $25
Stripe Pago por uso 2.9% + 30¢ por transacción
Brevo Starter $9
Claude API Basado en uso ~$150
PostHog Nivel gratuito $0
Total costos fijos ~$204/mes

Eso es notablemente asequible para una plataforma de mercado de producción. El plan Pro de Supabase te da 8GB de espacio de base de datos, 250GB de ancho de banda, y 100GB de almacenamiento -- más que suficiente para un directorio con 50K listados.

A medida que escales más allá de 100K listados y en mayor tráfico, espera que los costos aumenten a aproximadamente $500-800/mes. Aún dramáticamente más barato que el enfoque antiguo de ejecutar servidores dedicados, clusters Elasticsearch gestionados, y bases de datos de vectores separadas.

Si estás planificando un proyecto de directorio o mercado y quieres entender precios con más detalle, consulta nuestra página de precios o ponte en contacto para una estimación específica del proyecto.

Preguntas frecuentes

¿Cuál es la mejor base de datos para un sitio web de directorios en 2026? PostgreSQL a través de Supabase es nuestra principal recomendación. La combinación de pgvector para búsqueda semántica, PostGIS para consultas geográficas, y búsqueda de texto completo integrada significa que puedes manejar las tres dimensiones de búsqueda sin servicios externos. Con 253K+ registros en nuestros proyectos de producción, maneja datos a escala de directorio sin problema. Alternativas como PlanetScale (basada en MySQL) carecen de soporte PostGIS, haciendo la búsqueda geo significativamente más difícil.

¿Puede Next.js manejar 100,000+ páginas para un sitio de directorios? Sí, pero necesitas ISR (Incremental Static Regeneration). No generas todas las 100K páginas en el momento de la compilación. En cambio, pre-generas tus páginas de mayor tráfico (quizás los 1,000-5,000 mejores) y dejas que ISR genere el resto bajo demanda. Lo hemos hecho con 137K páginas en producción. La clave es establecer intervalos de revalidación apropiados -- usamos 3600 segundos (1 hora) para páginas de listados e intervalos más cortos para páginas de categoría/búsqueda.

¿Cómo funciona la búsqueda semántica en un sitio web de directorios? Cada listado se convierte en un vector numérico (una "incrustación") que captura su significado usando un modelo de IA como Claude. Cuando un usuario busca con lenguaje natural -- "alguien que ayude a los niños con TDAH" -- esa consulta también se convierte en un vector. La base de datos encuentra listados cuyos vectores son matemáticamente cercanos al vector de consulta usando el operador de similitud de coseno de pgvector. Esto funciona incluso cuando el listado no contiene las palabras exactas de la consulta de búsqueda.

¿Es Stripe Connect necesario para un mercado, o puedo usar Stripe regular? Si tu mercado implica pagos entre compradores y vendedores (o clientes y proveedores de servicios), necesitas Stripe Connect. Stripe regular solo te permite aceptar pagos en tu propia cuenta. Connect maneja la división -- tomando una comisión de plataforma y enrutando lo restante al proveedor de servicios. También maneja reportes 1099 para vendedores basados en EE.UU., que es un requisito de cumplimiento que no quieres construir tú mismo.

¿Cuánto cuesta construir un sitio web de directorios desde cero? Usando la pila descrita aquí, tus costos de infraestructura continuos empiezan alrededor de $200/mes para un directorio de tamaño medio. Los costos de desarrollo varían mucho según características, pero un directorio listo para producción con búsqueda, cuentas de usuario, y gestión de listados típicamente toma 8-16 semanas para construir. Un mercado completo con pagos, reservas, y suscripciones añade otras 4-8 semanas. Puedes explorar nuestras capacidades de desarrollo de directorios y mercados para más especificidades.

¿Debería usar Algolia o Elasticsearch en lugar de búsqueda en la base de datos? Para la mayoría de sitios de directorios, no. La complejidad de sincronizar datos entre tu base de datos primaria y un servicio de búsqueda separado crea errores, añade latencia, e incrementa costos. Algolia cobra basado en operaciones de búsqueda -- a escala, esto se vuelve costoso rápidamente (sus precios empiezan en $1/1,000 solicitudes de búsqueda en el plan Build). Las capacidades de búsqueda integradas de PostgreSQL, especialmente combinadas con pgvector, manejan búsqueda a escala de directorio bien. La excepción: si necesitas tolerancia a errores tipográficos y filtrado facetado con tiempos de respuesta sub-10ms en millones de registros, Algolia vale la pena la complejidad.

¿Cuál es la diferencia entre construir un directorio vs. un mercado? Un directorio lista cosas y permite a los usuarios encontrarlas. Un mercado añade transacciones -- pagos, reservas, comisiones, e a menudo interacciones de dos caras entre proveedores y consumidores. La pila de tecnología es en gran parte la misma, pero los mercados añaden Stripe Connect (o equivalente), más roles de auth complejos, y flujos de email transaccional. El esquema de la base de datos también se vuelve más complejo con tablas de órdenes, facturas, y seguimiento de pagos.

¿Puedo añadir características de IA a un sitio de directorios existente? Absolutamente. La capa de IA en nuestra pila es aditiva, no fundamental. Puedes añadir búsqueda semántica generando incrustaciones para tus listados existentes (un trabajo de lote único), almacenándolas en una columna de pgvector, y añadiendo un punto final de búsqueda semántica junto a tu búsqueda de texto existente. Las características de enriquecimiento de contenido y chatbot pueden ser añadidas como rutas API independientes. La parte más difícil es usualmente la generación de incrustaciones para un conjunto de datos grande existente -- presupuesta algunas horas de tiempo de procesamiento y $50-100 en costos de API para 100K listados.