Postgres como plataforma: colas, búsqueda y vectores sin infra extra

La decisión de arquitectura más subestimada de la década: hacer menos. Postgres se fue comiendo en silencio la mitad de la categoría de infraestructura de datos, y la mayoría de los equipos no se dio cuenta porque el presupuesto de marketing de "usá la base de datos que ya tenés corriendo" es cero. Antes de que tu próxima revisión de arquitectura sume una cola, un cluster de búsqueda y un vector store al diagrama, fijate todo lo que cubre la opción aburrida, y exactamente dónde deja de alcanzar.

1. Colas de jobs con SKIP LOCKED

Una cola de workers en quince líneas de SQL, con la semántica de procesamiento exactly-once que tu setup de Redis en realidad nunca tuvo. FOR UPDATE SKIP LOCKED deja que cualquier cantidad de workers tome jobs en paralelo sin pisarse, y como la cola vive en la misma base que los datos de tu aplicación, encolar un job y commitear el cambio de negocio que lo originó pasan en una sola transacción. Sin outbox pattern, sin bug de doble escritura, sin un job de reconciliación para escribir más adelante.

DELETE FROM queue
WHERE id = (
  SELECT id FROM queue
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
RETURNING payload;

La parte operativa es la que los equipos subestiman: tu cola ahora tiene backups, point-in-time recovery y monitoreo gratis, porque es simplemente una tabla. Cuando un job se porta mal, lo debuggeás con un SELECT, no con el dashboard de un proveedor.

2. Búsqueda full-text que alcanza y sobra

tsvector con un índice GIN cubre las necesidades de búsqueda de la mayoría de los productos: stemming, ranking, resaltado, varios idiomas. No sos Google, y tus cuarenta mil documentos no necesitan un cluster con su propia guardia. La limitación honesta es el ajuste de relevancia: Postgres te da perillas, no ranking con machine learning. Para un sitio de documentación, un catálogo de productos o un panel de administración, nadie lo va a notar nunca.

SELECT title, ts_rank(search, query) AS rank
FROM posts, websearch_to_tsquery('english', 'edge rendering') query
WHERE search @@ query
ORDER BY rank DESC
LIMIT 10;

3. Vectores al lado de tus datos

pgvector pone los embeddings en la misma transacción que las filas que describen. Cuando un documento se actualiza, su embedding se actualiza en el mismo commit: sin pipeline de sincronización, sin desfase de consistencia entre tu base y tu vector store, una sola estrategia de backup en lugar de dos. Con índices HNSW, la búsqueda por similitud en milisegundos de un dígito se sostiene cómoda hasta millones de embeddings, que es más de lo que la mayoría de los productos va a guardar jamás.

La parte incómoda: límites de conexiones y vacuum

Postgres como plataforma tiene dos modos de falla que conviene respetar. Las tablas con mucha rotación —y eso es justamente una cola con movimiento— exigen ajustar el autovacuum, o las dead tuples van a degradar en silencio la misma query que mantiene alimentados a tus workers. Y cada worker, cron job y función serverless ahora quiere una conexión a la misma base, así que poner un pooler adelante deja de ser opcional. Ninguno de los dos problemas es exótico; los dos ya mordieron a equipos que trataron la base como si fuera infinitamente elástica.

Cuándo ir a buscar infra de verdad

Pasadas esas líneas, especializate sin culpa: la migración es más fácil justamente porque la carga ya está bien definida en SQL. Antes de llegar ahí, disfrutá del diagrama de arquitectura que entra en una servilleta, de la estrategia de backup única y de una guardia que tiene un solo sistema por el cual despertarte.