Bases de datos

PostgreSQL Full-Text Search vs Elasticsearch: cuándo la búsqueda integrada es suficiente en 2026

Ruslan Ismailov Publicado 12 min de lectura
P

Introducción: por qué la elección de la herramienta de búsqueda importa en 2026

La búsqueda de texto completo es una de esas tareas donde los desarrolladores tradicionalmente recurren a la herramienta "correcta": Elasticsearch o su fork OpenSearch. Pero en 2026, PostgreSQL FTS ha madurado considerablemente, y el coste de mantener un clúster de búsqueda independiente se ha vuelto más notable. La pregunta "¿realmente necesitamos Elasticsearch?" suena cada vez más frecuente en las revisiones de arquitectura.

Este artículo está dirigido a desarrolladores backend en Go y PHP/Laravel, así como a arquitectos que diseñan funcionalidades de búsqueda. Analizaremos cómo funciona el FTS integrado en PostgreSQL, en qué casos rinde bien y dónde sus capacidades se quedan cortas objetivamente, y cómo tomar una decisión fundamentada sin dejarse llevar por las herramientas de moda.

Cómo funciona Full-Text Search en PostgreSQL: tsvector, tsquery, GIN y GiST

PostgreSQL implementa la búsqueda de texto completo a través de dos tipos de datos clave y un conjunto de funciones sobre ellos.

tsvector y tsquery

tsvector es una representación normalizada del documento: una lista de lexemas con posiciones y pesos. tsquery es una consulta de búsqueda con operadores booleanos (&, |, !) y soporte para búsqueda de frases.

-- Conversión de texto a tsvector
SELECT to_tsvector('spanish', 'El veloz zorro marrón salta sobre el perro perezoso');
-- Resultado: 'veloz':2 'zorro':3 'marron':4 'salt':5 'perr':8 'perez':9

-- Búsqueda simple
SELECT to_tsvector('spanish', 'El veloz zorro marrón') @@ to_tsquery('spanish', 'zorro');
-- t

-- Búsqueda de frase
SELECT to_tsvector('spanish', 'PostgreSQL es una base de datos potente') @@ phraseto_tsquery('spanish', 'base de datos');
-- t

Índices GIN y GiST

Para acelerar el FTS, PostgreSQL ofrece dos tipos de índices:

  • GIN (Generalized Inverted Index) — índice invertido, similar al de Elasticsearch. Más rápido en búsqueda, más lento en actualización. Óptimo para datos estáticos o que cambian con poca frecuencia.

  • GiST (Generalized Search Tree) — más compacto, se actualiza más rápido, pero es más lento en lectura. Adecuado para tablas que se actualizan con frecuencia.

-- Agregar columna calculada e índice GIN
ALTER TABLE articles ADD COLUMN search_vector tsvector
  GENERATED ALWAYS AS (
    to_tsvector('spanish', coalesce(title, '') || ' ' || coalesce(body, ''))
  ) STORED;

CREATE INDEX idx_articles_search ON articles USING GIN(search_vector);

-- Ahora la búsqueda utiliza el índice
EXPLAIN ANALYZE
SELECT id, title FROM articles
WHERE search_vector @@ to_tsquery('spanish', 'PostgreSQL & índice');

Desde PostgreSQL 15+, el optimizador aprendió a usar mejor los índices GIN en combinación con otros predicados, lo que redujo la necesidad de hints manuales.

Ejemplos prácticos de FTS: clasificación, resaltado, idioma español

Clasificación de resultados

La función ts_rank calcula la relevancia basándose en la frecuencia de los lexemas y sus posiciones. ts_rank_cd tiene en cuenta la "cobertura" del documento por la consulta.

SELECT
  id,
  title,
  ts_rank(search_vector, query) AS rank
FROM
  articles,
  to_tsquery('spanish', 'búsqueda & PostgreSQL') query
WHERE
  search_vector @@ query
ORDER BY rank DESC
LIMIT 20;

Resaltado de fragmentos encontrados

SELECT
  title,
  ts_headline(
    'spanish',
    body,
    to_tsquery('spanish', 'búsqueda & texto'),
    'MaxWords=50, MinWords=20, StartSel=<mark>, StopSel=</mark>'
  ) AS snippet
FROM articles
WHERE search_vector @@ to_tsquery('spanish', 'búsqueda & texto');

Búsqueda en español

Para un funcionamiento correcto con el español, se utiliza la configuración spanish, que viene incluida con PostgreSQL y usa diccionarios Snowball para el stemming. Sin embargo, para un análisis morfológico más preciso, se recomienda añadir la extensión ispell con diccionarios en español:

-- Verificar configuraciones disponibles
SELECT cfgname FROM pg_ts_config;

-- Analizar la tokenización para texto en español
SELECT * FROM ts_debug('spanish', 'los desarrolladores utilizan PostgreSQL');

-- Búsqueda con análisis morfológico
SELECT title FROM articles
WHERE search_vector @@ to_tsquery('spanish', 'desarrollador');
-- Encontrará: «desarrolladores», «desarrolladora», «desarrolladores»

Limitación: el stemmer Snowball para español maneja peor los verbos irregulares y los homónimos en comparación con soluciones comerciales. Para e-commerce con un catálogo extenso, esto puede ser crítico.

Capacidades y limitaciones de PostgreSQL FTS

Qué puede hacer PostgreSQL FTS

  • Búsqueda con lógica booleana y frases

  • Clasificación por fórmula similar a tf-idf

  • Resaltado de fragmentos (ts_headline)

  • Búsqueda con errores tipográficos mediante pg_trgm (índice de trigramas)

  • Configuraciones multilingüe

  • Categorías de peso (A, B, C, D) para distintos campos

-- Búsqueda con coincidencia aproximada mediante pg_trgm
CREATE EXTENSION pg_trgm;
CREATE INDEX idx_articles_trgm ON articles USING GIN(title gin_trgm_ops);

SELECT title, similarity(title, 'postgrss') AS sim
FROM articles
WHERE title % 'postgrss'
ORDER BY sim DESC;

Limitaciones

  • Sin soporte nativo para sinónimos y tesauro "de fábrica" (requiere configuración manual de diccionarios)

  • Sin búsqueda facetada ni agregaciones al estilo de Elasticsearch

  • Sin búsqueda distribuida — el escalado es solo vertical o mediante particionamiento

  • Sin autocompletado integrado (suggest/autocomplete)

  • La indexación de tablas grandes bloquea recursos (se resuelve con CREATE INDEX CONCURRENTLY)

Cuándo PostgreSQL FTS es suficiente: criterios de decisión

Usa PostgreSQL FTS como herramienta principal de búsqueda si se cumplen las siguientes condiciones:

  1. Volumen de datos de hasta 10–50 millones de registros en la tabla de búsqueda. El índice GIN gestiona estos volúmenes con hardware correctamente configurado.

  2. Modelo de relevancia simple: clasificación por frecuencia y peso de campos sin aprendizaje automático.

  3. Búsqueda en documentos estructurados con campos claramente definidos (artículos, productos, usuarios).

  4. Sin requisitos de indexación en tiempo real con latencia inferior a 1 segundo.

  5. Sin navegación facetada (filtros por categorías con conteo de resultados).

  6. El equipo ya trabaja con PostgreSQL y no quiere añadir un nuevo componente operacional.

Por experiencia en proyectos reales: la búsqueda interna en una base de conocimiento corporativa, la búsqueda en un blog o portal de noticias, la búsqueda de usuarios en una aplicación SaaS — todos son excelentes candidatos para PostgreSQL FTS.

Cuándo es necesario Elasticsearch o alternativas

Elasticsearch se justifica cuando los requisitos superan las capacidades de PostgreSQL:

  • Búsqueda facetada multicampo con agregaciones: «encontrar productos en la categoría X, de precio Y a Z, con valoración superior a 4» — con contadores por cada filtro.

  • Cientos de millones de documentos con escalado horizontal mediante shards.

  • Búsqueda personalizada con Learning to Rank (LTR) y señales de usuario.

  • Búsqueda multilingüe con analizadores para más de 30 idiomas, incluidos los ideográficos.

  • Indexación near real-time: un nuevo documento está disponible para búsqueda en ~1 segundo.

  • Búsqueda en logs y métricas (Elastic Stack / ELK) — es su área de aplicación nativa.

  • Autocompletado y búsqueda por prefijo en grandes volúmenes con baja latencia.

Si tu proyecto es un marketplace con facetas, un gran e-commerce o búsqueda en logs de microservicios, Elasticsearch sigue siendo el estándar de facto.

Integración de PostgreSQL FTS con Go y Laravel

Go: pgx y sqlc

En Go, el driver más eficiente para PostgreSQL es pgx. Para consultas con seguridad de tipos, usa sqlc.

// Consulta mediante pgx pasando un parámetro tsquery
package search

import (
    "context"
    "github.com/jackc/pgx/v5/pgxpool"
)

type Article struct {
    ID    int
    Title string
    Rank  float32
}

func SearchArticles(ctx context.Context, db *pgxpool.Pool, query string) ([]Article, error) {
    sql := `
        SELECT
            id,
            title,
            ts_rank(search_vector, websearch_to_tsquery('spanish', $1)) AS rank
        FROM articles
        WHERE search_vector @@ websearch_to_tsquery('spanish', $1)
        ORDER BY rank DESC
        LIMIT 20
    `
    rows, err := db.Query(ctx, sql, query)
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var results []Article
    for rows.Next() {
        var a Article
        if err := rows.Scan(&a.ID, &a.Title, &a.Rank); err != nil {
            return nil, err
        }
        results = append(results, a)
    }
    return results, nil
}

La función websearch_to_tsquery (PostgreSQL 11+) convierte la entrada del usuario en un tsquery seguro sin riesgo de errores de sintaxis — ideal para cadenas de búsqueda en REST API.

Laravel: Scout y consultas nativas

En Laravel para PostgreSQL FTS existen dos enfoques. El primero — mediante el paquete laravel/scout con el driver teamtnt/laravel-scout-tntsearch-driver o un driver personalizado para Postgres. El segundo — consultas nativas con Eloquent.

<?php
// app/Models/Article.php
namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Builder;

class Article extends Model
{
    public function scopeSearch(Builder $query, string $term): Builder
    {
        return $query
            ->selectRaw("
                *,
                ts_rank(
                    search_vector,
                    websearch_to_tsquery('spanish', ?)
                ) AS rank
            ", [$term])
            ->whereRaw(
                "search_vector @@ websearch_to_tsquery('spanish', ?)",
                [$term]
            )
            ->orderByDesc('rank');
    }
}

// Uso en el controlador
$results = Article::search($request->input('q'))->paginate(20);

Para crear un trigger que actualice automáticamente search_vector, usa una migración de Laravel:

<?php
// En la migración
DB::unprepared("
    CREATE OR REPLACE FUNCTION update_article_search_vector() RETURNS trigger AS \$\$
    BEGIN
        NEW.search_vector :=
            setweight(to_tsvector('spanish', coalesce(NEW.title, '')), 'A') ||
            setweight(to_tsvector('spanish', coalesce(NEW.body, '')), 'B');
        RETURN NEW;
    END;
    \$\$ LANGUAGE plpgsql;

    CREATE TRIGGER articles_search_vector_update
    BEFORE INSERT OR UPDATE ON articles
    FOR EACH ROW EXECUTE FUNCTION update_article_search_vector();
");

Rendimiento: pruebas de carga e indexación

Benchmarks reales en una tabla de 5 millones de artículos (PostgreSQL 16, 32 GB RAM, NVMe SSD):

  • Búsqueda sin índice (seq scan): ~8–12 segundos por consulta — inaceptable.

  • Índice GIN, consulta simple: 5–20 ms en el percentil 95.

  • GIN + pg_trgm (búsqueda difusa): 20–80 ms en el percentil 95.

  • Elasticsearch 8.x, dataset equivalente: 3–10 ms en el percentil 95.

Una diferencia de 2–3 veces en latencia para consultas simples es real. Pero para la mayoría de las aplicaciones web, 20 ms frente a 5 ms no son críticos si la consulta no se ejecuta 10.000 veces por segundo.

Creación de índice en una tabla grande

-- CONCURRENTLY no bloquea la tabla para escritura
CREATE INDEX CONCURRENTLY idx_articles_search_gin
ON articles USING GIN(search_vector);

-- Configurar maintenance_work_mem acelera la creación del índice GIN
SET maintenance_work_mem = '1GB';
CREATE INDEX idx_articles_search_gin ON articles USING GIN(search_vector);

-- Analizar el tamaño del índice
SELECT
    indexname,
    pg_size_pretty(pg_relation_size(indexname::regclass)) AS index_size
FROM pg_indexes
WHERE tablename = 'articles';

Un índice GIN sobre 5 millones de filas ocupa aproximadamente 2–4 GB. Esto debe tenerse en cuenta al planificar el espacio en disco.

Enfoque híbrido: PostgreSQL FTS + Redis para caché

Incluso con buen rendimiento de PostgreSQL FTS, las consultas de búsqueda suelen repetirse. Cachear los resultados en Redis permite reducir la carga sobre la base de datos y mejorar el tiempo de respuesta hasta 1–2 ms.

// Go: caché de resultados de búsqueda en Redis
package search

import (
    "context"
    "encoding/json"
    "fmt"
    "time"

    "github.com/redis/go-redis/v9"
    "github.com/jackc/pgx/v5/pgxpool"
)

type SearchService struct {
    db    *pgxpool.Pool
    cache *redis.Client
}

func (s *SearchService) Search(ctx context.Context, query string, page int) ([]Article, error) {
    cacheKey := fmt.Sprintf("search:%s:page:%d", query, page)

    // Verificamos la caché de Redis
    cached, err := s.cache.Get(ctx, cacheKey).Bytes()
    if err == nil {
        var articles []Article
        if json.Unmarshal(cached, &articles) == nil {
            return articles, nil
        }
    }

    // Consulta a PostgreSQL
    articles, err := SearchArticles(ctx, s.db, query)
    if err != nil {
        return nil, err
    }

    // Cacheamos durante 5 minutos
    if data, err := json.Marshal(articles); err == nil {
        s.cache.Set(ctx, cacheKey, data, 5*time.Minute)
    }

    return articles, nil
}

Estrategia de invalidación de caché: invalida la caché al actualizar artículos mediante PostgreSQL NOTIFY o una cola de tareas. En Laravel esto se implementa cómodamente mediante un Observer y el evento saved.

Nota importante: cachea solo las consultas populares (top-N por frecuencia). Cachear consultas de long-tail no es recomendable — ocuparán memoria de Redis sin un beneficio real.

Conclusión: matriz de selección de herramienta de búsqueda

A continuación, una matriz práctica para tomar la decisión. Úsala como punto de partida, no como regla absoluta.

  • PostgreSQL FTS — excelente elección, si: volumen de hasta 20–50 millones de documentos, sin búsqueda facetada, el equipo domina PostgreSQL, presupuesto limitado, se necesita simplicidad de infraestructura.

  • PostgreSQL FTS + Redis — buena elección, si: aparece alta carga en consultas repetidas y se quiere reducir la latencia de respuesta sin cambiar el stack.

  • Elasticsearch/OpenSearch — necesario, si: búsqueda facetada, más de 100 millones de documentos, personalización, autocompletado en grandes volúmenes, búsqueda en logs.

  • Typesense / Meilisearch — considera como alternativa a Elasticsearch si necesitas un motor fácil de operar con buen UX desde el primer momento.

En 2026, PostgreSQL FTS es una solución madura y lista para producción para una amplia clase de tareas. No es necesario incorporar Elasticsearch en cada proyecto. Comienza con PostgreSQL, añade Redis para cachear las consultas más frecuentes, y obtendrás un stack capaz de atender a millones de usuarios sin carga operacional adicional. Migra a un motor de búsqueda especializado solo cuando te encuentres con limitaciones concretas — no antes.

Tecnologías

Etiquetas

Ruslan Ismailov

Desarrollador Senior Web / Backend. Desarrollador senior web/backend con 9 años de experiencia. Stack: PHP, Laravel, PostgreSQL, Redis, Docker, Kubernetes, REST, microservicios, CI/CD. Más sobre mí →