Meilisearch frente a PostgreSQL 18: búsqueda y límite
Meilisearch v1.53.1 y PostgreSQL 18 muestran dos caminos para buscar datos. Cuándo usar índice separado, filtros, permisos, tareas y restauración sin exponer datos.
Un índice de búsqueda guarda palabras, filtros y tareas pendientes antes de mostrar resultados. Meilisearch publicó v1.53.1 el 13 de agosto de 2026 con una variable para limitar lectores simultáneos de la cola de tareas. PostgreSQL mantiene en la versión 18 su capítulo de búsqueda de texto completo. La decisión concreta es dónde conviene buscar.
Dónde aparece el buscador que tarda
El síntoma típico no está en la página bonita; aparece en un operador que escribe "válvula", "inscripción" o "expediente" y espera doce segundos. La consulta puede estar apoyada en ILIKE '%texto%', una vista pesada o filtros mezclados con permisos. Cuando eso pasa, el buscador compite con facturación, trámites o stock por la misma base. La búsqueda también tiene permisos. La encuesta 2025 de Stack Overflow ubica a SQL con 58,6% de uso entre todos los encuestados. Ese dato no obliga a usar PostgreSQL para todo; muestra por qué muchas pymes ya guardan su operación en tablas. Meilisearch entra cuando se necesita autocompletado rápido, tolerancia a errores de tipeo, ranking y filtros preparados para lectura. PostgreSQL sigue siendo el registro principal cuando cada cambio debe tener transacción, integridad y auditoría. El antagonista concreto es el catálogo que creció sin criterio de búsqueda. Al principio alcanza con ordenar por fecha. Después aparecen sinónimos, nombres mal escritos, filtros por rubro, estado, sucursal y permiso de lectura. La solución no nace de instalar otra herramienta; nace de decidir qué dato es registro y qué dato es índice reconstruible.
Cómo funciona por dentro
El flujo mínimo separa seis pasos. Primero, la aplicación escribe producto, expediente, socio o trámite en PostgreSQL. Segundo, un proceso de sincronización toma campos permitidos para búsqueda: nombre, descripción, etiquetas, estado público, fechas y claves de relación. Tercero, Meilisearch recibe documentos y crea una tarea asíncrona. Cuarto, la interfaz consulta el índice con texto y filtros. Quinto, la aplicación recibe identificadores ordenados. Sexto, el detalle final vuelve a leerse desde PostgreSQL para respetar permisos y estado vigente. La guía de inicio rápido muestra carga de documentos y búsqueda básica. La documentación de filtrado exige declarar atributos filtrables antes de usarlos. La página de API keys separa llave maestra y claves de acceso. Las operaciones asíncronas explican que muchas acciones quedan en cola como tareas. El cambio de v1.53.1 agrega una variable técnica: MEILI_EXPERIMENTAL_TASK_QUEUE_MAX_READERS=100. El release la describe como control del máximo de transacciones de lectura simultáneas en LMDB para la cola de tareas. Traducido a operación, la actualización puede importar si hay muchos procesos leyendo estado de indexación. No reemplaza medición; obliga a registrar tiempos de cola, errores y tamaño de índices antes de tocar producción.
Qué se instala o configura primero
En un proyecto UMSA, el primer entregable sería un mapa de búsqueda: tablas de origen, campos indexables, filtros, permisos, frecuencia de sincronización, tamaño del índice y forma de reconstrucción. Después se carga un piloto con 5.000 registros reales, errores de tipeo y filtros usados por usuarios. La prueba termina cuando una búsqueda devuelve IDs, el detalle respeta permisos y el índice se reconstruye desde PostgreSQL sin editar datos a mano. La pila mínima puede usar PostgreSQL 18, Meilisearch, un worker de sincronización, proxy con TLS, backup diario, monitoreo de cola y tablero de tiempos. Para una municipalidad chica, comercio con catálogo o empresa de servicios, servidor y monitoreo pueden ubicarse entre USD 40 y USD 85 mensuales, entre $61.200 y $130.050 al dólar oficial vendedor de $1530. La implementación inicial, con índice, filtros, claves, worker, tablero y restauración probada, puede ir de USD 1.400 a USD 2.400, entre $2.142.000 y $3.672.000. Ese rango no incluye limpieza histórica ni rediseño de permisos existentes.
Dónde se rompe y cómo probarlo
El primer riesgo es filtrar por un campo que no fue declarado. La señal aparece cuando el buscador devuelve resultados por texto, pero falla al pedir estado, rubro o sucursal. La prueba carga tres filtros reales y confirma que una búsqueda combinada devuelve el mismo conjunto que una consulta revisada en PostgreSQL. El segundo riesgo es exponer más de lo permitido. La señal aparece cuando un usuario sin rol ve títulos o descripciones que pertenecen a otra área. La prueba crea dos usuarios, indexa registros con distintas marcas de visibilidad y revisa que la interfaz consulte sólo lo autorizado. El índice puede ser rápido; el control de acceso sigue en la aplicación. El tercer riesgo es creer que el índice reemplaza al backup. La señal aparece cuando Meilisearch responde, pero PostgreSQL perdió el registro principal o el worker no sabe reconstruir. La prueba borra un índice de ensayo, lo crea de nuevo desde la base, mide tiempo y compara conteos. Si no se puede reconstruir, el índice dejó de ser descartable. La decisión final puede escribirse en una regla simple. PostgreSQL guarda la verdad transaccional, permisos y relaciones. Meilisearch atiende búsqueda de lectura con ranking, tolerancia y filtros preparados. El costo de mantener dos piezas se justifica cuando el usuario busca más rápido y el equipo puede explicar de dónde salió cada resultado.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.