Typesense 30 en pymes: búsqueda, filtros y API keys
Typesense permite sumar búsqueda rápida sin convertir el índice en base principal. Flujo, colecciones, filtros, API keys, costos y pruebas.
¿Qué devuelve la búsqueda cuando un cliente escribe media palabra, se equivoca en una tilde o recuerda solo el número de serie? PostgreSQL puede seguir guardando el dato válido, mientras Typesense atiende consultas rápidas sobre una copia controlada. La decisión técnica no pasa por cambiar la base principal: pasa por definir qué campos viajan al índice, con qué filtros y con qué prueba de reconstrucción.
Dónde aparece el límite de búsqueda
La presión aparece cuando el usuario no busca por una clave exacta. Un colegio técnico agrotécnico puede tener legajos, cuotas, talleres, herramientas y prácticas en una aplicación con PostgreSQL. El filtro por DNI o estado responde bien. La búsqueda por "tractor beca 2024", con errores de escritura y palabras mezcladas, empieza a pedir otra pieza. Typesense publicó la versión 30.2 el 19 de abril de 2026. Su documentación lo presenta como un servidor de búsqueda rápido y tolerante a errores tipográficos. Esa definición sirve para una pyme porque separa dos trabajos: la base transaccional decide y el buscador encuentra. La guía oficial de Typesense organiza el uso alrededor de colecciones, documentos y consultas. Una colección define campos y tipos. Un documento guarda la copia qué se quiere buscar. La consulta usa texto, filtros y orden. El punto crítico está en no mandar al índice datos que el usuario nunca debería ver. La encuesta Stack Overflow 2025 muestra que SQL fue usado por 58,6 % de los encuestados y PostgreSQL por 55,6 % entre bases de datos. La búsqueda especializada no reemplaza esa base; la acompaña cuando el texto libre se vuelve parte de la operación diaria.
Cómo funciona por dentro
El flujo tiene seis pasos. La aplicación guarda alumnos, clientes, activos o tickets en PostgreSQL. Cada alta o cambio genera un evento interno. Un worker toma el registro permitido, arma un documento acotado y lo envía a Typesense. El buscador indexa campos públicos, campos filtrables y campos de orden. La interfaz consulta Typesense con filtros derivados del usuario autenticado. Luego pide a la API principal el detalle completo del resultado elegido. Las colecciones de Typesense definen qué campos existen y cuáles se pueden filtrar. Por ejemplo: nombre, código, sede, estado, categoría y fecha. La clave no es indexar todo, sino escribir el contrato de búsqueda. Si administración solo ve su sede, cada consulta lleva filtro de sede. Si soporte solo ve activos asignados, el filtro viaja con su rol. Las API keys separan permisos de administración, escritura y búsqueda. La clave de administración no va al navegador. La aplicación usa una clave de escritura en el backend y genera búsquedas con alcance limitado. Los logs guardan usuario, texto de búsqueda, filtros aplicados y cantidad de resultados. El índice se considera reconstruible. PostgreSQL conserva la verdad operativa y Typesense conserva una copia para encontrar. El backup principal sigue siendo base y archivos de la aplicación. El respaldo del índice reduce tiempo de vuelta, pero la prueba de salida exige borrarlo y reconstruirlo desde PostgreSQL sin perder permisos.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 17, Typesense 30, un worker de sincronización, cola de eventos, proxy HTTPS, métricas básicas y logs de búsqueda. El primer entregable verificable es una búsqueda de diez registros reales con filtros por rol y comparación contra la API principal. Con Banco Nación como referencia del 15 de junio de 2026, se tomó USD 1 vendedor a ARS 1.450. Un servidor de USD 18 a 40 mensuales queda entre ARS 26.100 y ARS 58.000. La puesta en marcha suele pedir 20 a 36 horas: elegir campos, limpiar textos, crear colección, armar worker, limitar claves, registrar consultas y probar reconstrucción. UMSA puede aplicar este patrón cuando una aplicación propia empieza a recibir reclamos por "no encuentro el dato" aunque el dato exista. El alcance inicial debe ser chico: una colección, dos roles, un índice reconstruible y un tablero con cola pendiente, errores de sincronización y tiempo de respuesta.
Dónde se rompe y cómo probarlo
El primer riesgo es un índice atrasado. La señal aparece cuando PostgreSQL muestra un estado nuevo y Typesense devuelve el anterior. La prueba crea un registro, cambia su estado, espera el worker y compara resultado de búsqueda contra la API principal. El segundo riesgo es una clave expuesta. La señal aparece cuando el navegador puede escribir documentos o listar colecciones. La prueba intenta usar la clave pública para crear un documento y debe recibir rechazo. El tercer riesgo es filtrar solo en pantalla. La señal aparece cuando el usuario cambia una consulta desde el navegador y ve datos de otra sede. La prueba captura la llamada HTTP y modifica filtros; la API debe recomponerlos desde sesión y rol, no confiar en el cliente. El cuarto riesgo es indexar datos sensibles. La señal aparece cuando una búsqueda devuelve DNI, deuda o comentario interno. La prueba revisa veinte documentos del índice y valida que solo tengan campos permitidos. El quinto riesgo es una reconstrucción lenta que nadie midió. La prueba borra la colección en ambiente aislado, la reconstruye desde la base y mide duración, cantidad de documentos y errores. La búsqueda sirve cuando se puede volver a crear sin discutir qué dato era verdadero.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.