Introducción: ¿Necesitas capacidades de búsqueda potentes en tu aplicación pero no quieres la complejidad de gestionar Elasticsearch o OpenSearch? No estás solo. Estas soluciones dedicadas son poderosas pero añaden sobrecarga operativa: clústeres adicionales, tuberías ETL, sincronización y latencias. ¿Y si pudieras disponer de un motor de búsqueda dentro de PostgreSQL? Eso es precisamente lo que ofrece pg_search. En este artículo explico qué es pg_search, por qué no funciona en Amazon RDS y cómo diseñamos una solución con EC2 que mantiene todo dentro de PostgreSQL mientras entrega funciones de búsqueda modernas.

Qué es pg_search: pg_search es una extensión para PostgreSQL desarrollada por ParadeDB que convierte la base de datos en un buscador completo. En lugar de búsquedas por subcadenas con LIKE o ILIKE, ofrece búsqueda de texto completo con ranking BM25, búsqueda vectorial para similitud semántica usando embeddings y búsquedas híbridas que combinan relevancia textual y similitud vectorial, todo mediante consultas SQL estándar. El resultado son respuestas ordenadas por relevancia, igual que un buscador real, no solo filas que contienen palabras clave.

Por qué pg_search y no la solución tradicional: Considera pg_search cuando las consultas básicas de Postgres no son suficientes. Las consultas con LIKE no entregan ranking por relevancia y escalar la búsqueda de texto a múltiples columnas se complica. Además evitarás infraestructura adicional como clusters de Elasticsearch, pipelines de ETL y la necesidad de mantener la consistencia entre dos sistemas, con la latencia extra que implica. Con pg_search todo queda en Postgres, aprovechando copias de seguridad, permisos, transacciones y herramientas que ya conoces.

El reto con RDS: Amazon RDS no permite instalar pg_search. RDS solo permite una lista preaprobada de extensiones porque AWS controla lo que se carga en el proceso de PostgreSQL. Intentar crear la extensión en RDS retornará un error indicando que la extensión no está disponible. La solución requiere controlar la instalación en una instancia PostgreSQL autogestionada.

Nuestra arquitectura: RDS primario más EC2 como réplica de búsqueda. Diseñamos una arquitectura híbrida que mantiene RDS como base de datos primaria para escrituras y transacciones, y desplegamos una instancia PostgreSQL en EC2 con pg_search instalada para las consultas de búsqueda y analítica. Los datos fluyen desde RDS hacia EC2 mediante replicación lógica. Las aplicaciones realizan escrituras y lecturas normales contra RDS y consultas de búsqueda contra EC2. Todo ocurre dentro de la VPC privada de AWS sin servicios externos.

Despliegue en EC2: pasos generales. 1 Provisionar EC2 en la misma VPC que RDS, preferiblemente en una subred privada, con almacenamiento adecuado (por ejemplo 100 GB gp3) y reglas de seguridad que permitan conexión al puerto 5432 desde RDS y acceso SSH administrativo. 2 Instalar PostgreSQL y compilar pg_search en la instancia EC2. Recomendamos usar contenedores Docker para reproducibilidad: base postgres 16, dependencias de compilación, toolchain Rust, cargo pgrx para compilar extensiones nativas, instalar pgvector si se desea búsqueda vectorial, clonar el repositorio de pg_search y compilarlo. 3 Configurar postgres con wal_level lógico, suficientes replication slots y max wal senders. 4 Habilitar las extensiones dentro de la base de datos de búsqueda: crear la base de datos app_db y ejecutar CREATE EXTENSION pg_search y CREATE EXTENSION vector si se usa vector search.

Índices de búsqueda: Una vez instalada la extensión puedes crear índices que permitan búsquedas eficientes. Por ejemplo un índice BM25 para búsqueda de texto completo sobre columnas de título y cuerpo y un índice IVFFLAT para embeddings vectoriales. Estos índices permiten consultas con ranking BM25 y búsquedas por similitud vectorial para escenarios semánticos, además de combinarlas en búsquedas híbridas.

Sincronización de datos desde RDS a EC2: La instalación de pg_search es solo la mitad de la solución. Necesitas replicación continua. Flujo típico: 1 Carga inicial mediante volcado desde RDS con pg_dump y restauración en EC2 con pg_restore. 2 Configurar RDS para replicación lógica ajustando parámetros como rds.logical_replication en el parameter group, aumentar replication slots y wal senders y aplicar reinicio si procede. 3 Crear un usuario de replicación en RDS con permisos mínimos necesarios para publicar los datos. 4 Crear una publication en RDS que incluya todas las tablas relevantes o un conjunto específico. 5 En EC2 crear una subscription apuntando a RDS, usando un slot de replicación lógico y configurando copy_data según se prefiera. 6 Verificar estado de la replicación consultando las vistas de pg_stat_subscription y probar con inserciones en RDS para comprobar que aparecen en EC2 en pocos segundos.

Mantenimiento y tablas nuevas: Si la publicación se creó con FOR ALL TABLES las nuevas tablas en el publicador quedarán incluidas, pero el subscriber necesita refrescar la publicación para incorporar la estructura o los datos iniciales. Puedes automatizar un refresh de la suscripción con una tarea cron que ejecute ALTER SUBSCRIPTION app_sub REFRESH PUBLICATION con periodicidad razonable para detectar nuevas tablas.

Ventajas y desventajas. Ventajas: búsqueda avanzada con BM25 y vector search sin salir del ecosistema Postgres; uso de SQL y herramientas conocidas; RDS como origen primario y respaldo administrativo; todo dentro de la VPC sin dependencias externas; flexibilidad para instalar extensiones adicionales en la réplica de búsqueda. Desafíos: añadir un nodo PostgreSQL autogestionado implica operaciones adicionales; la replicación lógica necesita diseño y monitorización; la réplica de búsqueda está ligeramente retrasada respecto al primario, normalmente unos segundos; la aplicación ha de gestionar dos endpoints de base de datos; coste adicional por la instancia EC2 y almacenamiento.

Por qué esta arquitectura puede ser la mejor opción: Para equipos que ya dominan PostgreSQL, añadir una réplica con pg_search ofrece la mayoría de capacidades de motores de búsqueda modernos sin la complejidad de mantener clusters de búsqueda y pipelines ETL. La relación coste beneficio suele ser favorable cuando se valora la simplicidad operativa y la integración con procesos existentes.

Cómo puede ayudar Q2BSTUDIO: En Q2BSTUDIO somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad y servicios cloud. Podemos diseñar e implementar la arquitectura descrita, desde el despliegue en AWS hasta la integración de embeddings y modelos de IA para búsquedas semánticas. Si necesitas migrar o crear una solución de búsqueda integrada con tus aplicaciones a medida podemos ayudarte a evaluar rendimiento, coste y seguridad. Ofrecemos además servicios de ciberseguridad y pentesting para asegurar la replica y las comunicaciones, y soluciones de inteligencia de negocio y power bi para explotar los resultados de búsqueda en cuadros de mando.

Si quieres una consultoría para llevar esto a producción solicita soporte en nuestros servicios cloud o para desarrollo de aplicaciones. Por ejemplo podemos acompañarte en el despliegue en AWS y Azure contratando nuestros servicios cloud en AWS y Azure y en la creación de experiencias de usuario avanzadas y escalables mediante aplicaciones a medida. También integramos capacidades de inteligencia artificial y agentes IA para enriquecer las búsquedas semánticas y conectar resultados con paneles de Business Intelligence y Power BI.

Recomendaciones prácticas antes de empezar: comienza con una prueba de concepto desplegando una réplica EC2 pequeña, replicando un subconjunto de tablas y validando latencia y rendimiento de búsqueda. Mide tiempos de sincronización y comportamiento del índice frente a cargas de actualización. Evalúa el coste total frente a alternativas como un motor externo y valora seguridad de red y backups. Si decides avanzar, automatiza la creación de índices y la monitorización de replicación, e incorpora pruebas de integridad de datos.

Conclusión: Implementar pg_search en una réplica PostgreSQL autogestionada en EC2 es una solución práctica para disponer de funciones de búsqueda avanzadas dentro del ecosistema Postgres sin añadir un stack de búsqueda independiente. La opción es especialmente adecuada para equipos que prefieren mantener operaciones y datos dentro de la VPC y aprovechar experiencia existente en PostgreSQL. En Q2BSTUDIO podemos acompañarte en todas las fases del proyecto, desde el diseño de la arquitectura hasta la puesta en producción, integrando además inteligencia artificial, servicios de ciberseguridad, automatización y soluciones de inteligencia de negocio para maximizar el valor de tus datos.

¿Tienes dudas sobre esta arquitectura o quieres que preparemos una prueba de concepto? Ponte en contacto con nosotros para estudiar tu caso y ofrecer una solución a medida que combine búsqueda avanzada, seguridad y escalabilidad.