ParadeDB supera a PlanetScale TIN en búsqueda sobre Postgres

¿Qué pasó entre ParadeDB y PlanetScale?

ParadeDB afirma haber cerrado la brecha con TIN, la extensión de búsqueda full-text para Postgres que PlanetScale presentó a mediados de septiembre. El benchmark donde TIN presumía la mayor ventaja era el ranking por BM25 (el algoritmo estándar para ordenar resultados de búsqueda por relevancia), donde PlanetScale reportó al menos 8 veces de ventaja sobre ParadeDB 0.25.

ParadeDB es la extensión open source de búsqueda y analytics sobre Postgres que en julio de 2025 cerró una Serie A de US$12M liderada por Craft Ventures con participación de Y Combinator, según reportó TechCrunch. Entre sus clientes figuran Alibaba, Modern Treasury, Bilt Rewards y TCDI.

La respuesta de ParadeDB se publicó el 1 de octubre de 2026. En su propio dataset de 28,7 millones de filas de Hacker News, reportan ser ahora 2 veces más rápidos que TIN. Lo más interesante no es la velocidad con la que cerraron la brecha, sino cómo lo hicieron: dos optimizaciones algorítmicas en Tantivy, la librería open source de búsqueda en la que se basa ParadeDB, que no tocaron el esquema de identificadores de documento que PlanetScale criticaba.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Las dos optimizaciones que cerraron la brecha

La primera optimización ataca la localidad de los fieldnorms. En Tantivy, los fieldnorms (valores que codifican la longitud del campo indexado y que BM25 usa para normalizar el score) se almacenaban en un array global separado del postings list. Para una consulta típica sobre el dataset de Hacker News, ParadeDB tocaba alrededor de 1.500 páginas de Postgres solo para leer fieldnorms, equivalente al 83% de los accesos a página de la consulta. Tras mover los fieldnorms junto a cada postings list, en el mismo orden que los DocId, los accesos cayeron a 30 páginas. El costo: el índice creció aproximadamente un 9%, razonable para la mayoría de los casos.

La segunda optimización cambia el algoritmo de poda Blockmax. Tantivy usaba WAND, que salta más bloques pero gasta más CPU decidiendo qué saltar. ParadeDB implementó un camino con MAXSCORE, el algoritmo que Lucene introdujo en 2023 para ciertos tipos de query, con una heurística simple: MAXSCORE para disyunciones con al menos tres términos y postings densos, WAND para el resto. En una query de 10 términos, la latencia p50 cayó cerca de 6 veces y la p95 cerca de 8 veces.

El punto controversial: cuando "más rápido" no es lo que parece

ParadeDB señala dos anomalías en los benchmarks originales de PlanetScale que, según su análisis, favorecían a TIN sin pretenderlo. La primera es de sintaxis: las consultas de PlanetScale usaban el operador @@@ de ParadeDB sin calificar el campo, lo que hacía que ParadeDB buscara en dos columnas indexadas a la vez, mientras TIN buscaba solo en una. ParadeDB cambió a sus operadores nativos |||, &&& y ### para igualar las condiciones.

La segunda anomalía es más sustantiva. TIN incorpora una técnica llamada dense-term elision: en tiempo de consulta, salta el scoring de cualquier término que aparezca en más del 10% del corpus, umbral configurable vía dense_ratio. La lógica es razonable: las stopwords (los términos más frecuentes del corpus) tienen postings lists enormes pero un peso BM25 bajísimo. El problema, según ParadeDB, es de corrección.

Con elisión activada, ParadeDB midió que el 47,8% de las consultas devolvía al menos un resultado fuera del Top 10 calculado con BM25 exacto. El 6,4% devolvía resultados donde ninguno del Top 10 estaba en el ranking correcto. En disyunciones, la cifra sube al 88,2%. PlanetScale había generado las queries del benchmark sampleando ventanas consecutivas del corpus, lo que producía consultas irreales como is it o to a, exactamente el tipo de entrada donde la elisión desordena el ranking.

Para la comparación principal, ParadeDB configuró TIN con dense_ratio=2 (elisión desactivada) en ambos motores, de modo que ambos calcularan el BM25 exacto. La publicación también incluye los números con la configuración por defecto de TIN, donde TIN gana, para que el lector pueda comparar.

ctid vs DocId: la decisión arquitectónica detrás del debate

PlanetScale sostuvo en su lanzamiento que usar ctid (el puntero físico que Postgres usa para identificar una fila) como identificador de documento era la clave de su rendimiento. ParadeDB responde que cerró la brecha sin tocar este punto.

Un ctid apunta a una posición física en el almacenamiento por bloques de Postgres: (página 190, slot 17). ParadeDB argumenta que estos identificadores de 48 bits, producto de concatenar dos dominios distintos, no comprimen tan bien como enteros densos y únicos como los DocId u32 de Tantivy. Y rompen una propiedad importante: la conexión directa con almacenamiento columnar. Para queries como ordenar por precio o facetar por categoría, los DocId densos permiten saltar directo a la columna. Con ctid haría falta un mapeo extra.

En otras palabras: TIN optimiza BM25 y conteo muy bien, pero para el resto de búsqueda (filtros, facetas, joins sobre columnas) ParadeDB considera que su esquema es más sostenible.

Postgres como terreno de batalla: tres anuncios en dos semanas

La pelea ParadeDB-PlanetScale no ocurre en el vacío. El 21 de septiembre de 2026, Tiger Data anunció que su extensión open source pg_textsearch ya estaba disponible de forma nativa en AlloyDB y Cloud SQL de Google Cloud, con soporte para Postgres 17 y 18. El 28 de septiembre de 2026, Databricks presentó Lakebase Search, con dos extensiones (lakebase_vector y lakebase_text) que llevan BM25 y búsqueda vectorial dentro de su Postgres serverless en AWS y Azure. La empresa reportó un cliente, Conexiom, que logró 5 veces más throughput y un tercio del costo de infraestructura frente a su setup anterior con pgvector.

En apenas diez días, Postgres pasó de ser una base de datos a la que le falta buena búsqueda a tener al menos cuatro ofertas serias de búsqueda full-text nativa, BM25 e híbrida. La categoría se está consolidando, y la presión competitiva es lo que está forzando a los actores a iterar rápido.

¿Qué significa esto para tu startup?

Si ya usas Elasticsearch u OpenSearch con Postgres, este es el momento de reevaluar. La promesa de mantener búsqueda y datos primarios en la misma base ya tiene varios contendientes creíbles. Migrar sigue siendo trabajo serio, pero la decisión de no migrar también debería revisarse ahora que hay oferta real.
Si evalúas PlanetScale TIN, no confíes en un solo número de benchmark. Los resultados cambian mucho según la configuración de dense_ratio y según si tus consultas son realistas o no. Pide al vendor un benchmark con tus queries reales antes de comprometerte.
Si construyes sobre ParadeDB, la versión 0.26 trae mejoras sustanciales sin breaking changes, aunque requiere reindexar para heredar todas las optimizaciones. La release candidate 0.26.0-rc.2 ya está disponible y la stable está prevista para la semana del 6 de octubre de 2026.

Conclusión

La respuesta de ParadeDB a TIN es infrecuente en infraestructura: una empresa que, en lugar de defender su benchmark, loauditó, lo reprodujo y mostró exactamente dónde estaban las diferencias. El resultado, Tantivy actualizado, optimizaciones ya en upstream y una RC pública reproducible, beneficia a todo el ecosistema de búsqueda sobre Postgres. Para los founders, la lectura práctica es que el espacio de búsqueda nativa en Postgres se está moviendo con una intensidad inusual, y conviene mirar de cerca antes de tomar decisiones de arquitectura que comprometan los próximos dos o tres años.