Caso de éxito · Plataforma de analítica confidencial, Norteamérica
Cómo UnlockLive usó tablas UNLOGGED de PostgreSQL, ingesta COPY por lotes y un patrón disciplinado de dos tablas para llevar un pipeline de analítica de alto volumen de 8K a 80K eventos/seg — sin perder las garantías de integridad de datos que exigía la ruta auditada.
Una plataforma de analítica ingería eventos de producto de una base de clientes en crecimiento en una única tabla "raw_events". El esquema original era correcto pero lento: cada evento llegaba a una tabla con registro y siete índices, el WAL era el cuello de botella y el rendimiento de ingesta se había estancado en unos 8,000 eventos por segundo. Las IOPS de RDS eran la partida de costo dominante, y una expansión prevista de clientes de 3 veces iba a romper el pipeline antes de firmar el siguiente contrato.
El equipo había leído los consejos habituales — "use una cola", "fragmente la tabla", "pase a una TSDB dedicada" — pero todas esas respuestas implicaban una migración de varios trimestres. La verdadera pregunta era: ¿puede PostgreSQL seguir el ritmo si dejamos de pelear con él? La dificultad era un requisito estricto: todo lo que llegara a las tablas de informes auditados debía ser duradero, consistente e indexado. No podíamos sacrificar la integridad en el lado de analítica para salvar el lado de ingesta.
Dividimos el pipeline en dos etapas claramente separadas con dos contratos de durabilidad distintos.
Etapa 1 (ingesta): una tabla de staging UNLOGGED que recibe el torrente de datos. Las tablas UNLOGGED de PostgreSQL omiten las escrituras WAL en las inserciones, lo cual es justo la compensación adecuada para datos de staging de corta vida — obtenemos de 5 a 10 veces más rendimiento de inserción bruta a cambio de perder las filas en staging si el servidor se cae. Combinado con COPY por lotes (no INSERT) desde un servicio de ingesta en Python y una regla deliberada de "sin índices en la tabla de staging", la ingesta bruta pasó de 8K a más de 80K eventos/seg en la misma instancia RDS.
Etapa 2 (duradera): un worker de Celery vacía la tabla de staging en microlotes hacia la tabla real `events`, con registro completo e índices, dentro de una única transacción con upserts idempotentes. La ruta de informes auditados solo lee de la tabla duradera. Si el servidor se cae durante la ingesta, perdemos como máximo unos segundos de eventos en tránsito de la tabla de staging — y los productores originales reintentan, de modo que la tabla duradera converge de nuevo a lo correcto.
Lo complementamos con una capa operativa pequeña pero cuidadosa: un panel de Grafana para la tasa de llenado de la etapa 1, una alerta crítica si el drenador se retrasa, rotación de particiones en la tabla duradera y un runbook escrito para los tres modos de fallo que importan.
Antes de tocar el esquema dedicamos una semana a pg_stat_statements, RDS Performance Insights y un rastreador personalizado del throughput de WAL. Los datos fueron inequívocos: las escrituras de WAL y el mantenimiento de índices en la única tabla de eventos voluminosa representaban el 78 % del tiempo de escritura. El problema no eran la CPU ni la memoria, sino la durabilidad.
Redactamos un breve documento de diseño que definía exactamente qué nos aportaba UNLOGGED, qué nos costaba y qué garantías debían ofrecer los productores upstream (entrega al menos una vez, ID de evento idempotentes). El contrato hizo explícito el perfil de pérdida para que el equipo de auditoría pudiera aprobarlo de antemano: "puede perder hasta N segundos de eventos en staging en una conmutación por error de RDS; la tabla durable no se ve afectada."
Reemplazamos las inserciones fila a fila por un servicio de ingesta en Python que almacena eventos en memoria hasta 250 ms y los vuelca mediante PostgreSQL COPY a la tabla de staging UNLOGGED. Un drainer de Celery traslada micro-lotes de 5000 filas a la tabla durable dentro de una única transacción con ON CONFLICT DO NOTHING para la idempotencia.
Añadimos particionado mensual a la tabla durable (para que el vacuum y la reconstrucción de índices sigan siendo baratos), paneles de Grafana para el retraso de extremo a extremo, alertas sobre el llenado de staging y el retraso del drainer, y un runbook escrito que cubre los tres modos de fallo reales: caída del drainer, conmutación por error de RDS y contrapresión del productor. Lo entregamos al equipo de guardia del cliente con acompañamiento.
“Esperábamos dedicar un trimestre a migrar a una base de datos de series temporales dedicada. En cambio, UnlockLive nos mostró cómo hacer que Postgres cumpla esa función, y nuestros auditores aprobaron el nuevo diseño antes de lanzarlo.”
Sí, para el trabajo adecuado. Las tablas UNLOGGED omiten las escrituras en el WAL, lo que ofrece un rendimiento de inserción bruto de 5 a 10 veces mayor a cambio de un perfil de pérdida documentado: las filas se descartan ante una caída del servidor y no se replican. Son ideales para datos de staging de corta vida cuando un sistema aguas arriba puede reproducir los eventos. Son pésimas para cualquier cosa que necesite releer de forma fiable. Siempre las combinamos con una tabla duradera y con registro de la que realmente lee la ruta auditada.
Porque el costo de migración y la superficie operativa son reales. Si su equipo ya opera bien PostgreSQL y su objetivo de rendimiento es de decenas de miles de eventos por segundo, el patrón UNLOGGED + COPY por lotes suele llevarle allí en semanas en lugar de trimestres. Recomendamos una TSDB dedicada cuando la carga de trabajo realmente necesita almacenamiento columnar, índices particionados por tiempo o consultas de rango en milisegundos a escala.
Puede, pero casi no debería. El objetivo de la capa de staging es la velocidad de inserción bruta; cada índice que agrega cuesta rendimiento de ingesta. Mantenemos la tabla de staging sin índices y ponemos todos los índices en la tabla duradera aguas abajo sobre la que realmente se ejecutan las consultas analíticas.
Dos reglas. Primero, los productores aguas arriba deben ofrecer entrega al menos una vez con IDs de evento idempotentes para que los reintentos sean seguros. Segundo, el lado duradero del pipeline solo lee de la tabla aguas abajo con registro completo, nunca de la tabla de staging UNLOGGED. El peor caso se reduce a unos segundos de eventos de staging reproducibles ante una caída, nunca a un reporte perdido.
Depende del tamaño de las filas, la red y la clase de instancia, pero en una modesta AWS RDS db.r6g.xlarge con este patrón exacto de dos tablas vemos de forma habitual entre 60 000 y 100 000 eventos por segundo sostenidos, con latencia de inserción de la etapa 1 en p95 por debajo de 50 ms. Más allá de eso, particionaríamos la tabla de staging o escalaríamos horizontalmente con un enrutador de escritura.
SaaS8x Reducción de la latencia p95 en endpoints críticos (de 1.8 s a 220 ms)Cómo rediseñamos la arquitectura de una API Python/FastAPI de alta demanda con una capa de caché Redis de varios niveles para reducir la latencia p95 de 1.8 s a 220 ms y la carga de PostgreSQL en un 70% en un SaaS B2B norteamericano.
Educación50K+ Llamadas diarias a la API de Canvas, con holgura dentro de la cuota de la universidadCómo UnlockLive reemplazó una frágil sincronización nocturna de Canvas LMS por una integración orientada a eventos en Python y FastAPI que gestiona más de 50K llamadas diarias a la API, sin incidentes de límite de tasa y con una ventana de sincronización un 90% menor — sin romper un solo sistema dependiente.
Educación80% Reducción de la carga administrativa del soporte docenteCómo UnlockLive construyó una plataforma de captura de clases totalmente automatizada que integra Canvas LMS y Panopto con Python y FastAPI — publicando automáticamente unas 3,000 clases por período, reduciendo la carga administrativa en un 80% y dotando a cada grabación de un rastro de auditoría verificable.
Hable con el mismo equipo que construyó Rendimiento de ingesta 10 veces mayor en un pipeline de analítica en PostgreSQL con tablas UNLOGGED. Definiremos el alcance de su proyecto, le daremos una propuesta a precio fijo y le mostraremos el caso más parecido de nuestro portafolio.
Reservar una llamada estratégicaUnlockLive IT Limited — sede en Toronto para atención al cliente y gestión de proyectos; centro de ingeniería dedicado en Dhaka, Bangladesh. Empresa registrada en el Reino Unido n.º 15563368 (UnlockLive IT Limited, Londres).
Copyright© UnlockLive .Todos los derechos reservados 2008 - 2026