Escrito por
Mauro Abbatemarco
Publicado
24 de abril de 2026
Los datos inmobiliarios son un desorden. Los registros de propiedades, los datos hipotecarios, las tasaciones fiscales y la información de titularidad vienen de docenas de fuentes, se actualizan con frecuencias distintas y necesitan poder consultarse de formas que varían según el cliente. Construir una plataforma de analítica que maneje ese volumen de forma confiable — sin convertirse en una carga de mantenimiento — requiere tomar decisiones de arquitectura deliberadas desde el principio.
Así lo encaramos para uno de nuestros clientes, y por qué el stack que elegimos funciona mejor que las alternativas que consideramos.
El cliente necesitaba procesar millones de registros inmobiliarios por día y servir analítica personalizada sobre esos datos. Los requerimientos eran simples pero exigentes: storage costo-efectivo, performance de consultas rápida, suficiente flexibilidad para evolucionar el schema a medida que cambiara el modelo de datos, y que un equipo chico pudiera mantenerlo sin ingenieros de infraestructura dedicados.
La tentación en este tipo de proyecto es recurrir a sistemas distribuidos — Spark, Databricks, un data warehouse gestionado. Evaluamos esas opciones y decidimos no usarlas. La complejidad que introducen no se justifica con este volumen de datos, y la sobrecarga operativa habría consumido al equipo.
S3 con Parquet como formato de archivo te da storage costo-efectivo para datasets grandes, performance de consulta rápida gracias a lecturas columnares, evolución flexible del schema sin migraciones, y compresión incorporada. No es una elección novedosa — pero es la correcta para este caso de uso, y elegir tecnología aburrida de forma deliberada es una decisión de arquitectura válida.
DuckDB maneja la capa de procesamiento analítico. Corre in-process sin configuración, usa SQL nativamente, y entrega una performance de consulta excepcional sobre archivos Parquet sin necesitar un cluster. Para un equipo que sabe SQL, la curva de aprendizaje es mínima.
dbt se ubica encima como la capa de transformación. Le da al proyecto testing incorporado, documentación y linaje de datos claro — cosas que importan enormemente cuando estás procesando datos que alimentan decisiones de negocio. Cada transformación queda versionada, testeada y documentada automáticamente.
Dagster gestiona el pipeline de punta a punta. Lo elegimos por sobre Airflow porque está construido alrededor de assets en lugar de tareas — definís qué datos estás produciendo, no solo qué código estás ejecutando. Eso hace que el monitoreo y el debugging sean significativamente más simples, y se integra naturalmente con dbt.
El stack procesa millones de registros de propiedades por día con un turnaround rápido para pedidos de analítica personalizada. El costo es significativamente menor que los enfoques tradicionales de data warehouse porque no hay gestión de clusters, no hay pricing por consulta, y no hay costo de compute ocioso.
La experiencia del developer también importa acá. Un equipo que entiende las herramientas y puede debuggear problemas rápido, entrega más rápido y comete menos errores. Evitamos deliberadamente herramientas que requieren expertise especializado para operar.
La arquitectura también maneja bien el cambio. Cuando el cliente necesitó agregar una nueva fuente de datos o modificar el schema, el impacto quedó aislado y el cambio pudo testearse antes del deployment.
El pipeline corre a diario, ingiriendo registros de propiedades de múltiples fuentes, transformando y validando los datos a través de modelos de dbt, y dejando los resultados disponibles para consulta en la capa de analítica del cliente. Dagster da visibilidad sobre cada corrida — qué funcionó, qué falló, y por qué.
Cuando algo se rompe — y va a romperse — el manejo de errores y el monitoreo incorporados al stack hacen que el diagnóstico sea directo. No hay caja negra.
Las plataformas de datos modernas no necesitan ser complejas o caras para manejar volúmenes de datos serios. Las herramientas que existían hace cinco años requerían sistemas distribuidos a esta escala. DuckDB, dbt y Dagster no. Elegir las herramientas correctas para el problema real — no para el problema hipotético futuro — es la diferencia entre una plataforma que funciona y una que se convierte en un pasivo.
Si estás construyendo una plataforma de datos para real estate, servicios financieros o cualquier dominio con datos estructurados de alto volumen, estamos para ayudarte a pensar la arquitectura.
¿Tu equipo está construyendo una plataforma de datos? Hablemos →
© 2026 - Renaiss, hecho con cariño