Meilisearch frente a PostgreSQL FTS: permisos y salida
Guía para separar búsqueda rápida y dato canónico: índices, filtros, API keys, dumps, auditoría y prueba de restauración en pymes que atienden mostradores con permisos distintos.
Un índice de búsqueda acelera respuestas, pero también puede mostrar datos que la base ya corrigió. Meilisearch y PostgreSQL FTS resuelven búsquedas internas con decisiones distintas: copia especializada o consulta sobre el dato canónico. Para una pyme, la pregunta práctica es qué campo se indexa, quién lo puede leer y cómo se reconstruye. Esta guía compara permisos, costo y prueba de salida antes de cargar documentos reales. ## Dónde aparece la búsqueda que miente Meilisearch publicó v1.55.0 el 12 de octubre de 2026 con mejoras para reglas dinámicas de búsqueda y correcciones internas. La fecha sirve para recordar una regla simple: un buscador también se versiona, se respalda y se prueba antes de ponerlo delante de clientes, socios o empleados. El número que corrige la decisión viene de PostgreSQL: en Stack Overflow 2026, PostgreSQL figura con 57,9 % de uso entre quienes respondieron sobre bases de datos en el reporte de tecnología. El tesorero de una cámara empresaria en San Martín no necesita una moda; necesita una búsqueda que encuentre actas, socios y pagos sin exponer documentos de otra comisión. El antagonista es el buscador sin filtro de rol: devuelve rápido, mezcla todo y deja a soporte explicando por qué apareció un archivo cerrado. El detalle visible es mínimo: una etiqueta adhesiva en una caja de archivo dice "asamblea 2024", y el índice devuelve "acta 2023" porque nadie cargó fecha, categoría ni dueño. La búsqueda falló antes de tocar el servidor.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, el usuario carga acta, factura, trámite o nota en la aplicación interna. Segundo, PostgreSQL 17 guarda el registro canónico: título, texto, estado, responsable, permisos y auditoría. Tercero, la aplicación envía a Meilisearch solo los campos qué se pueden buscar. Cuarto, Meilisearch crea un índice con atributos de búsqueda y filtros. Quinto, la interfaz consulta el índice con una API key restringida por acción e índice. Sexto, el backup copia PostgreSQL, archivos y dumps del índice, y una restauración reconstruye la búsqueda desde la base. PostgreSQL FTS vive cerca del dato. La documentación de búsqueda de texto de PostgreSQL 17 describe documentos, consultas, configuraciones e índices. En una aplicación chica, esa cercanía simplifica permisos porque la consulta puede respetar las mismas tablas y roles que usa el sistema principal. Meilisearch vive como servicio especializado. La documentación de índices de Meilisearch explica que cada índice tiene documentos, settings, atributos filtrables, reglas de ranking y tareas. La documentación de filtros exige declarar atributos filtrables antes de usarlos en una consulta. Ese paso define el permiso real: sede, categoría, estado y responsable deben viajar al índice si después van a limitar resultados.
Qué se instala o configura primero
El primer entregable verificable es una búsqueda de 200 documentos de prueba: actas, socios, facturas y notas. Cada documento necesita id canónico, título, texto limpio, categoría, fecha, estado, dueño y permisos. La pila inicial usa PostgreSQL 17, Meilisearch 1.55.0, una aplicación web, cola de indexación, API keys de búsqueda, dump programado y copia externa. El costo mensual para un piloto chico ronda USD 35 a USD 80 para servidor, disco y copia externa. Con dólar oficial vendedor a ARS 1535, queda entre ARS 53.725 y ARS 122.800. El rango incluye infraestructura básica y deja afuera horas de limpieza documental, definición de permisos y carga histórica. UMSA puede entrar cuando la organización ya definió qué campos se buscan y qué campos quedan fuera. El primer tablero útil muestra documentos indexados, tareas fallidas, tiempo de respuesta, última sincronización y resultados bloqueados por permiso. La documentación de API keys de Meilisearch separa llave maestra y llaves de API. La llave de búsqueda solo debe consultar índices y expirar cuando cambia el sistema. La documentación de dumps permite exportar datos para migración o recuperación, pero la prueba de salida debe reconstruir el índice desde PostgreSQL para evitar dependencia de una copia vieja.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en filtros incompletos. La señal es que una búsqueda por socio devuelve documentos de otra sede. La prueba carga dos sedes, dos roles y veinte documentos, luego busca con cada usuario y compara resultados permitidos. El segundo riesgo vive en datos duplicados. La señal es un documento editado en PostgreSQL que sigue apareciendo con el texto anterior. La prueba cambia estado y título, espera la tarea de indexación y revisa que el resultado nuevo reemplace al anterior. El tercer riesgo aparece en llaves demasiado amplias. La señal es una API key de frontend con permisos de escritura. La prueba intenta crear, borrar y consultar desde el navegador; solo la búsqueda debe responder. El cuarto riesgo es restaurar la base y olvidar el índice. La señal es una aplicación sana con búsqueda vacía. La prueba restaura PostgreSQL, ejecuta reindexación, carga un dump si hace falta y mide los primeros diez resultados. La decisión queda escrita en una frase corta: el dato vive en PostgreSQL; el índice acelera, filtra y se puede borrar.
