¡Hola, chicos! ¿Cómo estás? ¿Emocionado por otra publicación?

Recientemente tuve el honor de participar en una sensacional transmisión en vivo por CanaldotNET, junto a mis grandes amigos Renato Groffe y Thiago Bertuzzi. Fueron más de tres horas de intensa conversación sobre el ecosistema de datos, los cambios en el rol del DBA y las tendencias de IA que están llamando a nuestra puerta.

Como el contenido era sumamente denso y rico, decidí crear este post que es prácticamente un resumen de lo que discutimos, detallando cada tema relevante para quienes viven su día a día en la “trinchera” de datos. Si quieres entender hacia dónde se dirige el mercado y cómo no quedarte atrás, este post es para ti.

Para aquellos que quieran ver el vídeo completo y las demostraciones prácticas de Renato Groffe y Bertuzzi, el enlace está aquí:

El cuadrado dorado de las bases de datos (0:15:20)

Comenzamos la conversación desmitificando la aparición de nuevas bases de datos cada semana. Aunque tecnologías como SurrealDB o CockroachDB aportan innovaciones interesantes, el mercado empresarial de misión crítica todavía está dominado por lo que yo llamo el “Cuadrado Dorado”: Servidor SQL, Oracle, MySQL y PostgreSQL.

Mi visión como DBA es pragmática: las modas surgen todo el tiempo, pero el sólido mercado laboral y los sistemas de misión crítica giran en torno a estos 4 DBMS principales. NoSQL a menudo se vende como un reemplazo del relacional, pero en la práctica generalmente sirve como una capa de ingestión rápida o caché, mientras que la verdad de los datos termina muriendo en una base de datos relacional robusta debido a la consistencia ACID.

EL PostgreSQL ha ganado un protagonismo absurdo, no sólo porque es de código abierto, sino por su facilidad de extensiones. Sin embargo, el Servidor SQL sigue siendo la herramienta más completa en términos de gestión, diagnóstico e integración con el ecosistema Microsoft.

Observación: No se deje llevar por el revuelo sobre los nuevos bancos sin antes dominar los fundamentos de uno de estos cuatro gigantes. La base del almacenamiento, los índices y la optimización de consultas es lo que realmente distingue a un profesional senior.

La IA y el auge de los bancos de vectores (0:42:15)

Uno de los momentos más destacados del directo fue la discusión sobre Tiendas de vectores y Incrustaciones. Con el avance de los LLM (como GPT-4), las bases de datos ahora necesitan lidiar con datos no estructurados transformados en vectores numéricos para búsquedas semánticas. La IA generativa no es sólo chat. Para aplicaciones reales (RAG – Recuperación-Generación Aumentada), necesitamos Vector Stores.

Le expliqué cómo PGVector le dio a Postgres una ventaja competitiva, pero destaqué que el Servidor SQL ya está integrando soporte nativo para vectores. Esto nos permitirá realizar búsquedas de “proximidad de significado” directamente a través de T-SQL, sin tener que exportar datos a bases de datos especializadas.

También analizamos el uso del kernel semántico para abstraer esta capa de datos, lo que le permite cambiar el modelo de IA o la base de datos vectorial sin tener que reescribir toda la lógica empresarial.

Carrera: El “fin” del DBA y el surgimiento del ingeniero de datos (1:05:40)

Hemos discutido mucho sobre cómo ha cambiado el papel del DBA tradicional. Hoy en día, no basta con saber instalar SQL Server y crear usuarios. El profesional moderno necesita comprender Infraestructura como código (IaC), contenedores y automatización.

La línea entre DBA y Ingeniero de datos es cada vez más tenue. Mientras que el DBA se centra en la estabilidad y el rendimiento del motor, el ingeniero se centra en la fluidez de la tubería de datos. Pero una cosa es segura: ambos deben ser maestros en SQL.

Énfasis: El “DBA de los clics” está muriendo. El futuro pertenece al "DBA de automatización", que utiliza PowerShell, Terraform y canalizaciones de CI/CD para gestionar cientos de instancias simultáneamente.

Arquitectura para IoT y transmisión de datos (1:10:15)

Una pregunta común en el chat fue sobre dónde guardar los datos de los sensores y de IoT. Aquí el secreto no es el banco, es la Arquitectura. Lanzar millones de eventos por segundo directamente en una tabla relacional generará un cuello de botella. ESCRIBIR REGISTRO violento.

El flujo correcto generalmente implica:

  • Ingestión vía kafka o Centros de eventos de Azure.
  • Almacenamiento de materias primas en uno Lago de datos (ADLS).
  • Procesamiento a través de Spark (ladrillos de datos o tela) en microlotes.

Serie temporal con TimescaleDB (1:25:40)

Si su problema es específicamente Time Series, TimescaleDB ha sido muy elogiado. Es una extensión de Postgres que optimiza la escritura y lectura de datos cronológicos, manteniendo toda la flexibilidad de SQL.

Otras opciones mencionadas fueron Cosmos DB, Elasticsearch y Redis.

Migración a la nube y el costo de IOPS (1:32:10)

Hablamos de los desafíos de migrar entornos On-Premise a SQL azul o AWS RDS. El mayor error que veo es "levantar y cambiar" sin una planificación del desempeño.

En la nube, IOPS es dinero. Si tiene una consulta mal escrita que analiza una tabla de millones de filas, no sólo está ralentizando el sistema; estás quemando el presupuesto de la empresa. Hablamos de herramientas como Servicio de migración de bases de datos de Azure (DMS) para facilitar este proceso con un tiempo de inactividad mínimo.

Alerta crítica: Antes de migrar a PaaS, asegúrese de que sus aplicaciones no dependan de la funcionalidad a nivel de instancia (como trabajos específicos del Agente SQL o consultas entre bases de datos) que puedan tener limitaciones en Azure SQL Database.

SQL Server económico en Azure para POC y MVP (1:45:10)

Mucha gente piensa que Azure SQL es caro, pero les mostré en pantalla cómo comenzar con el modelo DTU (Básico o S0). Puede obtener una base de datos SQL Server real, con respaldo automático y alta disponibilidad, pagando entre R$ 25,00 y R$ 80,00 por mes.

Énfasis: Azure SQL ya realiza copias de seguridad de forma predeterminada. EL Restauración a un momento dado le permite devolver la base de datos al segundo exacto antes de que alguien realizara un BORRAR sin DONDE. Esto no tiene precio para quienes se encuentran en la fase de desarrollo.

Aprovisionado frente a sin servidor en Azure (2:05:30)

Le expliqué la diferencia crucial entre estos dos modelos:

  • Aprovisionado: Reservas el recurso y pagas 24x7, ya que en el caso de Azure SQL Database no existe la opción de apagar la base de datos. Ideal para cargas de trabajo constantes.
  • Sin servidor: El banco “pausa” cuando nadie lo utiliza. Es perfecto para entornos de prueba o procesos de BI que solo se ejecutan en las primeras horas de la mañana.
Alerta crítica: En Serverless, la primera consulta después de que la base de datos se "despierta" puede tardar unos segundos o incluso fallar debido a un tiempo de espera. Tenga esto en cuenta antes de ponerlo en producción crítica.

Microsoft Fabric y OneLake: la revolución analítica (2:05:45)

Nos adentramos profundamente Tela de Microsoft. La propuesta de unificar el almacenamiento en un solo lugar (un lago) usando el formato abierto Delta/Parquet Es un momento decisivo.

el concepto de Atajo es fenomenal: puedes “apuntar” a datos que están en AWS S3 y consultarlos desde Fabric como si fueran tablas locales, sin tener que mover físicamente un solo byte (cero ETL). Esto resuelve la pesadilla de la fragmentación de datos en silos.

Profundizando en Azure Database para PostgreSQL (2:25:15)

Mostré el aprovisionamiento de Postgres en Azure. Sigue el modelo PaaS (Plataforma como Servicio), donde no te preocupas por el sistema operativo.

Miramos los perfiles de la máquina:

  • Estallable: El más barato, para uso ligero y picos ocasionales.
  • Propósito general: Equilibrio entre CPU y memoria.
  • Memoria optimizada: Para bancos que necesitan mucha caché (RAM) para mejorar el rendimiento.

Microservicios y elección bancaria (2:45:00)

Hoy en día, PostgreSQL es el estándar de facto para microservicios. Es ligero, robusto y escala muy bien en contenedores. La recomendación de oro aquí es el aislamiento: intente mantener una base de datos (o al menos un esquema/usuario aislado) por microservicio para evitar que una consulta lenta de un servicio destruya a todos los demás.

El peligro de Raspberry Pi como servidor bancario (2:55:20)

Surgió la pregunta: "¿Puedo utilizar una Raspberry Pi para operaciones bancarias de empresa?"
La respuesta corta es: No. Para el estudio es fantástico, pero para la producción no tienes redundancia física, las tarjetas SD fallan constantemente bajo estrés de E/S y no tienes una estrategia de respaldo administrada. El costo de Azure SQL Basic es menor que el riesgo de perder sus datos.

Carrera y certificaciones (3:05:45)

Para aquellos que quieran destacarse en el área de datos, recomendé dos caminos de Microsoft:

  • DP-900 (Fundamentos de datos de Azure): Para quienes quieren la base de todo (Relacional, NoSQL, Data Lake).
  • DP-300 (Administración de soluciones Azure SQL): Para quienes ya tienen experiencia y ya trabajan administrando bases de datos en la nube.

Conclusión

El directo fue una auténtica maratón de contenidos centrados en el área de datos, pero el mensaje final es sencillo: la tecnología evoluciona rápidamente, pero los fundamentos de los datos son eternos. Ya sea que utilice SQL Server, Oracle, MySQL o PostgreSQL, cualquiera que entienda cómo se procesan los datos siempre tendrá un lugar en el mercado.

Espero que te haya gustado este tip, un fuerte abrazo y ¡hasta la próxima!