Tu base de datos en producción alcanza 100K registros y los tiempos de consulta comienzan a aumentar. Actualizas el panel de control — 2.4 segundos para una lista filtrada que solía renderizarse en 300ms. Tu cliente pregunta por qué su panel de administración se siente más lento. Sabes que es hora de evaluar si Supabase, Firebase, PlanetScale, Neon o Turso pueden realmente manejar esta escala. La mayoría de artículos de comparación crean una aplicación de tareas pendientes y la llaman investigación. Hemos estado ejecutando 253,000+ registros en cinco sitios cliente activos en Supabase PostgreSQL durante más de un año. Probamos Firebase Firestore, PlanetScale, Neon y Turso en proyectos reales con patrones de tráfico reales. Aquí está lo que realmente se rompe a escala — y lo que no.

Si estás construyendo una aplicación web que necesita manejar 100K+ registros con consultas complejas, características en tiempo real y autenticación, tu elección de base de datos definirá tu arquitectura durante años. Elige mal y estarás reescribiendo tu capa de datos en seis meses o pagando 3 veces lo que deberías. Quiero ahorrarte de ambas situaciones.

Tabla de Contenidos

Mejor Base de Datos para Sitios con 100K+ Registros: Supabase vs Firebase vs PlanetScale Probado

Por Qué Existe Esta Comparación

En Social Animal, construimos aplicaciones web headless — principalmente con Next.js y Astro — para clientes que necesitan sitios dinámicos y pesados en datos. Piensa en directorios empresariales con 50K+ listados, sitios de SEO programático que generan miles de páginas, y dashboards de SaaS que necesitan actualizaciones en tiempo real.

Cuando un cliente nos trae un proyecto que implica 100K+ registros, la conversación sobre la base de datos ocurre en el primer día. No es una ocurrencia tardía. Tu elección de base de datos se filtra en tu estrategia de autenticación, tu diseño de API, tus costos de hospedaje, y tu capacidad de lanzar características seis meses a partir de ahora.

No voy a pretender que he ejecutado cargas de trabajo en producción idénticas en las cinco bases de datos. Sería deshonesto. Lo que he hecho es ejecutar producción seria en Supabase (253K+ registros, cinco sitios, 14 meses) y hacer evaluaciones técnicas exhaustivas de las alternativas para proyectos cliente específicos. Seré claro acerca de qué datos provienen de producción y cuáles provienen de evaluación.

Los Contendientes de un Vistazo

Antes de profundizar, aquí está la descripción rápida:

  • Supabase — PostgreSQL con todo incluido (autenticación, almacenamiento, tiempo real, funciones edge)
  • Firebase Firestore — Base de datos NoSQL de documentos de Google con excelentes SDKs móviles
  • PlanetScale — MySQL sin servidor con ramificación de base de datos (impulsado por Vitess)
  • Neon — PostgreSQL sin servidor con ramificación y escala a cero
  • Turso — SQLite distribuido en el edge (impulsado por libSQL)

Cada uno es genuinamente bueno en algo. La pregunta es si ese algo coincide con lo que estás construyendo.

Supabase PostgreSQL: Nuestro Caballo de Batalla en Producción

Comenzaré con Supabase porque es donde tenemos la experiencia más profunda. En cinco sitios de producción, nuestra tabla más grande tiene 137K filas (un sistema de direcciones nacionales para un proyecto de directorio), y estamos en 253K+ registros totales en todas las bases de datos.

Lo Que Usamos Diariamente

Row Level Security (RLS) es probablemente la característica que cerró el trato para nosotros. Cuando estás construyendo aplicaciones multitenant — que la mayoría de sitios impulsados por CMS headless eventualmente se convierten — necesitas aislamiento de datos por usuario. Con RLS, la lógica de seguridad vive en la base de datos misma. Tu capa de API no necesita recordar filtrar por user_id en cada consulta. La base de datos lo hace cumplir.

Aquí está lo que una política RLS típica se ve como en nuestros proyectos:

-- Los usuarios solo pueden ver los listados de su propia organización
CREATE POLICY "org_isolation" ON listings
  FOR SELECT
  USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));

-- Los administradores pueden ver todo
CREATE POLICY "admin_access" ON listings
  FOR ALL
  USING (EXISTS (
    SELECT 1 FROM profiles
    WHERE id = auth.uid() AND role = 'admin'
  ));

Esto es SQL real. No es un DSL propietario. Si alguna vez necesitas dejar Supabase, estas políticas se traducen a cualquier host PostgreSQL.

pgvector ha sido una revelación para búsqueda semántica. Lo implementamos en un sitio con mucho contenido donde la búsqueda de texto completo tradicional no funcionaba. Los usuarios buscarían "lugares para comer cerca del centro" y esperarían resultados que incluyan restaurantes, cafeterías y camiones de comida — incluso si esas palabras exactas no estaban en el listado.

-- Crear la columna vectorial
ALTER TABLE listings ADD COLUMN embedding vector(1536);

-- Crear el índice (esto importa MUCHO a 100K+ registros)
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

-- Consulta de búsqueda semántica
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;

A 137K registros con vectores de dimensión 1536, esta consulta retorna en ~45ms en el plan Pro de Supabase. Eso es lo suficientemente rápido para búsqueda en tiempo real a medida que escribes.

PostGIS las consultas geo alimentan nuestras características basadas en ubicación. Encontrar listados dentro de un radio, ordenar por distancia, calcular tiempos de conducción — todo manejado a nivel de base de datos en lugar de en código de aplicación.

-- Encontrar listados dentro de 10km de un punto, ordenados por distancia
SELECT id, name,
  ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
  location,
  ST_MakePoint(-73.9857, 40.7484)::geography,
  10000
)
ORDER BY distance_m
LIMIT 50;

Las suscripciones en tiempo real nos permiten construir dashboards en vivo sin infraestructura WebSocket. Un panel de administración del cliente muestra nuevos envíos apareciendo instantáneamente porque nos suscribimos a eventos INSERT en la tabla relevante. Cero infraestructura adicional.

Lo Que No Es Perfecto

No voy a pretender que Supabase es impecable. El dashboard puede ser lento cuando estás navegando por tablas con 100K+ filas. El editor de tabla está bien para conjuntos pequeños de datos pero es tedioso para operaciones en masa — querrás usar SQL directamente. Sus Edge Functions están impulsadas por Deno, lo que significa que algunos paquetes de Node.js no funcionan. Y si necesitas agrupación de conexiones para entornos sin servidor, tienes que usar su cadena de conexión Supavisor (han descontinuado PgBouncer a partir de principios de 2025).

También, su nivel gratuito es genuinamente generoso para desarrollo pero tiene un límite duro de 500MB de espacio de base de datos. Para producción con 100K+ registros, estás mirando el mínimo de plan Pro ($25/mes).

Mejor Base de Datos para Sitios con 100K+ Registros: Supabase vs Firebase vs PlanetScale Probado - arquitectura

Firebase Firestore: Dónde Gana y Dónde No

Evaluamos Firebase seriamente para dos proyectos cliente en 2024. Uno era una aplicación orientada a móvil con requisitos de sincronización sin conexión. El otro era un sitio de directorio con filtrado complejo.

Dónde Firebase Genuinamente Gana

La sincronización en tiempo real de Firebase para aplicaciones móviles sigue siendo lo mejor de su clase. La persistencia sin conexión, la resolución automática de conflictos y la integración cerrada con los SDKs de iOS/Android hacen que sea la opción obvia si tu plataforma principal es móvil. La integración de Google Auth es muy simple — algunas líneas de código y tienes Sign-in con Google, Apple, número de teléfono y correo electrónico/contraseña.

Firebase Crashlytics, Remote Config y Analytics forman un ecosistema de desarrollo móvil que nada más iguala. Si estás construyendo una aplicación móvil primero y una aplicación web segundo, Firebase merece consideración seria.

Por Qué Elegimos Supabase en su lugar

Firestore es una base de datos de documentos. No hay uniones. Que eso se asiente por un momento.

Cuando estás construyendo un directorio con listados que tienen categorías, etiquetas, ubicaciones, reseñas y perfiles de usuario, necesitas datos relacionales. En Firestore, o desnormalizas todo (duplicando datos en documentos y rezando para mantenerlo sincronizado) o haces múltiples consultas de viaje de ida y vuelta y unes los datos en código de aplicación.

Aquí está lo que se ve una consulta de "buscar listados por categoría con calificación promedio" en cada uno:

-- Supabase: una consulta, hecho
SELECT l.*, c.name AS category_name,
  AVG(r.rating) AS avg_rating,
  COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;

// Firestore: tres consultas + unión del lado del cliente
const categorySnap = await db.collection('categories')
  .where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;

const listingsSnap = await db.collection('listings')
  .where('categoryId', '==', categoryId).get();

// Ahora obtén reseñas para cada listado...
// Luego calcula promedios en código de aplicación...
// Luego ordena... ya entiendes la idea.

Y aquí está el verdadero problema: Firestore cobra por lectura de documento. Ese patrón de triple consulta de arriba? Cada documento en cada consulta cuenta. A 100K+ registros con tráfico moderado, tu factura se vuelve genuinamente impredecible. Hemos escuchado historias de horror de facturas sorpresas de $400+ de desarrolladores que no se dieron cuenta de que sus consultas estaban escaneando más documentos de lo esperado.

Firestore tampoco tiene equivalente a pgvector o PostGIS. Puedes hacer consultas geohash básicas, pero son aproximadas y limitadas en comparación con verdadera indexación espacial.

PlanetScale: Excelente Base de Datos, Plataforma Incompleta

PlanetScale ejecuta Vitess bajo el capó — la misma tecnología que impulsa la base de datos de YouTube. Para rendimiento puro de MySQL, es excelente. Su característica de ramificación de base de datos (crear una rama, hacer cambios de esquema, fusionar atrás) es genuinamente innovadora y algo que desearía que Supabase tuviera de forma nativa.

Lo Que PlanetScale Hace Bien

Su controlador sin servidor es rápido. La gestión de conexiones se maneja para ti, lo que importa enormemente en entornos sin servidor donde cada invocación de función podría abrir una nueva conexión de base de datos. La ramificación de esquema hace que las migraciones de base de datos se sientan como solicitudes de extracción de Git — seguras, revisables, reversibles.

Para equipos con una fuerte experiencia en MySQL construyendo aplicaciones web tradicionales, PlanetScale es sólido.

Lo Que Falta

PlanetScale es solo una base de datos. Eso es todo. Compara lo que necesitas para construir una pila de aplicación completa:

Característica Supabase PlanetScale + Extras
Base de Datos ✅ Incluido ✅ Incluido
Autenticación ✅ Incluido ❌ Necesita Clerk ($25+/mes) o Auth0
Almacenamiento de Archivos ✅ Incluido ❌ Necesita S3 o Cloudflare R2
Tiempo Real ✅ Incluido ❌ Necesita Pusher o Ably
Búsqueda Vectorial ✅ pgvector ❌ No disponible
Consultas Geo ✅ PostGIS ❌ Espacial básico de MySQL
Funciones Edge ✅ Incluido ❌ Necesita despliegue separado

Para el momento en que hayas añadido Clerk para autenticación, S3 para almacenamiento, Pusher para tiempo real, y una base de datos vectorial separada para búsqueda, estás gestionando cinco servicios en lugar de uno. Tu factura es más alta, tu complejidad es más alta, y tu superficie de área de debugging es enorme.

PlanetScale también descontinuó su nivel gratuito (plan Hobby) en abril de 2024, por lo que el punto de entrada ahora es $39/mes para su plan Scaler. Eso es más caro que Supabase Pro y te proporciona menos funcionalidad.

Neon: La Elección del Purista

Neon es la base de datos que elegiría si solo necesitara PostgreSQL y nada más. Su arquitectura sin servidor es genuinamente impresionante — escala a cero significa que no pagas nada cuando tu base de datos no está siendo consultada. Su característica de ramificación es excelente para despliegues de vista previa (genera una rama de base de datos para cada PR).

Neon soporta pgvector y PostGIS porque es PostgreSQL estándar. Así que obtienes búsqueda vectorial y consultas geo. Las capacidades de base de datos cruda son casi idénticas a Supabase.

Por Qué Aún Elegimos Supabase

Neon es una base de datos. Supabase es una plataforma. Con Neon, necesitas añadir:

  1. Autenticación — Clerk, Auth0, o construir la tuya propia
  2. Almacenamiento — S3, Cloudflare R2, o similar
  3. Tiempo Real — Pusher, Ably, o un servidor WebSocket personalizado
  4. Funciones Edge — Despliega en Cloudflare Workers o Vercel por separado

Para algunos equipos, ese enfoque modular es actualmente preferible. Si ya tienes opiniones sobre autenticación (y el presupuesto para Clerk), usas S3 para todo, y no necesitas tiempo real, el enfoque enfocado de Neon significa menos bloqueo de proveedor.

Pero para nuestros proyectos de desarrollo headless, tener autenticación, almacenamiento y tiempo real en un dashboard con una factura y un conjunto de claves de API es muy valioso. La velocidad del desarrollador importa cuando estás lanzando proyectos cliente en plazos ajustados.

El precio de Neon también es competitivo: su nivel gratuito incluye 0.5GB de almacenamiento y 190 horas de cómputo/mes. El plan Launch a $19/mes te proporciona 10GB. Para un juego puro de base de datos, es el mejor valor en PostgreSQL sin servidor.

Turso: SQLite Orientado al Edge

Turso es una tecnología fascinante. Han tomado SQLite — la base de datos más implementada del mundo — e hicieron que fuera distribuida. Tus datos viven en el edge, cerca de tus usuarios, lo que significa que la latencia de lectura puede ser increíblemente baja (menos de 10ms globalmente).

Dónde Turso Brilla

Cargas de trabajo de lectura intensiva con audiencias globales. Si estás sirviendo contenido que no cambia frecuentemente a usuarios en todo el mundo, la replicación de edge de Turso te proporciona lecturas de base de datos que se sienten instantáneas. Su característica de réplicas incrustadas te permite agrupar una réplica de SQLite directamente en tu aplicación.

Para sitios estático-ish construidos con Astro que necesitan una capa de datos ligera, Turso es convincente.

Por Qué No Se Ajustó a Nuestras Necesidades

Nuestras cargas de trabajo de 100K+ registros implican escrituras significativas — envíos de usuarios, actualizaciones de administrador, creación de reseñas, cambios de datos en tiempo real. El modelo de escritura de SQLite (escritor único) se convierte en un cuello de botella a escala. Turso maneja esto mejor que SQLite crudo a través de su bifurcación libSQL, pero sigue sin estar diseñado para aplicaciones con mucha escritura y 100K+ registros.

Sin búsqueda vectorial. Sin equivalente a PostGIS. Ecosistema limitado en comparación con PostgreSQL o MySQL. Para nuestros proyectos de directorio y SaaS, estos fueron puntos de quiebre.

Comparación de Características Frente a Frente

Aquí está la tabla de comparación completa basada en nuestra experiencia en producción y evaluaciones a mediados de 2026:

Característica Supabase Firebase PlanetScale Neon Turso
Tipo de Base de Datos PostgreSQL NoSQL (Firestore) MySQL (Vitess) PostgreSQL SQLite (libSQL)
Autenticación Incorporada ✅ Sí ✅ Sí ❌ No ❌ No ❌ No
Búsqueda Vectorial ✅ pgvector ❌ No ❌ No ✅ pgvector ❌ No
Consultas Geo ✅ PostGIS ⚠️ Limitado (Geohash) ⚠️ Espacial básico de MySQL ✅ PostGIS ❌ No
Tiempo Real ✅ Sí ✅ Sí ❌ No ❌ No ❌ No
Almacenamiento de Archivos ✅ Sí ✅ Sí ❌ No ❌ No ❌ No
Funciones Edge ✅ Basadas en Deno ✅ Cloud Functions ❌ No ❌ No ❌ No
Uniones / Relaciones ✅ SQL Completo ❌ Sin uniones ✅ SQL Completo ✅ SQL Completo ✅ SQL (limitado)
Ramificación ⚠️ Vía migraciones ❌ No ✅ Nativa ✅ Nativa ❌ No
Escala a Cero ❌ No ✅ Sí ✅ Sí ✅ Sí ✅ Sí
Previsibilidad de Precios 🟢 Alta (niveles fijos) 🔴 Baja (por lectura) 🟡 Media 🟢 Alta 🟢 Alta
Código Abierto ✅ Sí ❌ No ❌ No (Vitess es) ✅ Sí ✅ Sí
Auto-hospedable ✅ Sí ❌ No ❌ No ❌ No ✅ Sí

Benchmarks de Rendimiento a 100K+ Registros

Estos números provienen de nuestra instancia de Supabase en producción (plan Pro, región us-east-1) con 137K filas en la tabla principal. Para las otras bases de datos, estoy usando benchmarks publicados y nuestras pruebas de evaluación con 100K registros sintéticos.

Tipo de Consulta Supabase Firebase PlanetScale Neon Turso
SELECT Simple por ID 3ms 8ms 4ms 5ms 1ms
Consulta Filtrada (indexada) 12ms 15ms 10ms 14ms 3ms
JOIN Complejo (3 tablas) 35ms N/A (sin uniones) 28ms 38ms 25ms
Similitud Vectorial (top 20) 45ms N/A N/A 42ms N/A
Radio Geo (10km) 22ms ~50ms (geohash) N/A 24ms N/A
Búsqueda de Texto Completo 18ms N/A (usar Algolia) 15ms 20ms 12ms
Inserción en Masa (1000 filas) 180ms 250ms 150ms 195ms 320ms
Inicio en Frío (sin servidor) N/A (siempre activo) ~100ms ~50ms ~300ms ~20ms

Varias cosas se destacan. El rendimiento de lectura de Turso es excepcional — esa es la ventaja de SQLite en el edge. El motor MySQL de PlanetScale maneja uniones ligeramente más rápido que PostgreSQL en nuestras pruebas. El inicio en frío de Neon es notable (300ms) porque necesita despertar el cómputo, aunque las consultas posteriores son rápidas. La falta de uniones de Firebase significa que literalmente no puedes ejecutar algunas de estas consultas.

El cómputo siempre activo de Supabase (sin escala a cero en Pro) significa cero inicios en frío, lo que importa para aplicaciones orientadas al usuario donde esa primera solicitud no puede ser lenta.

Desglose de Precios para Cargas de Trabajo de 100K Registros

Modelemos una aplicación realista de 100K registros: un sitio de directorio con 100K listados, 50K usuarios activos mensuales, ~2M lecturas de base de datos/mes, ~50K escrituras/mes, 5GB de tamaño de base de datos, 10GB de almacenamiento de archivos.

Supabase Pro Firebase (Blaze) PlanetScale Scaler Neon Launch Turso Scaler
Costo Base $25/mes $0 (pago por uso) $39/mes $19/mes $29/mes
Base de Datos Incluido (8GB) ~$18 (lecturas + escrituras) Incluido (10GB) Incluido (10GB) Incluido (9GB)
Autenticación Incluido (50K MAU) Incluido +$25/mes (Clerk) +$25/mes (Clerk) +$25/mes (Clerk)
Almacenamiento (10GB) Incluido ~$3/mes +$2/mes (R2) +$2/mes (R2) +$2/mes (R2)
Tiempo Real Incluido Incluido +$25/mes (Pusher) +$25/mes (Pusher) +$25/mes (Pusher)
Total Estimado $25/mes ~$21/mes ~$91/mes ~$71/mes ~$81/mes

Firebase parece barato hasta que te das cuenta de dos cosas. Primero, esa estimación de $21 asume patrones de lectura predecibles. Un momento viral o un bot rastreando tu sitio puede disparar las lecturas dramáticamente — y tu factura se dispara con ella. Segundo, una vez que necesitas características como búsqueda vectorial, estás añadiendo Pinecone o Weaviate, que comienzan en $70/mes.

El $25/mes fijo de Supabase para todo — base de datos, autenticación, almacenamiento, tiempo real, funciones edge — es una relación precio-valor notablemente buena para este tamaño de carga de trabajo. El plan Pro incluye 8GB de base de datos, 250GB de ancho de banda, 100GB de almacenamiento, y 50K usuarios activos mensuales para autenticación.

¿Qué Base de Datos Deberías Elegir?

Aquí está mi recomendación honesta basada en construir con estas herramientas:

Elige Supabase si estás construyendo una aplicación web con datos relacionales, necesitas autenticación + almacenamiento + tiempo real en una plataforma, quieres el ecosistema de PostgreSQL (pgvector, PostGIS, búsqueda de texto completo), o estás construyendo con Next.js. Esto cubre probablemente el 80% de los proyectos que vemos.

Elige Firebase si estás construyendo una aplicación orientada a móvil donde la sincronización sin conexión importa, tu equipo ya conoce el ecosistema de Firebase, o tus datos son verdaderamente de forma de documento (mensajes de chat, feeds de actividad, perfiles de usuario simples).

Elige PlanetScale si tienes un equipo MySQL fuerte, necesitas ramificación de base de datos para gestión de esquema compleja, y ya estás usando servicios separados para autenticación y almacenamiento. Es una excelente base de datos — simplemente no es una plataforma completa.

Elige Neon si quieres PostgreSQL sin la sobrecarga de plataforma, prefieres ensamblar tu propia pila de servicios de mejor en su clase, o necesitas escala a cero para optimizar costos en proyectos de bajo tráfico.

Elige Turso si estás construyendo una aplicación de lectura intensiva y distribuida globalmente donde la latencia de edge importa más que el rendimiento de escritura, o estás trabajando con Astro en sitios orientados al contenido.

Para nuestro trabajo en Social Animal construyendo aplicaciones web headless, Supabase ha sido la opción correcta. La plataforma todo en uno significa desarrollo más rápido, arquitectura más simple y costos predecibles. Hemos escalado a 253K+ registros sin ningún problema. Si estás planeando un proyecto a esta escala y quieres hablar de arquitectura, comunícate con nosotros — hemos hecho esto algunas veces ya.

Preguntas Frecuentes

¿Es Supabase bueno para aplicaciones a gran escala? Sí, y tenemos evidencia de producción para respaldar eso. Estamos ejecutando 253K+ registros en cinco sitios de producción en Supabase Pro. El rendimiento de consultas se mantiene consistente — nuestras uniones más complejas con búsqueda de similitud vectorial retornan en menos de 50ms a 137K filas. Supabase se ejecuta en PostgreSQL estándar, que alimenta aplicaciones órdenes de magnitud más grandes que cualquier cosa que la mayoría de nosotros construiremos. La capa de plataforma (autenticación, almacenamiento, tiempo real) es la parte que es más nueva, pero ha sido estable para nosotros desde principios de 2024.

¿Cómo se compara el precio de Supabase con Firebase a escala? Supabase es dramáticamente más predecible. Su plan Pro es un $25/mes fijo que incluye autenticación para 50K MAU, 8GB de almacenamiento de base de datos, 250GB de ancho de banda y 100GB de almacenamiento de archivos. Firebase cobra por lectura, escritura y eliminación de documento — lo que hace que los costos sean altamente variables. Una aplicación de 100K registros con 2M lecturas mensuales podría costar entre $15 y $200+ en Firebase dependiendo de patrones de consulta. Hemos visto facturas de Firebase triplicarse durante la noche cuando una página se comparte en redes sociales.

¿Puede PlanetScale manejar 100K+ registros? Absolutamente. PlanetScale ejecuta Vitess, que alimenta cargas de trabajo de escala de YouTube. Para rendimiento puro de base de datos con 100K registros, PlanetScale es excelente. La limitación no es escala — es totalidad. Necesitarás añadir servicios separados para autenticación, almacenamiento de archivos, actualizaciones en tiempo real y búsqueda vectorial. Eso añade tanto costo ($90+/mes total) como complejidad arquitectónica en comparación con el enfoque todo en uno de Supabase.

¿Qué es pgvector y por qué importa? pgvector es una extensión de PostgreSQL que almacena y consulta incrustaciones vectoriales directamente en tu base de datos. Esto permite búsqueda semántica — los usuarios pueden buscar por significado en lugar de palabras clave exactas. Para un directorio con 100K+ listados, esto significa una búsqueda de "lugares amigables para niños para brunch" puede retornar resultados etiquetados como "restaurante familiar" o "desayuno de fin de semana" aunque esas palabras no coincidan. Sin pgvector, necesitarías una base de datos vectorial separada como Pinecone ($70+/mes) y lidiar con mantener dos bases de datos sincronizadas.

¿Es Firebase Firestore bueno para sitios de directorio? Honestamente, no. Los sitios de directorio son inherentemente relacionales. Los listados pertenecen a categorías, tienen etiquetas, reciben reseñas de usuarios, y necesitan filtrado complejo ("muéstrame restaurantes dentro de 5 millas con 4+ estrellas que están abiertos ahora"). Firestore no puede hacer uniones, tiene operadores de consulta limitados, y cobra por lectura de documento — lo que significa que consultas filtradas complejas se vuelven caras rápidamente. Evaluamos Firestore para un proyecto de directorio y estimamos 4 veces el tiempo de desarrollo comparado con Supabase debido a desnormalización de datos y soluciones alternativas de consulta del lado del cliente.

¿Debo usar Neon o Supabase para mi aplicación Next.js? Si solo necesitas una base de datos, Neon ofrece mejor valor (el nivel gratuito es generoso, y el plan Launch a $19/mes es sólido). Si necesitas autenticación, almacenamiento, tiempo real o funciones edge — que la mayoría de aplicaciones Next.js en producción necesitan — Supabase te ahorra de integrar y pagar por múltiples servicios separados. Usamos Supabase para nuestros proyectos de desarrollo Next.js porque la autenticación integrada y el almacenamiento ahorran semanas en líneas de tiempo de proyecto típicas.

¿Cuál es la mejor base de datos para sitios de SEO programático? Supabase PostgreSQL. Los sitios de SEO programático generan miles de páginas de datos estructurados, lo que significa que necesitas consultas rápidas, buen indexado, y la capacidad de manejar relaciones de datos complejas. Hemos construido sitios de SEO programático en Supabase que generan 10K+ páginas de una sola base de datos — PostGIS para páginas de ubicación, pgvector para contenido relacionado, y búsqueda de texto completo para filtrado dinámico. El precio fijo significa que picos de tráfico de Google indexando no vuelen tu factura.

¿Está Turso (libSQL) listo para aplicaciones web en producción? Para aplicaciones de lectura intensiva, sí. SQLite replicado en el edge de Turso te proporciona lecturas sub-5ms globalmente, lo que es increíble para sitios orientados al contenido. Pero para aplicaciones con mucha escritura con 100K+ registros — como directorios donde los usuarios envían datos, paneles de administración procesan actualizaciones y las reseñas llegan constantemente — el modelo de escritor único de SQLite se convierte en limitante. Recomendaríamos Turso para sitios de contenido construidos con Astro y Supabase o Neon para aplicaciones dinámicas con cargas de trabajo de escritura significativas.