Dashboards de cliente desde un solo Parquet en R2: sin base de datos

Por qué este experimento con un Parquet de 40 MB importa

Hamilton Ulmer, ingeniero en MotherDuck, publicó el 24 de agosto un prototipo demoledor: un dashboard de analytics drilldown —filtros por agencia, tipo de queja, canal, barrio y una serie de tiempo diaria— construido sin base de datos y sin motor de consultas. Sirvió los datos directamente desde un único archivo Parquet de 40 MB servido desde Cloudflare R2, leído en el navegador con Hyparquet, un lector de Parquet en JavaScript puro. Para Ulmer, la motivación era directa: un amigo suyo tenía datos de uso de cliente en Iceberg sobre R2 y quería mostrarle a sus propios clientes unas gráficas básicas con filtros, pero sin sumar otro vendor.

Para un founder SaaS la pregunta deja de ser técnica y se vuelve económica: si un archivo Parquet con un layout inteligente puede reemplazar un dashboard analítico entero, ¿cuánto de tu stack de analytics está sobrando?

Qué es Hyparquet y por qué encaja aquí

Hyparquet es una librería JavaScript open source del proyecto Hyperparam, descrita en su repositorio como un parser Parquet para JavaScript que corre en navegador y Node.js y minimiza los datos a traer usando HTTP range requests. Es decir: en lugar de descargarse el archivo entero, el cliente pide por rango solo los row groups que necesita. Soporta todos los tipos físicos, codificaciones y codecs de Parquet, y pesa alrededor de 10 KB minificado y comprimido según el blog del equipo, frente al motor WASM de DuckDB que arrastra varios megabytes.

👥 ¿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

El truco de Hyparquet es exactamente el que Ulmer explota: leer solo el footer del archivo una vez, obtener los rangos de bytes de cada row group y, sobre todo, las estadísticas min/max por columna, y a partir de ahí decidir qué rangos de bytes descargar para responder una consulta concreta. Pushdown de predicados sobre metadatos: si pides filtrar por NYPD, Hyparquet descarga solo los ~260 KB del row group que contiene la agencia, no el archivo entero.

El truco del archivo: data cubes con `GROUP BY GROUPING SETS`

El artículo no vive solo en el lector: vive en cómo Ulmer ordena el Parquet. La técnica es clásica de data warehousing, pero pocas veces aplicada con tan poca fanfarria:

Cada agrupamiento útil se precomputa y se guarda como un grouping set dentro del mismo archivo. Un grouping set de totales históricos alimenta los leaderboards; uno diario por cada combinación de filtros alimenta la serie de tiempo; uno semanal y uno anual reducen filas escaneadas al brushing del gráfico.
Cada grouping set se ordena por las columnas por las que se va a filtrar, lo que hace que las filas relevantes queden contiguas en el archivo y que los min/max del footer sirvan como índice efectivo.
El navegador agrega en cliente las filas leídas. Para agregaciones distributivas y algebraicas —sumas, cuentas, máximos, promedios— el patrón funciona; para las holistic (percentiles, medianas aproximadas exactas) Ulmer lo deja como ejercicio.

El pipeline, además, sale prácticamente gratis: según describe, un cube de ~10 MB por cliente es el resultado natural de una sola sentencia DuckDB GROUP BY GROUPING SETS. Toda la complejidad se desplaza a la izquierda, hacia el data pipeline, que es "donde va el dinero de verdad" cuando tienes una base de datos analítica real.

Lo que cuesta de verdad: R2 cobra escrituras, no lecturas

Aquí la jugada económica es lo que vuelve el experimento realista. Ulmer tira los números tal cual salen de la documentación oficial de Cloudflare R2 (vigente al 7 de agosto de 2026 según el portal de developers):

Storage Standard: US$0,015 / GB-mes.
Class A operations (escrituras como PutObject, CopyObject, multipart): US$4,50 por millón de requests.
Class B operations (lecturas como GetObject, HeadObject): US$0,36 por millón de requests.
Egress a Internet: gratis — sin cargos por transferencia de salida desde ningún storage class.

Con esas cifras, Ulmer proyecta el coste mensual para 10.000 clientes:

Storage: 10 MB × 10.000 = 100 GB, unos US$1,50/mes; con cubes de 40 MB serían 400 GB y unos US$6/mes.
1 rebuild diario: 300.000 escrituras/mes ≈ US$1,35/mes.
1 rebuild por hora: 7,2 millones de escrituras/mes ≈ US$32/mes.
1 rebuild cada 5 minutos (caso pesimista en que cada cliente tenga actividad en cada ventana): 86 millones de escrituras/mes ≈ US$389/mes.

Ulmer subraya dos cosas que cualquier founder debe mirar antes de emocionarse:

El pipeline es el componente caro. R2 regala la lectura; las escrituras se facturan 12,5 veces más caras que las lecturas. Si reconstruyes por cada cambio viajas, no importa.
Iceberg snapshot diffs permiten saber exactamente qué clientes tienen datos nuevos y reconstruir solo esos cubes — diferencial, no global.

La comparación con S3 sale "solo ~20% más cara" en agregado, principalmente por egress: "unos US$20 al mes de egress a un millón de consultas", según Ulmer, que ese volumen ya es más tráfico del que verá la mayoría de dashboards de cliente.

Autenticación, multi-tenant y caché de borde, casi gratis

El setup de Ulmer es de esos que encantan a un founder porque resuelve problemas caros con piezas pequeñas:

Una URL firmada por cliente o un Worker que valide la sesión basta para autorización. No hay motor de policies que mantener.
El archivo es inmutable por construcción (se reemplaza entero en cada rebuild), así que el Worker que Ulmer interpone delante del endpoint público r2.dev (que está rate-limited) puede cachear byte ranges sin miedo a invalidación.
La demo en sí pesa 18 KB de JavaScript según Ulmer; el resto del peso se va en los bytes de Parquet, y aun así carga rápido porque solo se piden los chunks necesarios.

Limitaciones que tienes que validar antes de imitarlo

El propio Ulmer es claro sobre cuándo no funciona el patrón:

Necesita combinatoria acotada. Charts y filtros deben ser un conjunto cerrado y pequeño. Funciona para uso de producto y billing; no funciona para analytics exploratorio abierto.
El rebuild tiene que ser más rápido que la cadencia de actualización. Si prometes datos casi en tiempo real a 10.000 clientes, los 86 millones de escrituras/mes se convierten en una decisión seria.
Las funciones de agregación tienen que ser distributivas o algebraicas. Sumas, cuentas, maxes y promedios van. Para agregaciones holistic (mediana exacta, percentiles altos) hay que buscar otra arquitectura.
El demo usó 34 millones de filas del dataset NYC 311 — unos 15 años de datos. Ulmer advierte que la elección de grano diario lo hizo unas 7 veces más grande que el equivalente semanal (5,6 MB), aunque no impactó la latencia de las interacciones porque cada interacción solo lee unos pocos row groups.

Qué significa esto para tu startup

Lo que Ulmer demuestra no es "Parquet lo hace todo" — es que el stack por defecto para dashboards de cliente es overkill para la mayoría de SaaS, y el cuello de botella no es técnico sino de想象力 sobre el layout del archivo. Si tu producto tiene métricas de uso o billing limitadas y bien tipadas, y un rebuild cada hora o cada día es aceptable, la arquitectura Parquet-plus-R2-plus-Hyparquet puede reemplazar una instancia de Postgres analítico, un warehouse chico, una herramienta de dashboards como vendor y un pipeline de ETL, en miles de dólares al mes de coste.

Acciones concretas para empezar a experimentar:

Prototipa un cube por cliente con DuckDB local. Carga una tabla de eventos cruda y prueba GROUP BY GROUPING SETS por las dimensiones reales de tu producto. Si el cube resultante queda entre 1 y 50 MB por cliente, el patrón aplica.
Súbelo a R2 y mide coste real. Las cifras de la documentación pública muestran que a 10.000 clientes el techo razonable del patrón está en US$389/mes incluso con rebuild agresivo cada 5 minutos. Compara eso con el coste actual de tu capa analítica.
Evalúa Hyparquet como capa de lectura. Su modelo de HTTP range requests sobre Parquet es lo que vuelve viable esta arquitectura para SaaS B2B pequeños y medianos; revisa su repo y la demo oficial antes de comprometerte a un stack más pesado.