🔓 Open Source
Adiós a Elasticsearch: TIN hace búsqueda de texto 25× más rápido en Postgres
Imagina que tu app necesita buscar texto en millones de registros, y en vez de montar Elasticsearch, usar algo que vive dentro de la misma base de datos. Eso es exactamente lo que acaba de lanzar PlanetScale, y los números de sus benchmarks son tan absurdos que hay que leerlos dos veces.
¿Qué es TIN y por qué tanto revuelo?
TIN es una extensión open source para PostgreSQL que agrega búsqueda full-text con ranking BM25 directamente en SQL, usando un operador nuevo: ==>. Nada de servicios externos, nada de sincronización de índices.
El post de anuncio explotó en Hacker News con más de 170 puntos y 70 comentarios en horas, porque ataca el problema de fondo: Postgres nunca fue bueno buscando texto, y Elasticsearch sigue siendo un dolor de cabeza operativo para equipos pequeños.
Los benchmarks que dejan en ridículo a la competencia
PlanetScale probó TIN contra ParadeDB, pg_textsearch y el GIN nativo de Postgres 18.6, sobre un corpus de 85 GB con 150 millones de documentos de Stack Exchange. Los resultados son brutales:
- 25× más consultas por segundo que ParadeDB en queries mixtas, con latencias p99 26× menores.
- 541× más rápido que el GIN de Postgres en queries de conjunción y frase.
- 10,260 QPS contando documentos en Wikipedia desde memoria… con latencia p99 de 2 ms.
Y lo más impresionante no es la velocidad en lecturas puras: es que TIN aguanta 1000 updates por segundo mientras sigue buscando. ParadeDB se hunde y pg_textsearch prácticamente se congela (735 updates en 10 minutos contra 270,000 de TIN).
¿Cómo logra ser tan rápido?
La clave es una decisión de diseño radical: en vez de usar identificadores de documento secuenciales como casi todos los índices de texto, TIN usa directamente el ctid de Postgres, la ubicación física de cada fila.
Eso le permite comprimir las listas de postings en bitmaps por página que caben en los registros vectoriales AVX2 y AVX-512 del CPU. Las consultas de conjunción y disyunción se vuelven simples instrucciones AND y OR sobre registros vectoriales. Y como las intersecciones se hacen con operaciones nativas del procesador, los loops y branches desaparecen.
Además, como usa ctids, cuando Postgres necesita leer las filas coincidentes las lee en orden físico del heap, que en discos NVMe es muchísimo más rápido que el acceso aleatorio. Optimizaciones gratis que otros índices ni siquiera intentan.
¿Por qué esto importa en LATAM?
En la región, la mayoría de los equipos corren Postgres en un solo servidor o un VPS, y montar Elasticsearch significa pagar otra máquina, otro operador, y lidiar con memoria y clusterización que nadie tiene tiempo de mantener.
Que la búsqueda de texto viva dentro de la base que ya usas reduce costos de infraestructura a la mitad en muchos proyectos. Para un SaaS latino que factura miles de dólares, no millones, esa diferencia es la que separa el proyecto vivo del proyecto muerto.
Y no es solo para startups: cualquier app con buscador de productos, documentación, correos o comentarios puede migrar a TIN sin reescribir la lógica de negocio.
¿Está lista para producción?
TIN v1.0.2 ya maneja insertar, actualizar y borrar documentos con corrección MVCC, integra con VACUUM y fusiona segmentos en segundo plano con muy poca amplificación de escritura. Los autores dicen que es el primer índice de texto que resuelve el problema de renumeración de segmentos al mergear.
¿Mi opinión? El ecosistema de Postgres le está ganando la guerra a las bases de datos especializadas. Primero JSON, luego vector search, y ahora full-text search. La frontera de "para eso necesitas otra base" se sigue encogiendo.
¿Te cambiarías de Elasticsearch a un full-text search dentro de Postgres, o prefieres el buscador dedicado? Comparte esto con algún dev que todavía esté peleando con un cluster de Elasticsearch.