Meilisearch 1.45 frente a PostgreSQL: búsqueda y límite
Cuándo sumar Meilisearch a una aplicación con PostgreSQL: índice, permisos, sincronización, backup y una prueba mínima para detectar filtraciones.
Un índice de búsqueda sirve cuando la consulta pide tolerar errores, ordenar relevancia y responder en milisegundos. Una escuela técnica agrotécnica puede tener PostgreSQL para legajos, cuotas y talleres, y aun así sufrir cuando alguien busca “tractor beca 2024” en un campo de texto. Meilisearch 1.45.1 entra como índice separado; esta guía explica cuándo usarlo, qué dato copia y cómo probar permisos.
Dónde aparece el límite de la búsqueda SQL
PostgreSQL sigue siendo una base excelente para transacciones. Stack Overflow 2024 lo midió con 48,7% de uso entre desarrolladores y lo puso primero entre bases por segundo año. Esa cifra corrige una costumbre local: muchas pymes intentan resolver búsqueda difusa, ranking y filtros de usuario dentro de la misma consulta que cobra, factura o cambia estados.
Meilisearch publicó la versión 1.45.1 el 28 de mayo de 2026. La fecha importa menos que la división de responsabilidades. PostgreSQL guarda el dato válido y auditable; Meilisearch guarda una copia preparada para buscar rápido. Si el índice cae, la aplicación pierde comodidad de búsqueda, pero conserva la operación principal.
La búsqueda deja de ser cómoda cuando el usuario escribe mal y espera encontrar igual.
El antagonista tiene nombre simple: el reporte único. Arranca con una consulta SQL razonable, después suma acentos, sinónimos, filtros por sede, permisos por rol y orden por relevancia. En pocos meses, ventas, administración y soporte discuten por la misma consulta.
La comparación práctica queda clara en una búsqueda de mesa de ayuda. PostgreSQL responde bien cuando el filtro pide estado, fecha o responsable exacto. Meilisearch gana cuando el usuario recuerda media palabra, cambia una tilde o mezcla producto con apellido. El diseño sano acepta esa diferencia y deja escrito qué campos viajan al índice y cuáles quedan solo en la base principal.
Cómo funciona por dentro
El flujo empieza en PostgreSQL. La aplicación guarda productos, legajos, expedientes o tickets con identificador, estado, sede, dueño y fecha de última edición. Un worker lee cambios confirmados y arma documentos de búsqueda con solo los campos permitidos: título, resumen, etiquetas, estado y un identificador externo.
Meilisearch recibe esos documentos y crea el índice. Los atributos filtrables separan sede, rol, estado y dueño; la aplicación manda cada búsqueda con filtros que nacen del usuario autenticado. El navegador nunca recibe un índice completo. Recibe una lista acotada de resultados y luego pide el registro completo a la API principal.
La seguridad se parte en dos capas. La API decide quién puede leer, editar o borrar en PostgreSQL. Meilisearch acelera la selección, pero no autoriza cambios. Si se usan tenant tokens, cada token incluye filtros obligatorios por organización o sede. Si la empresa usa Keycloak, la API traduce grupos en filtros y registra la consulta.
El backup también se separa. PostgreSQL necesita copia consistente y prueba de restauración. Meilisearch puede reconstruirse desde la base, aunque sus dumps y snapshots reducen tiempo de vuelta. La prueba mínima borra el índice, lo reconstruye y compara diez resultados esperados.
Qué se instala o configura primero
La pila mínima usa PostgreSQL 17 o 18, Meilisearch 1.45, un worker de sincronización, logs de cambios y monitoreo de cola. En un VPS de 2 vCPU, 4 GB de RAM y 40 GB de disco, el costo mensual ronda USD 18 a 35, entre ARS 25.740 y ARS 50.050 al dólar vendedor de ARS 1.430. El cálculo no incluye horas de desarrollo ni limpieza de datos viejos.
El primer entregable verificable es una búsqueda con dos usuarios. El usuario de administración ve legajos activos y bajas. El usuario de taller ve máquinas, prácticas y tickets propios. UMSA suele pedir una captura de ambos resultados con el mismo término, porque la filtración más común no está en el índice: está en olvidar un filtro antes de consultar.
La configuración inicial define clave primaria, atributos filtrables, campos mostrados y frecuencia de sincronización. Después se agregan sinónimos y tolerancia de errores. La API debe guardar cada reindexado con fecha, cantidad de documentos y duración, para que soporte sepa si el índice quedó viejo.
Dónde se rompe y cómo probarlo
El primer riesgo es un índice atrasado. La señal aparece cuando PostgreSQL muestra un estado y Meilisearch devuelve otro. La prueba crea un registro, cambia su estado, espera el worker y compara la respuesta de búsqueda contra la API principal.
El segundo riesgo es una filtración por permisos. La señal es un resultado visible con identificador correcto, pero dueño ajeno. La prueba usa dos usuarios reales y el mismo término; cada usuario debe recibir listas distintas y el log debe mostrar qué filtro aplicó la API.
El tercer riesgo es tratar el índice como base de verdad. La señal aparece cuando soporte corrige datos desde el índice o exporta resultados sin validar contra PostgreSQL. La prueba borra Meilisearch, reconstruye desde cero y verifica que la aplicación siga cobrando, cargando y editando.
El límite sano queda escrito: PostgreSQL decide y Meilisearch encuentra.