OpenSearch frente a PostgreSQL: búsqueda, costo y límite
Guía para decidir cuándo alcanza PostgreSQL full text y cuándo conviene sumar OpenSearch, con datos, permisos, snapshots, costo y prueba mínima.
Un índice de búsqueda guarda documentos preparados para responder rápido; una base transaccional guarda estados que deben cerrar con la operación. Esa diferencia decide si una pyme resuelve búsqueda interna con PostgreSQL full text o suma OpenSearch. La guía compara datos, permisos, costo y prueba de salida para que gerencia y sistemas elijan sin duplicar infraestructura innecesaria.
Dónde aparece la consulta lenta
El síntoma común es una búsqueda de contratos, facturas o tickets que tarda 12 segundos y devuelve resultados mezclados. La clínica privada de Godoy Cruz tenía carpetas por área, una aplicación administrativa y un buscador interno que revisaba texto, número de afiliado y observaciones. El antagonista concreto era la búsqueda pegada a una tabla que también procesaba altas, turnos y caja. La cifra que ordena la conversación sale de la propia documentación de OpenSearch: antes de buscar datos, hay que indexarlos; la unidad básica es un documento JSON con identificador único. PostgreSQL, en cambio, documenta text search con tsvector, diccionarios, ranking y operadores dentro de la misma base. La escala global la da Stack Overflow 2025: PostgreSQL volvió a aparecer entre las bases más usadas y queridas por desarrolladores profesionales. Ese dato no manda la decisión local, pero muestra por qué muchos equipos intentan resolver primero dentro de la base que ya administran. El punto de corte aparece cuando la búsqueda deja de consultar registros y empieza a servir documentos.
Cómo funciona por dentro
El flujo con PostgreSQL tiene cinco pasos. Primero, la aplicación carga factura, contrato, ticket o historia administrativa. Segundo, PostgreSQL guarda campos estructurados, permisos, estado y auditoría. Tercero, una columna tsvector prepara texto buscable desde título, descripción y observaciones. Cuarto, un índice GIN responde consultas por palabra, ranking y filtros. Quinto, el backup de la base recupera datos y búsqueda juntos. El flujo con OpenSearch agrega una copia especializada. Primero, la aplicación guarda el registro principal en PostgreSQL. Segundo, un job o evento toma campos permitidos y arma un documento JSON. Tercero, OpenSearch indexa ese documento mediante API individual o bulk. Cuarto, el buscador consulta OpenSearch y muestra identificador, resumen y ranking. Quinto, la aplicación vuelve a PostgreSQL para abrir el registro real y aplicar permisos finos. PostgreSQL recibe transacciones y entrega datos consistentes. OpenSearch recibe documentos preparados y entrega resultados de búsqueda. Metabase o un panel propio muestra volumen, errores de indexación y consultas lentas. El monitoreo avisa si la cola se atrasa. El backup de PostgreSQL recupera la operación; el snapshot de OpenSearch recupera índices, plantillas y estado del clúster, según la guía de snapshots. El permiso manda sobre la comodidad. Si un usuario no puede leer un expediente en la aplicación, tampoco debe verlo en resultados de búsqueda.
Qué se instala o configura primero
La pila conservadora empieza con PostgreSQL 17, tsvector, índice GIN, una tabla de búsquedas auditadas y un reporte de consultas lentas. El primer entregable es una consulta repetible sobre 10.000 registros con tiempo medido, filtro por rol y restauración de base. Si esa prueba queda por debajo del umbral acordado, OpenSearch puede esperar. La pila con OpenSearch suma un nodo chico, almacenamiento separado, snapshots, API key de escritura, API key de lectura, job de indexación y un tablero de diferencias entre registros e índice. La página de versión history muestra mantenimiento activo del proyecto; la página de índices marca el método de carga por Index API o bulk. El costo cambia por memoria y operación. Un PostgreSQL ya existente puede sumar búsqueda por horas de configuración. Un OpenSearch autoadministrado agrega servidor, almacenamiento, snapshots y guardia de alertas. Para un piloto chico, el rango puede ir de USD 50 a USD 140 mensuales, entre ARS 75.000 y ARS 210.000 al dólar oficial de venta de ARS 1.500. La referencia de AWS OpenSearch pricing sirve para comparar gestión administrada, no para fijar el costo de un servidor local. UMSA suele entrar después de la prueba de consulta, cuando el equipo necesita decidir si indexa solo título y resumen o también adjuntos, observaciones y metadatos. Esa decisión define permisos, volumen y restauración.
Dónde se rompe y cómo probarlo
El primer riesgo aparece por datos duplicados. La señal es un contrato actualizado en PostgreSQL que sigue viejo en OpenSearch. La prueba es cambiar un campo, medir demora de indexación y bloquear el resultado si la versión del documento no coincide. El segundo riesgo aparece por permisos copiados de manera incompleta. La señal es un resultado visible para un usuario sin acceso al registro. La prueba es crear dos roles, buscar el mismo término y comparar cantidad de resultados con la aplicación. El tercer riesgo aparece en snapshots que recuperan índice sin fuente. La señal es un OpenSearch restaurado que muestra documentos cuyo registro transaccional ya no existe. La prueba es restaurar PostgreSQL y OpenSearch en entorno limpio, ejecutar recuentos y abrir diez resultados al azar. El cuarto riesgo aparece por memoria insuficiente. La señal es latencia alta durante indexación bulk o consultas con agregaciones. La prueba es cargar un lote de documentos, registrar uso de heap, tiempo de respuesta y errores. La decisión queda clara cuando el equipo escribe una frase simple: qué se busca, quién puede verlo, dónde vive el dato real y cómo se reconstruye si el índice se pierde.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.