Only Postgres: por qué tu MVP quizá aún no necesite Redis, Elasticsearch ni una base de datos vectorial

Frase clave SEO: Only Postgres en MVP

TL;DR

La mayoría de los MVP y sistemas pequeños funciona muy bien con Only Postgres en MVP, sin Redis, Elasticsearch ni una base de datos vectorial dedicada.
PostgreSQL moderno ya resuelve cachés simples, búsqueda de texto, filtros, informes, colas básicas e incluso búsqueda vectorial mediante extensiones.
En lugar de adivinar los cuellos de botella antes de tiempo, empieza de forma simple, mide y añade nuevas piezas solo cuando el problema sea real.
El objetivo no es “Postgres para siempre”, sino “Postgres como default seguro” + una arquitectura que permita evolucionar después, incorporando herramientas especializadas cuando tenga sentido.

1. Contexto: ¿por qué estamos complicando todo tan pronto?

Comparación entre un MVP con Only Postgres y otro con varios servicios como Redis, Elastic, una cola y una base vectorial.

Una escena clásica.

Entras en el repositorio de un MVP que todavía no tiene ni diez usuarios y encuentras:

API en microservicios (tres o cinco, obviamente).
Redis para caché.
Elasticsearch para búsqueda.
Una base de datos vectorial “porque vamos a usar IA en algún momento”.
Una cola (Kafka o RabbitMQ) “para estar listos para escalar”.

Y el problema de negocio todavía está en definición.

Esto termina convirtiéndose en una especie de arquitectura “currículum de LinkedIn”: muchas piezas sofisticadas y poca claridad sobre la necesidad real. El resultado es un equipo gastando energía en levantar, configurar, monitorear y depurar infraestructura… mientras el producto todavía está descubriendo si alguien quiere usarlo.

¿Por qué ocurre esto con tanta frecuencia?

FOMO técnico: miedo a “quedarse atrás” si no se utiliza el stack de moda.
Referencia equivocada de escala: copiar la arquitectura de Netflix o Meta para un SaaS con 50 clientes.
Confusión entre “podría ser útil algún día” y “necesito esto hoy”.

La tesis de este texto es simple:

Para muchos MVP, Only Postgres en MVP es un punto de partida más seguro, barato y fácil de operar. Y, si funciona, siempre puedes evolucionar después.

No es un manifiesto contra Redis, Elastic o las bases de datos vectoriales. Estas herramientas son excelentes —en el momento adecuado. El foco aquí está en el timing de la complejidad: retrasar el coste de operar un zoológico de tecnologías hasta que realmente lo necesites.

Si quieres ver la misma discusión en formato de presentación, vale la pena consultar la charla sobre Only Postgres en MVP, que profundiza en este razonamiento dentro de otro contexto.

2. Qué resuelve ya un “Only Postgres” bien utilizado

Infografía sobre recursos de PostgreSQL: índices BTREE y GIN, JSONB, búsqueda full-text y extensiones.

Mucha gente todavía considera PostgreSQL simplemente “una base de datos relacional que hace CRUD y joins”. Sin embargo, el PostgreSQL moderno ofrece mucho más y cubre varias necesidades que algunas personas delegan demasiado pronto en otras herramientas.

Capacidades importantes de PostgreSQL hoy

Algunos recursos que suelen aprovecharse poco:

Índices variados
BTREE: lo básico para igualdad y ordenación.
GIN: excelente para índices sobre arrays, JSONB y full-text.
GiST: admite datos geométricos, búsquedas por proximidad y algunos escenarios de full-text.
BRIN: ayuda en tablas muy grandes, especialmente cuando los datos están naturalmente ordenados.
JSONB y datos semiestructurados
Permite guardar partes más “flexibles” del dominio sin salir de Postgres.
Es útil para metadatos, configuraciones por cliente, payloads de integraciones, etc.
Full-text search nativo
Con tsvector / tsquery, stemming, ranking básico y stopwords.
Permite buscar títulos, descripciones y contenido textual de forma bastante competente.
Extensiones
pg_trgm: búsqueda por similitud (fuzzy), excelente para autocompletado y correcciones.
pgvector: columna vectorial para IA (hablaremos de ello más adelante).
Otras extensiones pueden resolver nichos específicos, pero para un MVP estas dos suelen cubrir mucho terreno.
Mecanismos de concurrencia útiles
FOR UPDATE SKIP LOCKED, por ejemplo, permite implementar colas concurrentes en una tabla de tareas, evitando que dos workers procesen el mismo registro.

Estos recursos, combinados, ya cubren casos como:

Caché simple.
Colas básicas.
Búsqueda textual.
Informes y filtros más pesados.
Casos iniciales de IA generativa con RAG.

Esto no significa que PostgreSQL sustituya a los sistemas de caché, colas distribuidas, motores de búsqueda o bases de datos vectoriales en todos los contextos. Significa que, durante una fase de MVP, suele ser “suficientemente bueno” para evitar incorporar esas otras piezas demasiado pronto.

Beneficios arquitectónicos de empezar con una única base de datos

Cuando eliges Only Postgres en MVP, algunos beneficios aparecen de forma natural:

Menos piezas → menos puntos de fallo
Una instancia (o clúster) menos que levantar, monitorear y pagar.
Menos latencia entre servicios; muchas cosas se convierten en una simple llamada a la base de datos.
Operación y observabilidad más sencillas
Backups centralizados.
Monitorización concentrada en un solo stack (métricas de Postgres + logs de la aplicación).
Tuning concentrado en un único punto.
El equipo se enfoca en el producto
Menos tiempo configurando pipelines, operando colas y haciendo deploy de nuevos servicios.
Más tiempo validando hipótesis de negocio, escuchando a los usuarios y ajustando los flujos.

Este razonamiento se desarrolla con más detalle en el análisis de Only Postgres en MVP, que explora por qué muchos MVP no necesitan empezar con Redis, Elasticsearch ni una base de datos vectorial dedicada.

Ejemplo: un MVP sencillo de SaaS B2B

Imagina un SaaS B2B para gestionar propuestas comerciales:

Entidades básicas:
Usuario, empresa, cliente, propuesta, elemento de propuesta y archivo adjunto.
Funcionalidades:
CRUD de clientes y propuestas.
Filtros por estado, fecha, importe y responsable.
Informe mensual de propuestas aprobadas frente a rechazadas.
Autenticación básica (usuario/contraseña, quizá OTP por correo electrónico).

¿Qué necesita este sistema?

CRUD rápido → índices BTREE en claves primarias y columnas utilizadas para filtrar.
Filtros e informes → consultas con agregaciones (SUM, COUNT, GROUP BY), quizá views.
Búsqueda simple → full-text en el título y la descripción de la propuesta, o pg_trgm para buscar por nombre del cliente.
Sesión/autenticación → tabla de usuarios + tokens de sesión/refresh.

Todo esto cabe tranquilamente en un único Postgres, con:

Un esquema relacional claro.
Algunos índices planificados a partir de las consultas reales.
Un poco de full-text / trigram si hace falta.

Ninguna de estas necesidades obliga, por defecto, a levantar Redis, Elasticsearch o una base de datos vectorial el día cero.

3. Sustituir (por ahora) la tríada “Redis + Elastic + base de datos vectorial” por Postgres

Veamos ahora tres casos clásicos en los que las personas tienden a incorporar nuevas tecnologías demasiado pronto, y cómo Postgres puede cubrir buena parte de esas necesidades antes de que tengas que complicar la arquitectura.

La idea no es decir que Postgres sea mejor que estas herramientas, sino mostrar hasta dónde funciona bien durante una fase de MVP.

3.1. Cuando “crees” que necesitas Redis

Casos típicos en los que alguien grita “¡Redis!” durante la planificación de un MVP:

Caché de lectura para endpoints muy utilizados (por ejemplo, /me o una lista de productos).
Almacenamiento centralizado de sesiones de usuario.
Rate limiting para evitar abusos de la API.

En sistemas más grandes esto puede tener sentido, pero en un MVP muchas veces ese todavía no es el problema.

Qué puedes hacer solo con Postgres

Caché “implícita” con índices + consultas adecuadas

En muchos casos, el problema no es “necesito una caché”, sino:

Falta un índice en la columna usada para filtrar.
La consulta hace SELECT * sobre una tabla enorme.
Las listas no tienen paginación.

La combinación de:

Índices adecuados (BTREE en la columna filtrada, GIN en JSONB si hace falta).
Consultas concisas (seleccionando solo las columnas necesarias).
Una paginación correcta.

ya reduce bastante el tiempo de respuesta, hasta el punto de que una caché externa no sea prioritaria al principio.

Sesiones asociadas al usuario en Postgres

En lugar de guardar la sesión en Redis, puedes:

Crear una tabla sessions con:
user_id.
Token (o refresh token).
Datos pequeños en JSONB (user agent, IP).
created_at, expires_at.

O, de forma todavía más sencilla, usar tokens JWT con una validez corta y almacenar solo los refresh tokens en la base de datos. Para un MVP, la escala suele ser tan baja que esto resulta suficiente durante bastante tiempo.

Rate limiting con tablas ligeras

Puedes tener una tabla api_usage con:

user_id.
endpoint o una “clave” de operación.
window_start (por ejemplo, el inicio del minuto actual).
count.

Con un índice compuesto en (user_id, endpoint, window_start), puedes aplicar un límite por usuario y endpoint en una ventana de tiempo. No es tan eficiente como Redis en escenarios de escala muy alta, pero funciona bien en MVP y sistemas con tráfico bajo o medio.

Límites prácticos: cuándo empieza a tener sentido Redis

Por otro lado, insistir en usar Postgres para todo también tiene un límite. Redis empieza a tener sentido cuando:

La instancia de Postgres sufre por lecturas repetitivas muy frecuentes.
Se necesita una latencia de red muy baja con un volumen alto de requests.
Hay picos de tráfico difíciles de absorber solo con Postgres, incluso después de optimizar índices y consultas.

En estos casos, Redis para caché caliente o rate limiting más agresivo es un complemento útil. La diferencia está en empezar de forma simple e introducir Redis cuando el problema sea evidente, y no solo por costumbre.

3.2. Cuando “crees” que necesitas Elasticsearch

Otra escena común: un MVP con media docena de pantallas ya tiene un clúster de Elasticsearch porque “vamos a necesitar una búsqueda potente”.

Argumentos típicos:

“Necesitamos un autocompletado como el de Google”.
“Filtros avanzados en todas partes”.
“Búsqueda con relevancia sofisticada”.

A veces tiene sentido, pero en la mayoría de los MVP todavía no.

Qué hace Postgres de forma nativa para la búsqueda

Full-text search (tsvector / tsquery)

Puedes:

Crear una columna search_vector de tipo tsvector.
Rellenar esa columna a partir del título, la descripción y el contenido.
Crear un índice GIN sobre search_vector.
Ejecutar consultas usando to_tsquery o plainto_tsquery.

Esto permite:

Buscar términos.
Usar stemming (encontrar “corriendo” al buscar “correr”, por ejemplo).
Ordenar resultados con ts_rank.
pg_trgm para búsquedas por similitud

Con la extensión pg_trgm puedes:

Hacer que LIKE sea más eficiente.
Implementar búsquedas “parecidas” (fuzzy).
Crear un autocompletado sencillo (por prefijo o similitud).
Índices GIN/GiST bien utilizados

Combinados con tsvector o pg_trgm, estos índices mejoran mucho el tiempo de respuesta de búsquedas y filtros, sin salir de Postgres ni operar un clúster separado.

Ejemplo: búsqueda de productos o publicaciones de blog

Imagina un catálogo de productos con:

Nombre.
Descripción.
Etiquetas.

Puedes:

Crear una columna search_vector con la concatenación del nombre, la descripción y las etiquetas, convertidos a tsvector.
Indexarla con GIN.
Hacer consultas que:
Filtren por categoría y precio.
Busquen términos textuales en search_vector.
Ordenen por relevancia básica (rank) o por fecha.

Para un MVP, esto cubre bien la mayoría de los casos de “búsqueda de catálogo” o “búsqueda de contenido”.

Límites prácticos: cuándo Elasticsearch destaca

Elasticsearch empieza a justificar su coste cuando:

Tienes muchos documentos y consultas complejas de relevancia.
Necesitas facets y agregaciones más sofisticadas a gran escala.
Requieres un clúster distribuido con alta disponibilidad solo para búsqueda.
Utilizas funcionalidades avanzadas de ranking, sinónimos, boosting, pipelines de ingestión, etc.

Hasta entonces, Only Postgres en MVP con full-text + pg_trgm cubre buena parte de los escenarios sin obligarte a operar otro componente crítico.

3.3. Cuando “crees” que necesitas una base de datos vectorial

En el mundo posterior a ChatGPT, el hype se ha desplazado:

“Nuestro MVP necesita IA generativa”.
“Vamos a hacer RAG (Retrieval-Augmented Generation) desde el día cero”.
“He levantado una base de datos vectorial dedicada; ahora estoy preparado para el futuro”.

Para muchos MVP de IA, esto es más complejo de lo necesario.

Qué existe ya en el ecosistema de Postgres

Hoy Postgres cuenta con extensiones como:

pgvector: añade un tipo de dato vectorial + índices para búsquedas por similitud (coseno, L2, etc.).

En la práctica, puedes:

Tener una tabla documents con:
id, title, content (columnas normales).
embedding (columna vectorial mediante pgvector).
Insertar el contenido y el embedding (proveniente de un modelo externo).
Ejecutar consultas de “similitud” por vector para recuperar documentos relevantes.

Con esto puedes montar un RAG básico usando solo Postgres + pgvector, suficiente para muchas pruebas de concepto y pilotos.

Por qué esto es suficiente para muchos MVP de IA

Muchos MVP de IA:

Tienen pocos documentos (cientos o algunos miles).
Tienen baja frecuencia de consulta (demostración, POC, piloto de pago).
No exigen una latencia ultrabaja.

En estas condiciones, Postgres con pgvector funciona bien gracias a:

Menos componentes que administrar.
Menor coste de infraestructura.
Mayor facilidad para que el equipo lo mantenga y depure.

Límites prácticos: cuándo conviene una base vectorial dedicada

Las bases de datos vectoriales dedicadas empiezan a tener sentido cuando:

Tienes datasets grandes (del orden de millones de vectores).
Necesitas una latencia muy baja para consultas vectoriales frecuentes.
Quieres funcionalidades avanzadas de particionamiento, caché de índices y replicación específica para este tipo de datos.

Llegar a ese punto suele ser una buena señal: significa que tu producto de IA ha salido de la fase de MVP y está en otro nivel. Pero no necesitas empezar allí.

4. ¿Hasta dónde funciona bien Postgres? Señales de que todo sigue bien

Panel sencillo de monitorización con gráficos de latencia, conexiones y tamaño de las tablas.

¿Cómo saber si Only Postgres en MVP sigue siendo una elección saludable en tu contexto?

Checklist: “todo bien, continúa con Only Postgres”

Algunas señales de que todo está bajo control:

La latencia media es aceptable con una carga realista
Las requests más comunes responden en un tiempo adecuado para tu caso de uso.
La base de datos no es el cuello de botella visible
CPU utilizable, IO dentro de lo normal y locks bajo control.
Tu dominio todavía cabe en un esquema claro
No se ha convertido en una maraña de tablas y JSONB que nadie entiende.
Tu equipo entiende al menos la mitad de lo que está ejecutándose
Las consultas principales son legibles.
Los índices no son una caja negra cuyo propósito nadie conoce.

Métricas sencillas que conviene seguir

Sin montar un stack de observabilidad gigante, ya puedes obtener buenas pistas observando:

Tiempo medio de las consultas más comunes
Sigue las 10–20 consultas más ejecutadas: ¿se mantienen estables o están empeorando?
Número de conexiones activas frente al límite
Comprueba si te acercas a max_connections o si el pool está mal configurado.
Crecimiento de las tablas principales
¿Las tablas están creciendo demasiado rápido? ¿Ya tiene sentido considerar particionamiento o almacenamiento en frío?

Herramientas como pg_stat_statements y el slow query log ya resuelven bastante, sin exigir un ecosistema complejo alrededor.

Pitfall: optimización prematura

Errores frecuentes en esta discusión:

Crear caché para todo antes de medir.
Añadir cola + Redis + Elastic “porque es más profesional”.
Estimar problemas de alta escala sin tener un tráfico que los justifique.

No hay ningún premio por la cantidad de tecnologías en un MVP. En general, esto aumenta la deuda técnica y los puntos de fallo sin aportar un beneficio real en la fase inicial.

5. Cuándo “Only Postgres” empieza a doler de verdad

También es importante reconocer el otro lado: Postgres no puede soportarlo todo para siempre. ¿Cómo notar que estás llegando al límite saludable de un modelo Only Postgres en MVP?

Señales claras de que está llegando la hora de añadir otras piezas

Postgres se ha convertido en un cuello de botella incluso después de optimizar lo básico

Ya has:

Ajustado los índices a partir de las consultas reales.
Revisado las consultas más utilizadas.
Corregido problemas de N+1 y accesos innecesarios.
Ajustado la configuración básica de memoria, conexiones, etc.

Aun así:

La latencia sigue siendo alta en escenarios de uso real.
La CPU y el IO viven al límite.
La contención de locks es frecuente.
Patrones de acceso muy diferentes compiten por la misma base de datos

Un caso muy común:

Carga transaccional (CRUD de la aplicación) conviviendo con:
Informes pesados.
Procesos batch intensivos.
Analytics de BI consultando directamente la base de datos de producción.

Esto suele requerir:

Réplicas de lectura dedicadas para informes.
Un data warehouse separado.
Colas/eventos para alimentar otras bases de datos.
Requisitos de latencia o disponibilidad difíciles de atender solo con tuning

Si necesitas:

Un SLA de milisegundos muy exigente.
Una concurrencia de escritura muy alta.
Una distribución geográfica compleja.

…quizá sea el momento de:

Añadir una caché (Redis).
Utilizar mecanismos de cola.
Dividir responsabilidades entre más de un sistema especializado.

Ejemplos de escenarios en los que tiene sentido salir de Only Postgres

Algunos ejemplos:

Añadir Redis para caché distribuida cuando:
Tienes endpoints de lectura extremadamente pesados y con alta frecuencia de acceso.
La respuesta puede reutilizarse para muchos usuarios.
Usar una cola (Kafka/RabbitMQ) cuando:
Los procesos asíncronos son pesados y afectan la experiencia del usuario.
Necesitas escalar workers por separado y contar con un reprocesamiento estructurado.
Introducir Elasticsearch cuando:
Hay muchos documentos y necesidad de búsqueda avanzada, con facets pesadas y relevancia ajustable en detalle.
La búsqueda es lo bastante crítica como para justificar un clúster dedicado.

En estos escenarios, Postgres sigue siendo parte de la solución, pero las herramientas especializadas entran para atender demandas específicas que la base de datos, por sí sola, no cubre de forma cómoda.

6. Estrategia práctica: cómo empezar con Only Postgres sin quedar atrapado

Línea de tiempo que muestra la evolución desde una aplicación con PostgreSQL hasta la incorporación gradual de Redis y otros servicios.

Una preocupación legítima es: “Si empiezo con Only Postgres en MVP, ¿me quedaré atrapado en un camino sin retorno?”.

En la práctica, esto depende mucho más de cómo organizas el código que de la tecnología en sí.

Modelar pensando en la evolución futura

Algunas ideas prácticas:

Separar las capas de la aplicación
Usar algo como ports/adapters, arquitectura hexagonal, clean architecture o, al menos, un módulo de “infra” que aísle el acceso a datos.
Evitar que el SQL crudo quede repartido por todo el código.
Evitar depender desde el principio de detalles demasiado específicos
Si sabes que en el futuro podrías migrar el full-text de Postgres a Elastic, escóndelo detrás de una interfaz de “búsqueda”.
Lo mismo ocurre con la caché: implementa una interfaz de caché que hoy hable con Postgres y mañana pueda hablar con Redis.

Así puedes empezar con Only Postgres en MVP sin bloquear evoluciones futuras.

Ejemplo: diseñar interfaces de “caché” y “búsqueda”

Interfaz de caché

Puedes tener algo como:

CacheService.get(key)
CacheService.set(key, value, ttl)

Al principio:

Implementas CacheService usando una tabla cache_entries en Postgres.

En el futuro, si hace falta:

Implementas una nueva versión de CacheService usando Redis.
El resto del sistema ni siquiera necesita saber que el backend ha cambiado.
Servicio de búsqueda

Crear algo como:

SearchService.searchProducts(query, filters)
SearchService.searchArticles(query)

Al inicio:

Lo implementas usando full-text (tsvector) + pg_trgm en Postgres.

Si después necesitas escalar:

Implementas otro SearchService que llame a Elasticsearch.
Migras los datos gradualmente, cambiando la implementación mediante una feature flag si es necesario.

Buenas prácticas para usar Postgres en este contexto

Algunos cuidados ayudan a sostener esta estrategia:

Monitorizar desde el principio
Activar el slow query log.
Usar pg_stat_statements para saber qué se ejecuta realmente.
Crear índices de forma incremental
Evitar crear índices para todo “por si acaso”.
Crear índices a medida que aparecen consultas reales y se pueden medir.
Cuidado con las extensiones poco conocidas
pg_trgm, pgvector y el mecanismo de full-text están relativamente consolidados.
Las extensiones muy exóticas pueden dificultar las actualizaciones de versión o las migraciones.

Cómo comunicar esta estrategia al equipo y a las partes interesadas

Por último, está la parte de alineamiento:

Para el equipo técnico:
“Vamos a empezar de forma simple, con Only Postgres en MVP, pero la arquitectura está pensada para permitir cambiar o multiplicar servicios después”.
Mostrar cómo las interfaces (caché, búsqueda y cola) permiten cambiar el detalle de infraestructura sin reescribir el dominio.
Para las partes interesadas (producto, negocio y liderazgo):
Explicar el coste de cargar con tecnologías que quizá nunca lleguen a utilizarse realmente.
Reforzar que añadir Redis, Elastic o una base de datos vectorial no está prohibido; es simplemente una decisión que queremos tomar basándonos en datos, cuando aparezca el problema.

7. Conclusión: el poder de retrasar la complejidad

El punto central de este artículo no es que “Postgres sea la respuesta para todo”. Es algo más pragmático:

Postgres es un excelente “default seguro” para empezar la mayoría de los MVP.

Ofrece:

Recursos modernos (JSONB, full-text y extensiones como pg_trgm y pgvector).
Una operación relativamente sencilla.
Un camino de evolución conocido (réplicas, particionamiento y offload hacia otras herramientas).

La estrategia sugerida es:

Usa Only Postgres en MVP como default.
Mide el rendimiento y sigue algunas métricas sencillas.
Optimiza lo básico (índices, consultas y configuración).
A partir de ahí, añade Redis, Elasticsearch, una base de datos vectorial dedicada o colas cuando los problemas sean claros y medibles.

PostgreSQL puede resolver diversas necesidades comunes —como caché simple, colas básicas, búsqueda textual e incluso casos iniciales de IA mediante extensiones—, pero estas soluciones no sustituyen a las herramientas especializadas en todos los escenarios. En algún momento, tiene sentido incorporar sistemas dedicados para escalar mejor determinados tipos de carga.

Una arquitectura saludable no es la que acumula más logos en el diagrama, sino la que crece junto con el producto: ni antes ni después.

Si ya has sufrido un exceso de tecnología en un MVP, vale la pena compartir tu experiencia con otras personas desarrolladoras. Estos relatos ayudan a evitar que el próximo proyecto empiece con más infraestructura que usuarios.

Participa en la comunidad SCCB — https://instagram.com/software_craftsmanship
Consulta los próximos eventos — https://instagram.com/software_craftsmanship

Próximos pasos

Si quieres poner este enfoque en práctica en el próximo proyecto:

Define Postgres como default explícito
Documenta en el README del proyecto: “Comenzaremos con Only Postgres; Redis/Elastic/etc. se incorporarán solo si estas métricas X/Y/Z muestran un problema”.
Mapea pronto las interfaces de infraestructura
Identifica dónde tiene sentido contar con abstracciones: caché, búsqueda y cola/eventos.
La idea no es crear capas porque sí, sino evitar un acoplamiento directo a una solución específica.
Configura el mínimo de observabilidad
Habilita el slow query log y pg_stat_statements.
Crea un panel sencillo para seguir el tiempo medio de las consultas y las conexiones.
Revisa tu arquitectura actual
Si ya tienes Redis, Elastic o una base de datos vectorial en un MVP con poco tráfico, pregúntate:
- “¿Qué partes se están utilizando realmente?”.
- “¿Qué podría volver a resolverse en Postgres sin causar problemas?”.
Comparte las lecciones con el equipo
Usa este debate para alinear expectativas: ni 8 (un monolito caótico sin índices) ni 80 (un clúster distribuido sin usuarios).