Revisá tus conexiones y elegí la base que querés consultar.
| Fuente / motor | Conexión | Base de datos | Estado | Rol | Acciones |
|---|
El estado se verifica en cada conexión. Los puertos corresponden a la conexión que usa el servidor.
Elegí una fuente, explorá su catálogo y consultá sus datos.
SELECT sobre una tabla del catálogo, columnas, filtros WHERE unidos con AND, ORDER BY y LIMIT (máximo 500). No se admiten funciones, JOIN, subconsultas ni escrituras. LIMIT funciona con todos los motores.
Las tablas disponibles se cargan desde la base seleccionada.
Elegí el origen, las tablas y el destino de cada flujo de datos.
Podés guardar qué querés replicar. La activación de estas configuraciones todavía no está conectada al motor de captura; guardarlas no copia ni modifica datos.
Decisiones, arquitectura y guías del proyecto.
Copia de Obsidian
La actualización de esta copia es manual.Cargando documentación…
Tablero, tareas y avance de DBLakeTag en Linear.
Vista de solo lectura. Las tareas se actualizan en Linear; el avance refleja su estado allí.
Código, merge requests y pipelines del repositorio GitLab.
Un merge o una pipeline correcta no certifican un despliegue. Esta vista muestra el estado del código y de CI en GitLab.
Vista de solo lectura. Los cambios de código, las revisiones y las ejecuciones de CI se gestionan en GitLab.
Conectá tus bases transaccionales IBM i (AS/400) y Microsoft SQL Server con PostgreSQL, ClickHouse, Apache Kafka y Data Lakes modernos. Sin agentes invasivos, sin Java y con menos de 50 MB de memoria RAM.
Las arquitecturas actuales fuerzan a las organizaciones a elegir entre costos millonarios de licencias o infraestructuras JVM colosales y frágiles.
Alto costo de propiedad & bloqueo tecnológico
Sobrecarga de infraestructura & complejidad operativa
Ultra ligero, predecible y optimizado para la nube
Un dato solo genera valor cuando es exacto, consistente y está disponible a tiempo. La captura de cambios transaccional es el mecanismo que mantiene esas tres propiedades entre el sistema de registro y la plataforma analítica.
La integridad es la garantía de que un dato es exacto, completo y consistente en todo su ciclo de vida: desde que se crea en la transacción hasta que se consulta en el lago. Sus dimensiones clásicas son exactitud, consistencia entre sistemas, fidelidad (sin corrupción), completitud, unicidad, validez y oportunidad.
La gobernanza define políticas, responsables y controles sobre calidad, seguridad y disponibilidad del dato. Su función es que información verificada fluya por canales seguros hacia destinos y usuarios de confianza, con linaje auditable de cada transformación.
Un data lake centraliza datos en formato abierto sobre almacenamiento de objetos de bajo costo. Sin transacciones, calidad ni gobernanza degenera en un pantano de datos; el lakehouse resuelve eso agregando una capa transaccional sobre el lago.
Lo que reportan los líderes de datos y analítica en el estudio 2026 State of Data Integrity and AI Readiness de Precisely y el Center for Applied AI and Business Analytics de Drexel LeBow (505 encuestados).
Fuentes conceptuales: IBM Think · Integridad de datos, IBM Think · Gobernanza de datos, Databricks · Introducción a data lakes y el reporte 2026 State of Data Integrity and AI Readiness (Precisely / Drexel LeBow).
Tres pilares de diseño de bajo nivel para garantizar streaming continuo, cero degradación transaccional y resiliencia determinística.
Lectura directa de diarios del OS (QjoRetrieveJournalEntries / QSYS2.JOURNAL_ENTRY_INFO) y Transaction Logs con LSN. Sin triggers ni modificaciones a programas RPG/COBOL/TSQL.
QjoRetrieveJournalEntries / QSYS2fn_dblog() · LSN CDC ContinuousRing buffer transaccional, desempaquetado de alta velocidad para Packed Decimal (COMP-3) y Zoned a 3.75 ns/op, traducción CCSID EBCDIC a UTF-8.
3.75 ns/op a nivel de nibbles binariosStreaming optimizado hacia PostgreSQL, ClickHouse y Kafka. Checkpoints por LSN / Sequence Number que reanudan automáticamente ante cortes sin duplicar transacciones.
LSN / Sequence Number checkpointsComparación de capacidades técnicas y operativas entre DBLakeTag CDC Engine, suites propietarias y el stack JVM/Kafka.
| Criterio de evaluación | RecomendadoDBLakeTag CDC Engine | Precisely Connect / InfoSphere CDC | Debezium + Kafka Connect |
|---|---|---|---|
| Huella de memoria (RAM) | < 50 MBBinario nativo Go | 1 – 2 GB + Agentes en servidor | 2 – 4 GB+ (JVM + Kafka cluster) |
| Tiempo de despliegue | MinutosBinario único / Docker | Semanas a meses de consultoría | Días (Clúster Kafka + Conectores) |
| Soporte IBM i (AS/400) | Nativo de primer nivelJournals OS & SQL | Nativo (Propietario / Cerrado) | Comunitario y frágil |
| Decodificación COMP-3 | 3.75 ns/opNativo en memoria | Soportado con drivers pesados | Manual o plugins frágiles |
| Impacto en apps | Zero ImpactLectura pasiva de logs | Medio (Agentes residentes) | Medio (Consultas JDBC recurrentes) |
| Costo total de propiedad | Fracción del costo tradicionalSin licencias leoninas | Muy alto ($50k – $200k+ USD/año) | Alto (Infraestructura JVM y Kafka) |
Resultados medidos en bancos de pruebas bajo cargas transaccionales reales continuas.
Velocidad de desempaquetado binario COMP-3 en Go nativo sin asignaciones intermedias de memoria.
Latencia de replicación continua hacia PostgreSQL desde la confirmación del diario de transacciones.
Consumo de RAM en operación normal sostenida, permitiendo despliegues de bajo costo en cualquier host.
Cero degradación en el rendimiento transaccional del origen al operar directamente sobre los diarios del sistema.