Infrastructura de datos con open source: tus datos, tu negocio

Por qué opendome construye sobre estándares abiertos, y por qué esa decisión es la que garantiza, de forma demostrable, el control y la soberanía sobre el dato.

Para quien dirige una organización que opera con Salesforce, SAP o Microsoft, el término "open source" puede evocar todavía una idea imprecisa: software de programadores, proyectos sin garantías, tecnología sin una empresa solvente detrás a la que exigir responsabilidades. Es una percepción extendida, y es incorrecta. Conviene corregirla con precisión, porque el código abierto no es la opción arriesgada frente a lo propietario: es, hoy, la base técnica más sólida, más auditada y más fiable sobre la que se puede construir una infraestructura de datos. Este documento expone por qué, con evidencia.

El punto de partida es un hecho que rara vez se explicita: el software propietario que una organización utiliza a diario está construido, internamente, sobre open source.

El software propietario funciona sobre código abierto

En 2023, Salesforce estandarizó su infraestructura global de nube híbrida sobre Red Hat Enterprise Linux —un sistema operativo de código abierto— para disponer de "una base más flexible y consistente" a escala. SAP ejecuta sus soluciones sobre ese mismo Linux y sobre Kubernetes, el orquestador de contenedores de código abierto originado en Google. Microsoft Azure opera una proporción mayoritaria de máquinas Linux y contribuye a miles de proyectos abiertos. Los hyperscalers no toleran el open source: construyen sus productos sobre él.

No se trata de excepciones, sino del principio de funcionamiento de internet. La red, tal y como opera hoy, se sostiene sobre software abierto que la mantiene en marcha de forma segura, interoperable y sin dueño único:

• Linux es el sistema operativo de prácticamente la totalidad de los servidores del mundo, incluidos los de los propios hyperscalers.
• El servidor web Apache y el resto de proyectos de la Apache Software Foundation —de Kafka a Spark— han servido durante décadas una fracción dominante del tráfico y del procesamiento de datos a escala mundial.
• PostgreSQL, la base de datos relacional abierta, la utiliza el 55,6% de los desarrolladores del mundo según la encuesta de Stack Overflow de 2025 —su mayor crecimiento anual registrado— y más de 48.000 empresas, entre ellas Netflix, Spotify, Uber, Reddit, Instagram y Discord.
• Kubernetes se ejecuta en producción en el 82% de las organizaciones de TI, con 5,6 millones de desarrolladores.

La magnitud de la inversión que las mayores compañías tecnológicas destinan al código abierto confirma su carácter estratégico, no marginal. En mayo de 2026, IBM y Red Hat comprometieron 5.000 millones de dólares y más de 20.000 ingenieros para asegurar el software open source de uso empresarial; IBM, por sí sola, integra más de 62.000 paquetes de código abierto. No es filantropía: es el reconocimiento de que el open source es la infraestructura sobre la que se edifica todo lo demás.

La conclusión es inequívoca. La elección no se plantea entre "lo propietario fiable" y "lo abierto arriesgado". Lo abierto ya sostiene lo propietario. La diferencia relevante no está en la fiabilidad de la base, sino en quién controla la capa superior — y, en consecuencia, quién retiene el control sobre el dato.

El open source como decisión de control, no de coste

opendome construye sobre open source de forma deliberada. No es una decisión de coste, sino una decisión estratégica que ocupa el centro de la propuesta, y obedece a una razón principal: es la única vía demostrable de garantizar que los datos del cliente son, efectivamente, del cliente.

Cuando la infraestructura de datos se asienta sobre estándares abiertos, no existen contratos de licencia propietaria que condicionen el acceso a la propia información, ni cláusulas de retención de datos, ni dependencia técnica de un proveedor con capacidad para monetizar un día el acceso a lo que la organización generó. El dato reside en formato abierto, legible por cualquier motor del ecosistema. Si la organización decide prescindir de su proveedor, los datos permanecen en un formato que cualquier otro actor puede leer. El coste de salida tiende a cero — no como argumento comercial, sino como propiedad técnica de los formatos abiertos.

Esta cuestión enlaza con un riesgo jurídico concreto y documentado. La CLOUD Act estadounidense faculta a las autoridades de EE. UU. para obligar a un proveedor con sede en ese país a entregar datos, con independencia del lugar donde se almacenen físicamente. En junio de 2025, la filial francesa de Microsoft lo reconoció bajo juramento ante el Senado francés: no podía garantizar la soberanía de los datos frente a las autoridades estadounidenses, ni siquiera para datos alojados en Francia. Construir sobre open source, en infraestructura del propio cliente y dentro de su jurisdicción, no es una postura de valores: es gestión de riesgo. Y solo el código abierto la hace verificable.

Las piezas, y quién las opera en producción

Ninguna de las piezas sobre las que opendome construye es experimental. Son proyectos maduros, en producción en las organizaciones más exigentes del mundo, con comunidades amplias y, en numerosos casos, con compañías solventes que prestan soporte profesional sobre ellos. La continuidad de estos proyectos no depende de opendome. A continuación se describen una a una.

Las tres piezas centrales

Apache Iceberg — el formato de tabla abierto. Es la pieza sobre la que se centraliza y se almacena el dato. Iceberg nació en Netflix en 2017 y se donó a la Apache Software Foundation en 2018. En 2025 se ha convertido, sin discusión, en el estándar de facto de los formatos de tabla abiertos: lo usan en producción Apple, Netflix, LinkedIn, Airbnb, Adobe, Bloomberg y Expedia, entre muchos otros. Apple lo ha desplegado en cientos de equipos de datos y contribuye activamente al proyecto. Y los tres grandes proveedores de nube —AWS, Microsoft y Google— además de Snowflake y Databricks, todos lo soportan. La razón por la que el mundo se ha unido en torno a Iceberg es exactamente la nuestra: propiedad del dato y ausencia de lock-in. Al usar un formato no atado a ninguna plataforma, la organización mantiene el control y la libertad de cambiar de motor cuando quiera. Airbnb reportó un 50% de ahorro de cómputo y un 40% de reducción de tiempo en su ingesta tras migrar a Iceberg.

Lance / LanceDB — el formato para datos multimodales y de IA. Es la pieza que une el dato no estructurado —documentos, correos, imágenes, transcripciones— con el resto, y la que permite la búsqueda semántica que los agentes necesitan. Lance es un formato columnar abierto pensado desde cero para IA, creado por uno de los autores originales de Pandas (la librería de datos más usada del mundo en Python). Su adopción es un quién es quién de la IA generativa: Midjourney, Character.ai, Runway, World Labs (de Fei-Fei Li), Luma Labs y la unidad de IA de ByteDance usan Lance en producción. Netflix lo emplea para búsqueda multimodal. WeRide reportó una mejora de 90x en la productividad de sus desarrolladores de ML. LanceDB levantó una Serie A de 30 millones de dólares en 2025: hay una empresa solvente detrás y, al ser el formato abierto, no se genera dependencia de ella.

La capa semántica y el metrics layer — la pieza que extendemos. Es la capa que transforma el dato en conocimiento de negocio. Donde las dos piezas anteriores centralizan y almacenan, esta describe: establece que un campo numérico es "ingresos en euros", que una fila es un "cliente", y que dos tablas inconexas se relacionan como "el cliente que firmó este contrato". El resultado no es un catálogo de tablas, sino un grafo semántico — una representación formal de qué entidades existen en el negocio, qué atributos tienen y cómo se conectan entre sí. Es, en sentido estricto, una ontología: el modelo de la realidad del negocio sobre el que tanto las personas como los agentes formulan preguntas.

El núcleo técnico de esta capa es un metrics layer, y conviene detenerse en él porque es donde reside buena parte del rigor formal del sistema. Partimos del estándar abierto del sector —MetricFlow, el motor que sustenta el dbt Semantic Layer, distribuido bajo licencia Apache 2.0— y lo hemos extendido para el caso agéntico. Su funcionamiento ilustra por qué un metrics layer es cualitativamente superior a definir métricas a mano o dentro de cada herramienta de BI:

• Definición formal y versionada. Las entidades, las dimensiones (los ejes por los que se agrupa: tiempo, geografía, categoría) y las measures (las agregaciones numéricas) se declaran una sola vez, en código, revisables y auditables en control de versiones. Una métrica como "ingresos" deja de tener tantas definiciones como cuadros de mando existan: tiene una, y es la misma para todos los consumidores.

• Composición sobre un grafo. Las entidades actúan como nodos y las relaciones como aristas de un grafo. El motor conoce los caminos de unión entre tablas y, ante una pregunta —"ingresos por cliente y por mes"—, genera el SQL óptimo sobre la marcha, resolviendo automáticamente los joins necesarios aunque la consulta atraviese decenas o cientos de tablas y varios saltos entre ellas. Lo hace, además, evitando de forma estructural los errores clásicos del modelado dimensional —los fan-out y chasm joins— que un analista humano introduce con facilidad y que corrompen silenciosamente los resultados.

• Tipos de métrica de primer nivel. El metrics layer soporta como construcciones formales no solo las agregaciones simples, sino las razones (ingreso por cliente), las expresiones (transacciones menos cancelaciones), las métricas acumulativas (usuarios activos semanales) y las comparativas temporales (crecimiento mes a mes). Una consulta que escrita a mano superaría las 150 líneas de SQL se reduce, optimizada, a un tercio — y a una definición declarativa que cualquiera puede leer y aprobar.

• Una sola verdad para BI, apps y agentes. Como la definición vive en la capa semántica y no en la herramienta de consumo, la misma métrica —idéntica, gobernada y testada— alimenta un dashboard, una aplicación embebida o un agente de IA. Para el agente esto es decisivo: recibe el significado de negocio resuelto y consistente, en lugar de tener que inferirlo. El sector entero reconoce hoy esta capa como condición para que la IA dé respuestas fiables, hasta el punto de que MetricFlow se desarrolla dentro de la iniciativa Open Semantic Interchange (OSI), el esfuerzo del sector por estandarizar la definición semántica e interoperar entre plataformas — lo que garantiza que las definiciones que se modelan hoy son portables mañana, sin reescritura.

Sobre su solvencia: dbt es la herramienta de transformación de datos estándar de la industria, usada por JetBlue, HubSpot, Vodafone y GitLab. En el plano de la capa semántica, Cube (Apache 2.0) tiene más de 400 empresas sobre su plataforma —entre ellas Brex, Coinbase, Intuit y Toyota— y Brex la eligió frente a las alternativas propietarias para construir su analista financiero de IA. Son piezas con rigor formal, comunidad amplia y compañías solventes detrás.

El resto de la arquitectura, pieza por pieza

Aunque las tres anteriores son el corazón, todas las capas se construyen sobre proyectos igual de solventes:

• El dato en la nube del cliente: Kubernetes, Helm, OpenTofu y CloudNativePG sobre almacenamiento compatible con S3. Kubernetes lo operan BBVA, ING o Deutsche Bahn; CloudNativePG cuenta con el respaldo de la comunidad de Red Hat.

• Centralización de fuentes corporativas: Meltano + Singer (con más de 600 conectores) y Trino, el motor de consulta distribuida. Meltano nació en GitLab; Trino lo usan Netflix, Airbnb, LinkedIn y la propia Salesforce. Permiten llevar los datos de Salesforce, SAP o Dynamics a un único lakehouse abierto, sin pagar un fee por cada conector.

• Datos estructurados y no estructurados unificados: además de Iceberg y Lance, pgvector (usado por Supabase y Microsoft) y Apache Tika (el extractor de contenido que usa Alfresco) para que documentos y tablas convivan y se relacionen.

• Datos navegables desde un ID: dbt modela el dato de crudo a curado, de modo que desde un customer_id se llega a sus pedidos, incidencias, contratos o pólizas en milisegundos, sea cual sea la fuente original.

• Seguridad atómica por acceso: Open Policy Agent (OPA) —usado por Google, Netflix y Goldman Sachs— junto con el control a nivel de fila y columna de Trino, para que cada acceso se autorice por la combinación de agente, propósito, entidad y campo. No es un rol general: es una llave específica.

• Observabilidad inmutable: Prometheus, Grafana, Loki, Tempo y OpenTelemetry, el estándar de observabilidad que mantienen Microsoft, Google y AWS. Generan el registro de accesos auditable que exigen DORA y el EU AI Act, sin desarrollos adicionales.

• Compliance estructural EU: el aislamiento por NetworkPolicy, la residencia en la UE, el audit atómico, y la firma de la cadena de suministro con Sigstore (de Google y GitHub). Cumplimiento por diseño, no como capa de pintura añadida al final.

Un ecosistema de servicios profesionales, no un proyecto sin respaldo

La objeción que con más frecuencia frena la adopción de infraestructura abierta en el ámbito directivo es la del respaldo: si surge un problema, ¿a quién se llama?. La respuesta es que existe un ecosistema maduro de miles de empresas que prestan servicios profesionales —soporte, implantación, operación gestionada, garantías contractuales— sobre exactamente estas piezas.

Ese ecosistema lo encabezan compañías de primer orden. Red Hat —adquirida por IBM— construyó un negocio de miles de millones de dólares íntegramente sobre soporte a software abierto, y es el proveedor sobre el que Salesforce y SAP apoyan su propia infraestructura. Alrededor de cada proyecto central existen empresas especializadas y solventes: las que respaldan PostgreSQL, las que mantienen las distribuciones de Kubernetes, las que sostienen Iceberg, Trino o Cube. El reciente compromiso conjunto de 5.000 millones de dólares de IBM y Red Hat para asegurar el código abierto empresarial es la medida del respaldo institucional que hay detrás.

Conviene además ser preciso sobre la naturaleza de ese servicio, porque es aquí donde la diferencia con el modelo propietario resulta más relevante. Los proveedores de servicios sobre tecnología abierta operan en un mercado competitivo y abierto, y eso disciplina tanto su calidad técnica como su precio. Compiten por el cliente sobre la base de su competencia —porque cualquiera puede leer, auditar y operar el mismo código— y no sobre la base de una dependencia impuesta. El resultado tiende a ser un servicio más técnico y menos extractivo que el de los ecosistemas de partners que orbitan alrededor de las plataformas propietarias, cuyo negocio depende, estructuralmente, de profundizar la dependencia del cliente respecto al fabricante. Donde el partner propietario tiene un incentivo a perpetuar el vínculo, el proveedor de servicios abiertos solo puede retener al cliente mereciéndolo.

Esto reconfigura la relación con el proveedor en un punto esencial. Con un stack propietario, la dependencia es estructural: ante una subida de precios, un cambio de condiciones o la decisión de monetizar el acceso a los propios datos, la única salida es una migración costosa. Con un stack abierto, la relación es voluntaria. Una organización elige a su proveedor —a opendome, o a cualquier otro— por la calidad con que integra, opera y da servicio sobre estas piezas, no por imposibilidad de marcharse. El dato permanece en formatos abiertos que cualquier otro actor del ecosistema puede leer.

Esa es, en última instancia, la propiedad que define al open source bien aplicado a la infraestructura de datos: no reduce la dependencia de la tecnología —ninguna organización opera sin ella— sino que elimina la dependencia respecto a un único proveedor para acceder a lo que es propio. La infraestructura es del cliente; los formatos son del dominio común; y el servicio lo presta quien mejor lo haga, en un mercado donde competir exige excelencia y no cautividad.

Fuentes

• Red Hat, Salesforce Standardizes Global Hybrid Cloud Infrastructure on Red Hat Enterprise Linux — https://www.redhat.com/en/about/press-releases/salesforce-standardizes-global-hybrid-cloud-infrastructure-red-hat-enterprise-linux
• Red Hat / IBM, Project Lightwell: $5 Billion Commitment to Open Source — https://newsroom.ibm.com/2026-05-28-ibm-and-red-hat-commit-5-billion-to-redefine-the-future-of-open-source-in-the-ai-era
• Stack Overflow Developer Survey 2025 (PostgreSQL, Kubernetes adoption), vía DEV — https://dev.to/akshaykurve/15-open-source-tools-every-developer-should-try-in-2026-d26
• Apache Iceberg — Wikipedia (origen en Netflix, adopción) — https://en.wikipedia.org/wiki/Apache_Iceberg
• Cloudera, The Iceberg Wave: How an Open Format Became an Enterprise Standard — https://www.cloudera.com/blog/business/the-iceberg-wave-how-an-open-format-became-an-enterprise-standard.html
• Qlik, How Iceberg Powers Data and AI at Apple, Netflix, LinkedIn (datos de Airbnb) — https://www.qlik.com/blog/how-iceberg-powers-data-and-ai-applications-at-apple-netflix-linkedin-and
• Forkable, LanceDB leans on open source (ByteDance, World Labs, Luma Labs) — https://www.forkable.io/p/lancedb-leans-on-open-source-to-build
• LanceDB, Raises $30M Series A to Build the Multimodal Lakehouse — https://www.lancedb.com/blog/series-a-funding
• Cube, dbt Semantic Layer Alternatives 2026 (Brex, 400+ empresas) — https://cube.dev/articles/dbt-semantic-layer-alternatives-2026
• dbt Labs, How the dbt Semantic Layer works with MetricFlow (grafo semántico, joins automáticos) — https://www.getdbt.com/blog/how-the-dbt-semantic-layer-works
• dbt Labs, The future of the dbt Semantic Layer and MetricFlow (fan-out/chasm joins, reducción de SQL) — https://www.getdbt.com/blog/dbt-semantic-layer-whats-next
• GitHub, dbt-labs/metricflow (Apache 2.0, Open Semantic Interchange, plan de consulta dataflow) — https://github.com/dbt-labs/metricflow
• The Register, Don't let hyperscalers hijack digital sovereignty (CLOUD Act, admisión de Microsoft) — https://www.theregister.com/2026/03/18/cispe_sovereignty_washing/