Las buenas prácticas de ClickHouse se reducen a una idea incómoda: el motor casi nunca es el problema. ClickHouse es brutalmente rápido cuando lo usas como fue diseñado, y sorprendentemente lento cuando lo tratas como un PostgreSQL con esteroides.

Casi todos los problemas de rendimiento en producción son autoinfligidos: una ORDER BY mal elegida, inserciones fila por fila, un FINAL en el camino caliente, un JOIN al revés. No son límites del motor. Son decisiones tuyas, y casi todas se toman el día que escribes el CREATE TABLE.

Esta guía recoge las reglas que sí o sí debes cumplir para optimizar ClickHouse en producción, con el porqué de cada una y, cuando se puede medir, con la medición delante.

En una frase: elige la ORDER BY por tus filtros reales, inserta en lotes grandes, no uses SELECT * ni FINAL, pon la tabla pequeña a la derecha del JOIN, protege cada consumidor con perfil y cuota, y mide con EXPLAIN indexes = 1 y system.query_log en vez de adivinar.

Lo que cubre esta guía:

• Cómo elegir la ORDER BY y por qué la PRIMARY KEY debería ser más corta

• Particionado, tipos, zonas horarias y códecs de compresión

• Ingesta por lotes, async_insert, deduplicación y TOO_MANY_PARTS

• Ingesta desde Kafka sin perder eventos

• Consultas: poda del índice, FINAL, JOIN y memoria

• Cuándo usar un índice de salto, una proyección o una vista materializada

• Replicación, Keeper, sharding y consultas distribuidas

• Seguridad, cuotas y multi-tenancy

• Migraciones de esquema y backups que de verdad restauran

• Observabilidad, antipatrones, preguntas frecuentes y checklist

Al final tienes el entorno Docker para reproducirlo todo en tu máquina en cinco minutos.

1. Cómo elegir la ORDER BY en ClickHouse

En MergeTree, la clave de ordenamiento define el índice primario, que es disperso: una marca cada 8.192 filas (index_granularity). ClickHouse no busca filas, descarta bloques de 8.192. Todo lo demás —códecs, proyecciones, índices de salto— es secundario frente a esta decisión.

Las reglas:

• Ordena las columnas de menor a mayor cardinalidad.

• Pon primero las columnas por las que siempre filtras.

• Mantenla corta: de 2 a 4 columnas. Más columnas rara vez ayudan y encarecen los merges.

• La marca de tiempo casi nunca va primero: suele ser la columna de mayor cardinalidad.

-- Mal: el timestamp primero mata la poda por tenant
CREATE TABLE events (...)
ENGINE = MergeTree
ORDER BY (event_time, tenant_id, user_id);

-- Bien: filtras por tenant, luego acotas por tiempo
CREATE TABLE events
(
    tenant_id   UInt32,
    event_type  LowCardinality(String),
    user_id     UInt64,
    event_time  DateTime('UTC') CODEC(Delta, ZSTD(1)),
    duration_ms UInt32          CODEC(T64, ZSTD(1)),
    revenue     Decimal(18,4),
    payload     String          CODEC(ZSTD(3))
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
PRIMARY KEY (tenant_id, event_type)
ORDER BY (tenant_id, event_type, event_time, user_id)
SETTINGS index_granularity = 8192;

La diferencia, medida

Sobre una tabla de dos millones de filas, la misma consulta con y sin el prefijo de la ORDER BY:

consulta                       marcas  filas leídas   bytes leídos
con prefijo de la ORDER BY          3      24.580         192 KiB
sin prefijo                        93     757.150        2,89 MiB

Treinta veces menos filas, quince veces menos bytes, y el mismo resultado. En una tabla de mil millones de filas esa proporción es la diferencia entre un dashboard y un incidente.

No lo supongas: míralo.

EXPLAIN indexes = 1
SELECT count()
FROM events
WHERE tenant_id = 5 AND event_time >= now() - INTERVAL 1 DAY;

Si el plan muestra que lee todas las partes y todos los granules, tu WHERE no está tocando el prefijo de la clave. Y no envuelvas la columna indexada en funciones: WHERE toDate(event_time) = today() dificulta la poda, WHERE event_time >= today() AND event_time < today() + 1 no.

La PRIMARY KEY puede ser más corta que la ORDER BY

Esta es la optimización avanzada que casi nadie aplica. PRIMARY KEY debe ser un prefijo de ORDER BY, pero no tiene por qué ser igual de larga. Las marcas del índice primario viven en RAM: si tu ORDER BY termina en una columna de altísima cardinalidad que solo necesitas para ordenar dentro del granule, déjala fuera de la PRIMARY KEY y te ahorras memoria en cada réplica.

SELECT
    t.primary_key AS clave_primaria,
    t.sorting_key AS clave_de_orden,
    formatReadableSize(sum(p.primary_key_bytes_in_memory)) AS marcas_en_ram
FROM system.tables AS t
INNER JOIN system.parts AS p
    ON p.database = t.database AND p.table = t.name
WHERE t.database = currentDatabase() AND t.name = 'events' AND p.active
GROUP BY clave_primaria, clave_de_orden;

No existe una ORDER BY buena para todos los patrones de consulta. Si tienes dos patrones muy distintos, la respuesta es una proyección o una tabla aparte, nunca una clave de compromiso que sirve mal a ambos.

2. Particionado: cuántas particiones aguanta una tabla

La partición es una unidad de gestión de datos (borrado, TTL, mover a almacenamiento frío), no un mecanismo de aceleración. Eso lo hace la ORDER BY.

Objetivo: decenas o pocos cientos de particiones por tabla, nunca miles. Y si no necesitas borrar por rango, puedes no particionar: es una opción perfectamente válida y a menudo la correcta.

Para expirar datos, TTL y nunca un cron con DELETE:

ALTER TABLE events MODIFY TTL event_time + INTERVAL 365 DAY DELETE;

Si además quieres enfriar antes de borrar (TO VOLUME 'cold'), necesitas una storage_policy configurada en el servidor con ese volumen definido; sin ella el ALTER falla. Ese es el camino habitual para mover datos antiguos a S3 y pagar almacenamiento de objetos en vez de NVMe.

3. Tipos y códecs: la compresión es velocidad

El tipo de dato no es una cuestión de pulcritud. Menos bytes en disco son menos bytes que descomprimir, y la descompresión es tiempo de CPU en cada consulta.

LowCardinality es la victoria más barata de toda la lista. Dos tablas con exactamente los mismos dos millones de valores, una con String y otra con LowCardinality(String):

tabla        comprimido    sin comprimir
t_lowcard     30,50 KiB        1,92 MiB
t_string     126,68 KiB       26,32 MiB

Cuatro veces menos en disco y, sobre todo, catorce veces menos trabajo de descompresión. Aplícalo a cualquier String con menos de unos 10.000 valores distintos; por encima de esa cifra empieza a ser contraproducente.

Sobre Nullable: añade una columna de máscara aparte, con más I/O, peor compresión y menos optimizaciones. Usa un valor centinela o DEFAULT, salvo que la diferencia entre “cero” y “desconocido” sea semánticamente necesaria. Y nunca pongas una columna Nullable en la ORDER BY.

Pon la zona horaria en el tipo, no en la cabeza

Esta es la bomba de relojería más barata de desactivar. Un DateTime sin zona horaria usa la del servidor, y el día que migras de máquina o cambias el timezone del contenedor, todos tus informes se desplazan una hora sin que nadie se entere.

CREATE TABLE eventos_utc
(
    id       UInt64,
    ocurrido DateTime('UTC') CODEC(Delta, ZSTD(1))
)
ENGINE = MergeTree ORDER BY (ocurrido, id);

Guarda siempre en UTC y convierte en la capa de presentación. No al revés.

Códecs

Los códecs se eligen por la forma del dato, no por gusto:

• Delta y DoubleDelta para secuencias monótonas: timestamps, contadores, identificadores incrementales.

• Gorilla o T64 para flotantes y enteros de métricas.

• ZSTD(1..3) para texto y datos fríos, cuando el disco pesa más que la CPU.

• LZ4 (el default) cuando la CPU pesa más que el disco.

Audita lo que de verdad está ocupando espacio, columna por columna:

SELECT
    column,
    formatReadableSize(sum(column_data_compressed_bytes))   AS comprimido,
    formatReadableSize(sum(column_data_uncompressed_bytes)) AS crudo,
    round(sum(column_data_uncompressed_bytes)
        / sum(column_data_compressed_bytes), 1)             AS ratio
FROM system.parts_columns
WHERE active AND table = 'events' AND database = currentDatabase()
GROUP BY column
ORDER BY sum(column_data_compressed_bytes) DESC;

La columna con peor ratio y más peso es siempre la primera candidata a un códec distinto o a un tipo más estrecho.

Y si el esquema no lo controlas tú

Para payloads semiestructurados que cambian sin avisar, ClickHouse tiene un tipo JSON nativo que crea subcolumnas sobre la marcha, en vez de obligarte a guardar un String y parsearlo en cada consulta:

CREATE TABLE eventos_json (id UInt64, payload JSON)
ENGINE = MergeTree ORDER BY id;

INSERT INTO eventos_json VALUES (1, '{"a": 1, "b": {"c": "x"}}');

SELECT id, payload.a, payload.b.c FROM eventos_json;

Úsalo para lo que de verdad es variable. Las columnas que consultas siempre merecen ser columnas de verdad, con su tipo y su códec.

4. Ingesta: por qué fila a fila rompe el clúster

Cada INSERT crea una parte en disco. Las partes se fusionan en segundo plano. Si insertas fila por fila, generas miles de partes, el merge no da abasto y recibes TOO_MANY_PARTS.

Los umbrales no son misteriosos, están en una tabla del sistema:

SELECT name, value
FROM system.merge_tree_settings
WHERE name IN ('parts_to_delay_insert', 'parts_to_throw_insert',
               'replicated_deduplication_window',
               'replicated_deduplication_window_seconds');

En ClickHouse 26.9 los valores por defecto son 1.000 partes activas por partición para empezar a retrasar los INSERT y 3.000 para rechazarlos. Si estás rozando el primero, ya tienes un problema: el segundo llega en cuestión de horas.

De 10.000 a 100.000 filas o más por INSERT, y como máximo una inserción por segundo y por tabla desde cada productor. Si tienes muchos clientes concurrentes y pequeños, no los coordines a mano: deja que el servidor agrupe.

INSERT INTO estados
SETTINGS async_insert = 1,
         wait_for_async_insert = 1,
         async_insert_busy_timeout_ms = 1000,
         async_insert_max_data_size = 10000000
VALUES (3, 'nuevo', 1);

wait_for_async_insert = 1 mantiene la garantía de durabilidad: el cliente recibe el acuse cuando el bloque está escrito. Ponerlo a 0 multiplica el rendimiento y te deja sin saber si el dato llegó. Es una decisión de negocio, no de ingeniería.

Si tu solución a TOO_MANY_PARTS es subir el límite de partes, no has arreglado nada: has movido el incidente a la semana que viene.

Reintentos sin duplicados

Las tablas replicadas deduplican bloques idénticos automáticamente: guardan en Keeper la huella de los últimos 10.000 bloques insertados, durante una hora. Si tu reintento manda exactamente el mismo bloque dentro de esa ventana, no se duplica.

El problema es que casi ningún pipeline reenvía el bloque exactamente igual. Para eso existe el token explícito:

INSERT INTO estados
SETTINGS insert_deduplication_token = 'lote-2026-10-09-0001'
VALUES (4, 'nuevo', 1);

Con un token derivado del lote de origen (offset de Kafka, id de fichero, rango de fechas), tu pipeline puede reintentar sin miedo y sin lógica de deduplicación en la aplicación.

Dos detalles más que ahorran incidentes: nombra siempre las columnas (INSERT INTO t (a, b, c) ...) para que un ALTER TABLE ADD COLUMN no te rompa la ingesta, y usa formatos nativos (Native o RowBinary por encima de Parquet, y Parquet por encima de JSONEachRow), con compresión activada en el cliente.

Actualizar y borrar es excepcional

ALTER TABLE ... UPDATE y DELETE son mutaciones: reescriben partes completas de forma asíncrona. No son transacciones y no son baratas.

• Para corregir datos: DROP PARTITION y reinsertar.

• Para “última versión gana”: ReplacingMergeTree.

• Para borrados puntuales: DELETE FROM ... WHERE ... (ligero, marca filas), entendiendo que la fila sigue en disco hasta el siguiente merge.

• Para expiración por antigüedad: TTL.

Cuando lances una mutación y necesites esperar a que termine, SETTINGS mutations_sync = 2. Y vigila las que se quedan atascadas, que es un clásico silencioso:

SELECT database, table, mutation_id, command, parts_to_do, latest_fail_reason
FROM system.mutations
WHERE NOT is_done;

5. Ingesta desde Kafka sin perder eventos

Kafka es el origen más común de datos en ClickHouse, y también el que más gente monta mal. La tabla con ENGINE = Kafka no es una tabla: es un consumidor. Leer de ella consume del topic, y lo que lees desaparece para el resto.

Hacen falta tres objetos, no dos: la cola, la vista que la vacía y la tabla donde viven los datos.

CREATE TABLE events_kafka
(
    tenant_id  UInt32,
    event_type String,
    user_id    UInt64,
    event_time DateTime
)
ENGINE = Kafka
SETTINGS kafka_broker_list = 'kafka:9092',
         kafka_topic_list = 'events',
         kafka_group_name = 'clickhouse-events',
         kafka_format = 'JSONEachRow',
         kafka_num_consumers = 3,
         kafka_max_block_size = 1048576,
         kafka_handle_error_mode = 'stream';

CREATE MATERIALIZED VIEW mv_kafka_events TO events AS
SELECT tenant_id, event_type, user_id, event_time
FROM events_kafka;

Las reglas que evitan el 90% de los incidentes:

• Nunca hagas SELECT a la tabla Kafka para “ver si llegan datos”. Cada consulta consume mensajes que ya no llegarán a la vista materializada. Si quieres inspeccionar, mira la tabla destino.

• kafka_num_consumers nunca por encima del número de particiones del topic. Los consumidores sobrantes se quedan ociosos ocupando hilos.

• kafka_handle_error_mode = 'stream' manda los mensajes que no parsean a un flujo de errores en vez de bloquear el consumidor. Sin esto, un solo mensaje corrupto puede parar la ingesta entera.

• Una vista materializada por destino. Si necesitas escribir en tres tablas, son tres vistas sobre la misma cola, no una vista con tres INSERT.

• Vigila system.kafka_consumers: ahí se ve el retraso, las excepciones y si el consumidor está vivo.

Para idempotencia real de extremo a extremo, usa el offset de Kafka en el insert_deduplication_token de la sección anterior. Es la forma más simple de aproximarse a exactly-once sin inventar un sistema de control de estado.

6. Consultas: lo que cuesta caro

Nunca SELECT *

ClickHouse es columnar. SELECT * lee todas las columnas del disco y anula la principal ventaja del motor. Pide solo lo que necesitas. Siempre.

Evita FINAL en el camino caliente

FINAL fuerza la fusión en tiempo de consulta. Es correcto, y es lento. Para ReplacingMergeTree, agrega explícitamente:

SELECT
    id,
    argMax(status, version) AS estado_actual,
    max(version)            AS ultima_version
FROM estados
GROUP BY id;

Ojo con los alias, porque aquí hay una trampa que la mayoría de artículos copia mal. Esta variante, que circula por todas partes, falla en ClickHouse moderno:

-- NO funciona: Code 184, aggregate function inside another aggregate function
SELECT id, argMax(status, version) AS status, max(version) AS version
FROM estados
GROUP BY id;

Al llamar version al alias de max(version), el analizador resuelve el version de dentro de argMax contra el alias, y acabas con una agregación dentro de otra. Dale a los alias nombres distintos de las columnas que agregas.

Y nunca ejecutes OPTIMIZE TABLE ... FINAL de forma periódica sobre tablas grandes: reescribe todo y es la causa habitual de clústeres saturados.

Haz los JOIN en el orden correcto

ClickHouse carga la tabla derecha en memoria para construir la hash table. El orden no es una preferencia del optimizador: es la diferencia entre 200 ms y un MEMORY_LIMIT_EXCEEDED.

Filtra y agrega en subconsultas antes de unir, no después. Y si la tabla derecha realmente no cabe, cambia de algoritmo antes que de límite de memoria:

SELECT count()
FROM events AS e
JOIN estados AS s ON e.user_id = s.id
SETTINGS join_algorithm = 'grace_hash';

Para dimensiones, lo correcto no es un JOIN mejor, sino ningún JOIN. Un diccionario vive en memoria, se refresca solo y se consulta con una función:

CREATE DICTIONARY dim_tenants
(
    tenant_id UInt32,
    nombre    String,
    plan      String
)
PRIMARY KEY tenant_id
SOURCE(CLICKHOUSE(QUERY $q$
    SELECT tenant_id, nombre, plan FROM dim.tenants
$q$))
LAYOUT(HASHED())
LIFETIME(MIN 600 MAX 900);

SELECT
    dictGet('dim_tenants', 'nombre', toUInt64(tenant_id)) AS tenant,
    count() AS eventos
FROM events
WHERE event_time >= now() - INTERVAL 1 DAY
GROUP BY tenant
ORDER BY eventos DESC;

Aproxima cuando puedas

uniq() en lugar de count(DISTINCT), uniqCombined si necesitas ajustar memoria y precisión, quantile() en lugar de quantileExact(). Reserva las versiones exactas para cuando el negocio realmente las exija, que es menos a menudo de lo que la gente cree.

Pon límites a cada consulta

Un cliente mal escrito no debe poder tumbar el clúster.

SELECT count() FROM events
SETTINGS max_execution_time = 60,
         max_memory_usage = 10000000000,
         max_rows_to_read = 1000000000,
         max_result_rows = 100000,
         max_bytes_before_external_group_by = 2000000000;

max_bytes_before_external_group_by es el que evita que una agregación enorme muera: a partir de ese umbral vuelca a disco en vez de reventar. Pero no lo escribas consulta a consulta: eso es la sección 9.

Y si tienes un dashboard que repite la misma consulta cada quince segundos, la caché de consultas sale casi gratis:

SELECT count() FROM events WHERE tenant_id = 7
SETTINGS use_query_cache = 1, query_cache_ttl = 60;

7. Índice de salto, proyección o vista materializada

Cuando aparece un segundo patrón de acceso, hay cuatro respuestas posibles y cada una te cobra algo distinto. Elegir mal aquí es el error de arquitectura más caro de revertir.

Índice de salto

ALTER TABLE events
    ADD INDEX idx_user user_id TYPE bloom_filter(0.01) GRANULARITY 4;

ALTER TABLE events MATERIALIZE INDEX idx_user SETTINGS mutations_sync = 2;

Barato en disco, pero inútil si es poco selectivo: si el valor buscado aparece en casi todos los granules, el índice no descarta nada y solo has añadido coste de escritura. El GRANULARITY del índice multiplica los granules que cubre cada entrada; afinarlo importa tanto como el tipo. Verifícalo siempre con EXPLAIN indexes = 1.

Proyección

Una proyección es una segunda copia de los datos con otra ORDER BY, mantenida por el propio motor durante los merges:

ALTER TABLE events ADD PROJECTION by_user
(
    SELECT tenant_id, user_id, event_time, duration_ms
    ORDER BY (user_id, event_time)
);

ALTER TABLE events MATERIALIZE PROJECTION by_user
SETTINGS mutations_sync = 2;

Medido sobre la misma tabla, con y sin proyección para un filtro por user_id:

modo               marcas  filas leídas   bytes leídos
con proyección          3      24.580         192 KiB
sin proyección         16     131.070        1,00 MiB

Para comprobar que el optimizador la está usando de verdad, hay dos herramientas: EXPLAIN projections = 1, que muestra ReadFromMergeTree (by_user) cuando entra, y SETTINGS force_optimize_projection = 1, que hace fallar la consulta si ninguna proyección se aplica. Esa segunda es perfecta para un test de regresión en CI.

El precio: duplica el almacenamiento de las columnas proyectadas y no se combina con FINAL.

Vista materializada

Una vista materializada en ClickHouse es un trigger de inserción: se dispara con cada bloque insertado en la tabla origen y escribe en la tabla destino.

CREATE TABLE events_por_hora
(
    tenant_id  UInt32,
    hora       DateTime,
    eventos    AggregateFunction(count),
    usuarios   AggregateFunction(uniq, UInt64),
    ingresos   AggregateFunction(sum, Decimal(18,4))
)
ENGINE = AggregatingMergeTree
ORDER BY (tenant_id, hora);

CREATE MATERIALIZED VIEW mv_events_por_hora TO events_por_hora AS
SELECT
    tenant_id,
    toStartOfHour(event_time) AS hora,
    countState()              AS eventos,
    uniqState(user_id)        AS usuarios,
    sumState(revenue)         AS ingresos
FROM events
GROUP BY tenant_id, hora;

Dos consecuencias que la gente descubre tarde. La primera: no reprocesa el histórico, solo ve lo que entra a partir de su creación. El backfill lo haces tú, a mano, y conviene hacerlo por rangos para no comerte la memoria:

INSERT INTO events_por_hora
SELECT
    tenant_id,
    toStartOfHour(event_time) AS hora,
    countState(),
    uniqState(user_id),
    sumState(revenue)
FROM events
WHERE event_time >= '2026-01-01' AND event_time < '2026-02-01'
GROUP BY tenant_id, hora;

La segunda: si la vista falla o es lenta, frena la ingesta de la tabla origen. Una vista materializada mal hecha no te da consultas lentas, te da un pipeline caído. Mantenlas simples: una vista, una agregación.

Y se lee siempre con las funciones -Merge, nunca directamente:

SELECT
    tenant_id,
    countMerge(eventos)  AS eventos,
    uniqMerge(usuarios)  AS usuarios,
    sumMerge(ingresos)   AS ingresos
FROM events_por_hora
WHERE hora >= now() - INTERVAL 7 DAY
GROUP BY tenant_id;

Tabla aparte

Cuando el patrón de acceso es tan distinto que nada de lo anterior encaja, la respuesta honesta es una segunda tabla alimentada por su propia vista materializada. Doble ingesta y doble almacenamiento, sí, pero sin parches que se rompen a los seis meses.

8. Clúster: replicación, Keeper y consultas distribuidas

ReplicatedMergeTree y al menos dos réplicas para cualquier dato que te importe. La coordinación va con ClickHouse Keeper, no ZooKeeper, con 3 o 5 nodos (número impar) y disco rápido, porque es sensible a la latencia. Usa macros {shard} y {replica} en las rutas de las tablas replicadas para que el mismo DDL funcione en todo el clúster.

La clave de sharding importa más de lo que parece

CREATE TABLE events_distributed AS events
ENGINE = Distributed('default', currentDatabase(), events,
                     cityHash64(tenant_id));

Si repartes con rand(), los datos quedan perfectamente equilibrados y cada agregación por tenant tiene que cruzar la red. Si repartes con el hash de la columna por la que agrupas, cada shard puede resolver sus grupos en local. El precio es el desequilibrio: un tenant gigante satura su shard. Elige sabiendo lo que pagas.

Dónde se ejecuta cada parte de la consulta

El iniciador reparte la consulta a los shards, cada shard agrega lo suyo sobre su tabla local, y el merge final ocurre en un único nodo. De ahí se derivan tres reglas:

• El nodo iniciador no debería ser también un nodo de ingesta pesada.

• Inserta en la tabla local de cada shard cuando puedas, en vez de en la Distributed.

• Una subconsulta en un IN o un JOIN se resuelve en cada shard por separado, lo que multiplica el trabajo y puede dar resultados incompletos. Para eso están GLOBAL IN y GLOBAL JOIN, que la resuelven una vez en el iniciador y reparten el resultado.

SELECT count()
FROM clusterAllReplicas('default', currentDatabase(), events)
WHERE user_id GLOBAL IN (SELECT id FROM estados);

9. Seguridad, cuotas y multi-tenancy

Esta es la sección que falta en casi todas las guías de ClickHouse, y la que más caro sale olvidar. Una base analítica acaba siempre con herramientas de BI, cuadernos de datos y gente del negocio conectada. Si solo tienes el usuario default, lo que tienes es un incidente pendiente de fecha.

Son tres capas distintas y ninguna sustituye a las otras.

El perfil de ajustes limita cada consulta individual:

CREATE SETTINGS PROFILE bi_readonly SETTINGS
    max_execution_time = 30,
    max_memory_usage = 4000000000,
    max_rows_to_read = 500000000,
    max_result_rows = 100000,
    readonly = 1;

CREATE USER bi IDENTIFIED WITH sha256_password BY 'cambia-esto'
    SETTINGS PROFILE bi_readonly;

GRANT SELECT ON default.events TO bi;

La cuota limita el consumo acumulado en una ventana de tiempo, que es lo que el perfil no puede ver. Mil consultas de treinta segundos cada una pasan todos los límites por consulta y aun así tumban el clúster:

CREATE QUOTA bi_hora
    FOR INTERVAL 1 HOUR MAX queries = 1000, read_rows = 5000000000
    TO bi;

La política de filas decide qué filas existen para quién. Se aplica siempre, también en SELECT *, y es la única forma seria de hacer multi-tenancy sobre una tabla compartida:

CREATE ROW POLICY solo_mi_tenant ON default.events
    USING tenant_id = 5
    TO bi;

Un tenant que puede leer las filas de otro no es un bug de la aplicación: es un fallo de diseño del esquema. Y revisa lo que hay puesto de verdad, que la deriva de configuración es real:

SELECT short_name, database, table, select_filter, is_restrictive, apply_to_list
FROM system.row_policies
WHERE table = 'events';

Tres reglas más: el usuario default sin contraseña no sale del entorno de desarrollo, cada herramienta externa tiene su propio usuario (si todas comparten uno, no puedes revocar ni medir nada), y los permisos se dan sobre tablas concretas, nunca GRANT ALL ON *.* “mientras probamos”.

10. Migraciones de esquema y backups que restauran

No todos los ALTER cuestan lo mismo

Añadir una columna es una operación de metadatos: instantánea, sin reescribir nada.

ALTER TABLE events ADD COLUMN pais LowCardinality(String) DEFAULT '';

Cambiar el tipo de una columna es una mutación: reescribe todas las partes afectadas.

ALTER TABLE events MODIFY COLUMN duration_ms UInt64
SETTINGS mutations_sync = 2;

En una tabla de mil millones de filas, lo primero tarda milisegundos y lo segundo puede tardar horas y saturar el pool de merges. Antes de lanzar un MODIFY COLUMN en producción, pruébalo sobre una copia de una partición y mide. Y usa ON CLUSTER para la DDL distribuida, verificando después system.distributed_ddl_queue, porque un DDL que falla en un solo nodo deja el clúster inconsistente en silencio.

Si necesitas tocar un límite solo en una tabla, no cambies el servidor entero:

ALTER TABLE events MODIFY SETTING parts_to_throw_insert = 3000;

Un backup que no has restaurado no es un backup

BACKUP necesita un disco declarado explícitamente como permitido; sin esa configuración el comando falla, y descubrirlo el día del incidente es tarde:

<!-- /etc/clickhouse-server/config.d/backups.xml -->
<clickhouse>
    <storage_configuration>
        <disks>
            <backups>
                <type>local</type>
                <path>/var/lib/clickhouse/backups/</path>
            </backups>
        </disks>
    </storage_configuration>
    <backups>
        <allowed_disk>backups</allowed_disk>
    </backups>
</clickhouse>

Con eso, el ciclo completo funciona, y es exactamente el que deberías ensayar en un entorno de pruebas cada trimestre:

BACKUP TABLE estados TO Disk('backups', 'estados.zip');

DROP TABLE estados SYNC;

RESTORE TABLE estados FROM Disk('backups', 'estados.zip');

En producción, cambia Disk('backups', ...) por S3(...) y añade ASYNC para no bloquear la sesión. Lo que no cambia es la regla: si nunca has ejecutado el RESTORE, no tienes copia de seguridad, tienes una carpeta.

11. Observabilidad: las consultas que debes tener a mano

La métrica de salud número uno es el número de partes activas:

SELECT
    database,
    table,
    count() AS partes,
    sum(rows) AS filas,
    formatReadableSize(sum(bytes_on_disk)) AS tamano
FROM system.parts
WHERE active AND database = currentDatabase()
GROUP BY database, table
ORDER BY partes DESC;

Las consultas más caras, agrupadas por forma y no por texto literal, que es lo que hace útil a normalized_query_hash:

SELECT
    normalized_query_hash,
    count() AS ejecuciones,
    formatReadableSize(avg(memory_usage)) AS memoria_media,
    round(avg(query_duration_ms)) AS ms_medios,
    formatReadableQuantity(avg(read_rows)) AS filas_leidas
FROM system.query_log
WHERE type = 'QueryFinish' AND event_time >= now() - INTERVAL 1 DAY
GROUP BY normalized_query_hash
ORDER BY avg(query_duration_ms) DESC
LIMIT 20;

Y la consulta que convierte “me parece que va lento” en un número: cuántas marcas y cuántas filas tocó de verdad una consulta concreta.

SELECT
    ProfileEvents['SelectedMarks']    AS marcas,
    ProfileEvents['SelectedRanges']   AS rangos,
    formatReadableQuantity(read_rows) AS filas_leidas,
    formatReadableSize(read_bytes)    AS bytes_leidos
FROM system.query_log
WHERE type = 'QueryFinish'
  AND query LIKE '%FROM events WHERE tenant_id = 5%'
  AND event_time >= now() - INTERVAL 10 MINUTE
ORDER BY event_time DESC
LIMIT 1;

Esta es, de lejos, la herramienta más infrautilizada de ClickHouse. Todas las cifras de este artículo salen de ahí.

Y una advertencia sobre el propio query_log: en la imagen oficial se crea sin TTL. Crece hasta que se llena el disco, y entonces pierdes a la vez la base de datos y el histórico que te habría dicho por qué. Compruébalo y ponle fecha de caducidad:

SELECT engine_full FROM system.tables
WHERE database = 'system' AND name = 'query_log';

El resto del arsenal: system.merges y system.mutations para el almacenamiento, system.replication_queue y system.replicas para el retraso de replicación, system.kafka_consumers si ingieres de Kafka, system.errors para lo que realmente está fallando, y system.asynchronous_metrics para alimentar Prometheus y Grafana.

Alerta sobre cinco cosas y dormirás tranquilo: partes activas, retraso de replicación, mutaciones sin terminar, memoria del servidor y espacio en disco.

En el host, lo de siempre: NVMe para datos calientes, almacenamiento por niveles para el resto, swap desactivado, max_server_memory_usage en torno al 80% de la RAM, límite de ficheros abiertos alto y transparent huge pages desactivadas.

12. Antipatrones: lo que nunca debes hacer

• Usar ClickHouse como base OLTP: no hay transacciones multi-sentencia, ni actualizaciones puntuales rápidas, ni unicidad garantizada.

• Usarlo como key-value store para leer una fila por clave. Para eso está Redis.

• Insertar fila por fila sin async_insert.

• Hacer SELECT a una tabla con ENGINE = Kafka.

• Ejecutar OPTIMIZE FINAL en un cron.

• Dejar SELECT * en código de aplicación.

• Particionar por una columna de alta cardinalidad.

• Confiar en que ReplacingMergeTree deduplica al instante.

• Permitir consultas sin perfil de ajustes ni cuota.

• Dar acceso a herramientas externas con el usuario default.

• Guardar DateTime sin zona horaria explícita.

• Dejar system.query_log sin TTL.

• Tener un solo nodo, sin réplicas, para datos que no puedes perder.

• Llamar backup a algo que nunca has restaurado.

• Asumir que la clave primaria es única. En ClickHouse no lo es.

13. Preguntas frecuentes

¿Sirve ClickHouse como base de datos transaccional?

No. ClickHouse es una base analítica (OLAP) orientada a columnas. No tiene transacciones multi-sentencia, las actualizaciones por fila son mutaciones asíncronas que reescriben partes enteras, y la clave primaria no impone unicidad. Para OLTP, usa PostgreSQL o MySQL y replica hacia ClickHouse lo que necesites analizar.

¿Cada cuánto debo insertar en ClickHouse?

Como mucho una vez por segundo y por tabla desde cada productor, con lotes de 10.000 filas o más. Si tu arquitectura no te deja agrupar, activa async_insert = 1 y deja que el servidor lo haga por ti.

¿Qué significa el error TOO_MANY_PARTS?

Que estás creando partes más rápido de lo que el motor puede fusionarlas. En las versiones actuales, ClickHouse empieza a retrasar los INSERT a partir de 1.000 partes activas por partición y los rechaza a partir de 3.000. Casi siempre la causa es ingesta fila por fila o una partición de cardinalidad demasiado alta. La solución es arreglar la ingesta, no subir el límite.

¿Cuántas columnas debe tener la ORDER BY?

Entre dos y cuatro, ordenadas de menor a mayor cardinalidad, empezando por lo que siempre filtras. Más columnas encarecen los merges sin mejorar la poda.

¿Cuándo uso una vista materializada y cuándo una proyección?

Proyección si necesitas otra ORDER BY sobre los mismos datos y quieres que el motor la mantenga solo. Vista materializada si lo que repites son agregaciones y quieres preagregar en el momento de la ingesta. Si el patrón es completamente distinto, una tabla aparte.

¿Por qué mi consulta con FINAL va lenta?

Porque FINAL fusiona las partes en tiempo de consulta para darte la última versión de cada fila. Sustitúyelo por una agregación explícita con argMax y GROUP BY, cuidando de que los alias no se llamen igual que las columnas agregadas.

¿Cómo aíslo a varios clientes en la misma tabla de ClickHouse?

Con una política de filas (CREATE ROW POLICY ... USING tenant_id = ...) por usuario, además de un perfil de ajustes y una cuota. Filtrar por tenant solo en la aplicación no es aislamiento: cualquier consulta directa se lo salta.

¿Cómo leo de Kafka sin perder mensajes?

Con tres objetos: una tabla ENGINE = Kafka, una vista materializada y una tabla MergeTree de destino. Nunca consultes directamente la tabla Kafka, porque cada lectura consume del topic.

¿ClickHouse necesita índices como PostgreSQL?

No en el mismo sentido. El índice primario es disperso y se deriva de la ORDER BY; no hay índices B-tree por fila. Los índices de salto son un complemento para columnas fuera de la clave, y solo valen la pena si son muy selectivos.

14. La lista, en una pantalla

Cómo reproducir todo esto en tu máquina

Todo el SQL de este artículo —56 bloques, incluidas las mediciones, los backups y la seguridad— se ejecutó contra ClickHouse 26.9 antes de publicarlo. Puedes repetirlo en cinco minutos:

docker run -d --name ch-blog \
  --ulimit nofile=262144:262144 \
  clickhouse/clickhouse-server:latest

docker exec -it ch-blog clickhouse-client

Crea la tabla events de la sección 1, cárgala con datos sintéticos y mide tú mismo:

INSERT INTO events
SELECT
    number % 50                                   AS tenant_id,
    ['click','view','purchase'][number % 3 + 1]   AS event_type,
    number % 100000                               AS user_id,
    now() - toIntervalSecond(number % 5184000)    AS event_time,
    number % 900                                  AS duration_ms,
    toDecimal64(number % 100, 4)                  AS revenue,
    repeat('x', 40)                               AS payload
FROM numbers(2000000);

Dos millones de filas en unos segundos, y ya puedes comparar planes con EXPLAIN indexes = 1 y marcas leídas en system.query_log. Medir en tu propio hardware, con tu propio esquema, vale más que cualquier lista de buenas prácticas. Incluida esta.

Si cumples esta guía, ClickHouse te devuelve agregaciones sobre miles de millones de filas en menos de un segundo. Si no, vas a culpar a la base de datos de algo que está escrito en tu CREATE TABLE.

La documentación oficial de ClickHouse es excelente y conviene tenerla cerca, sobre todo las páginas de MergeTree, vistas materializadas y control de acceso.

¿Te has peleado con alguno de estos puntos en producción? Cuéntamelo en los comentarios: la lista está viva, y hay errores que solo se aprenden a las tres de la mañana.

Registrar 300 millones de transacciones al mes no es lo difícil; un Postgres bien afinado lo aguanta. Lo difícil llega el 31 de diciembre, cuando alguien pide el balance de comprobación de un año con 3600 millones de transacciones y más de 7200 millones de líneas de asiento, mientras siguen entrando pagos como cualquier otro día.

Aquí cuento cómo lo resolví con ClickHouse Cloud, con el SQL que probé.

Todo el SQL corre en ClickHouse 26.9, PostgreSQL 17 y la extensión pg_clickhouse sobre PostgreSQL 18, y las capturas son de ejecuciones reales. El procedimiento incluye cómo responder a los fallos del CDC (ClickPipes), que reproduje uno por uno.

1. El problema de escala

Trescientos millones de transacciones al mes son unas 115 por segundo. El problema es lo que se acumula durante el año y lo que hay que leer para cerrarlo.

El balance de comprobación agrega todas esas líneas por cuenta. La conciliación compara miles de millones de registros con los extractos de bancos y pasarelas. La diferencia en cambio revalúa cada saldo monetario en moneda extranjera. Y la auditoría pide rastrear cualquier saldo hasta su transacción de origen.

Una base de datos orientada a filas, como PostgreSQL, MySQL u Oracle, lee todas las columnas de cada fila aunque la consulta solo necesite tres. De ahí que los cierres tradicionales vivan de procesos nocturnos, tablas de resumen mantenidas a mano y equipos trabajando el fin de semana de fin de año. ClickHouse es columnar: lee solo las columnas que pide la consulta, las comprime muy bien (cuentas, monedas y centros de costo se repiten muchísimo) y agrega en paralelo.

2. La arquitectura

Postgres registra cada transacción con garantías ACID: valida el saldo disponible, bloquea la cuenta, aplica la clave de idempotencia y confirma. El CDC (captura de cambios) lleva a ClickHouse cada cambio que hace COMMIT, en torno a un minuto con la configuración por defecto. ClickHouse guarda el histórico completo, genera los asientos, mantiene los saldos y responde las consultas del cierre, la conciliación y los reportes.

ClickHouse no reemplaza al motor transaccional: no tiene transacciones de varias sentencias, ni claves foráneas, ni bloqueos de fila. Para leer un saldo, validarlo y descontarlo está Postgres. ClickHouse entra cuando hay que agregar miles de millones de filas en segundos.

3. El modelo de datos

Todo vive en una base de datos llamada finance. Los identificadores y comentarios del código están en inglés, que es lo habitual en equipos mixtos.

3.1 El dinero como enteros en unidades menores

Las APIs de pago modernas representan cada importe como un entero en la unidad más pequeña de la moneda, junto con su código ISO 4217. Diez dólares son 1000, porque el dólar tiene dos decimales. Uso la misma convención: los enteros no tienen errores de redondeo, se suman y comparan sin sorpresas, y quedan alineados con las pasarelas de pago.

Donde más veo errores es en los decimales de cada moneda. Según la lista oficial de ISO 4217, el peso colombiano tiene dos, igual que el dólar. O sea que 1 234 567 pesos se guardan como 123456700. Si guardas 1234567 creyendo que el peso no tiene decimales, cualquier integración con una pasarela cobra cien veces menos.

El yen y el peso chileno no tienen decimales, y el dinar kuwaití tiene tres. Por eso el número de decimales nunca va como un /100 fijo en el código: se lee de una tabla de referencia.

Esa tabla vive en Postgres con el resto de los datos de referencia:

-- PostgreSQL: ISO 4217 reference data
CREATE TABLE currencies (
    code         char(3)  PRIMARY KEY,  -- alphabetic code
    numeric_code smallint NOT NULL,     -- numeric code
    minor_units  smallint NOT NULL      -- decimal places
);

INSERT INTO currencies VALUES
    ('COP', 170, 2), ('USD', 840, 2), ('EUR', 978, 2),
    ('JPY', 392, 0), ('CLP', 152, 0), ('KWD', 414, 3);

ClickHouse la lee como un diccionario en memoria. Las credenciales de Postgres van en una named collection que crea un administrador una sola vez, y ninguna consulta posterior las repite:

-- ClickHouse: created once by an administrator
CREATE NAMED COLLECTION pg_finance AS
    host = 'pg-finance.internal',
    port = 5432,
    user = 'clickhouse_reader',
    password = '***',
    database = 'accounting';

CREATE DATABASE IF NOT EXISTS finance;

CREATE DICTIONARY finance.currency_dict
(
    code        String,
    minor_units UInt8
)
PRIMARY KEY code
SOURCE(POSTGRESQL(NAME pg_finance TABLE 'currencies'))
LIFETIME(MIN 3600 MAX 7200)
LAYOUT(COMPLEX_KEY_HASHED());

Las tasas de cambio sí necesitan decimales y las guardo como Decimal(18, 10). Para convertir entre monedas escribí una función que respeta los decimales de cada una, redondea una sola vez al final y falla si la moneda no existe en el diccionario. Esto último importa: un dictGet sobre una clave ausente devuelve 0, que aquí significaría cero decimales, justo el error de cien veces.

-- Converts an amount in minor units between currencies.
-- rate = units of to_ccy per one unit of from_ccy.
CREATE FUNCTION convert_minor AS
    (amount_minor, from_ccy, to_ccy, rate) ->
    toInt64(round(
        toDecimal256(amount_minor, 0) * rate
        * intExp10(dictGet('finance.currency_dict',
                           'minor_units', toString(to_ccy))
            + throwIf(NOT dictHas('finance.currency_dict',
                                  toString(to_ccy)),
                      'Unknown currency'))
        / intExp10(dictGet('finance.currency_dict',
                           'minor_units', toString(from_ccy))
            + throwIf(NOT dictHas('finance.currency_dict',
                                  toString(from_ccy)),
                      'Unknown currency')),
        0));

Al probarla me encontré con tres comportamientos de ClickHouse que no esperaba:

• Multiplicar un Int64 por un Decimal64 da un Decimal(18, 10), que solo tiene ocho dígitos enteros; con importes grandes la consulta falla con Decimal math overflow. En Decimal128 y Decimal256 pasa lo contrario: ClickHouse no comprueba el desbordamiento, lo dice su documentación y lo vi en una multiplicación de Decimal128 que devolvió un número negativo sin error. La función trabaja en Decimal256, cuyo rango cubre cualquier Int64 por cualquier tasa, y deja que el toInt64 final falle si el resultado no cabe.

• round sobre un decimal redondea alejándose de cero (2,5 pasa a 3 y −2,5 a −3), pero convertir a otra escala con toDecimal128(x, 4) trunca.

• sum() sobre Int64 desborda sin error al pasar de 9,2 × 10¹⁸, unos 92 000 billones de pesos. Ninguna entidad llega ahí en un año, y los controles del cierre lo detectarían.

  

  3.2 La fuente: transacciones en Postgres

  Postgres es la fuente de verdad. Cada transacción guarda su importe en moneda de la transacción y en moneda funcional (amount_lcy_minor, COP en los ejemplos), calculado con la tasa vigente en event_ts.

  -- PostgreSQL: monthly period status per entity
  CREATE TABLE accounting_periods (
      entity_id  text    NOT NULL,
      period     integer NOT NULL,  -- e.g. 202612
      status     text    NOT NULL
          CHECK (status IN ('OPEN', 'CLOSING', 'CLOSED')),
      closed_by  text,
      closed_at  timestamptz,
      PRIMARY KEY (entity_id, period)
  );
  
  CREATE TABLE accounts (
      id                      bigint PRIMARY KEY,
      available_balance_minor bigint NOT NULL
  );
  
  CREATE TABLE transactions (
      tx_id            uuid    PRIMARY KEY,
      idempotency_key  uuid    NOT NULL UNIQUE,
      entity_id        text    NOT NULL,
      channel          text    NOT NULL,
      tx_type          text    NOT NULL,
      event_ts         timestamptz NOT NULL DEFAULT now(),
      accounting_date  date    NOT NULL,
      account_id       bigint  NOT NULL REFERENCES accounts (id),
      debit_account    bigint  NOT NULL,
      credit_account   bigint  NOT NULL,
      cost_center      text    NOT NULL,
      counterparty_id  bigint  NOT NULL,
      currency         char(3) NOT NULL
          CHECK (currency ~ '^[A-Z]{3}$'),
      amount_minor     bigint  NOT NULL
          CHECK (amount_minor > 0),
      amount_lcy_minor bigint  NOT NULL
          CHECK (amount_lcy_minor > 0),
      -- corrections are new rows with tx_type = 'REVERSAL'
      status           text    NOT NULL
          CHECK (status IN ('PENDING', 'CONFIRMED',
                            'REJECTED'))
  );
  
  -- Confirmed or rejected rows are final, only the status of
  -- a pending row may change, and only OPEN periods accept
  -- new or newly confirmed operations.
  CREATE FUNCTION guard_transactions() RETURNS trigger
  LANGUAGE plpgsql AS $$
  BEGIN
      IF TG_OP IN ('UPDATE', 'DELETE')
         AND OLD.status IN ('CONFIRMED', 'REJECTED') THEN
          RAISE EXCEPTION 'transaction % is final', OLD.tx_id;
      END IF;
      IF TG_OP = 'DELETE' THEN
          RETURN OLD;
      END IF;
      IF TG_OP = 'UPDATE' AND
         (NEW.tx_id, NEW.entity_id, NEW.accounting_date,
          NEW.debit_account, NEW.credit_account, NEW.currency,
          NEW.amount_minor, NEW.amount_lcy_minor)
         IS DISTINCT FROM
         (OLD.tx_id, OLD.entity_id, OLD.accounting_date,
          OLD.debit_account, OLD.credit_account, OLD.currency,
          OLD.amount_minor, OLD.amount_lcy_minor) THEN
          RAISE EXCEPTION 'only the status can change';
      END IF;
      IF NEW.status <> 'REJECTED' AND NOT EXISTS (
          SELECT 1 FROM accounting_periods p
          WHERE p.entity_id = NEW.entity_id
            AND p.period = to_char(NEW.accounting_date,
                                   'YYYYMM')::integer
            AND p.status = 'OPEN') THEN
          RAISE EXCEPTION 'period of % is not open', NEW.tx_id;
      END IF;
      RETURN NEW;
  END;
  $$;
  
  CREATE TRIGGER transactions_guard
      BEFORE INSERT OR UPDATE OR DELETE ON transactions
      FOR EACH ROW EXECUTE FUNCTION guard_transactions();

  Todo lo que sigue depende de este disparador. Una transacción confirmada o rechazada no se modifica ni se borra; de una pendiente solo cambia el estado; y nada se confirma en un periodo que no esté abierto. Las correcciones son transacciones de reversión nuevas. Para que nadie lo salte, el rol de la aplicación no es dueño de la tabla (no puede desactivar el disparador), no puede cambiar session_replication_role y no tiene permiso de TRUNCATE.

  Este es el registro de un débito con control de saldo:

  -- $1 account_id, $2 amount_minor (COP), $3 tx_id,
  -- $4 idempotency_key, $5 entity_id, $6 accounting_date,
  -- $7 debit_account, $8 credit_account, $9 counterparty_id
  BEGIN;
  
  SELECT available_balance_minor
  FROM accounts
  WHERE id = $1
  FOR UPDATE;
  
  -- the application checks available_balance_minor >= $2
  
  INSERT INTO transactions
      (tx_id, idempotency_key, entity_id, channel, tx_type,
       accounting_date, account_id, debit_account,
       credit_account, cost_center, counterparty_id,
       currency, amount_minor, amount_lcy_minor, status)
  VALUES ($3, $4, $5, 'API', 'PAYMENT', $6, $1, $7, $8,
          'CC100', $9, 'COP', $2, $2, 'CONFIRMED');
  
  UPDATE accounts
  SET available_balance_minor = available_balance_minor - $2
  WHERE id = $1;
  
  COMMIT;

  Los comprobantes que genera el cierre (diferencia en cambio, cierre de resultados y apertura) se calculan en ClickHouse en una tabla de preparación, se aprueban en Postgres con sus totales a la vista y solo entonces se insertan en el libro. Así tienen consecutivo, quién los preparó, quién los aprobó y cuándo, y el cierre comprueba que ninguna línea manual entró sin aprobación:

  -- PostgreSQL: header of every manual voucher
  CREATE TABLE journal_vouchers (
      tx_id        uuid    PRIMARY KEY,
      voucher_no   bigint  GENERATED ALWAYS AS IDENTITY UNIQUE,
      period       integer NOT NULL,
      kind         text    NOT NULL
          CHECK (kind IN ('ADJUSTMENT', 'CLOSING', 'OPENING')),
      description  text    NOT NULL,
      prepared_by  text    NOT NULL,
      approved_by  text,
      approved_at  timestamptz,
      CHECK (approved_by IS NULL OR approved_by <> prepared_by)
  );

  Si la pasarela de pagos ya envía los importes en unidades menores, se guardan tal cual. Solo hay que normalizar la moneda a mayúsculas, convertir las marcas de tiempo en segundos Unix a timestamptz y guardar los identificadores de la pasarela como texto opaco.

  3.3 La tabla de transacciones en ClickHouse

  Las transacciones llegan por el CDC de ClickPipes, que escribe en una tabla ReplacingMergeTree con tres columnas propias. Yo creo la tabla vacía antes de agregarla a la replicación, con los tipos que corresponden al mapeo documentado de ClickPipes (bigint pasa a Int64, uuid a UUID, text a String, date a Date y timestamptz a DateTime64(6)), porque las vistas materializadas tienen que existir antes de la carga inicial; si no, el histórico no pasa por ellas. ClickPipes solo rechaza una tabla existente si tiene datos. Después de agregarla, compara el resultado de SHOW CREATE TABLE finance.transactions con esta definición.

  -- Destination of the ClickPipes CDC for public.transactions
  -- (create it empty, then add the table to the pipe)
  CREATE TABLE finance.transactions
  (
      tx_id              UUID,
      idempotency_key    UUID,
      entity_id          String,
      channel            String,
      tx_type            String,
      event_ts           DateTime64(6),
      accounting_date    Date,
      account_id         Int64,
      debit_account      Int64,
      credit_account     Int64,
      cost_center        String,
      counterparty_id    Int64,
      currency           String,
      amount_minor       Int64,
      amount_lcy_minor   Int64,
      status             String,
      _peerdb_synced_at  DateTime64(9) DEFAULT now64(),
      _peerdb_is_deleted Int8,
      _peerdb_version    Int64
  )
  ENGINE = ReplacingMergeTree(_peerdb_version)
  PARTITION BY toYYYYMM(accounting_date)
  ORDER BY tx_id;

  ReplacingMergeTree se queda con la versión más reciente de cada fila, pero lo hace durante las fusiones, cuando el motor decide. Toda consulta que necesite exactitud lee con FINAL. La clave de ordenación es la clave primaria de Postgres, la que ClickPipes usa por defecto, así que no hay que tocar la REPLICA IDENTITY. La partición es el mes contable, y como el disparador impide cambiar la fecha contable, todas las versiones de una transacción caen en la misma partición. Eso permite leer con do_not_merge_across_partitions_select_final = 1, que abarata mucho el FINAL. La única excepción son los borrados de filas pendientes, que llegan sin fecha y no afectan a nada porque los filtros piden transacciones confirmadas. Las columnas _peerdb_* son de ClickPipes. Su documentación las declara Int8 e Int64, y el código de PeerDB las crea como UInt8 y UInt64; ninguna consulta de este artículo depende de esa diferencia.

  Las fechas siguen ISO 8601: los instantes se guardan en UTC y la fecha contable se calcula en la zona horaria de la entidad. Un pago del 2026-10-01T02:00:00Z es del 30 de septiembre en Bogotá, y ese detalle mueve el cierre de mes:

  SELECT toDate(
      toDateTime64('2026-10-01 02:00:00', 3, 'UTC'),
      'America/Bogota') AS accounting_date;
  -- 2026-09-30

  3.4 La partida doble con vistas materializadas

  

Las vistas materializadas de ClickHouse son incrementales: se disparan con cada bloque insertado y procesan solo los datos nuevos. La documentación de ClickPipes las propone como disparadores sobre las tablas del CDC. Una vista se dispara con cada bloque que llega, aunque repita filas, y el CDC repite filas. Por eso guardo las líneas de asiento de forma que una línea repetida se colapse sola:

CREATE TABLE finance.journal_entries
(
    tx_id            UUID,
    line_no          UInt32,
    entity_id        LowCardinality(String),
    accounting_date  Date,
    event_ts         DateTime64(3, 'UTC'),
    account          Int64,
    cost_center      LowCardinality(String),
    counterparty_id  Int64,
    currency         LowCardinality(String),
    debit_minor      Int64,
    credit_minor     Int64,
    debit_lcy_minor  Int64,
    credit_lcy_minor Int64,
    source           LowCardinality(String),
    -- source: OPERATION, ADJUSTMENT, CLOSING, OPENING
    src_version      UInt64,  -- CDC version, 0 for manual
    posted_by        LowCardinality(String)
        DEFAULT currentUser(),
    posted_at        DateTime64(3, 'UTC') DEFAULT now64(3)
)
ENGINE = ReplacingMergeTree(src_version)
PARTITION BY toYYYYMM(accounting_date)
ORDER BY (entity_id, account, accounting_date, tx_id, line_no);

CREATE MATERIALIZED VIEW finance.mv_journal_entries
TO finance.journal_entries AS
SELECT
    tx_id,
    line.1 AS line_no,
    entity_id,
    accounting_date,
    event_ts,
    line.2 AS account,
    cost_center,
    counterparty_id,
    currency,
    line.3 AS debit_minor,
    line.4 AS credit_minor,
    line.5 AS debit_lcy_minor,
    line.6 AS credit_lcy_minor,
    'OPERATION' AS source,
    toUInt64(_peerdb_version) AS src_version
FROM finance.transactions
ARRAY JOIN [
    (toUInt32(1), debit_account, amount_minor, toInt64(0),
     amount_lcy_minor, toInt64(0)),
    (toUInt32(2), credit_account, toInt64(0), amount_minor,
     toInt64(0), amount_lcy_minor)
] AS line
WHERE status = 'CONFIRMED'
  AND _peerdb_is_deleted = 0;

ARRAY JOIN convierte cada transacción en varias líneas dentro del mismo bloque. Si una transacción lleva IVA, retención y comisión, el arreglo tiene cuatro o cinco tuplas y el patrón no cambia. Como todas las columnas de la clave salen de una transacción que no cambia, una línea repetida por el CDC tiene la misma clave que la original y ReplacingMergeTree deja una sola. posted_by y posted_at registran quién insertó cada línea y cuándo; en las líneas del CDC es el usuario de ClickPipes.

Un límite del modelo: cada transacción tiene una sola moneda y un solo importe en moneda funcional. Una compra de dólares con pesos, o el pago de una factura en dólares a una tasa distinta de la de causación, necesita un comprobante de varias líneas con una cuenta puente de posición por moneda y una línea en moneda funcional para la diferencia en cambio realizada.

Los saldos diarios se consolidan con SummingMergeTree:

CREATE TABLE finance.daily_balances
(
    entity_id        LowCardinality(String),
    account          Int64,
    cost_center      LowCardinality(String),
    currency         LowCardinality(String),
    accounting_date  Date,
    debit_minor      Int64,
    credit_minor     Int64,
    debit_lcy_minor  Int64,
    credit_lcy_minor Int64,
    entry_count      UInt64
)
ENGINE = SummingMergeTree((debit_minor, credit_minor,
    debit_lcy_minor, credit_lcy_minor, entry_count))
PARTITION BY toYYYYMM(accounting_date)
ORDER BY (entity_id, account, cost_center, currency,
          accounting_date);

CREATE MATERIALIZED VIEW finance.mv_daily_balances
TO finance.daily_balances AS
SELECT
    entity_id, account, cost_center, currency,
    accounting_date,
    sum(debit_minor)      AS debit_minor,
    sum(credit_minor)     AS credit_minor,
    sum(debit_lcy_minor)  AS debit_lcy_minor,
    sum(credit_lcy_minor) AS credit_lcy_minor,
    count()               AS entry_count
FROM finance.journal_entries
GROUP BY entity_id, account, cost_center, currency,
         accounting_date;

Los 7200 millones de líneas del año quedan en una fila por cuenta, centro de costo, moneda y día: decenas de millones de filas al año en lugar de miles de millones.

Ojo: esta tabla es un saldo provisional. Una suma no se puede deduplicar, y si el CDC repite un bloque, la línea repetida se colapsa en journal_entries pero su importe ya quedó sumado aquí. Antes de usarla para cerrar la reconstruyo desde las líneas deduplicadas. Está particionada por mes para poder reconstruir solo los meses afectados.

Para indicadores que no se pueden sumar, como clientes únicos o percentiles, uso AggregatingMergeTree, que guarda estados parciales combinables entre meses. Por la misma razón que los saldos, es un indicador de monitoreo: un bloque repetido cuenta dos veces su volumen.

CREATE TABLE finance.monthly_kpis
(
    entity_id        LowCardinality(String),
    month            Date,
    tx_type          LowCardinality(String),
    volume_lcy       AggregateFunction(sum, Int64),
    unique_customers AggregateFunction(uniq, Int64),
    ticket_quantiles AggregateFunction(
        quantiles(0.5, 0.95, 0.99), Int64)
)
ENGINE = AggregatingMergeTree
ORDER BY (entity_id, month, tx_type);

CREATE MATERIALIZED VIEW finance.mv_monthly_kpis
TO finance.monthly_kpis AS
SELECT
    entity_id,
    toStartOfMonth(accounting_date) AS month,
    tx_type,
    sumState(amount_lcy_minor)      AS volume_lcy,
    uniqState(counterparty_id)      AS unique_customers,
    -- approximate percentiles, enough for monitoring
    quantilesState(0.5, 0.95, 0.99)(amount_lcy_minor)
        AS ticket_quantiles
FROM finance.transactions
WHERE status = 'CONFIRMED'
  AND _peerdb_is_deleted = 0
GROUP BY entity_id, month, tx_type;

-- Read path: merge the partial states
SELECT
    month,
    tx_type,
    sumMerge(volume_lcy)        AS volume_lcy_minor,
    uniqMerge(unique_customers) AS customers,
    quantilesMerge(0.5, 0.95, 0.99)(ticket_quantiles)
        AS ticket_p50_p95_p99
FROM finance.monthly_kpis
WHERE entity_id = 'CO01' AND month >= '2026-01-01'
GROUP BY month, tx_type
ORDER BY month, tx_type;

3.5 El plan de cuentas como diccionario jerárquico

El plan de cuentas es un árbol: clase, grupo, cuenta, subcuenta y auxiliar. ClickHouse lo carga como diccionario jerárquico desde Postgres, con la misma named collection, y lo refresca solo. La clave de un diccionario jerárquico debe ser UInt64 y las cuentas raíz llevan parent_account = 0. Las cuentas del libro son Int64 (así las crea el CDC desde un bigint) y dictGet las acepta sin conversión; lo comprobé.

Uso códigos del PUC (Decreto 2650 de 1993) como ejemplo. Una entidad que reporta bajo NIIF puede tener su propio catálogo, y las vigiladas por la Superintendencia Financiera reportan con el CUIF, que tiene otros códigos. En producción, las cuentas especiales del cierre (diferencia en cambio, utilidad, pérdida) deberían salir de un atributo del plan de cuentas y no del SQL.

CREATE DICTIONARY finance.chart_of_accounts
(
    account        UInt64,
    parent_account UInt64 HIERARCHICAL,
    account_name   String,
    normal_side    String,  -- 'D' debit, 'C' credit
    account_class  UInt8,   -- 1 assets ... 6 cost of sales
    account_level  UInt8
)
PRIMARY KEY account
SOURCE(POSTGRESQL(NAME pg_finance TABLE 'chart_of_accounts'))
LIFETIME(MIN 300 MAX 600)
LAYOUT(HASHED());

Subir por la jerarquía es una búsqueda en memoria, sin consultas recursivas:

SELECT
    dictGetHierarchy('finance.chart_of_accounts', 11050501)
        AS ancestry,
    dictIsIn('finance.chart_of_accounts', 11050501, 1)
        AS is_asset;

3.6 Tasas de cambio con ASOF JOIN

Convertir a moneda funcional exige la tasa vigente en el instante de la transacción. ASOF JOIN busca, para cada fila, la tasa más reciente anterior o igual a ese instante. Lo uso como control de auditoría: recalculo el importe en pesos con la tasa de la mesa de cambios, que cambia durante el día, y lo comparo con el que registró el origen. La TRM, que rige un día completo, queda para la revaluación del cierre.

CREATE TABLE finance.fx_rates
(
    currency    LowCardinality(String),
    valid_from  DateTime64(3, 'UTC'),
    rate        Decimal(18, 10),  -- COP per unit
    rate_source LowCardinality(String)  -- 'DESK' or 'TRM'
)
ENGINE = ReplacingMergeTree
ORDER BY (currency, rate_source, valid_from);

SELECT
    t.tx_id,
    t.event_ts,
    t.currency,
    t.amount_minor,
    r.rate,
    convert_minor(t.amount_minor, t.currency, 'COP', r.rate)
        AS recalculated_lcy_minor,
    t.amount_lcy_minor,
    recalculated_lcy_minor - t.amount_lcy_minor
        AS difference_minor
FROM finance.transactions AS t FINAL
ASOF LEFT JOIN
(
    SELECT currency, valid_from, rate
    FROM finance.fx_rates
    WHERE rate_source = 'DESK'
) AS r
    ON t.currency = r.currency
   AND t.event_ts >= r.valid_from
WHERE t.accounting_date = '2026-12-31'
  AND t.currency != 'COP'
  AND t._peerdb_is_deleted = 0
SETTINGS do_not_merge_across_partitions_select_final = 1;

4. El CDC desde Postgres: ¿qué garantiza y qué no?

El CDC funciona casi siempre, y por eso es fácil suponer que cada fila llega exactamente una vez. ¿No es así?

4.1 ¿Cómo funciona?

ClickPipes lee el WAL de Postgres mediante un slot de replicación lógica y una publicación. Primero hace una carga inicial de cada tabla y luego aplica los cambios en lotes. Cada INSERT o UPDATE llega como una fila nueva con una versión mayor, y cada DELETE como una fila con _peerdb_is_deleted = 1. Cada replicación configurada se llama un pipe.

4.2 Requisitos en Postgres

ClickPipes admite Postgres 12 o superior, autoadministrado o en los servicios administrados más comunes, y se conecta directo al servidor: los poolers de conexiones como PgBouncer no sirven para CDC. En un Postgres propio, la decodificación lógica se activa así:

-- PostgreSQL (self-managed): enable logical decoding
ALTER SYSTEM SET wal_level = 'logical';
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_replication_slots = 10;
ALTER SYSTEM SET max_slot_wal_keep_size = '100GB';
-- restart PostgreSQL for wal_level to take effect

En un Postgres administrado, la replicación lógica se activa con el parámetro que define el proveedor, también con reinicio. Para el WAL retenido, la guía de instalación propone 100 GB y la FAQ pide al menos dos días de WAL o 200 GB; yo dimensiono con dos o tres veces el pico diario.

El usuario de ClickPipes necesita lectura sobre las tablas y permiso de replicación:

-- PostgreSQL: dedicated CDC user (password from a vault)
CREATE USER clickpipes_user PASSWORD '***';
GRANT USAGE ON SCHEMA public TO clickpipes_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public
    TO clickpipes_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT ON TABLES TO clickpipes_user;
ALTER USER clickpipes_user WITH REPLICATION;

Cada tabla replicada necesita clave primaria o REPLICA IDENTITY. ClickPipes crea por su cuenta la publicación y el slot para las tablas que eliges. Limita la duración de las transacciones con statement_timeout e idle_in_transaction_session_timeout: una transacción abierta durante horas retiene WAL en el slot.

4.3 Configuración del pipe

En ClickPipes elijo transactions, accounting_periods, journal_vouchers y parties, con la partición toYYYYMM(accounting_date) para transactions y sin las columnas cifradas de parties. Antes de crear el pipe, ten en cuenta:

• Después de crearlo puedes agregar o quitar tablas y ajustar el intervalo de sincronización y el tamaño de lote. La clave de ordenación, la partición, el motor y las columnas excluidas de cada tabla se fijan al agregarla; cambiarlos exige resincronizarla.

• El intervalo de sincronización es de 60 segundos por defecto y la documentación recomienda no bajarlo de 10. Un lote además espera el COMMIT de cada transacción de Postgres.

• Si una vista se crea después de la carga inicial, hay que rellenarla con el procedimiento de la sección 4.6.

4.4 Lo que el CDC no garantiza

Esto fue lo que más me costó entender, y de aquí sale el diseño de los asientos.

La entrega se comporta como “al menos una vez”. La FAQ de ClickPipes explica que, si se interrumpe la escritura en la tabla final, la deduplicación queda a cargo de ReplacingMergeTree. En el código de PeerDB, esa escritura es un INSERT ... SELECT por lote que no usa insert_deduplication_token y que marca el lote como terminado en una operación aparte. Si el proceso cae entre las dos, el lote se inserta otra vez con la misma versión. La tabla de transacciones lo resuelve en la siguiente fusión, pero las vistas materializadas se disparan de nuevo.

Una resincronización no pasa por las vistas. Resincronizar carga todo en tablas con sufijo _resync y luego las intercambia con las originales. Las vistas definidas sobre la tabla original no ven esa carga y sus tablas de destino pueden quedar con huecos.

Hay operaciones que no viajan. TRUNCATE se ignora; solo ADD COLUMN se propaga como cambio de esquema, y solo cuando la tabla recibe su siguiente cambio; las columnas generadas no se replican; y por defecto ninguna columna es Nullable, así que un NULL llega como el valor por defecto del tipo (una cadena vacía, por ejemplo).

Pausar no detiene el WAL. Un pipe pausado deja que el slot siga acumulando WAL. Si supera max_slot_wal_keep_size, Postgres invalida el slot, y según la FAQ la única salida es una resincronización completa.

4.5 El diseño que lo absorbe

1. Transacciones definitivas en Postgres, de modo que cada línea de asiento tiene una clave estable.

2. Líneas de asiento idempotentes: journal_entries usa ReplacingMergeTree con (tx_id, line_no) en la clave. Repetir un lote o volver a derivar un mes nunca deja una línea duplicada después de deduplicar.

3. Saldos reconstruibles: daily_balances se reconstruye antes de cerrar.

4. Controles hasta el origen: el cierre compara Postgres con transactions, transactions con journal_entries y journal_entries con daily_balances. Cualquier diferencia detiene el proceso.

4.6 Después de una resincronización

Primero compruebo que las vistas siguen enganchadas a la tabla, porque una resincronización de tabla la reemplaza:

-- Both materialized views must still depend on the table
SELECT dependencies_table
FROM system.tables
WHERE database = 'finance' AND name = 'transactions';
-- expected: ['mv_journal_entries', 'mv_monthly_kpis']

Luego vuelvo a derivar las líneas de asiento de los meses afectados desde las transacciones deduplicadas. Como la tabla de asientos es idempotente, las líneas que ya estaban no se duplican:

-- After a ClickPipes resync: re-derive the journal lines
-- of the affected months (idempotent thanks to the RMT)
INSERT INTO finance.journal_entries
    (tx_id, line_no, entity_id, accounting_date, event_ts,
     account, cost_center, counterparty_id, currency,
     debit_minor, credit_minor, debit_lcy_minor,
     credit_lcy_minor, source, src_version)
SELECT
    tx_id,
    line.1 AS line_no,
    entity_id,
    accounting_date,
    event_ts,
    line.2 AS account,
    cost_center,
    counterparty_id,
    currency,
    line.3 AS debit_minor,
    line.4 AS credit_minor,
    line.5 AS debit_lcy_minor,
    line.6 AS credit_lcy_minor,
    'OPERATION' AS source,
    toUInt64(_peerdb_version) AS src_version
FROM finance.transactions FINAL
ARRAY JOIN [
    (toUInt32(1), debit_account, amount_minor, toInt64(0),
     amount_lcy_minor, toInt64(0)),
    (toUInt32(2), credit_account, toInt64(0), amount_minor,
     toInt64(0), amount_lcy_minor)
] AS line
WHERE status = 'CONFIRMED'
  AND _peerdb_is_deleted = 0
  AND toYYYYMM(accounting_date) BETWEEN 202611 AND 202612
SETTINGS do_not_merge_across_partitions_select_final = 1;

Después reconstruyo los saldos de esos meses y repito los controles del paso 1. Los indicadores de monthly_kpis se reconstruyen igual si se usan para algo más que monitoreo.

4.7 Monitoreo

ClickHouse Cloud expone métricas de ClickPipes en formato Prometheus. Vigilo ClickPipes_SourceReplicationLatency_MiB (retraso del slot en Postgres), la distancia entre ClickPipes_LastFetchedBatchId y ClickPipes_LastSentBatchId, ClickPipes_Errors_Total y el estado del pipe en ClickPipes_Info. En Postgres, el retraso del slot también se ve en pg_replication_slots.

5. Consultas financieras

5.1 Saldo acumulado

Una consulta de operación diaria sobre los saldos provisionales; para cifras de cierre, ejecútala después del paso 0.

SELECT
    accounting_date,
    account,
    sum(debit_lcy_minor - credit_lcy_minor) AS movement,
    sum(sum(debit_lcy_minor - credit_lcy_minor)) OVER (
        PARTITION BY account
        ORDER BY accounting_date
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_balance
FROM finance.daily_balances
WHERE entity_id = 'CO01'
  AND account = 111005
  AND accounting_date BETWEEN '2026-01-01'
                          AND '2026-12-31'
GROUP BY accounting_date, account
ORDER BY accounting_date;

Como el rango empieza el 1 de enero, el saldo incluye la apertura del año.

5.2 Antigüedad de cartera en una sola pasada

SELECT
    counterparty_id,
    sumIf(balance, days <= 30)              AS d0_30,
    sumIf(balance, days BETWEEN 31 AND 60)  AS d31_60,
    sumIf(balance, days BETWEEN 61 AND 90)  AS d61_90,
    sumIf(balance, days BETWEEN 91 AND 180) AS d91_180,
    sumIf(balance, days > 180)              AS d180_plus,
    sum(balance)                            AS total
FROM
(
    SELECT
        counterparty_id,
        dateDiff('day', accounting_date,
                 toDate('2026-12-31')) AS days,
        debit_lcy_minor - credit_lcy_minor AS balance
    FROM finance.journal_entries FINAL
    WHERE entity_id = 'CO01'
      -- receivables group (13) and every sub-account
      AND dictIsIn('finance.chart_of_accounts', account, 13)
      AND accounting_date BETWEEN '2026-01-01'
                              AND '2026-12-31'
)
GROUP BY counterparty_id
HAVING total != 0
ORDER BY total DESC
SETTINGS do_not_merge_across_partitions_select_final = 1;

El rango es el año, por la razón que explico en la sección 6.4. Es un ejemplo simplificado. La apertura conserva el saldo de cada tercero pero no la fecha de sus documentos, así que un informe de antigüedad real cruza cada pago con su factura y usa la fecha de vencimiento. Lo que me interesa mostrar es el combinador -If, que evita un CASE por columna o varias pasadas sobre los datos.

5.3 VPN y TIR dentro del motor

Desde la versión 25.7, ClickHouse trae funciones financieras nativas, incluidas las versiones con fechas irregulares equivalentes a XNPV y XIRR de las hojas de cálculo. Solo aceptan enteros o Float, no Decimal; convierto los flujos a unidades mayores en Float64, que para valoración alcanza. El libro sigue en enteros.

-- finance.loan_cash_flows(loan_id, payment_date,
--                         currency, cash_flow_minor)
SELECT
    loan_id,
    arraySort(groupArray((
        payment_date,
        cash_flow_minor / intExp10(dictGet(
            'finance.currency_dict', 'minor_units',
            toString(currency)))
    ))) AS flows,
    financialInternalRateOfReturnExtended(
        arrayMap(f -> f.2, flows),
        arrayMap(f -> f.1, flows)) AS irr,
    financialNetPresentValueExtended(
        0.12,
        arrayMap(f -> f.2, flows),
        arrayMap(f -> f.1, flows)) AS npv_12
FROM finance.loan_cash_flows
GROUP BY loan_id;

5.4 Riesgo de mercado

VaR histórico al 99 %, volatilidad diaria y correlación con el índice de referencia, por portafolio:

-- Historical 99% VaR, volatility and benchmark correlation
SELECT
    portfolio_id,
    quantileExact(0.01)(daily_return)    AS var_99,
    stddevSamp(daily_return)             AS volatility,
    corr(daily_return, benchmark_return) AS correlation
FROM finance.portfolio_returns
WHERE return_date >= today() - 500
GROUP BY portfolio_id;

ClickHouse también tiene exponentialMovingAverage, simpleLinearRegression, quantileTDigest, covarSamp, studentTTest y mannWhitneyUTest, entre otras.

5.5 Anomalías en tiempo real

Transacciones del último cuarto de hora que se salen más de seis desviaciones estándar del comportamiento del tercero en los últimos 90 días:

WITH stats AS
(
    SELECT
        counterparty_id,
        avg(amount_lcy_minor)       AS mean_minor,
        stddevPop(amount_lcy_minor) AS sd_minor
    FROM finance.transactions FINAL
    WHERE accounting_date >= today() - 90
      AND status = 'CONFIRMED'
      AND _peerdb_is_deleted = 0
    GROUP BY counterparty_id
)
SELECT
    t.tx_id,
    t.counterparty_id,
    t.amount_lcy_minor,
    (t.amount_lcy_minor - s.mean_minor)
        / nullIf(s.sd_minor, 0) AS z_score
FROM finance.transactions AS t FINAL
INNER JOIN stats AS s USING (counterparty_id)
WHERE t.accounting_date >= today() - 1
  AND t.event_ts >= now() - INTERVAL 15 MINUTE
  AND t.status = 'CONFIRMED'
  AND t._peerdb_is_deleted = 0
  AND z_score > 6
ORDER BY z_score DESC
SETTINGS do_not_merge_across_partitions_select_final = 1;

Para secuencias sospechosas, como un cambio de contraseña seguido de un beneficiario nuevo y una transferencia grande en pocos minutos, están sequenceMatch y windowFunnel.

6. El cierre fiscal

6.1 Calendario y periodos

Los periodos son mensuales y los controla Postgres. Diciembre sigue OPEN después del 31, porque las liquidaciones de tarjetas, los archivos bancarios y las compensaciones del 31 llegan el 1 y el 2 de enero y deben quedar en 2026. El corte es una fecha que fija el equipo contable, por ejemplo el 3 de enero a las 23:59. En ese momento diciembre pasa a CLOSING (el disparador ya no deja confirmar operaciones con fecha de diciembre) y espero a que el CDC haya llevado a ClickHouse todo lo anterior:

-- PostgreSQL: freeze December for operations
UPDATE accounting_periods
SET status = 'CLOSING'
WHERE period = 202612;

-- note the current WAL position...
SELECT pg_current_wal_lsn() AS cutoff_lsn;

-- ...and wait until the ClickPipes slot has confirmed it
SELECT slot_name,
       confirmed_flush_lsn >= '0/0'::pg_lsn AS caught_up
FROM pg_replication_slots
WHERE slot_type = 'logical';
-- replace '0/0' with the cutoff_lsn returned above

Antes de anotar la posición espero a que termine cualquier transacción que empezó antes del cambio a CLOSING (xact_start en pg_stat_activity), porque el disparador ya la dejó pasar. Cuando caught_up es verdadero, los cambios anteriores al corte ya salieron de Postgres; ClickPipes los aplica a la tabla final en el siguiente lote. Que diciembre esté completo en ClickHouse no lo prueba el slot sino el control contra Postgres de la sección 6.4. Los meses anteriores pasaron por lo mismo al cerrarse.

6.2 Pre-cierre: el balance preliminar

Durante diciembre uso una vista materializada refrescable. Ejecuta la consulta completa cada hora y reemplaza el resultado de forma atómica:

CREATE MATERIALIZED VIEW finance.preliminary_trial_balance
REFRESH EVERY 1 HOUR
ENGINE = MergeTree
ORDER BY (entity_id, account)
AS
SELECT
    entity_id,
    account,
    dictGet('finance.chart_of_accounts', 'account_name',
            account) AS account_name,
    sum(debit_lcy_minor)  AS total_debit_lcy,
    sum(credit_lcy_minor) AS total_credit_lcy,
    total_debit_lcy - total_credit_lcy AS balance_lcy,
    now() AS computed_at
FROM finance.daily_balances
WHERE accounting_date BETWEEN '2026-01-01'
                          AND '2026-12-31'
GROUP BY entity_id, account;

Sale de los saldos provisionales, así que sirve para ver venir el cierre, no para cerrarlo. Estas vistas admiten dependencias (DEPENDS ON) y se pueden encadenar sin un orquestador externo.

6.3 Conciliación

Comparar fila por fila 300 millones de registros entre dos sistemas es caro. Primero comparo huellas por día, cuenta y moneda, y solo bajo al detalle donde no coinciden. La huella es un XOR de un MD5 por transacción; la misma técnica, calculada en Postgres con bit_xor, es la que uso en la sección 6.4 para comparar contra el origen:

SELECT
    accounting_date,
    debit_account AS account,
    currency,
    count()           AS tx_count,
    sum(amount_minor) AS total_minor,
    groupBitXor(reinterpretAsInt64(reverse(unhex(left(hex(
        MD5(concat(toString(tx_id), '|',
                   toString(amount_minor)))), 16)))))
        AS fingerprint
FROM finance.transactions FINAL
WHERE entity_id = 'CO01'
  AND toYYYYMM(accounting_date) = 202612
  AND status = 'CONFIRMED'
  AND _peerdb_is_deleted = 0
GROUP BY accounting_date, account, currency
SETTINGS do_not_merge_across_partitions_select_final = 1;

El XOR no depende del orden de las filas, pero dos filas idénticas se anulan entre sí; por eso la huella siempre se compara junto con el conteo y el total.

Cuando una combinación no cuadra, cruzo el libro auxiliar de bancos con el extracto. Los bancos y el sistema de pagos inmediatos Bre-B ya usan mensajes ISO 20022, y lo práctico es normalizar los extractos a una estructura tipo camt.053 en archivos Parquet que ClickHouse lee desde el almacenamiento de objetos. Las credenciales del almacenamiento también van en named collections:

-- Created once by an administrator; queries use the names
CREATE NAMED COLLECTION s3_finance AS
    url = 'https://storage.example.com/finance-data/',
    access_key_id = '***',
    secret_access_key = '***';
CREATE NAMED COLLECTION s3_worm AS
    url = 'https://storage.example.com/finance-worm/',
    access_key_id = '***',
    secret_access_key = '***';

SELECT
    coalesce(l.reference, b.reference) AS reference,
    l.amount_minor AS ledger_minor,
    b.amount_minor AS bank_minor,
    multiIf(
        l.reference IS NULL, 'BANK_ONLY',
        b.reference IS NULL, 'LEDGER_ONLY',
        l.amount_minor != b.amount_minor, 'AMOUNT_MISMATCH',
        'MATCHED') AS match_status
FROM
(
    SELECT reference, amount_minor
    FROM finance.cash_book_entries
    WHERE entry_date = '2026-12-31' AND account = 111005
) AS l
FULL OUTER JOIN
(
    -- camt.053-style statement, amounts in COP
    SELECT
        reference,
        toInt64(round(toDecimal128(amount, 4)
            * intExp10(dictGet('finance.currency_dict',
                               'minor_units', 'COP')), 0))
            AS amount_minor
    FROM s3(s3_finance,
            filename = 'bank-statements/2026-12-31/*.parquet',
            format = 'Parquet')
) AS b
ON l.reference = b.reference
WHERE match_status != 'MATCHED'
SETTINGS join_use_nulls = 1;

En ClickHouse Cloud también se puede dar acceso al bucket con un rol del proveedor de nube en lugar de claves.

6.4 Reconstruir y verificar

Todas las consultas del cierre filtran el año, del 1 de enero al 31 de diciembre, y nunca el histórico: cada año parte de su propia apertura, y sumar el histórico contaría dos veces lo ya trasladado. Lo que se suma entre cuentas y monedas es siempre el importe en moneda funcional.

Paso 0. Reconstruir los saldos desde las líneas deduplicadas. Lo hago mes a mes (un script recorre de 202601 a 202612) y lo repito antes del paso 4, que escribe un comprobante a partir de los saldos:

-- 0a. Rebuild one month of balances
CREATE TABLE IF NOT EXISTS finance.daily_balances_rebuild
    AS finance.daily_balances;
TRUNCATE TABLE finance.daily_balances_rebuild;

INSERT INTO finance.daily_balances_rebuild
SELECT
    entity_id, account, cost_center, currency,
    accounting_date,
    sum(debit_minor), sum(credit_minor),
    sum(debit_lcy_minor), sum(credit_lcy_minor),
    count()
FROM finance.journal_entries FINAL
WHERE toYYYYMM(accounting_date) = {period:UInt32}
GROUP BY entity_id, account, cost_center, currency,
         accounting_date
SETTINGS do_not_merge_across_partitions_select_final = 1;

ALTER TABLE finance.daily_balances
    REPLACE PARTITION {period:UInt32}
    FROM finance.daily_balances_rebuild;

-- 0b. Verify the month; if it fails, run 0a again
SELECT throwIf(count() > 0, 'Balances differ from journal')
FROM
(
    SELECT entity_id, account, currency,
           sum(debit_lcy_minor) AS d,
           sum(credit_lcy_minor) AS c
    FROM finance.daily_balances
    WHERE toYYYYMM(accounting_date) = {period:UInt32}
    GROUP BY entity_id, account, currency
) AS b
FULL OUTER JOIN
(
    SELECT entity_id, account, currency,
           sum(debit_lcy_minor) AS d,
           sum(credit_lcy_minor) AS c
    FROM finance.journal_entries FINAL
    WHERE toYYYYMM(accounting_date) = {period:UInt32}
    GROUP BY entity_id, account, currency
) AS j USING (entity_id, account, currency)
WHERE b.d != j.d OR b.c != j.c
SETTINGS do_not_merge_across_partitions_select_final = 1;

REPLACE PARTITION cambia la partición de forma atómica y no dispara las vistas materializadas. Si una línea llega a los asientos después de leer y antes del reemplazo, se queda fuera de los saldos; para eso está la verificación 0b.

Paso 1. Comprobar la partida doble, las líneas, el origen y los comprobantes. Cada consulta falla si algo no cuadra:

-- 1a. Debits equal credits per entity and currency
SELECT
    entity_id,
    currency,
    sum(debit_minor)      AS total_debit,
    sum(credit_minor)     AS total_credit,
    sum(debit_lcy_minor)  AS total_debit_lcy,
    sum(credit_lcy_minor) AS total_credit_lcy,
    throwIf(
        total_debit != total_credit
            OR total_debit_lcy != total_credit_lcy,
        'Double-entry check failed') AS check_result
FROM finance.daily_balances
WHERE accounting_date BETWEEN '2026-01-01'
                          AND '2026-12-31'
GROUP BY entity_id, currency;

-- 1b. A line may repeat (CDC retries), but two copies of
-- the same (tx_id, line_no) must never disagree
SELECT throwIf(count() > 0, 'Conflicting journal lines')
FROM
(
    SELECT tx_id, line_no
    FROM finance.journal_entries
    WHERE toYear(accounting_date) = 2026
    GROUP BY tx_id, line_no
    HAVING uniqExact(account, debit_minor, credit_minor,
                     debit_lcy_minor, credit_lcy_minor) > 1
);

-- 1c. Journal lines match the confirmed transactions
SELECT throwIf(count() > 0, 'Journal differs from CDC data')
FROM
(
    SELECT entity_id, toYYYYMM(accounting_date) AS period,
           2 * count() AS lines, sum(amount_lcy_minor) AS lcy
    FROM finance.transactions FINAL
    WHERE status = 'CONFIRMED' AND _peerdb_is_deleted = 0
      AND toYear(accounting_date) = 2026
    GROUP BY entity_id, period
) AS t
FULL OUTER JOIN
(
    SELECT entity_id, toYYYYMM(accounting_date) AS period,
           count() AS lines, sum(debit_lcy_minor) AS lcy
    FROM finance.journal_entries FINAL
    WHERE source = 'OPERATION'
      AND toYear(accounting_date) = 2026
    GROUP BY entity_id, period
) AS j USING (entity_id, period)
WHERE t.lines != j.lines OR t.lcy != j.lcy
SETTINGS do_not_merge_across_partitions_select_final = 1;

-- 1d. Every manual voucher was approved in Postgres
SELECT throwIf(count() > 0, 'Voucher without approval')
FROM
(
    SELECT DISTINCT tx_id
    FROM finance.journal_entries
    WHERE source != 'OPERATION'
      AND toYear(accounting_date) = 2026
) AS j
LEFT ANTI JOIN
(
    SELECT tx_id
    FROM finance.journal_vouchers FINAL
    WHERE approved_by != '' AND _peerdb_is_deleted = 0
) AS v USING (tx_id);

-- 1e. Every account exists in the chart of accounts
SELECT throwIf(count() > 0, 'Unmapped accounts')
FROM finance.daily_balances
WHERE toYear(accounting_date) = 2026
  AND NOT dictHas('finance.chart_of_accounts',
                  toUInt64(account));

El control 1a no basta por sí solo: una línea duplicada también cuadra. Por eso existen 1b y 1c. El control 1c supone dos líneas por transacción, como en este modelo; si las tuyas generan más, compara con el número esperado. El 1e importa porque una cuenta que no está en el diccionario tendría clase 0 y desaparecería en silencio de los pasos 3, 4 y 6.

El último eslabón es Postgres. Al cerrar cada mes comparo conteo, total y huella con una vista de ClickHouse que Postgres consulta a través de pg_clickhouse:

-- ClickHouse: monthly control figures from the CDC table
CREATE VIEW finance.monthly_tx_control AS
SELECT
    entity_id,
    toYYYYMM(accounting_date) AS period,
    count()                   AS tx_count,
    sum(amount_lcy_minor)     AS total_lcy,
    groupBitXor(reinterpretAsInt64(reverse(unhex(left(hex(
        MD5(concat(toString(tx_id), '|',
                   toString(amount_lcy_minor)))), 16)))))
        AS fingerprint
FROM finance.transactions FINAL
WHERE status = 'CONFIRMED' AND _peerdb_is_deleted = 0
GROUP BY entity_id, period
SETTINGS do_not_merge_across_partitions_select_final = 1;

-- PostgreSQL: the month in Postgres against ClickHouse
SELECT
    coalesce(p.entity_id, c.entity_id) AS entity_id,
    p.tx_count, c.tx_count AS ch_tx_count,
    p.total_lcy, c.total_lcy AS ch_total_lcy,
    p.tx_count = c.tx_count
        AND p.total_lcy = c.total_lcy
        AND p.fingerprint = c.fingerprint AS matched
FROM
(
    SELECT
        entity_id,
        count(*) AS tx_count,
        sum(amount_lcy_minor) AS total_lcy,
        bit_xor(('x' || left(md5(tx_id::text || '|'
            || amount_lcy_minor), 16))::bit(64)::bigint)
            AS fingerprint
    FROM transactions
    WHERE status = 'CONFIRMED'
      AND accounting_date >= DATE '2026-12-01'
      AND accounting_date <  DATE '2027-01-01'
    GROUP BY entity_id
) AS p
FULL JOIN
(
    SELECT entity_id, tx_count, total_lcy, fingerprint
    FROM ch.monthly_tx_control
    WHERE period = 202612
) AS c
    ON c.entity_id = p.entity_id;

Si alguna fila devuelve matched falso o vacío, el mes no está completo en ClickHouse y el cierre no sigue.

6.5 Ajustes y cierre de resultados

Paso 2. El balance de comprobación con subtotales.

SELECT
    multiIf(
        grouping(account_class) = 1, 'TOTAL',
        grouping(account_group) = 1, 'CLASS',
        grouping(account) = 1,       'GROUP',
        'ACCOUNT') AS row_level,
    dictGet('finance.chart_of_accounts', 'account_class',
            account) AS account_class,
    toUInt16(substring(toString(account), 1, 2))
        AS account_group,
    account,
    dictGet('finance.chart_of_accounts', 'account_name',
            account) AS account_name,
    sum(debit_lcy_minor)  AS total_debit_lcy,
    sum(credit_lcy_minor) AS total_credit_lcy,
    total_debit_lcy - total_credit_lcy AS balance_lcy
FROM finance.daily_balances
WHERE entity_id = 'CO01'
  AND accounting_date BETWEEN '2026-01-01'
                          AND '2026-12-31'
GROUP BY ROLLUP(account_class, account_group, account)
ORDER BY account_class, account_group, account;

row_level marca cada fila como cuenta, subtotal de grupo, subtotal de clase o total general; el grupo son los dos primeros dígitos del código. Como en todo *MergeTree, nunca doy por hecho una fila por clave: siempre sum() y GROUP BY.

Paso 3. Diferencia en cambio. Revalúo, por tercero, los saldos en moneda extranjera de las cuentas de balance con la última TRM vigente al cierre (las 23:59:59 del 31 de diciembre en Bogotá) y registro la contrapartida en ingresos (421020) o gastos (530525) por diferencia en cambio. Antes registro y apruebo en Postgres el comprobante con su tx_id:

INSERT INTO finance.journal_entries
    (tx_id, line_no, entity_id, accounting_date, event_ts,
     account, cost_center, counterparty_id, currency,
     debit_minor, credit_minor, debit_lcy_minor,
     credit_lcy_minor, source)
SELECT
    {fx_tx_id:UUID} AS tx_id,
    toUInt32(row_number() OVER (
        ORDER BY entity_id, currency, line.1, line.2,
                 line.3, line.4)) AS line_no,
    entity_id,
    toDate('2026-12-31') AS accounting_date,
    toDateTime64('2026-12-31 23:59:59.999', 3,
                 'America/Bogota') AS event_ts,
    line.1 AS account,
    line.2 AS cost_center,
    line.3 AS counterparty_id,
    currency,
    toInt64(0) AS debit_minor,
    toInt64(0) AS credit_minor,
    greatest(line.4, 0) AS debit_lcy_minor,
    greatest(-line.4, 0) AS credit_lcy_minor,
    'ADJUSTMENT' AS source
FROM
(
    SELECT
        b.entity_id,
        b.account         AS revalued_account,
        b.cost_center     AS revalued_cost_center,
        b.counterparty_id AS revalued_counterparty,
        b.currency,
        convert_minor(b.fc_minor, b.currency, 'COP', r.rate)
            - b.lcy_minor AS fx_diff_minor
    FROM
    (
        -- foreign-currency balances of monetary accounts
        SELECT
            entity_id, account, cost_center, counterparty_id,
            currency,
            sum(debit_minor) - sum(credit_minor) AS fc_minor,
            sum(debit_lcy_minor) - sum(credit_lcy_minor)
                AS lcy_minor
        FROM finance.journal_entries FINAL
        WHERE accounting_date BETWEEN '2026-01-01'
                                  AND '2026-12-31'
          AND currency != 'COP'
          AND dictGet('finance.chart_of_accounts',
                      'account_class', account) IN (1, 2)
        GROUP BY entity_id, account, cost_center,
                 counterparty_id, currency
    ) AS b
    INNER JOIN
    (
        -- latest official rate before the cut-off
        SELECT currency, argMax(rate, valid_from) AS rate
        FROM finance.fx_rates
        WHERE rate_source = 'TRM'
          AND valid_from < toDateTime64(
              '2027-01-01 00:00:00', 3, 'America/Bogota')
        GROUP BY currency
    ) AS r ON b.currency = r.currency
    WHERE fx_diff_minor != 0
)
ARRAY JOIN [
    -- revalued account, per counterparty
    (revalued_account, revalued_cost_center,
     revalued_counterparty, fx_diff_minor),
    -- FX gain (421020) or loss (530525)
    (if(fx_diff_minor > 0, 421020, 530525), 'CORP',
     toInt64(0), -fx_diff_minor)
] AS line
SETTINGS do_not_merge_across_partitions_select_final = 1;

Cada ajuste genera dos líneas que se compensan, así que el comprobante cuadra por construcción. Revaluar por tercero mantiene cuadrados los auxiliares de cartera y proveedores. Filtrar las clases 1 y 2 es una simplificación: según la NIC 21 solo se revalúan las partidas monetarias, y no los inventarios, las propiedades, los intangibles, los gastos pagados por anticipado ni los anticipos dados o recibidos. En producción el filtro sale del plan de cuentas. Las horas del corte van en la zona horaria de Bogotá y ClickHouse las convierte a UTC al comparar y al guardar; con 'UTC' el corte quedaría cinco horas antes.

Esta diferencia en cambio es contable (NIIF). En lo fiscal, la diferencia no realizada no tiene efecto hasta su realización (artículo 288 del Estatuto Tributario), genera impuesto diferido y debe quedar en el control de diferencias y en el reporte de conciliación fiscal (formato 2516).

Renombré account, cost_center y counterparty_id en la subconsulta porque en ClickHouse un alias tiene prioridad sobre una columna del mismo nombre y, sin ese cambio, la consulta falla con un error de identificador desconocido. Me pasó en la primera versión. Por lo mismo, cuando un total se reutiliza en el mismo SELECT (control 1a, balance de comprobación) lo llamo total_debit y no debit_minor.

Si la inserción se interrumpe y la repito tal cual, con los mismos saldos de entrada, las líneas repetidas se colapsan como las del CDC: el row_number ordena por la tupla completa y numera igual. Si algo cambió entre los dos intentos, el control 1b lo detecta; en ese caso, y siempre que haya que corregir un comprobante ya registrado, se revierte y se registra uno nuevo con otro tx_id.

Paso 4. Cerrar las cuentas de resultado. Antes de este paso ya están registrados el impuesto de renta corriente y diferido (NIC 12), las provisiones, las depreciaciones y las reclasificaciones, y la clase 7 (costos de producción) ya se trasladó a la 6 o al inventario. Repito el paso 0 y cierro las clases 4, 5 y 6 contra la utilidad (3605) o la pérdida (3610) del ejercicio:

INSERT INTO finance.journal_entries
    (tx_id, line_no, entity_id, accounting_date, event_ts,
     account, cost_center, counterparty_id, currency,
     debit_minor, credit_minor, debit_lcy_minor,
     credit_lcy_minor, source)
SELECT
    {closing_tx_id:UUID} AS tx_id,
    toUInt32(row_number() OVER (
        ORDER BY entity_id, currency, is_offset, account,
                 cost_center)) AS line_no,
    entity_id,
    toDate('2026-12-31') AS accounting_date,
    toDateTime64('2026-12-31 23:59:59.999', 3,
                 'America/Bogota') AS event_ts,
    account,
    cost_center,
    0 AS counterparty_id,
    currency,
    -- post the opposite of each balance
    greatest(-fc_minor, 0)  AS debit_minor,
    greatest(fc_minor, 0)   AS credit_minor,
    greatest(-lcy_minor, 0) AS debit_lcy_minor,
    greatest(lcy_minor, 0)  AS credit_lcy_minor,
    'CLOSING' AS source
FROM
(
    -- lines that bring each income-statement account to 0
    SELECT
        entity_id, account, cost_center, currency,
        0 AS is_offset,
        sum(debit_minor) - sum(credit_minor) AS fc_minor,
        sum(debit_lcy_minor) - sum(credit_lcy_minor)
            AS lcy_minor
    FROM finance.daily_balances
    WHERE accounting_date BETWEEN '2026-01-01'
                              AND '2026-12-31'
      AND dictGet('finance.chart_of_accounts',
                  'account_class', account) IN (4, 5, 6)
    GROUP BY entity_id, account, cost_center, currency
    HAVING fc_minor != 0 OR lcy_minor != 0

    UNION ALL

    -- offset per entity and currency. Profit (3605) or
    -- loss (3610) is decided on the entity's total result
    -- in functional currency, not per currency.
    SELECT
        entity_id,
        if(sum(sum(debit_lcy_minor) - sum(credit_lcy_minor))
               OVER (PARTITION BY entity_id) <= 0,
           3605, 3610) AS offset_account,
        'CORP' AS offset_cost_center,
        currency,
        1 AS is_offset,
        sum(credit_minor) - sum(debit_minor) AS offset_fc,
        sum(credit_lcy_minor) - sum(debit_lcy_minor)
            AS offset_lcy
    FROM finance.daily_balances
    WHERE accounting_date BETWEEN '2026-01-01'
                              AND '2026-12-31'
      AND dictGet('finance.chart_of_accounts',
                  'account_class', account) IN (4, 5, 6)
    GROUP BY entity_id, currency
    HAVING offset_fc != 0 OR offset_lcy != 0
);

La cuenta de utilidad o pérdida se elige con el resultado total de la entidad en moneda funcional. Las líneas de contrapartida se separan por moneda solo para que el control 1a siga cuadrando por moneda; el resultado del ejercicio solo tiene sentido en moneda funcional, y así se presenta.

Si tu entidad pasa primero por la 5905 (Ganancias y pérdidas), exclúyela del filtro de la clase 5. En el segundo bloque los alias tienen nombres distintos (offset_account) por la misma razón de antes: UNION ALL toma los nombres del primer SELECT, y account en el WHERE debe seguir siendo la columna.

Paso 5. Reconstruir y comprobar. Repito el paso 0 y los controles 1a, 1b y 1d, y compruebo que no quedó ninguna cuenta de resultado con saldo:

-- 5. No income-statement account may keep a balance
SELECT throwIf(count() > 0, 'P&L not closed')
FROM
(
    SELECT entity_id, account, currency
    FROM finance.daily_balances
    WHERE toYear(accounting_date) = 2026
      AND dictGet('finance.chart_of_accounts',
                  'account_class', account) IN (4, 5, 6)
    GROUP BY entity_id, account, currency
    HAVING sum(debit_lcy_minor) != sum(credit_lcy_minor)
        OR sum(debit_minor) != sum(credit_minor)
);

6.6 Apertura, sellado y archivo

Paso 6. Saldos de apertura de 2027. Traslado los saldos de las clases 1, 2 y 3 por tercero, para que la cartera y los proveedores conserven su detalle:

INSERT INTO finance.journal_entries
    (tx_id, line_no, entity_id, accounting_date, event_ts,
     account, cost_center, counterparty_id, currency,
     debit_minor, credit_minor, debit_lcy_minor,
     credit_lcy_minor, source)
SELECT
    {opening_tx_id:UUID} AS tx_id,
    toUInt32(row_number() OVER (
        ORDER BY entity_id, currency, account, cost_center,
                 counterparty_id)) AS line_no,
    entity_id,
    toDate('2027-01-01') AS accounting_date,
    toDateTime64('2027-01-01 00:00:00', 3,
                 'America/Bogota') AS event_ts,
    account,
    cost_center,
    counterparty_id,
    currency,
    greatest(fc_minor, 0)   AS debit_minor,
    greatest(-fc_minor, 0)  AS credit_minor,
    greatest(lcy_minor, 0)  AS debit_lcy_minor,
    greatest(-lcy_minor, 0) AS credit_lcy_minor,
    'OPENING' AS source
FROM
(
    SELECT
        entity_id, account, cost_center, counterparty_id,
        currency,
        sum(debit_minor) - sum(credit_minor) AS fc_minor,
        sum(debit_lcy_minor) - sum(credit_lcy_minor)
            AS lcy_minor
    FROM finance.journal_entries FINAL
    WHERE accounting_date BETWEEN '2026-01-01'
                              AND '2026-12-31'
      AND dictGet('finance.chart_of_accounts',
                  'account_class', account) IN (1, 2, 3)
    GROUP BY entity_id, account, cost_center,
             counterparty_id, currency
    HAVING fc_minor != 0 OR lcy_minor != 0
)
SETTINGS do_not_merge_across_partitions_select_final = 1;

Con las cuentas de resultado en cero y la clase 7 ya trasladada, los saldos de las clases 1, 2 y 3 suman cero y la apertura cuadra sola. Las cuentas de orden (clases 8 y 9) se trasladan aparte. La utilidad o pérdida del año (3605 o 3610) entra a 2027 tal cual y se reclasifica a utilidades acumuladas o reservas cuando la asamblea decide su destino. Desde aquí, las consultas de 2027 parten de la apertura y no necesitan leer 2026.

Paso 7. Sellar el año. Calculo la huella de cada mes y la guardo en Postgres con el acta de cierre; si dentro de cinco años alguien vuelve a calcularla y no coincide, algo cambió. Después respaldo el año en un bucket con bloqueo de objetos y guardo una copia del plan de cuentas tal como estaba, porque el diccionario se refresca y en diez años los nombres y las clases pueden ser otros:

-- 7a. Closing fingerprint per month
SELECT
    toYYYYMM(accounting_date) AS period,
    count()                   AS line_count,
    sum(debit_lcy_minor)      AS total_debit_lcy,
    sum(credit_lcy_minor)     AS total_credit_lcy,
    groupBitXor(cityHash64(tx_id, line_no, account,
        currency, debit_minor, credit_minor,
        debit_lcy_minor, credit_lcy_minor)) AS fingerprint
FROM finance.journal_entries FINAL
WHERE accounting_date BETWEEN '2026-01-01'
                          AND '2026-12-31'
GROUP BY period
ORDER BY period
SETTINGS do_not_merge_across_partitions_select_final = 1;

-- 7b. Back up the year to the object-locked bucket
BACKUP TABLE finance.journal_entries
    PARTITIONS '202601', '202602', '202603', '202604',
               '202605', '202606', '202607', '202608',
               '202609', '202610', '202611', '202612'
TO S3(s3_worm, '2026/journal_entries');

-- 7c. Freeze the chart of accounts used for 2026
CREATE TABLE finance.chart_of_accounts_2026
ENGINE = MergeTree ORDER BY account AS
SELECT * FROM dictionary('finance.chart_of_accounts');

Los datos de 2026 se quedan en journal_entries. Lo que impide cambiarlos es que solo el rol del proceso de cierre tiene INSERT sobre la tabla, que todo comprobante manual exige aprobación en Postgres (control 1d) y que la huella delataría cualquier cambio. Vale la pena darle a journal_vouchers la misma validación de periodo que tiene el disparador de transactions. ClickHouse Cloud hace además sus propias copias automáticas.

Paso 8. Exportar para la retención legal.

INSERT INTO FUNCTION s3(s3_worm,
    filename = 'legal-archive/2026/{_partition_id}.parquet',
    format = 'Parquet')
PARTITION BY toYYYYMM(accounting_date)
SELECT *
FROM finance.journal_entries FINAL
WHERE toYear(accounting_date) = 2026
SETTINGS do_not_merge_across_partitions_select_final = 1;

Va al bucket con bloqueo, como el respaldo. Elegí Parquet porque dentro de diez años se podrá leer con DuckDB, Spark o pandas, sin depender de ClickHouse.

6.7 Después del cierre

Diciembre se queda en CLOSING hasta que la asamblea aprueba los estados financieros (en marzo, como tarde) y solo entonces pasa a CLOSED. Si el auditor pide un ajuste después de registrar la apertura, registro el ajuste, un comprobante complementario de cierre de resultados (paso 4) y otro de apertura por la diferencia (paso 6), repito los pasos 0, 1 y 5 y vuelvo a sellar y exportar (pasos 7 y 8) con otra ruta de destino. La huella que vale es la del año que aprueba la asamblea. Un error material de años anteriores no se corrige en el resultado del año: la NIC 8 exige reexpresión retroactiva contra las ganancias acumuladas.

Si la moneda funcional de la entidad no es el peso, amount_lcy_minor va en esa moneda y los estados financieros necesitan además una conversión a la moneda de presentación.

7. Datos personales y seguridad

Un libro de pagos está lleno de datos personales: nombres, cédulas, correos, teléfonos, cuentas bancarias, llaves de Bre-B (que pueden ser un celular, un correo o un número de documento) y, si hay tarjetas, números de tarjeta. La Ley 1581 de 2012, el Reglamento General de Protección de Datos europeo (GDPR) si hay clientes en la Unión Europea y PCI DSS si hay tarjetas ponen reglas distintas, pero llevan al mismo diseño: el almacén analítico no necesita saber quién es cada persona.

7.1 Seudónimos en el libro, identidad en Postgres

El libro de ClickHouse solo guarda counterparty_id, una clave sustituta. Los datos personales viven en Postgres, cifrados por la aplicación, y no se replican. Para cruzar con fuentes externas, como listas de sanciones, uso un HMAC de la cédula que calcula la aplicación con un secreto guardado fuera de ambas bases de datos.

-- PostgreSQL 15+: identity data stays here, encrypted
CREATE TABLE parties (
    party_id           bigint  PRIMARY KEY,
    party_key          char(64),  -- hex HMAC-SHA256 of ID
    country_code       char(2) NOT NULL,  -- ISO 3166-1
    full_name_enc      bytea,     -- encrypted by the app
    national_id_enc    bytea,
    email_enc          bytea,
    phone_enc          bytea,
    -- address, Bre-B key and bank account: same pattern
    processing_blocked boolean NOT NULL DEFAULT false,
    retention_until    date
);

-- Optional second layer, only if you create the
-- publication yourself and give its name to ClickPipes
CREATE PUBLICATION clickhouse_cdc
    FOR TABLE transactions, accounting_periods,
              journal_vouchers,
              parties (party_id, party_key, country_code,
                       processing_blocked);

La barrera que documenta ClickPipes es la exclusión de columnas al configurar el pipe: en parties excluyo las columnas cifradas. Una columna excluida no se puede volver a incluir sin resincronizar la tabla, que es justo lo que quiero. ClickPipes crea por defecto su propia publicación; la lista de columnas en la publicación (PostgreSQL 15 o superior) solo aplica si la creas tú, y la uso como capa adicional, nunca como la única. La documentación de Postgres advierte además que las listas de columnas no son un mecanismo de seguridad. Evito REPLICA IDENTITY FULL en tablas con datos personales porque escribe la fila completa en el WAL.

Aquí la retención contable choca con el derecho de supresión. Los libros, sus soportes y la información de terceros se conservan diez años contados desde el último asiento, documento o comprobante (artículo 28 de la Ley 962 de 2005, que modificó el artículo 60 del Código de Comercio), y esa identidad también soporta la información exógena y el SARLAFT o el SAGRILAFT, según el supervisor. La Ley 1581, por su parte, da derecho a pedir la supresión.

El artículo 9 del Decreto 1377 de 2013 resuelve el choque: mientras exista el deber legal de conservar, la supresión no procede sobre esos datos. Se le responde al titular con la causal, se bloquean los datos para cualquier otra finalidad y se borran al vencer el plazo. Lo que no tiene deber de conservación, como el correo o el teléfono de contacto, sí se borra de inmediato:

-- PostgreSQL: erasure request for party 42.
-- Contact data has no retention duty: delete it now.
-- Identity data backs accounting, tax and AML records:
-- block it and delete it when the retention period ends.
UPDATE parties
SET email_enc          = NULL,
    phone_enc          = NULL,
    processing_blocked = true
WHERE party_id = 42;

-- Scheduled job: purge identity data after retention
UPDATE parties
SET full_name_enc   = NULL,
    national_id_enc = NULL,
    party_key       = NULL
WHERE processing_blocked
  AND retention_until < current_date;

-- ClickHouse: after the purge job, drop the previous
-- version of each row (the one that still holds the HMAC)
OPTIMIZE TABLE finance.parties FINAL;

processing_blocked sí se replica: cualquier análisis de mercadeo o perfilamiento en ClickHouse debe excluir a esos terceros. Cuando el trabajo programado borra la identidad, el cambio llega a ClickHouse como una versión nueva de la fila, con party_key vacío. La versión anterior, con el HMAC, sigue en disco hasta la siguiente fusión; OPTIMIZE ... FINAL la adelanta, y en una tabla pequeña como parties es barato. Las copias de seguridad guardan la versión anterior hasta que vencen.

Si hay titulares en la Unión Europea, el GDPR no ofrece la misma salida: la excepción del artículo 17.3.b exige una obligación del derecho de la Unión o de un Estado miembro, y una norma colombiana no basta. Ese caso requiere otro análisis. Y en ambos regímenes, los datos seudonimizados siguen siendo datos personales.

7.2 Controles en ClickHouse

El primer control es el permiso por columna, que funciona en cualquier edición. Un analista consulta las líneas de asiento sin ver el identificador del tercero:

CREATE ROLE analyst_role;
GRANT SELECT(tx_id, line_no, entity_id, accounting_date,
             account, cost_center, currency, debit_minor,
             credit_minor, debit_lcy_minor, credit_lcy_minor,
             source)
    ON finance.journal_entries TO analyst_role;

Si ese rol pide counterparty_id, ClickHouse responde con un error de acceso denegado, no con filas vacías, y así nadie lo pasa por alto. Lo mismo pasa con un SELECT *, que obliga a listar las columnas permitidas.

En ClickHouse Cloud, desde la versión 25.12, hay además políticas de enmascaramiento que transforman una columna al consultarla. Son exclusivas de Cloud: la versión de código abierto responde “Masking Policies are available only in ClickHouse Cloud”.

-- ClickHouse Cloud 25.12+ only
CREATE MASKING POLICY mask_counterparty
    ON finance.journal_entries
    UPDATE counterparty_id = 0
    TO bi_role;

Con las políticas de fila hay una trampa que comprobé: un usuario sin ninguna política sobre una tabla ve todas sus filas, aunque otros roles tengan políticas restrictivas. Por eso concedo acceso solo a través de roles y defino una política para cada uno.

CREATE ROW POLICY entity_co01_only
    ON finance.journal_entries
    FOR SELECT USING entity_id = 'CO01'
    TO co01_accountant_role;

Y además:

• Las claves escritas como literales en funciones como encrypt o HMAC pueden quedar en system.query_log; la documentación de query_masking_rules describe ese riesgo. Las credenciales de Postgres y del almacenamiento van en named collections y los secretos de cifrado se usan antes de que el dato llegue a ClickHouse. El acceso a query_log también se restringe.

• Solo el rol del proceso de cierre tiene INSERT sobre journal_entries; el usuario de ClickPipes escribe en las tablas del CDC y las vistas hacen el resto.

• En ClickHouse Cloud el cifrado en reposo viene activado por defecto. El cifrado con clave del cliente (CMEK) requiere el plan Enterprise, y borrar esa clave inutiliza el servicio completo; el borrado criptográfico de una persona se hace en la aplicación, con una clave por titular.

• DELETE, las mutaciones y el TTL borran al fusionar, y los respaldos guardan rastros.

• Desde el 31 de marzo de 2025, PCI DSS 4.0.1 exige que, si se usa un hash para hacer ilegible el número de tarjeta, sea un hash con clave (requisito 3.5.1.1), y deja de aceptar el cifrado de disco como única protección salvo en medios extraíbles (3.5.1.2). El truncamiento máximo depende de la longitud y la marca (hasta los primeros 8 y los últimos 4 en tarjetas de 16 dígitos), y las versiones truncada y con hash de una misma tarjeta no deben poder correlacionarse. Lo más simple es guardar solo el token de la pasarela, y con eso el almacén queda fuera del alcance de PCI.

• Las claves de idempotencia tampoco llevan datos personales. Uso UUID v4, con UNIQUE en Postgres como fuente de verdad.

7.3 Normas colombianas

Las regiones de ClickHouse Cloud están fuera de Colombia (la más cercana es São Paulo). Aun con seudónimos hay transmisión internacional, porque counterparty_id y el HMAC siguen siendo datos personales: se necesita un contrato de transmisión con el encargado o las cláusulas contractuales modelo de la Red Iberoamericana de Protección de Datos, que la SIC adoptó como opcionales en la Circular Externa 003 de 2025. La Circular Externa 002 de 2025 aplica además si hay transferencia de tecnología. Las entidades vigiladas por la Superintendencia Financiera tienen también las reglas de computación en la nube de la Circular Externa 005 de 2019 y los requisitos de ciberseguridad de la Circular Externa 007 de 2018.

Si la entidad presta servicios financieros digitales (crédito, depósitos de bajo monto o billeteras), revisa la Circular Externa 001 de 2025 de la SIC, que según los análisis publicados exige minimización, plazos de supresión y consentimientos separados. El registro de bases de datos ante la SIC es obligatorio para las sociedades y entidades sin ánimo de lucro con activos superiores a 100 000 UVT y para las personas jurídicas de naturaleza pública.

No soy abogado: esto es lo que encontré al revisar las normas para diseñar el sistema. Valídalo con tu área jurídica antes de implementarlo.

8. ClickHouse Cloud

Operar un clúster de ClickHouse que recibe 7200 millones de filas al año (réplicas, fragmentos, discos, actualizaciones, respaldos) pide un equipo dedicado. En Cloud eso lo opera ClickHouse: los datos viven en almacenamiento de objetos en una sola copia y el almacenamiento crece sin redimensionar discos.

Para el cierre, lo más útil fue separar el cómputo. Varios servicios leen los mismos datos: uno estable para la ingesta, otro para el cierre que agrando en diciembre y enero y apago el resto del año, uno de solo lectura para BI con escalado automático y otro para auditores, con sus propios usuarios y red, que solo enciendo durante la auditoría. Así el cierre no le quita CPU a la ingesta, y el servicio grande solo lo enciendo, de diciembre a marzo, cuando hay que correr el cierre.

ClickPipes, además del CDC de Postgres, se conecta a Kafka y servicios compatibles, a los servicios de streaming y almacenamiento de objetos de los principales proveedores de nube, y ofrece CDC para MySQL y MongoDB; algunos conectores siguen en vista previa. En cumplimiento, ClickHouse Cloud tiene SOC 2 Tipo II desde 2022, ISO 27001 desde 2023, HIPAA desde 2024 y PCI DSS desde 2025, con los informes en su Trust Center. HIPAA y PCI DSS requieren el plan Enterprise; la conectividad privada está disponible desde el plan Scale.

9. ClickHouse Managed Postgres y pg_clickhouse

ClickHouse Managed Postgres, anunciado al principio como “Postgres managed by ClickHouse”, es un Postgres administrado dentro de ClickHouse Cloud. Corre sobre discos NVMe locales; en su prueba de rendimiento PostgresBench, ClickHouse reporta hasta cinco veces las transacciones por segundo de un Postgres administrado sobre discos de red, en cargas limitadas por disco. Trae integrado el CDC hacia ClickHouse, en beta y construido sobre ClickPipes, así que todo lo de la sección 4 aplica igual. También trae pg_clickhouse, una extensión de código abierto para consultar ClickHouse desde Postgres.

Salió en beta pública en un primer proveedor de nube. Durante la beta se anunció gratis hasta el 15 de junio de 2026 y luego con 50 % de descuento mientras durara esa fase, con el CDC y pg_clickhouse incluidos, y el 9 de septiembre de 2026 se anunció una vista previa privada en un segundo proveedor. Esas condiciones cambian: revisa la página del producto antes de decidir.

Antes, para llevar Postgres a un almacén analítico había que montar Debezium, Kafka y conectores. Desde mayo de 2025, ClickPipes ofrece CDC administrado para cualquier Postgres 12 o superior, y Managed Postgres lo integra en el mismo proveedor.

Con pg_clickhouse, Postgres ve las tablas y vistas de ClickHouse como tablas foráneas:

-- PostgreSQL
CREATE EXTENSION IF NOT EXISTS pg_clickhouse;

CREATE SERVER clickhouse_finance
    FOREIGN DATA WRAPPER clickhouse_fdw
    OPTIONS (driver 'binary',
             host 'your-service.clickhouse.cloud',
             dbname 'finance');

-- one mapping for the admin who imports the schema,
-- one for the application
CREATE USER MAPPING FOR CURRENT_USER
    SERVER clickhouse_finance
    OPTIONS (user 'reader', password '***');
CREATE USER MAPPING FOR backoffice_app
    SERVER clickhouse_finance
    OPTIONS (user 'reader', password '***');

CREATE SCHEMA IF NOT EXISTS ch;
IMPORT FOREIGN SCHEMA "finance"
    LIMIT TO (daily_balances, monthly_tx_control)
    FROM SERVER clickhouse_finance INTO ch;

GRANT USAGE ON SCHEMA ch TO backoffice_app;
GRANT SELECT ON ch.daily_balances, ch.monthly_tx_control
    TO backoffice_app;

-- the aggregation runs inside ClickHouse
SELECT
    account,
    sum(debit_lcy_minor) - sum(credit_lcy_minor)
        AS balance_lcy_minor
FROM ch.daily_balances
WHERE entity_id = 'CO01'
  AND accounting_date BETWEEN '2026-01-01'
                          AND '2026-12-31'
GROUP BY account;

En la primera versión de este ejemplo olvidé el mapeo para el administrador y IMPORT FOREIGN SCHEMA falló; con los dos mapeos funciona. EXPLAIN VERBOSE muestra que Postgres envía a ClickHouse el filtro y la agregación y solo recibe el resultado:

Con driver 'binary' y un host de ClickHouse Cloud, pg_clickhouse usa el puerto 9440 y activa TLS automáticamente.

No lo recomiendo cuando el volumen exige fragmentar las escrituras (decenas de miles de transacciones por segundo sostenidas), cuando la regulación obliga a tener el OLTP en una región donde el servicio no existe, o mientras siga en beta si la política de riesgo de la organización no admite servicios beta en producción.

10. Tamaño estimado y riesgos

Lo que más pesa en disco son los identificadores aleatorios: dos UUID por transacción son 32 bytes que casi no se comprimen, a diferencia de las cuentas o las monedas. Si no usas idempotency_key en ClickHouse, exclúyela del pipe.

Para las cargas propias, inserta en lotes o con async_insert (miles de inserciones de una fila generan miles de partes pequeñas), usa insert_deduplication_token para que los reintentos sean idempotentes y no particiones más fino que un mes. ClickPipes ya inserta en lotes; sus reintentos están en la sección 4.4.

11. Lista de verificación del cierre

En noviembre:

• Servicio de cómputo para el cierre creado y probado.

• Ensayo general del cierre con los datos de noviembre, incluida la reconstrucción del paso 0.

• Balance preliminar refrescable activo.

• TRM como fuente oficial de tasas y hora de corte definidas.

• Bucket con bloqueo de objetos y named collections configurados.

• Alertas sobre el retraso del slot y el estado del pipe.

Entre el 31 de diciembre y el corte de operaciones (por ejemplo, el 3 de enero):

• 202612 sigue OPEN para las operaciones con fecha de diciembre que llegan tarde.

• Monitoreo de los pagos tardíos.

En el corte:

• 202612 en CLOSING en Postgres y posición del WAL anotada.

• Slot de ClickPipes al día con esa posición.

Conciliación:

• Saldos reconstruidos y verificados mes a mes (paso 0).

• Controles 1a a 1e superados.

• Cada mes comparado con Postgres a través de pg_clickhouse (conteo, total y huella).

• Conteos y totales iguales a los de bancos y pasarelas; diferencias explicadas partida por partida.

• Partidas conciliatorias documentadas.

Ajustes y cierre:

• Comprobantes registrados y aprobados en Postgres antes de insertarlos.

• Diferencia en cambio con la TRM del corte (paso 3), con su efecto fiscal documentado.

• Impuesto de renta corriente y diferido (incluido el de la diferencia en cambio), provisiones, depreciaciones, reclasificaciones y clase 7 contabilizados.

• Cuentas de resultado cerradas y sin saldo (pasos 4 y 5).

• Apertura de 2027 registrada y cuadrada (paso 6).

• Huella mensual guardada con el acta, respaldo en el bucket con bloqueo y plan de cuentas congelado (paso 7).

• Exportación a Parquet (paso 8).

Hasta la aprobación de los estados financieros:

• Diciembre en CLOSING; ajustes del auditor con el procedimiento de la sección 6.7, incluido un nuevo sellado y exportación.

• Servicio de solo lectura para auditores, con permisos por rol y políticas de fila.

• Diciembre en CLOSED después de la aprobación.

Durante todo el año:

• Si hubo una resincronización del CDC: comprobar que las vistas siguen enganchadas, volver a derivar las líneas de los meses afectados, reconstruir saldos e indicadores y repetir los controles.

• Solicitudes de supresión de datos personales atendidas en Postgres, sin tocar el libro.

Este diseño lo armé para una sola moneda funcional. Si te toca llevar NIIF y fiscal en paralelo, o varias monedas funcionales, cuéntame en los comentarios cómo lo resolviste: es lo siguiente que quiero probar.

12. Referencias

CDC de Postgres con ClickPipes

• Ingesting data from Postgres to ClickHouse (using CDC)

• Generic Postgres source setup guide

• ClickPipes for Postgres FAQ

• Deduplication strategies (using CDC)

• Ordering keys

• Handling TOAST columns

• Parallel snapshot in the Postgres ClickPipe

• Controlling the syncing of a database ClickPipe

• Schema changes propagation support

• Resyncing a database ClickPipe

• Resyncing specific tables

• Pausing and resuming a Postgres ClickPipe

• Postgres generated columns: gotchas and best practices

• Monitoring ClickPipes

• ClickPipes Terraform reference

• Postgres CDC connector for ClickPipes is now Generally Available

• Postgres to ClickHouse: Data Modeling Tips V2

• PeerDB: Data type matrix · ClickHouse data modeling best practices · Código de normalización (normalize.go)

ClickHouse

• MergeTree engine family

• Materialized views · CREATE VIEW (incremental y refrescables)

• JOIN clause: ASOF JOIN

• Hierarchical dictionaries · Functions for working with dictionaries · PostgreSQL dictionary source

• Named collections · CREATE FUNCTION

• Decimal(P, S) · Rounding functions · Financial functions

• Encryption functions · query_masking_rules

• GRANT · CREATE ROW POLICY · CREATE MASKING POLICY · Data masking in ClickHouse

• BACKUP and RESTORE · Manipulating partitions · s3 table function

• ClickHouse Release 25.7 · ClickHouse Release 25.12

ClickHouse Cloud, Managed Postgres y pg_clickhouse

• SharedMergeTree · Warehouses (compute-compute separation) · ClickHouse Cloud tiers · Supported cloud regions

• Security and compliance · Trust Center · Data encryption (CMEK)

• ClickHouse Managed Postgres · Sync to ClickHouse · Pricing

• Postgres managed by ClickHouse is now in beta · Anuncio de la vista previa privada (9 de septiembre de 2026) · PostgresBench

• pg_clickhouse (GitHub) · pg_clickhouse reference

PostgreSQL

• CREATE PUBLICATION · Logical replication: column lists · ALTER TABLE (REPLICA IDENTITY) · CREATE TRIGGER

Dinero y estándares

• ISO 4217: Agencia de mantenimiento · Lista oficial (XML)

• RFC 3339: Date and Time on the Internet · ISO 8601 · ISO 3166

• ISO 20022 message definitions

• Banco de la República: Bre-B (documento de trabajo, febrero de 2026)

Datos personales y seguridad

• Ley 1581 de 2012 · Decreto 1377 de 2013 · Decreto 1074 de 2015 · Decreto 090 de 2018

• SIC: Circular Externa 003 de 2025 · Circular Externa 002 de 2025 · Circular Externa 001 de 2025

• Superintendencia Financiera: Circular Externa 007 de 2018

• Reglamento (UE) 2016/679 (GDPR)

• PCI SSC: PCI DSS v4.0.1 · Formatos de truncamiento aceptados

Contabilidad y tributario

• Ley 962 de 2005 · Código de Comercio (Decreto 410 de 1971) · Estatuto Tributario (Decreto 624 de 1989)

• Decreto 2650 de 1993 (PUC) · Ley 1314 de 2009 · Decreto 2420 de 2015

• IFRS: NIC 8 · NIC 12 · NIC 21

Un brasileño paga el café con una llave de correo electrónico. Un colombiano manda plata con una arroba. Un venezolano teclea cédula, teléfono y banco, y reza. Los tres creen que están haciendo lo mismo. Y en parte tienen razón: los tres mueven dinero entre bancos distintos en segundos, sin tarjeta, sin efectivo y sin horario.

Pero por debajo, Pix, Bre-B y el Pago Móvil venezolano son tres respuestas muy distintas a una misma pregunta — y la diferencia entre ellas explica por qué uno arrasó, otro arrancó disparado y el tercero lleva casi una década funcionando sin que casi nadie fuera de Venezuela lo estudie.

Esta es la anatomía de los tres, con cifras oficiales, diagramas y las diferencias que sí importan. Si eres ingeniero de pagos, encontrarás la fontanería. Si nunca has oído hablar de un «sistema de pagos de bajo valor», también: cada cosa se explica antes de usarse. Cada número lleva al lado el enlace a la fuente de donde salió, para que puedas comprobarlo sin creerme nada.

En 60 segundos

• ¿Son lo mismo? No. Son la misma categoría —pagos inmediatos, interoperables, 24/7— con arquitecturas y dueños distintos.

• ¿Cuál es la diferencia de fondo? El directorio de llaves: la base de datos que traduce tu correo o tu celular a un número de cuenta. Pix y Bre-B tienen uno; el Pago Móvil venezolano no. Todo lo demás se deriva de ahí.

• ¿Cuál se usa más? Pix, sin competencia: más de 7.000 millones de transacciones en un solo mes. Pero si en vez de contar el total se cuenta por habitante, Venezuela queda en segundo lugar y muy por encima de Colombia — unas 360 operaciones diarias por cada 1.000 personas frente a 152. Ese cálculo es mío y lo explico, con sus límites en los puntos.

• ¿Cuál llegó primero? Venezuela, en 2017 — tres años antes que Pix y ocho antes que Bre-B.

• ¿Funcionan entre países? Ninguno. Ni uno solo cruza la frontera todavía.

• ¿Cuánto cuestan? Pix y Bre-B son gratis para las personas. El Pago Móvil venezolano no: cobra 0,30 % del monto con un mínimo de 14 bolívares, y ese mínimo subió desde 2 bolívares en julio de 2026 — un alza del 600 % que se siente sobre todo en los pagos chicos, porque un cobro fijo pesa más cuanto menos pagas.

• ¿Porqué nadie esta hablando de la solución venezolana si fue pionera junto con SPEI de México? No les voy a mentir, nadie lo sabe, pero yo particularmente supongo que es por la situación actual del país y como se ve desde afuera.

1. ¿Qué es exactamente un «pago inmediato»?

La expresión se usa para todo, así que conviene fijarla. Un sistema de pagos inmediatos —fast payment system en la literatura del Banco de Pagos Internacionales— cumple cuatro condiciones a la vez. Si le falta una, es otra cosa:

1. Es inmediato de verdad. El beneficiario puede usar el dinero en segundos, no verlo «en camino».

2. Está siempre encendido. Domingo a las tres de la mañana, 1.º de enero, feriado bancario: da igual.

3. Es interoperable. Funciona entre entidades distintas. Un sistema que solo mueve dinero dentro del mismo banco o de la misma billetera no clasifica.

4. Es irrevocable. Una vez ejecutado, no se deshace unilateralmente. Esto es una virtud y un peligro, y más adelante veremos por qué.

Nótese lo que no está en la lista: ni gratuidad, ni QR, ni celular, ni app bonita. Todo eso son decisiones de diseño encima de la infraestructura — y son justamente las decisiones donde Brasil, Colombia y Venezuela se separan.

2. La anatomía: ¿qué pasa en esos diez segundos?

Hay un detalle que casi nunca se cuenta y que ordena todo lo demás: el mensaje y el dinero viajan por caminos distintos.

Cuando pulsas «enviar», lo que sale disparado es un mensaje: «la cuenta A autoriza 50.000 a la cuenta B». Ese mensaje va a tu entidad, que valida saldo y firma; de ahí a la infraestructura central, que averigua a qué cuenta apunta el identificador y enruta; de ahí a la entidad de destino, que acepta y abona. Todo eso ocurre en menos de diez segundos y es lo que tú ves. Esa parte es compartida entre todos los sistemas.

El dinero entre bancos es otra historia. Los bancos se deben plata entre ellos todo el día, y eso se salda contra las cuentas que cada uno mantiene en el banco central — en tiempo real, o por compensación en ventanas a lo largo del día. Quien recibió ya gastó su dinero mucho antes de que esa cuenta cuadre. Ahí vive el riesgo del sistema, y por eso el banco central nunca está lejos del volante.

Los cuatro papeles que alguien tiene que ocupar

• El que manda. Obliga a participar, fija tarifas y define las reglas. Casi siempre el banco central o el regulador bancario.

• El que opera. Enruta los mensajes y resuelve las llaves. Puede ser el propio banco central, una cámara de compensación o un consorcio privado.

• El que liquida. Cuadra las cuentas entre entidades. Esto casi nunca se delega: lo hace el banco central.

• El que atiende. Pone la app, el soporte y la lucha contra el fraude. Bancos, cooperativas y billeteras.

3. La pregunta que lo decide todo: ¿cómo nombras a quien recibe?

Aquí está, en serio, la diferencia de fondo. Un número de cuenta bancaria es un identificador diseñado para los bancos, no para las personas: “nadie se sabe el suyo” (o al menos, para eso no estan diseñados). Los sistemas modernos resuelven esto con un directorio, una base de datos que traduce algo que sí te sabes —tu correo, tu celular, tu cédula— a una cuenta concreta.

Brasil lo llamó DICT (Diretório de Identificadores de Contas Transacionais). Colombia lo llamó directorio centralizado de llaves y lo puso bajo el Banco de la República. Venezuela no tiene: en el Pago Móvil, tú eres el enrutador. Tecleas cédula, teléfono y —esto es lo importante— el banco de destino. Si el banco está mal, el pago no sale, o sale a donde no debía.

De esa única decisión se derivan tres consecuencias que la gente siente todos los días:

• Confirmación antes de pagar. Con directorio, la app te muestra el nombre del destinatario antes de que confirmes. Sin directorio, confirmas a ciegas y el nombre aparece después, en el comprobante.

• Portabilidad. Con directorio, cambias de banco y te llevas la llave. Sin directorio, cambiar de banco significa avisarle a todo el mundo.

• Cobros automáticos. Un directorio es la precondición para que alguien te cobre de forma recurrente sin pedirte los datos cada vez.

4. Pix: el caso que todos copian

El Banco Central do Brasil encendió Pix el 16 de noviembre de 2020. Cinco años y medio después, las cifras son de otra escala:

• Más de 7.000 millones de transacciones en mayo de 2026, por encima de R$ 3 billones en el mes.

• Casi 80.000 millones de operaciones en todo 2025, con más de R$ 35 billones movilizados.

• Más de 170 millones de personas físicas lo han usado — en un país de unos 213 millones de habitantes.

¿Por qué funcionó? Tres decisiones, y ninguna es tecnológica:

1. Obligatorio. Las instituciones grandes no pudieron elegir si participaban. No hubo «efecto isla».

2. Gratis para las personas. Sin comisión, la resistencia a probarlo fue cero.

3. Una marca, no una función. Pix no es «transferencia inmediata del banco X»: es Pix, en todos lados, con el mismo nombre y el mismo flujo.

Vale la pena mencionar dos piezas que suelen pasar desapercibidas. El MED (Mecanismo Especial de Devolução) es el procedimiento para devolver fondos cuando hubo fraude — la respuesta al problema de la irrevocabilidad. Y el Pix Automático, encendido en junio de 2025, es el que permite cobros recurrentes: el momento en que Pix dejó de ser solo un instrumento de empuje. Volveremos a esto.

5. Bre-B: Colombia llegó tarde y arrancó rápido

Colombia tenía transferencias inmediatas desde antes —Transfiya, Nequi, Daviplata— pero cada una en su isla. Bre-B, del Banco de la República, es el sistema que las obliga a hablarse. El registro de llaves abrió en julio de 2025 y la operación plena arrancó en octubre de 2025.

Los números del primer año son notables — y, comparados con los de Pix en su mismo momento de vida, mejores:

• 108 millones de llaves registradas, al corte de junio de 2026.

• Unos 35 millones de personas vinculadas y 782.218.571 operaciones acumuladas al 4 de mayo de 2026.

• De 1,5 a más de 5 millones de operaciones diarias en siete meses, con picos por encima de 5,8 millones.

• Tope por transacción en 2026: COP 12.110.000, que es el equivalente a 1.000 UVB.

• Registrar una llave y transferir con ella: sin costo.

Las llaves pueden ser cinco cosas: número de documento, celular, correo electrónico, una alfanumérica que tú eliges (la famosa arroba, @tunombre) y un código de comercio para negocios. Cada llave apunta a una sola cuenta, pero una cuenta puede tener varias llaves. Las cifras al día viven en el tablero de indicadores del Banco de la República.

Un matiz que conviene tener a mano: los 108 millones de llaves no son 108 millones de personas. Una sola persona puede registrar documento, celular, correo y arroba — cuatro llaves, un ser humano. La cifra que importa es la de usuarios vinculados, que va por 35 millones.

6. Venezuela: Pago Móvil, C2P y el débito que casi nadie explica

Aquí es donde la mayoría de las comparaciones se rompen, porque tratan «Pago Móvil» como si fuera una sola cosa. No lo es. Venezuela tiene cuatro instrumentos que conviven, y la manera limpia de ordenarlos es preguntarse quién aprieta el botón.

De empuje: lo inicia quien paga

• Pago Móvil Interbancario (P2P). El que todo el mundo conoce. Arrancó en 2017, tras un piloto con diez bancos, bajo la supervisión de la Sudeban y sobre la Cámara de Compensación Electrónica del BCV. Cédula, teléfono, banco, monto.

• Crédito Inmediato (CI). La transferencia interbancaria que acredita el mismo día. Sus modalidades incluyen crédito ordinario, pago de nómina, fideicomisos y pagos de tarjeta de crédito. Es el riel de las empresas.

De jalón: lo inicia quien cobra, con permiso previo

• C2P (comercio a persona). El comercio pide cédula, teléfono y banco; al cliente le llega una clave por mensaje y la entrega en caja o la escribe en el checkout. Esa clave es la autorización. Da trazabilidad y conciliación automática — lo que el P2P, con su captura de pantalla y su «ya te pagué», nunca dio.

• Débito Inmediato (DI). Autorizas una vez y el cobro se repite: servicios, cuotas, suscripciones. Sus modalidades incluyen autorizaciones en línea, claves de pago y domiciliaciones, y verifica la disponibilidad de fondos en el momento.

Dicho de otro modo: el Débito Inmediato venezolano es el primo del Pix Automático brasileño, y existe desde hace años. Es uno de esos casos donde el país llegó antes al concepto y después al reconocimiento — aunque realmente no ha llegado el reconocimiento adecuado a esta idea nacida de la gran necesidad.

¿Cuánto se usa — y cuánto cuesta?

Según cifras del BCV recogidas por la banca, el pago móvil representa el 41 % de las operaciones bancarias del país, con los puntos de venta en 47 %. La velocidad, reportada por la prensa especializada, pasó de unas 6.000 a unas 7.000 operaciones por minuto durante 2026.

Y aquí está la diferencia más incómoda con Brasil y Colombia: en Venezuela, el pago móvil no es gratis. El BCV publicó en la Gaceta Oficial N.º 46.427, del 31 de julio de 2026, un tarifario donde:

• El P2P interbancario entre personas naturales queda en 0,30 %, con un cobro mínimo de 14 bolívares.

• El P2C entre bancos distintos puede llegar a 1,50 % del monto.

• Ese mínimo pasó de 2 a 14 bolívares: un alza del 600 % — entendiendo la volatilidad del bolívar venezolano.

Un cobro mínimo fijo es regresivo por construcción, y la aritmética lo enseña sola: 14 bolívares sobre un pago de 100 son un 14 %; sobre uno de 10.000, un 0,14 %. Cien veces más caro para quien paga cien veces menos. En un país donde el pago móvil sustituyó al efectivo para la compra diaria, eso no es un detalle de tarifario — es una decisión sobre quién paga la infraestructura.

Falta un contexto sin el cual nada de esto se entiende: Venezuela es una economía fuertemente dolarizada en efectivo. El pago móvil no compite contra la tarjeta como en Brasil; compite contra un billete de dólar que circula de mano en mano. Es el riel digital del bolívar, y arrastra consigo todo lo que le pasa al bolívar.

7. Entonces, ¿son lo mismo?

No. Comparten categoría y se parecen en la experiencia; se separan en casi todo lo demás. Pix y Bre-B son “gemelos” (al menos en principio) con diez años de diferencia: los dos tienen directorio, los dos son gratis, los dos obligan a las entidades a participar y los dos te enseñan el nombre de quien va a recibir antes de que confirmes.

El Pago Móvil venezolano se parece a ambos en velocidad y en alcance, y se separa en las tres cosas que más se notan: no hay directorio, no hay confirmación previa del nombre y no es gratis. Lo que sí tiene —y a Bre-B todavía le falta— es el cobro recurrente funcionando.

8. Veinte años de intentos

La región no empezó con Pix. México tiene SPEI desde 2004 —dos décadas— y le sumó CoDi (QR, 2019) y DiMo (pagos por número de celular, 2023) precisamente porque SPEI, siendo excelente infraestructura, nunca conquistó el menudeo.

Costa Rica encendió SINPE Móvil en 2015 y hoy lo usa cerca del 76 % de la población mayor de 15 años, con unos 4,6 millones de suscripciones activas: la penetración más alta de la región en proporción.

Argentina lanzó Transferencias 3.0 el 29 de noviembre de 2021. Perú obligó a Yape y Plin a interoperar desde 2023.

La lección se repite: la infraestructura no basta. Lo que mueve la aguja es la combinación de obligatoriedad, gratuidad y un identificador que la gente ya se sabe de memoria.

9. Penetración: los números, con sus asteriscos

Comparar estos sistemas es difícil porque cada país publica una métrica distinta: Brasil informa transacciones por mes, Colombia operaciones por día y llaves acumuladas, Venezuela porcentajes del total bancario.

Para poder ponerlos lado a lado, normalicé todo a una sola unidad: operaciones diarias por cada 1.000 habitantes. La división está impresa dentro de la figura para que cualquiera pueda rehacerla o discutirla.

Tres advertencias que hay que leer antes que el gráfico:

1. Bre-B cuenta solo lo que pasa por Bre-B. Un colombiano que paga de Nequi a Nequi no aparece: esa operación no cruza el sistema interoperado. El uso real de pagos digitales en Colombia es mayor que la barra.

2. La cifra venezolana viene de prensa, no de una serie oficial publicada periódicamente. Y la población del país es objeto de disputa metodológica, así que el denominador también tiene error.

3. Una transacción no es un peso. Muchos pagos pequeños y pocos pagos grandes dan volúmenes parecidos y economías completamente distintas.

Con todo eso dicho, el orden de magnitud sí aguanta: Brasil está en otra liga, y Venezuela, por habitante, está muy por encima de lo que su tamaño económico sugeriría. La razón más plausible no es tecnológica: cuando el efectivo escasea y la inflación castiga al que lo guarda, digitalizarse deja de ser una comodidad y pasa a ser la única forma práctica de comprar. La necesidad empuja más rápido que cualquier campaña.

Págo Móvil fue una iniciativa nacida luego de los mega apagones de Venezuela en 2017, que obligaron a la banca y el Banco Central de Venezuela o ofrecer soluciones ágiles e interoperables.

10. Percepciones: lo que se cree y lo que es

• «Pix es una app.» No: es infraestructura pública. Lo usas dentro de la app de tu banco, igual que usas la red eléctrica dentro de tu casa.

• «Bre-B reemplaza a Nequi o Daviplata.» Al contrario: las conecta. Sigues usando tu app de siempre; lo que cambia es hasta dónde alcanza.

• «El Pago Móvil venezolano es un invento improvisado.» Lleva desde 2017 corriendo sobre la cámara de compensación del banco central, con normativa y supervisión. Le falta un directorio, no seriedad. Y puede que incluso para algunos ojos, el que no tenga directorio lo hace mejor.

• «Es gratis en todas partes.» Gratis en Brasil y Colombia para personas naturales. En Venezuela se cobra, y desde 2026 bastante más. Eso hace que el sistemma venezolano ya sea rentable, y no como Bre-b que tiene planes dé, pero aún esta en “veremos”.

• «Pix sirve en toda Latinoamérica.» No. Es brasileño y liquida en reales. Lo que ves fuera de Brasil son pasarelas que lo intermedian. Aunque puede que en Venezuela operen los 3 sistemas, principalmente por las condiciones del país, y sobre todo en ciudades fronterizas.

• «Es más inseguro que una tarjeta.» El riesgo se desplaza, no crece: menos fraude con datos robados, más ingeniería social — te convencen de que tú mandes el dinero. Por eso Brasil tuvo que inventar el MED.

11. ¿Y si cruzo la frontera?

Hoy, nada de esto funciona de un país a otro de manera oficial. Pix liquida en reales dentro de Brasil; Bre-B en pesos dentro de Colombia; el Pago Móvil en bolívares dentro de Venezuela. Cuando ves «acepta Pix» en un comercio fuera de Brasil, casi siempre hay una pasarela que cobra en reales a una cuenta brasileña y luego hace otra cosa con ese dinero. No es interoperabilidad: es intermediación.

Pero, como les digo, lo más probable es que no oficialmente ya operen Pix y Bre-b en Venezuela; de hecho, casas de cambio en ciudades de frontera operan los servicios, porque Págo Móvil a día de hoy no compite con el uso de tarjetas, lo hace con divisas más sólidas, incluso el real y los pesos colombianos.

El intento serio de resolverlo se llama Nexus, del Banco de Pagos Internacionales: en vez de construir n × (n−1) conexiones bilaterales entre países, un estándar único al que cada sistema nacional se conecta una sola vez. Es la diferencia entre que cada país negocie con cada país, y que todos se enchufen al mismo tomacorriente.

Aúnque en mi opinión, cada vez más se apuesta por el exchange, por lo que creo que este último terminará conectandolos todos.

12. ¿Qué viene?

• El jalón gana terreno. Pix Automático es de 2025; Bre-B trabaja en su versión para empresas. El cobro recurrente es donde está el dinero aburrido y constante: servicios, suscripciones, cuotas.

• Crédito encima del riel. Pix parcelado ya existe; la tentación de poner financiación sobre una transferencia instantánea es enorme, y trae consigo los problemas del crédito al consumo.

• Las tarjetas defienden el margen. En Brasil, Pix ya superó a las tarjetas en número de operaciones. Esa pelea apenas empieza en Colombia.

• Venezuela tiene una tarea pendiente clara. No necesita otro instrumento: tiene empuje y jalón, P2P y C2P, crédito y débito inmediato. Necesita un directorio — y que el costo no expulse al pago pequeño.

Preguntas que algunos amigos me hacen:

¿Bre-B es lo mismo que Pix?
No, pero se le parece mucho a propósito. Ambos son sistemas de pagos inmediatos con directorio de llaves, gratuitos y obligatorios para las entidades. Cambian el operador, el país, la moneda y el alcance funcional.

¿El pago móvil venezolano es un sistema de pagos inmediatos?
Sí, cumple las cuatro condiciones: inmediato, 24/7, interoperable e irrevocable. Lo que no tiene es directorio de llaves ni gratuidad.

¿Puedo mandar dinero de Colombia a Venezuela con Bre-B?
No. Bre-B opera dentro de Colombia y liquida en pesos colombianos. Algunas casas de cambio pueden cobrarte en Pesos dentro de Colombia y enviarte bolívares a una cuenta de banco en Venezuela, pero eso es otra historia.

¿Cuál es la diferencia entre P2P y C2P?
El P2P lo inicia quien paga; el C2P lo inicia el comercio y el cliente lo autoriza con una clave que recibe por mensaje. El segundo deja trazabilidad y permite conciliar ventas.

¿Qué es el Débito Inmediato?
El instrumento venezolano de cobro recurrente autorizado: domiciliaciones, claves de pago y autorizaciones en línea, con verificación de fondos en el momento. Conceptualmente equivale al Pix Automático.

¿Cuánto puedo enviar por Bre-B?
Hasta COP 12.110.000 por transacción en 2026, que es el equivalente a 1.000 UVB. Cada entidad puede fijar topes más bajos por seguridad.³

Dejo la métodología que usé clara

Las cifras de Pix provienen de las estadísticas del Banco Central do Brasil; las de Bre-B, de las publicaciones e indicadores del Banco de la República; las de Venezuela, de datos del BCV recogidos por la banca y de prensa especializada, porque no existe una serie pública equivalente. Cada afirmación numérica lleva su enlace en el número volado que la sigue.

El indicador de la Figura 4 es una estimación propia, no un dato publicado por nadie: nace de dividir las cifras de operaciones de cada país entre su población, y su aritmética completa está impresa dentro del gráfico justamente para que se pueda auditar y rebatir. Donde el dato es de prensa y no de fuente primaria, está dicho en el propio texto. Corte de la información: septiembre de 2026.

Referencias — por si quieres profundizar

1. Banco Central do Brasil — Pix, página oficial.

2. Banco Central do Brasil — Estatísticas do Pix, portal de datos abiertos.

3. Banco de la República — Conozca Bre-B.

4. Banco de la República — Indicadores de Bre-B.

5. Banco de la República — «En siete meses, Bre-B triplicó sus transacciones diarias».

6. Banco de la República — Documento técnico de Bre-B (febrero de 2026, PDF).

7. Banca y Negocios — «Operaciones con pago móvil representan el 41 % de las transacciones bancarias en Venezuela».

8. El Nacional — «Aumento de 600 % en la comisión mínima del pago móvil».

9. El Estímulo — «BCV actualiza tarifas de operaciones bancarias».

10. La Prensa de Monagas — «Pago móvil creció de 6 mil a 7 mil operaciones por minuto en 2026».

11. Infobae — «Bre-B disparó sus transacciones y ya mueve hasta 5 millones de operaciones diarias».

12. Bank for International Settlements — BIS Papers n.º 152: Faster digital payments (PDF).

13. Bank for International Settlements — Proyecto Nexus.

14. Fintech News America — «SINPE Móvil driving financial inclusion in Costa Rica».

15. Sudeban — Superintendencia de las Instituciones del Sector Bancario.

16. Banco Central de Venezuela — sitio oficial.

17. Banco Central de la República Argentina — sitio oficial.

18. Banco de México — sitio oficial.

19. Banco Central de Costa Rica — SINPE.

Hay etapas profesionales que no se miden solamente por el tiempo que duran, sino por la cantidad de problemas reales que te obligan a entender, la cantidad de personas con las que construyes y la forma en que sales de ellas: con más criterio, más perspectiva y más respeto por el trabajo bien hecho.

Hoy estoy cerrando mi ciclo en Yummy, una compañía que fue para mí mucho más que un lugar de trabajo. Fue un espacio de crecimiento técnico, humano y profesional. Un lugar donde tuve la oportunidad de construir soluciones con impacto real, participar en decisiones complejas, liderar iniciativas estratégicas y aprender, muchas veces, en escenarios donde no había respuestas simples.

Me voy con gratitud, con orgullo por lo construido y con una visión mucho más clara de lo que significa hacer tecnología dentro de una operación viva, exigente y en constante movimiento.

Construir tecnología donde ocurre el negocio

Durante mi paso por Yummy trabajé principalmente en retos asociados al equipo tecnológico de finanzas, un equipo donde la tecnología no vive aislada: cada decisión técnica tiene relación directa con procesos financieros, conciliaciones, facturación, dispersión, reportería, integraciones internas, operación diaria y cumplimiento.

Eso cambia la forma en que uno entiende el software. La velocidad y la forma en la que comienzas a ver el mundo, sobre todo en un país como Venezuela.

No se trata solo de crear servicios, endpoints o dashboards. Se trata de construir sistemas que soporten decisiones, que reduzcan fricción operativa, que den trazabilidad, que permitan auditar, que conecten equipos y que ayuden a que el negocio funcione con mayor claridad.

Tuve la oportunidad de participar en iniciativas alrededor de:

• Modernización de procesos financieros: procesos que actualmente no tienen nada que envidiarle a cualquier corporación internacional existente a día de hoy.

• Integraciones con sistemas internos y externos: con lo último en tecnología, pero sin dejar de ser estable, escalable y altamente operativo.

• Automatización de flujos operativos: generando asistentes y operaciones automatizadas completamente, que antes requerían muchas horas hombre.

• Implementación y evolución de ERP: gestionando toda la cadena operativa y administrativa, con tecnología de vanguardia. Cuando se habla de Yummy, no son 100 o 200 operaciones aisladas al mes, son millones.

• Reporting financiero y herramientas de análisis: integrales, que operan a un nivel de seguridad muy alto, con capacidad y disponibilidad 24/7.

• Conciliación y dispersión de fondos: lo que puede parecer fácil, y que realmente es una de las cosas más complejas de hacer, por el volumen de la operación.

• Observabilidad y trazabilidad de procesos críticos: nos pusimos la meta de poder detectar fallos de forma proactiva, documentarlo todo y generar luego de eso, incluso, sistemas de predicción. Y sí, se cumplió.

• Revisión de arquitectura, seguridad y calidad: modernizando todos y cada uno de los servicios, ejecutando procesos modernos con arquitectura moderna y elastica.

• Gobernanza de datos y criterios de autoridad sobre la información: Trabajando de la mano con otros equipos especializados en el tema, nos convertimos en referencia de cómo se pueden hacer las cosas cumpliendo estos criterios.

• Uso práctico de inteligencia artificial: haciéndola realmente útil, no simplemente diciéndole a la IA “construyeme un front bonito y seguro para ver el proceso de conciliación“, sino integrándola al desarrollo de un equipo altamente profesional y dedicado a su trabajo, no solo como asistente, sino como parte de las soluciones.

Cada una de estas áreas dejó una enseñanza distinta. Algunas fueron profundamente técnicas; otras, más organizacionales. Muchas fueron ambas al mismo tiempo.

De resolver tickets a diseñar sistemas

Uno de los aprendizajes más importantes que me llevo es que un equipo técnico madura cuando deja de pensar únicamente en entregables aislados y empieza a pensar en sistemas como soluciones.

Un ticket puede cerrar una necesidad puntual. Un sistema bien diseñado cambia la forma en que el equipo opera.

En Yummy pude trabajar en esa transición: liderando a mi equipo para pasar de resolver problemas caso por caso a crear mecanismos más repetibles, trazables y sostenibles; a soluciones sistematizadas y altamente operativas sin perder seguridad o confiabilidad.

Eso implicó fortalecer metodologías de planificación, análisis de impacto, documentación técnica, criterios de aceptación, revisión de arquitectura y validación antes de ejecutar.

Un error al sumar 1+1 en cualquier equipo puede ser un simple bug, o como mucho implicar una pérdida de estabilidad en el sistema, incluso una caída total; que, aun siendo muy grave, ese mismo error en finanzas puede hacer que no se puedan ejecutar operaciones financieras en toda una compañía; incluso puede ser motivo de sanción administrativa por el regulador.

Un ejemplo claro fue la evolución hacia una forma más estructurada de planificar iniciativas técnicas: antes de escribir código, entender el dominio, mapear dependencias, identificar riesgos, revisar impacto entre repositorios, definir escenarios de prueba y separar lo urgente de lo importante.

Ese tipo de disciplina no hace más lento al equipo. Bien aplicada, lo hace más confiable. Y claro que no es solo eso, sino dale la confianza necesaria, y aprender a delegar, entender que no todo lo importante es urgente, y que no todo lo urgente es importante; lo urgente e importante se ejecuta al momento; lo urgente se planifica y lo importante se comunica.

Porque cuando un cambio toca pagos, finanzas, facturación o conciliación, el costo de “probar en producción” sin suficiente claridad no es solo técnico. Puede convertirse en ruido operativo, reprocesos, inconsistencias de datos o pérdida de confianza entre áreas o, como les reitero, sanciones muy fuertes por parte del regulador.

Metodologías que realmente aportan

Una parte importante de mi paso por Yummy estuvo relacionada con impulsar mejores formas de trabajo. No metodologías como ritual vacío, sino como herramientas prácticas para reducir incertidumbre.

Entre las prácticas que más valor aportaron estuvieron:

• Planificación técnica estructurada, para convertir necesidades ambiguas en rutas de ejecución claras.

• Spec-Driven Development, usando especificaciones antes de implementar.

• Criterios de aceptación en Gherkin, para que negocio, QA y tecnología hablaran con mayor precisión.

• Definition of Ready y Definition of Done, evitando iniciar trabajo incompleto o cerrar trabajo que aún no estaba realmente operativo.

• Revisión de arquitectura, especialmente cuando una decisión podía afectar varios servicios.

• Análisis de impacto multi-repositorio, necesario en ecosistemas donde un cambio pequeño puede tener consecuencias en varios flujos.

• KPIs de ingeniería, no como herramienta de presión, sino como forma de entender tendencias, capacidad, foco y trade-offs.

• Retrospectivas basadas en hechos, para aprender de lo ocurrido sin convertir los problemas en culpa.

• Observabilidad como parte del diseño, no como algo que se agrega al final.

• Automatización de reportes y seguimiento, para liberar tiempo de coordinación y mejorar visibilidad.

Una metodología solo sirve si ayuda a tomar mejores decisiones. Si solo agrega reuniones o documentos sin impacto, no sirve. Esa diferencia fue algo que aprendí hace años y reforcé con mucha claridad.

Inteligencia artificial como capacidad adicional del equipo de desarrollo e ingeniería

Otro eje importante fue el uso de herramientas de IA en el trabajo técnico. No como reemplazo del criterio humano, sino como acelerador para tareas donde el contexto, la revisión y la estructura importan: análisis de repositorios, generación de planes, revisión de riesgos, documentación, validación de criterios, preparación de reportes, análisis de impacto y soporte a procesos de Tech Lead.

Uno de los trabajos que más orgullo me deja fue contribuir al desarrollo y uso de herramientas internas para AI. Brindandole seguridad, confiabilidad, contexto y sobre todo limites claros de su uso e implementación.

Logrando una forma de organizar contexto, memoria, reglas, agentes, revisiones y documentación para que distintas herramientas de IA pudieran apoyar el trabajo técnico sin depender de improvisación. Esto me confirmó algo importante: la IA en ingeniería no se trata de pedirle “hazme esto” a una herramienta.

Se trata de diseñar un sistema de trabajo donde la IA tenga contexto, límites, criterios de calidad y validación humana. Y en estos dos años con el impulso de la AI reforcé algo que observava desde los salones de mi antigua alma mater: la diferencia entre usar IA como juguete y usarla como capacidad real está en la disciplina con la que se integra al proceso.

Porque la AI puede parecer muy moderna, pero su desarrollo comenzo casi desde los inicios de la computación moderna, si mal no recuerdo los años 60’s. Solo que hace 15 años, eran “algoritmos avanzados“ los que se encargaban de ejecutar esas tareas.

Aprender a pensar en trazabilidad

En compañías con operación financiera, la velocidad importa, pero la trazabilidad importa igual o más. Liderando un equipo técnico en Yummy, desarrollando soluciones de alto nivel para el mercado venezolano, es donde más se nota.

Hay procesos donde no basta con que algo “funcione”. También hay que poder explicar qué ocurrió, cuándo ocurrió, por qué ocurrió, qué sistema lo produjo y cómo se puede verificar.

Esa forma de pensar estuvo presente en muchos retos: conciliaciones, reportes, integraciones, dispersión de fondos, dashboards, logs, validaciones y procesos de auditoría.

Un ejemplo práctico: cuando un flujo financiero atraviesa varios sistemas, no alcanza con saber que el resultado final llegó. Es necesario poder seguir la historia completa: desde el evento inicial, pasando por las transformaciones, validaciones, decisiones, estados intermedios y resultado final.

Esa trazabilidad reduce fricción entre equipos. Permite que soporte, finanzas, producto, data e ingeniería hablen sobre hechos y no sobre suposiciones.

Gobernanza de datos: una de las discusiones más valiosas

Uno de los aprendizajes más profundos estuvo alrededor de la gobernanza de datos: acalorado, pero gratificante cuando vez una implementación correcta, certificada y funcional en plena operación.

En tecnología es común escuchar frases como “una sola fuente de verdad”. Suena correcto, pero en dominios financieros la realidad suele ser más compleja.

A veces el problema no es tener un solo número. El problema es entender qué representa cada número, quién lo produce, bajo qué regla, en qué momento, con qué responsabilidad y para qué decisión se usa.

No todo dato tiene el mismo peso. No es lo mismo un dato analítico que un dato contable. No es lo mismo una métrica de observación que un registro que puede tener consecuencias fiscales, operativas o regulatorias.

Ese tipo de discusiones me ayudó a reforzar una idea que me parece fundamental:

• Lo reversible se puede centralizar con mayor facilidad.

• Lo irreversible debe quedarse cerca de quien lo firma, lo controla y responde por sus consecuencias.

Esa frase resume mucho de lo que aprendí sobre arquitectura, responsabilidad y operación.

También hubo momentos difíciles

No quiero romantizar el proceso. No todo fue simple, ni perfecto, ni siempre cómodo. Todos los procesos son complejos, aún más si sin procesos humanos.

Hubo momentos de presión alta, prioridades cambiantes, deuda técnica, ambigüedad, diferencias de criterio, urgencias operativas y decisiones tecnicas difíciles. También hubo conversaciones donde era necesario defender una postura técnica, ó reconocer errores, ajustar el enfoque o aceptar que una solución inicial no era suficiente, incluso enfrentar tus argumentos con los de la mismisima directiva.

Pero esos momentos también fueron parte esencial del aprendizaje. Yummy no es una empresa más, aquí te consigues al director de finanzas un viernes en la oficina y te invita un cafe, o vas a una reunión despues del trabajo y puedes conversar tranquilamente con el CEO. Pero, a mayor confianza, el mayor respeto posible; accesibilidad no siempre representa saltarte pasos necesarios para cumplir tus metas, sino saber aprovechar esa accesibilidad para comunicar lo que sea necesario, en el momento necesario y de la forma correcta.

Liderar técnicamente no es tener siempre la razón. Es crear claridad cuando hay ruido. Es saber cuándo empujar, cuándo escuchar, cuándo documentar, cuándo escalar y cuándo cambiar de opinión. Por eso es importante tener en cuenta que:

• Una buena discusión técnica no debería tratarse de ganar un argumento, sino de encontrar una solución que reduzca riesgo y haga sentido para el negocio.

• La comunicación efectiva, es tan importante como la arquitectura. Una solución técnicamente correcta puede fallar si no está bien explicada, si no considera a las personas que la operan o si no reconoce las restricciones reales del entorno.

La respuesta ante momentos inesperados

También me tocó ver y participar en momentos donde la tecnología tuvo un rol distinto al habitual, bueno, donde la empresa tuvo un movimiento que nunca habia visto en otra empresa, con mis 13 años en el sector TI.

Ver como durante un terremoto, toda la directiva de la empresa, llamo personalmente a cada uno de los empleados, de todos los niveles, personalmente para ver si estaban bien. Y no una, sino dos veces. ¡ES IMPRESIONANTE!

Durante situaciones de contingencia nacional, quedó claro que (según mi criterio) la empresa de tecnología más innovadora de Venezuela, y una de las tecnologicas más importantes del país, colocaba su equipo, infrestructura y tecnología completa; a disposición de los ciudadanos.

Cuando todos preguntamos si podiamos desconectarnos ese día para ir a ayudar, nos dijeron que podiamos ayudar desde Yummy. Y para alguien a +1.000 km del desastre, es algo que realmente fue útil. Noches sin dormir, dias de preocupación y aun con traumas desarrollamos soluciones altamente operativas en horas.

Contruyendo respuesta, coordinación, visibilidad y soporte cuando el contexto lo exige. Ese tipo de experiencias recuerdan que detrás de cada sistema hay personas. Y que la tecnología, cuando está bien orientada, puede ser una herramienta concreta para ayudar, ordenar información y responder mejor.

Me llevo ese aprendizaje con especial respeto.

Lo que me llevo de Yummy

Me llevo muchas cosas, no voy a negar que buenas y no tan buenas, pero esas ultimas son tan pocas que realmente sé que no afectarán en lo más minimo, porque así es Yummy, siempre evoluciona y se adapta para cumplir con lo que realmente importa.

1. Me llevo una comprensión más profunda de sistemas financieros y operativos.

2. Me llevo experiencia liderando iniciativas con impacto real.

3. Me llevo mejores criterios para arquitectura, automatización y datos.

4. Me llevo aprendizajes sobre IA aplicada a ingeniería.

5. Me llevo conversaciones difíciles que me hicieron crecer.

6. Me llevo equipos, personas y momentos que marcaron mi forma de trabajar.

Pero, sobre todo, me llevo una idea muy clara: la tecnología valiosa no es la que se ve más sofisticada desde afuera, sino la que resuelve problemas reales, y esto es sumamente importante en un país tan roto como mi querida Venezuela. La tenología esta para reducir incertidumbre y permite que otros trabajenmejor.

Gracias

Gracias a todas las personas con las que compartí este camino en Yummy: la directiva, ingeniería, producto, finanzas, operaciones, data, liderazgo, soporte y todos los equipos con los que tuve la oportunidad de colaborar, y hasta los que no.

Gracias por los retos, por la confianza, por las conversaciones, por los aprendizajes y también por los momentos complejos. Todo eso forma parte de lo que uno se lleva.

Cierro esta etapa con gratitud y con orgullo por lo construido.

Y abro la siguiente con más experiencia, más criterio y más ganas de seguir construyendo tecnología con impacto real.

Llegaste al límite. Tienes el query más optimizado que has escrito en tu vida: índices compuestos, particiones por fecha, CTEs anidados, vistas materializadas. Y aun así, ese reporte de balance financiero aparece en pantalla después de 20 minutos. Tu CEO lo abre cada lunes por la mañana. Cada lunes, un Slack o correo electrónico incómodo.

Este no es un problema de código. Es un problema de arquitectura. Y la buena noticia es que tiene solución —una solución que tiene nombre, historia y que hoy vive en producción en empresas desde startups hasta Amazon.

Se llama CQRS. Y hoy te cuento, ¿qué es y cómo funciona? Así se aplica en un sistema financiero real para lograr una mejora de más de 50 veces en el tiempo de respuesta de nuestros reportes críticos.

1. El problema real detrás del query lento

Antes de hablar de la solución, entendamos el problema correctamente. Porque no es solo que “el query es lento”.

Cuando tu base de datos supera los 100 GB, técnicamente estás en territorio de big data. Y el problema con big data no es almacenarlo; es que las bases de datos transaccionales tradicionales fueron diseñadas para una cosa muy específica, y esa cosa no es generar reportes analíticos sobre millones de registros históricos en tiempo real.

Lo que tu BD transaccional hace bien

• Registrar una venta nueva al instante

• Actualizar el saldo de un usuario

• Buscar un registro exacto por ID

• Garantizar que dos procesos no choquen (ACID)

• Operaciones de milisegundos en filas individuales

Lo que te está pidiendo el negocio

• Balance Sheet de los últimos 12 meses

• Revenue por categoría, por región, por hora

• Conciliaciones cruzando millones de transacciones

• Reportes que unen 40+ tablas

• Análisis sobre años de datos históricos

Estás forzando a tu base de datos a hacer algo para lo que no fue diseñada. Y el resultado es predecible: contención de locks, I/O saturado, timeouts y un reporte que tarda más que una reunión de roadmap.

La raíz del problema

Estás usando la misma base de datos para escribir operaciones transaccionales en tiempo real y para leer reportes analíticos masivos. Estas dos cargas de trabajo tienen necesidades radicalmente opuestas —y están peleando por los mismos recursos.

2. ¿Qué es CQRS?

CQRS son las siglas de Command Query Responsibility Segregation. En español: Segregación de responsabilidades entre comandos y consultas.

El concepto fue formalizado por el arquitecto de software Greg Young alrededor de 2010, inspirándose en el principio más simple de CQS (Command Query Separation) de Bertrand Meyer, que dice:

“Un método debería ser un comando que realiza una acción, o una consulta que retorna datos —nunca ambos.”

CQRS lleva esta idea al nivel arquitectónico. No solo separamos los métodos: separamos los modelos de datos, las bases de datos y los sistemas enteros según si su propósito es escribir o leer.

Un ejemplo practico

Imagina que tienes una sola caja registradora que sirve para cobrarles a los clientes y para generar el reporte contable de fin de mes. CQRS dice: usa una caja para cobrar (operaciones en vivo) y usa un sistema separado —optimizado para ello— para generar los reportes. Cada uno hace lo suyo, y los dos lo hacen mejor.

3. La analogía que lo explica todo

Piensa en un restaurante de alta rotación.

En la cocina, hay un sistema de comandas: cada mesero escribe el pedido, el chef lo ejecuta. Aquí la prioridad es velocidad, exactitud y consistencia. Si dos mesas piden el mismo plato, los pedidos no pueden mezclarse. Esto es el modelo de escritura: transaccional, secuencial, fuerte en garantías.

Ahora imagina que el dueño quiere saber cuál fue el plato más vendido el último trimestre, en qué mesa se genera más ticket promedio y a qué hora hay más rotación. Si le pregunta al chef en medio del servicio, el restaurante colapsa. Por eso existe la oficina del contador: toma los mismos datos (las comandas del día), los procesa en otro lugar y genera los reportes sin interrumpir la cocina.

CQRS es exactamente eso: la cocina sigue funcionando a máxima velocidad, y la oficina analítica trabaja con una copia de los datos —optimizada para responder preguntas complejas.

4. La arquitectura en detalle

Veamos cómo se ve esto en la práctica con el flujo completo de datos.

El lado de escritura: Commands

Todo lo que modifica el estado del sistema pasa por aquí. Un pago registrado, una factura emitida, un usuario actualizado. Estos son comandos: tienen intención clara y el sistema garantiza que se ejecutan correctamente, de forma atómica y consistente.

La base de datos de escritura es una BD transaccional clásica —típicamente PostgreSQL o MySQL. Está optimizada para escrituras rápidas, integridad referencial y concurrencia segura. Aquí viven tus garantías ACID.

El lado de lectura: Queries

Todo lo que solo consulta datos vive aquí. Un reporte de balance, el revenue por categoría, una conciliación histórica. Estas son consultas: no modifican nada —y necesitan hacerlo sobre grandes volúmenes de datos sin interferir con la operación.

La base de datos de lectura es una BD analítica, orientada a columnas —como ClickHouse, BigQuery, Redshift o DuckDB. Puede hacer en segundos lo que una BD transaccional haría en minutos, porque fue diseñada exactamente para eso.

El puente: Change Data Capture (CDC)

El mecanismo que mantiene ambas bases de datos sincronizadas se llama CDC. Cada vez que algo cambia en la BD de escritura, ese cambio se captura y se replica en la BD de lectura —en tiempo casi real, sin impactar el rendimiento del sistema principal.

5. Un caso real: de 27 minutos a 30 segundos

Trabajando en un sistema core bancario de puntaje crediticio, nos encontramos con este problema de frente. El reporte de Balance Sheet cruzaba decenas de tablas y agregaba años de datos históricos sobre una base de datos PostgreSQL que también estaba sirviendo todas las operaciones transaccionales en vivo.

Tiempo de generación antes de CQRS: 27 minutos.

• 27 min antes — OLTP solo

• 30 seg después — CQRS

• 54× en mejora de performance

La solución fue implementar CQRS sobre la infraestructura existente: replicar las tablas relevantes hacia una base de datos analítica columnar mediante CDC y redirigir las consultas de reportes para que se ejecutaran ahí —sin tocar el sistema de escritura ni el código de negocio.

El tipo de query que cambió todo

-- La misma query. Diferente motor. Eso es CQRS.

SELECT
    account_id,
    sum(debit)           AS total_debit,
    sum(credit)          AS total_credit,
    sum(debit - credit)  AS balance
FROM account_move_line
WHERE date >= '2024-01-01'
  AND company_id = 1
GROUP BY account_id
ORDER BY account_id;

-- En PostgreSQL (OLTP):   ~27 minutos
-- En BD columnar (OLAP):  ~30 segundos

El query no cambió una sola línea. Lo que cambió fue sobre qué motor corría.

6. ¿Cuándo sí y cuándo no aplicar CQRS?

CQRS no es una bala de plata. Es una herramienta poderosa con un costo real de complejidad operacional. Usarla mal puede crearte más problemas de los que resuelve.

✓ Úsalo cuando...

• Tus reportes tardan más de lo aceptable y optimizar el query ya no ayuda

• Tu BD transaccional se satura cuando alguien ejecuta un reporte pesado

• Tienes más de ~50–100 GB de datos con crecimiento constante

• Los patrones de lectura y escritura son radicalmente distintos

• Puedes tolerar datos con un pequeño delay (segundos o minutos)

• Tienes capacidad para operar y monitorear dos bases de datos

✗ No lo uses cuando...

• Tu app es simple y tu BD es menor de 10–20 GB

• Necesitas consistencia instantánea al 100% en todo momento

• Tu equipo no tiene experiencia en sistemas distribuidos

• Estás en etapa de validación de producto (premature optimization)

• No tienes observabilidad para detectar problemas de sincronización

7. ¿Cómo empezar sin romper producción?

La belleza de CQRS es que puedes adoptarlo incrementalmente. No necesitas reescribir tu sistema. El camino de menor riesgo:

• Identifica tu candidato piloto. El query más lento, más crítico, con mayor impacto en el negocio. Ese es tu punto de entrada.

• Levanta una BD analítica. ClickHouse, BigQuery, Redshift, DuckDB: los managed services reducen la operación inicial a casi cero. Empieza con una instancia pequeña.

• Configura el pipeline CDC. Debezium, AWS DMS, ClickPipes, Airbyte. Replica solo las tablas que necesita tu query piloto — no toda la BD de golpe.

• Redirige ese único query. El resto de tu sistema no cambia. Solo el reporte piloto apunta a la BD de lectura.

• Mide y valida. Compara tiempos. Verifica que los datos coinciden entre ambas bases. Documenta el delta de sincronización.

• Expande gradualmente. Agrega más queries y más tablas según el ROI real que vayas viendo. No migres todo de una vez.

Ejemplo, para que me entiendas

La migración incremental reduce el riesgo a casi cero. En ningún paso modificas el sistema de escritura ni tocas la fuente de verdad. El rollback es trivial: si algo falla en la BD de lectura, simplemente vuelves a apuntar el query al sistema original. Es una de las pocas apuestas arquitectónicas donde el downside está completamente acotado.

En mi experiencia

Si tu reporte tarda 20 minutos, el problema no es el query. El problema es que estás usando una herramienta de construcción para hacer trabajo de análisis. CQRS es el reconocimiento arquitectónico de que leer y escribir son problemas fundamentalmente diferentes —y merecen herramientas diferentes.

No es magia. Es separación de responsabilidades aplicada a escala de datos. Y cuando lo ves funcionar —cuando ese reporte que torturaba los lunes de tu C-Level o Stakeholder aparece en 30 segundos— entiendes por qué es uno de los patrones más influyentes de la ingeniería de software moderna.

El siguiente paso es tuyo. Identifica ese query e identifica de qué tabla o base de datos estamos hablando. Empieza pequeño. Mide todo; eso te ayudará a dar una idea si el escalamiento necesita segregación de responsabilidades o simple optimización.

¿Tienes preguntas?

Si estás evaluando implementar CQRS en tu stack —sea cual sea el motor analítico que consideras— deja tu pregunta en los comentarios. En el próximo artículo entro a los detalles de configurar CDC desde PostgreSQL: el WAL, los replication slots y los gotchas que nadie te cuenta hasta que estás en producción.

Hoy ya hace más de 13 años que inicié mi carrera profesional como desarrollador de software; como podrás calcular, hace 13 años, la información no era tan libre como lo es ahora, era mucho más difícil encontrar información sobre sistemas y programación en general.

Eso sumado al nivel de penetración que tenía el internet y el hecho de que tener una computadora en casa, para la mayoría de familias, era algo realmente difícil. Por sus precios, disponibilidad y, si era como en mi caso, por la zona donde vivías, quizás era más difícil aún.

¿Pero… cómo es que borraste una base de datos completa sin antes hacer backup?

Hace 13 años, cuando se pensaba en desarrollar un sitio web, muy probablemente se pensaba en usar WordPress o Joomla para desarrollarlo; era raro y hasta extraño el sitio web que no operaba con alguno de estos CMS.

Justo para esa época, se popularizó el uso de hosting compartido, que no era más que un servidor que corría un software (cPanel en la mayoría de los casos) que permitía asignar recursos a diferentes usuarios dentro de un mismo servidor.

Tener una cuenta cPanel era como tener un apartamento alquilado en un edificio; una empresa te ofrecía un segmento pequeño dentro de un servidor dedicado o VPS que ellos administraban, y tú compartías recursos con otros usuarios, como la IP, RAM, storage (entre otras cosas) y podías alojar allí tu sitio web con LAMP (Linux, Apache, MySQL y PHP) sin mayor problema.

¿Por qué no hice backup?

Esto tiene muchas posibles respuestas, y los que vivieron esa época lo pueden tener más claro, pero los que no tuvieron la oportunidad, en esa época los backups eran:

1. Era muy costoso; tener una cuenta con unos pocos megas ya era algo estándar y, cuando se tenía presupuesto, se contrataba más almacenamiento para poder alojar pesados archivos Flash u otros archivos multimedia.

2. No todos los proveedores lo ofrecían; de hecho, el tener opciones de backup (bien sea manual o automático) no estaba disponible en las primeras versiones de algunos paneles de gestión (como cPanel), por lo que muchos lo que hacían era descargarse un .sql de toda la base de datos y copiaban el código mediante FTP.

3. El flujo de desarrollo no tenía stages; hoy en día es imposible pensar en algún sistema que no tenga tan siquiera un ambiente adicional al de producción. Pero en esa época, hablando claramente: si no te alcanzaba para un sistema de backup, menos para una cuenta adicional donde tener una réplica para desarrollo.

4. Falta de interés en presencia web: Aunque puede que hoy sea diferente en muchos sentidos, hace 13 años tener un sitio web era “un lujo” de algunos negocios que podían permitirse tener presencia en internet. Los costos asociados a tener y mantener un sitio web hacían que muchos prefirieran publicitarse en radio, televisión o incluso Páginas Amarillas y Guías Telefónicas.

¿Qué sitio web era… y cómo lo restablecí?

El sitio web era de una estación de radio en la que trabajaba en ese entonces; vale destacar que desde los 8 años hasta los 23 años mi vida estuvo muy ligada a la radio, televisión y medios de comunicación masiva.

Recuerdo que esos eran de los pocos clientes que existían para este tipo de tecnología para ese tiempo, ya que con el auge de los sitios web, los servicios de streaming para estaciones de radio también se popularizaron mucho.

Principalmente, las estaciones de radio miraban de cerca la posibilidad de extender su cobertura y ampliar su masa de oyentes y clientes mediante estos canales digitales, no solo a nivel de streaming, sino también en las noticias que se podían publicar allí.

¿Por qué borré la base de datos?

Recuerdo que fue porque el cliente lo necesitaba; tenía otra página web alojada en su cuenta de cPanel. En ese tiempo, algunas personas hacían este tipo de cosas: un usuario contrataba una cuenta para 2 o 3 sitios web en cPanel y podía desarrollar varias páginas web dentro del mismo alojamiento.

Esto puede sonar contradictorio, pero por eso digo “algunos”, y estas personas tenían muchos motivos para tener cuentas con la posibilidad de tener 2 o 3 sitios web. Recuerdo que en ese entonces, esto lo hacía porque con el proveedor que tenía ofrecía cuentas con streaming incluido para los que pagaran este tipo de cuenta. Y sí, era más valioso que tuvieran un backup y no 6 páginas, pero ¿qué les puedo decir?, así eran esos tiempos.

En este caso puntual, la estación de radio tenía una web principal que yo desarrollé y necesitaban una segunda web para usarla de sitio web exclusivo para móviles (recuerden que eran años previos al 3G, y los famosos dominios m.turadio.com, lo normal de la época).

¿Dónde surgió el problema?

Esta nueva web que yo realicé no necesitaba una web exclusiva para celulares móviles, porque la que yo desarrollé ya tenía soporte para eso; yo analizaba los headers y, según el navegador y OS, entregaba una web u otra desde el mismo WordPress, y eso era muy potente para la época. Ya que no necesitaba subdominios o cosas adicionales, incluso se adaptaba según el navegador o resolución de pantalla.

Recuerden que en ese entonces el rey de los navegadores en móviles era Opera Mini, y los exploradores de los nuevos Android (en ese época nuevos aún) eran muy diferentes a Opera Mini, y eso hacía las diferencias entre las webs; casi que se desarrollaba una web para cada navegador y dispositivo.

El borrado ocurrió justamente porque en las bases de datos en cPanel tenían nombres similares, algo como: turadio_web101radio y la otra base de datos era algo como turadio_w3b101radio. Ya que para ese entonces se usaba una herramienta llamada Softaculous, que aún hoy en día existe y es usada para generar las instancias de WordPress y otras herramientas.

No solo yo la usaba, sino quizás quien hizo esa primera versión de la web, y por eso quizás se generó similar el nombre de las bases de datos. Lo que me confundió y terminé borrando la base de datos equivocada.

¿Fue muy costoso reestablecerlo?

Aquí viene el giro de la historia, porque la verdad no fue tan complejo, y aunque en ese entonces yo acostumbraba a trabajar 100% live, es decir, todos los cambios se realizaban directamente sobre el sitio web en producción, este era un proyecto que tenía relativamente poco funcionando. Cerca de 3 meses para ese momento, si mal no recuerdo bien.

En ese entonces yo usaba un viejo laptop VIT (Venezolana de Industria Tecnológica) para desarrollar, y en ese i3 de 2-3.ª generación con XAMPP correctamente (sí, olvídate de Docker, en ese entonces XAMPP era la forma y el método ideal) ejecutaba el desarrollo base de plantillas y plugins.

A los 17 años, realmente ya tenía como 10 años programando. Recuerdo que mi primer “sistema” estaba escrito en C, y era una calculadora desde terminal que logré copiar de una enciclopedia vieja y desarrollar en una IBM con Windows 2000 que tenía en mi casa. En esa enciclopedia se explicaba algo de sistemas, y en ella estaban capturas de pantalla de cómo hacerla, pero no se confundan, no estaba todo el código, solo capturas de algunos segmentos.

Así que siempre tenía una “base” de los datos a modo de demostración en mi laptop, así que eso sirvió mucho. Pero creo que más que eso, sirvieron muchísimo algunas acciones que tuve, como:

• Comunicar correcta y eficientemente lo que pasó: Recuerdo que en ese momento me dije algo como: “No importa lo que pase, los llamo y les digo que borre la base de datos”.

• Serenidad y control de daños: No se debe confundir estar sereno con “no importa”; son dos cosas totalmente diferentes. Cuando estás sereno, puedes medir y tomar acciones de forma más correcta; eso facilita el control de daños y poder dar soluciones realmente eficientes.

• Compromiso con una solución real: porque justamente no todas las soluciones son las más eficientes o indicadas para una solución real; por eso es importante tener claro lo que se quiere lograr y, según eso, desarrollar una forma de hacerlo funcionar.

• Asumir consecuencias: Creo que sin esto no hubiera podido llegar a donde estoy, pero recuerdo que en ese momento lo primero que tenía claro era que iba a tomar las consecuencias de lo que pasó y solucionarlo.

La primera desvelada profesional que tuve

Sí, no les voy a mentir diciendo que mágicamente pude hacer algo que solucionó todo y resolvió el problema; eso no pasó y, por ganar más lectores, no diré lo contrario. Recuerdo que fue la primera vez como programador ya profesionalmente; me quedé toda la noche despierto restableciendo todo.

Y no se confundan, digo que fue la primera vez porque antes lo hice, pero solo por diversión, y en esta ocasión fue porque tenía claro que era un compromiso profesional que cumplir antes con quien me contrató para desarrollar su sitio web.

Terminando de ajustar y reconstruir todo unas 10 horas luego, ya que todos los archivos y scripts quedaron intactos, pero temas relativos a ajustes, configuraciones y personalizaciones se perdieron.

Cosas que cambiaron desde ese día

Muchas, la verdad, no les voy a mentir, creo que, además de anecdótica, esa experiencia fue traumática, y la forma en la que desarrollaba cambió desde ese día.

Fueron varias, pero pueden detallarse en:

• Sin documentación, es imposible avanzar: sé que es quizás algo burocrático, pero esto es indispensable en todo proceso. Si quieres que algo salga bien, primero documenta; eso te sirve para aclarar tus ideas y dejar claro cómo van a ser las cosas desde el inicio.

• Todo Plan A debe tener un Plan B: no importa el cambio que realices, siempre tienes que tener la noción clara de lo que puede llegar a fallar, y debes tomarte el tiempo de tener un plan de respaldo en caso de que no salga como esperas.

• Confía en ti siempre: si te fijas, solo tenía 17 años, y excluirme en eso posiblemente no me hubiera llevado a donde estoy, porque sin compromiso y profesionalismo es imposible que alguien crea en ti. Nadie creerá en ti si tú mismo no lo haces primero, bajo cualquier circunstancia.

Pero eso nada más no es suficiente; recuerda siempre estar en lugares donde puedes cometer errores sin miedo a perder tu empleo solo por eso, y sí, esto tiene asteriscos, no es que todo lo que hagas va a estar mal, pero es importante que siempre comuniques las cosas de forma clara y eficiente.

Si estás comunicando todo oportunamente, y siguiendo todo según la documentación y convenciones, lo esperado es que, si algo llega a fallar, puedas tener la oportunidad de identificar el fallo, documentarlo y adquirir la experiencia suficiente para que este tipo de cosas no pasen nuevamente.

Facebank es uno de los bancos más utilizados por freelancers de toda Latinoamérica, no solo por su facilidad de uso, amplias características y formato 100% digital. Sino porque ha demostrado ser un banco estable y confiable para todos sus clientes en los diferentes países de Latinoamérica.

Este banco destaca por un soporte muy bueno, según mi experiencia personal. Ofrece un servicio base de cuentas bancarias, ahorro y crédito importante, pero sin lugar a dudas su estabilidad y servicio como PipolPay lo hacen destacar.

El gran beneficio: Euros a tu cuenta en Dólares

Hasta hace poco, mover dinero desde Europa hacia bancos americanos o con base en Puerto Rico solía implicar comisiones altas de bancos intermediarios y swaps de divisas poco favorables.

Con esta nueva actualización:

• Sin costo: Las transferencias por montos iguales o inferiores a 2,000€ no tienen costo de recepción por parte de Facebank.

• Conversión automática: El dinero se acredita directamente en tu cuenta en Dólares (USD).

• Rapidez: El tiempo estimado de acreditación es de hasta 2 días hábiles.

¿Cómo recibir tu pago? (Datos necesarios)

Para que la transferencia llegue correctamente y no sea rebotada (lo cual podría generar cargos adicionales), debes proporcionar los siguientes datos a la persona o empresa que envía el dinero:

1. Beneficiario: Prisma FACEBANK.

2. IBAN: (Este dato lo encuentras dentro de tu banca en línea o app de Facebank específica para Europa).

3. Concepto de la transferencia (CRUCIAL): Aquí es donde muchos fallan. Debes indicar exactamente:

   • FFC + Tu Nombre Completo + Tu número de cuenta Facebank.

   • Ejemplo: FFC Juan Pérez 6352XXXXXX

Nota de seguridad: Asegúrate de completar estos datos correctamente en el campo de “información adicional” o “concepto” para evitar demoras en el proceso.

Compartir José Carrillo

Pros (Ventajas)

• Ahorro en montos bajos: La ausencia de comisiones para transferencias menores a 2,000€ es ideal para pagos recurrentes pequeños.

• Eficiencia de costos: Al eliminar intermediarios, se reducen las tarifas ocultas que suelen aplicar los bancos corresponsales.

• Optimización para Freelancers: Es una solución perfecta para quienes trabajan con clientes en la Zona Euro (España, Alemania, Francia, etc.), facilitando el cobro de honorarios.

• Simplicidad operativa: Menos actores involucrados suele traducirse en una mayor rapidez en la acreditación de los fondos.

Contras (Desventajas o Limitaciones)

• Costo escalable: Si el monto supera los 2,000€, se aplica un tarifario adicional, lo que puede reducir la competitividad del servicio para operaciones grandes.

• Restricción geográfica estricta: El hecho de que deba provenir exclusivamente de bancos europeos limita su uso para clientes en EE. UU., Asia o Latinoamérica.

• Rigidez en la información: Existe una dependencia crítica del campo “Concepto”. Un error manual en este apartado puede derivar en retrasos, rebotes de fondos o procesos de soporte tediosos.

• Limitación de red: Al no usar canales tradicionales (o al saltarse intermediarios), se pierde la flexibilidad de recibir fondos de entidades fuera del circuito europeo especificado.

Mi análisis como experto

Este movimiento de Facebank busca competir directamente con plataformas como Wise o Revolut, ofreciendo la ventaja de tener el dinero en una institución bancaria establecida y conectada al sistema americano. Para quienes desarrollamos proyectos o gestionamos servicios internacionales a Europa, reducir la fricción de los pagos transatlánticos es fundamental para la escalabilidad.

Si tienes clientes en la Unión Europea, esta es, sin duda, una de las opciones más rentables a día de hoy.

Suscríbete ahora

¿Necesitas ayuda configurando tu cuenta?

Si ya eres usuario de Facebank y no encuentras tus datos para recibir transferencias SEPA (Europa), déjamelo en los comentarios y puedo preparar un tutorial rápido de dónde encontrar tu IBAN en la plataforma.

¿Ya probaste esta función? ¿Qué tal fue tu experiencia con la tasa de cambio? ¡Te leo!

Si estás dando tus primeros pasos en el mundo de la tecnología, es muy probable que uses los términos “programar” y “desarrollar software” como si fueran sinónimos. Pero, si queremos hablar con propiedad y proyectar una carrera sólida, debemos entender que no son lo mismo.

En mi experiencia, esta distinción es el primer muro físico con el que choca un profesional cuando llega a una compañía real. Aquí te explico por qué.

El Programador: El artesano del código

La capacidad principal de un programador es escribir código. Es quien tiene la destreza técnica para realizar pruebas, optimizar funciones y llevar ese código a un alto nivel de ejecución. Es una pieza indispensable, pero es solo una parte del rompecabezas.

El Desarrollador de Software: El arquitecto del sistema

Un desarrollador va mucho más allá de “picar código”. Es alguien que entiende el ciclo completo desde la concepción de la idea. Para ser un desarrollador integral, debes dominar conceptos que ocurren “detrás de escena”:

• Arquitectura y Bases de Datos: Cómo se estructura y se almacena la información.

• Ciberseguridad y Autenticación: Proteger la integridad del sistema.

• Resiliencia: La capacidad de un sistema para tolerar fallos sin que ocurra una caída crítica que deje inoperativo, por ejemplo, a un banco.

Suscríbete ahora

La paradoja del Senior: Menos código, más pensamiento

Algo que sorprende a muchos es que, a medida que avanzas en tu carrera, programas menos.

• En un nivel Junior, el porcentaje de codificación es alto porque estás experimentando.

• En un nivel Senior, el tiempo dedicado a escribir código puede bajar hasta un 20%.

• Como Líder Técnico, ese porcentaje se reduce aún más debido a las responsabilidades de liderazgo y estrategia.

El resto del tiempo se invierte en leer documentación, diseñar soluciones, participar en metodologías ágiles (como Scrum) y planificar con el equipo (PMs, QAs, TLs).

Mi consejo si estás empezando

No caigas en la trampa de la “deuda técnica eterna” por no documentar o no planificar. Si quieres destacar:

1. Aprende a leer código ajeno: Antes de escribir el tuyo, entiende cómo resuelven problemas los demás.

2. Planifica antes de actuar: No lances la primera línea de código sin tener claras las bases y la escalabilidad.

3. Entiende el negocio: Un desarrollador que comprende el producto es mucho más valioso que uno que solo sigue instrucciones técnicas.

Como suelo decir: No es lo mismo saber hacer flechas que ser selección nacional de tiro con arco. Programar es una herramienta; desarrollar es el arte completo.

Imagina poder pagar una cuenta en un restaurante o transferir dinero a un amigo en segundos, sin importar el banco de cada uno, las 24 horas del día, solo con tu número de celular, correo electrónico o un nombre de usuario. Esto ya es realidad en países como Brasil y Colombia gracias a innovaciones como PIX y BRE-B, impulsadas por tecnologías como el open banking y open finance.

Durante décadas, el procesamiento de pagos digitales estuvo dominado por un modelo relativamente simple: un usuario paga con una tarjeta y una red de intermediarios procesa la transacción. Visa, Mastercard, procesadores, adquirentes y emisores participan en la operación. Operaciones que pueden llevar días en terminarse; incluso para hacer una simple transferencia, se dependía en gran medida de la interoperabilidad de distintas operaciones, incluso entre un mismo país.

Durante décadas, el sistema financiero global funcionó bajo un modelo de “silos autónomos y cerrados”. Tu dinero y, más importante aún, tus datos financieros, vivían encerrados en la bóveda digital de tu banco. Si otra aplicación quería interactuar con ese dinero, el proceso era lento, costoso y estaba lleno de peajes tecnológicos.

Ese modelo fue relativamente exitoso, pero también tiene limitaciones claras, que a 2026 son más visibles que nunca:

• Costos elevados de procesamiento

• Tiempos de liquidación de uno a tres días

• Dependencias de redes privadas

• Baja inclusión financiera en algunos mercados

¿Qué es Open Banking y Open Finance?

El open banking no es más que una herramienta que permite a los bancos compartir datos de cuentas y datos de pagos de forma segura con terceros autorizados, usando APIs estandarizadas. Esto habilita servicios como la iniciación de pagos directos desde apps externas, mejorando la competencia y la innovación.

Antes de continuar recuerda suscribirte

Con esta acción me ayudas a seguir generando contenido especializado con este que estas mirando ahora con mayor frecuencia y detalle al respecto.

Suscríbete ahora

Open finance va un poco más allá: extiende el intercambio de datos a seguros, inversiones y pensiones, creando ecosistemas financieros completos centrados en el usuario. En Latinoamérica, open finance está en auge, con Colombia volviéndolo obligatorio en 2026 para estandarizar APIs y pagos. A diferencia del open banking (enfocado en pagos y cuentas), open finance crea productos personalizados, como saldos agregados de múltiples bancos en una sola app.

Todo esto ha dado origen a que en los últimos años haya surgido una alternativa poderosa: los pagos A2A (Account-to-Account). En lugar de pasar por redes de tarjetas, el dinero se mueve directamente entre cuentas bancarias. Siendo una de las claves de esta tecnológia la inicialización de pagos dentro del Open Banking.

Y es aquí donde entran sistemas como:

• Pix en Brasil

• Bre-B en Colombia

• UPI en India

• SEPA Instant en Europa

• FedNow en USA

Todos comparten una idea central: crear infraestructuras públicas de pagos instantáneos interoperables.

La Iniciación de Pagos (PIS): Elimina al intermediario

Dentro del Open Banking, hay un superpoder específico llamado Iniciación de Pagos (o PIS, por sus siglas en inglés: Payment Initiation Services). Y esta es posiblemente una de las formas menos explotadas del Open Banking, sobre todo en Colombia, donde todo lo relativo a estas tecnologías es muy nuevo. Esto funciona más o menos así:

Históricamente, los pagos en línea han sido dominados por las tarjetas de crédito y débito. El modelo de las tarjetas funciona “jalando” el dinero. Cuando compras algo, el comercio le pide a su procesador que “jale” el dinero de la red de la tarjeta (Visa, Mastercard...), que a su vez le pide a tu banco que lo apruebe. Hay al menos cuatro intermediarios en esa cadena, y cada uno cobra una comisión. Además, este proceso de liquidación puede tardar días en completarse a nivel contable.

La Iniciación de Pagos cambia las reglas del juego a un modelo de “empuje” (Push) de Cuenta a Cuenta (A2A):

1. La Solicitud: Estás en el checkout de una tienda o en una pasarela de pagos.

2. La Iniciación: La pasarela de pagos, actuando como un iniciador (PISP), se conecta vía API directamente con tu banco.

3. La autorización: Tu banco te pide (quizás con tu huella dactilar en tu celular) que apruebes enviar el dinero.

4. La ejecución: El banco “empuja” el dinero directamente a la cuenta del vendedor a través de rieles de pago en tiempo real.

¿El resultado? El dinero viaja en segundos de la Cuenta A a la Cuenta B, los costos de procesamiento se desploman al eliminar a los intermediarios tradicionales, y el riesgo de fraude disminuye drásticamente porque la autenticación se hace directamente en el entorno seguro de tu propio banco. La infraestructura tecnológica necesaria para soportar esto requiere una escalabilidad masiva, capaz de procesar miles de transacciones concurrentes por segundo sin un solo fallo de base de datos.

Anatomía de los pagos inmediatos: Tabla comparativa global

Antes de sumergirnos en los servidores y el código, veamos cómo se posicionan los grandes jugadores del mundo con respecto a infraestructura. Esta tabla resume las diferencias clave entre los sistemas de los que hemos hablado:

Comparativa de Sistemas de Pagos Inmediatos (RTP)

• Pix (Brasil)

  • Arquitectura: Centralizada bajo el Directorio DICT del Banco Central.

  • Liquidación: Realizada en menos de 10 segundos.

  • Iniciación: Multimodal a través de Llaves (alias), códigos QR y NFC.

  • Interoperabilidad: Total, garantizada por mandato regulatorio.

  • Costo: Gratuito para personas naturales.

• Bre-B (Colombia)

  • Arquitectura: SPI y Directorio Central orquestado por el Banco de la República.

  • Liquidación: Objetivo de menos de 20 segundos por transacción.

  • Iniciación: Basada en llaves, códigos QR y URLs de pago.

  • Interoperabilidad: Total y obligatoria por regulación.

  • Costo: Bajo costo o gratuito según la normativa vigente.

• FedNow (EE. UU.)

  • Arquitectura: Operada directamente por la Red de la Reserva Federal.

  • Liquidación: Liquidación bruta en tiempo real (segundos).

  • Iniciación: Integración directa a través de canales bancarios.

  • Interoperabilidad: Fragmentada, ya que la adopción es voluntaria para los bancos.

  • Costo: Varía según las políticas de cada entidad bancaria.

• PSD2 / SEPA Inst (Europa)

  • Arquitectura: Sistema descentralizado con infraestructura RT1/TIPS.

  • Liquidación: Confirmación en menos de 10 segundos.

  • Iniciación: Uso obligatorio de APIs estandarizadas (PISP).

  • Interoperabilidad: Total bajo mandato de la Unión Europea.

  • Costo: Depende de la estrategia comercial de cada banco.

Pix: el experimento financiero más exitoso de América Latina

Si hay un sistema que ha demostrado el potencial de este modelo, es Pix, desarrollado por el Banco Central de Brasil. Pix fue lanzado en 2020 y permite realizar transferencias instantáneas las 24 horas del día, todos los días del año.

Las transacciones se liquidan en cuestión de segundos mediante el Sistema de Pagos Instantáneos (SPI) operado por el banco central brasileño. En el sistema Pix, cada usuario puede registrar una clave Pix, que funciona como un alias de su cuenta bancaria, y puede ser:

• Número de teléfono

• Correo electrónico

• Número de identificación fiscal

• Clave aleatoria

• QR dinámico

Estas claves permiten enviar dinero sin necesidad de conocer el número de cuenta, siendo su flujo típico de una transacción Pix extremadamente simple:

1. Usuario A: abre su app bancaria

2. Introduce la clave Pix del receptor

3. Confirma el monto

4. SPI liquida la operación

5. Usuario B: recibe el dinero inmediatamente

Las transacciones suelen completarse en menos de 10 segundos, y es por eso que su adopción ha sido masiva. Pix superó al efectivo y a las tarjetas como medio de pago más usado en Brasil y maneja trillones de reales al año. Brasil lidera con APIs GraphQL, webhooks y Kubernetes para escalabilidad, integrando PIX en agregadores que muestran saldos de 15 bancos.

Este éxito tiene varias razones:

• Costo cero para usuarios

• Interoperabilidad obligatoria

• Infraestructura pública

• Experiencia de usuario extremadamente simple

¿Cómo se inicializan pagos en Pix?

Inicializar pagos en Pix sigue un flujo simple, y al usar estándares tecnológicos como Open Banking y Open Finance, la inicialización de pagos en otros países que implementan la tecnología debería ser, cuando menos, similar:

1. Autenticación: Usuario confirma identidad vía app bancaria (biometría o PIN).

2. Consentimiento: Acepta compartir datos vía API (ej. PSD2-style en open banking).

3. Procesamiento: Sistema central valida fondos, liquida en tiempo real.

4. Confirmación: Notificación push instantánea.

Para este fin, en Pix con Open Finance, se utilizan flujos embebidos sin redirects que mejoran la conversión móvil. Técnicamente, involucra rate limiting, monitoreo real-time y certificados digitales, pero para usuarios es tan fácil como escanear un QR. Brasil lidera con APIs GraphQL, webhooks y Kubernetes para escalabilidad, integrando PIX en agregadores que muestran saldos de 15 bancos.

Pix demostró que los bancos centrales pueden crear plataformas tecnológicas tan eficientes como las redes privadas, y ha logrado una alta penetración justamente porque en Brasil, a diferencia de Colombia, no existen impuestos o tasas a las transferencias bancarias, como sucede en Colombia con el famoso 4x1000.

Bre-B: el equivalente colombiano inspirado en Pix

Colombia está construyendo su propia infraestructura de pagos instantáneos con Bre-B, desarrollado por el Banco de la República y el apoyo de algunas instituciones privadas como Bancolombia, Redeban y otros grandes jugadores. Bre-B es un sistema interoperable que permite enviar dinero entre entidades financieras en tiempo real, sin importar el banco o billetera digital del usuario.

La lógica de funcionamiento es muy similar a Pix, los usuarios registran una llave, que puede ser:

• Número de celular

• Documento de identidad (o número de identificación fiscal para empresas)

• Correo electrónico

• Identificador alfanumérico

Una vez registrada la llave, enviar dinero es tan simple como introducirla en la aplicación del banco. El sistema fue diseñado para resolver uno de los problemas históricos del sistema financiero colombiano: la falta de interoperabilidad entre proveedores. Pero su adopción total se ha visto marcadamente menos pronunciada que en Brasil por cosas como los impuestos a transacciones interbancarias como el 4X100.

Antes de continuar recuerda suscribirte

Con esta acción me ayudas a seguir generando contenido especializado con este que estas mirando ahora con mayor frecuencia y detalle al respecto.

Suscríbete ahora

Sin embargo, antes de Bre-B, muchas soluciones funcionaban en silos, y aunque llegó a existir una solución de operatividad interbancaria llamada TransfiYa, esta era de origen privado, el consorcio ACH. Que llegó a materializarse en algunas:

• Billeteras digitales: como Movii, Nequi, Daviplata, Dale! entre otras más.

• Bancos: siendo los principales Bancolombia y Davivienda, pero integrando un alto porcentaje de usuarios en su conjunto.

Bre-B crea un directorio centralizado de llaves y un mecanismo de liquidación instantánea, permitiendo que todas las entidades se conecten a una infraestructura común.

Esto significa que una transferencia puede completarse en segundos entre cualquier entidad participante.

Bre-B no es un solo sistema: es una capa de interoperabilidad que actúa como hub central entre los sistemas de pago de bajo valor (SPBV) ya existentes en Colombia. El Banco de la República opera el núcleo del directorio de llaves y los estándares de mensajería, mientras las entidades administradoras de sistemas de pago de bajo valor (EASPBV) como Transfiya, Entrecuentas (Redeban), Visionamos y Credibanco actúan como nodos de conexión.

Diagrama de flujo de un pago Bre-B: los 9 pasos

Desde que el usuario pulsa “Pagar” hasta que el destinatario recibe la notificación, ocurren al menos 9 operaciones técnicas distintas en menos de 10 segundos. Este es el flujo completo, diferenciando el caso P2P (persona a persona) del caso PISP (pago desde un tercero):

¿Cómo debería ser un flujo detallado con PISP (Iniciación por tercero)?

Cuando el pago es iniciado por una aplicación de tercero (un e-commerce, una fintech, una app de mensajería), se agrega una capa de consentimiento regulada por la Circular 004/2024 de la SFC:

1. Comercio/App: El usuario elige “Pagar con cuenta bancaria” en el checkout. La app del tercero crea una solicitud de consentimiento con monto, descripción y TTL (tiempo de vida).

   • POST /open-finance/v1/payment-consents — {amount, description, expiresIn}

2. SFC/Directorio: El Tercero Receptor de Datos (TRD) está inscrito en el Directorio de Participantes administrado por la SFC. Se valida su identidad con mTLS + certificado digital emitido por entidad certificadora homologada.

3. App usuario: El usuario es redirigido (o la app embebe un WebView/SDK) hacia la interfaz de su banco para autenticación fuerte (SCA: biometría + factor adicional). La pantalla es 100% del banco, nunca del tercero.

4. Banco pagador: El banco valida la identidad, debita la cuenta y emite la instrucción de pago hacia el nodo EASPBV correspondiente con el mensaje ISO 20022 pacs.008.

   • Authorization Code Flow → access_token → POST /payments

5. Bre-B Core: El motor de enrutamiento resuelve la llave destino en el DICT-CO, identifica el banco receptor y encamina el mensaje. La liquidación ocurre en el Sistema de Compensación Electrónica (CEC) del BanRep.

6. Comercio/App: El banco del pagador emite un webhook al PISP con el estado del pago. El comercio actualiza el estado del pedido en tiempo real. El usuario ve la confirmación sin haber salido del flujo de compra.

   • POST [webhook_url] — {status: "ACSC", endToEndId, timestamp}

Comparación técnica profunda: estándares y seguridad

Esta comparativa demuestra que los modelos de Colombia y Brasil están adoptando los estándares de seguridad más rigurosos (FAPI 2.0/1.0) y la mensajería más robusta (ISO 20022). Esto posiciona a la región como un referente en modernización financiera frente a la fragmentación que todavía enfrenta el ecosistema europeo.

Bre-B / Open Finance Colombia

• Protocolo API: REST/JSON basado en el estándar ISO 20022.

• Autenticación: OAuth 2.0 con especificación FAPI 2.0.

• Seguridad: mTLS obligatorio para todas las conexiones.

• Firma de Mensajes: Utiliza JWS (RS256/PS256).

• Consentimiento: Explícito, trazable y revocable por el usuario.

• Infraestructura: Directorio centralizado bajo la SFC (en construcción) y Sandbox regulado en desarrollo.

• Mensajería: Estándar ISO 20022.

• Estado de Pagos: Recurrentes (PISP) y transfronterizos no disponibles actualmente.

Pix / Open Finance Brasil

• Protocolo API: REST/JSON + ISO 20022.

• Autenticación: OAuth 2.0 + FAPI 1.0 Advanced.

• Seguridad: mTLS obligatorio.

• Firma de Mensajes: JWS (PS256).

• Consentimiento: Explícito, granular y con tiempo de vida (TTL) definido.

• Infraestructura: Directorio centralizado (BCB — DICT) y Sandbox regulado operativo.

• Mensajería: ISO 20022 (específicamente pacs.008, 002 y 004).

• Estado de Pagos: Pix Automático programado para 2025; pagos transfronterizos en fase exploratoria.

UPI India

• Protocolo API: REST con una combinación propia de XML/JSON.

• Autenticación: Sistema propio (UPI 2.0) con PIN.

• Seguridad: TLS 1.2 o superior.

• Firma de Mensajes: Firma propiedad de la NPCI.

• Consentimiento: Implícito mediante el uso del PIN de UPI.

• Infraestructura: Directorio centralizado (NPCI) y Sandbox disponible.

• Mensajería: Híbrido entre ISO 8583 y JSON propio.

• Estado de Pagos: Soporta UPI AutoPay y pagos transfronterizos activos en más de 20 países.

Open Banking UK

• Protocolo API: REST/JSON bajo el estándar OBIE.

• Autenticación: FAPI 1.0 Advanced.

• Seguridad: mTLS más certificados eIDAS.

• Firma de Mensajes: JWS (PS256).

• Consentimiento: Explícito con renovación obligatoria cada 90 días.

• Infraestructura: Directorio centralizado (OBIE Directory) y Sandbox funcional.

• Mensajería: JSON propio definido por OBIE.

• Estado de Pagos: Soporta VRP (Variable Recurring Payments) y transferencias SEPA/SWIFT.

PSD2 Europa

• Protocolo API: REST/JSON (altamente fragmentado entre bancos).

• Autenticación: OAuth 2.0 (sin requerimiento estricto de FAPI).

• Seguridad: TLS 1.2+ (mTLS solo recomendado).

• Firma de Mensajes: JWS (opcional según la entidad bancaria).

• Consentimiento: Explícito con autenticación reforzada (SCA) cada 90 días.

• Infraestructura: Fragmentada por país; cada banco gestiona su propio Sandbox.

• Mensajería: Múltiples estándares (STET, Berlin Group o propios).

• Estado de Pagos: Recurrentes en diseño (PSD3) y SEPA Instant para transfronterizos.

¿Cómo debería ser conectar tu aplicación o negocio a Bre-B?

Dependiendo de tu rol en el ecosistema, la ruta de implementación varía significativamente. Existen tres perfiles principales: Entidad Financiera (banco, billetera), EASPBV (nodo conector) y Tercero Receptor de Datos / PISP (fintech, comercio, app). A continuación, la hoja de ruta para el perfil más relevante para nuevos actores: el PISP/TRD.

Obtén más de José Carrillo en la app de Substack

Disponible para iOS y Android

Descargar la app

Estado actual (marzo 2026): La iniciación de pagos por terceros (PISP) en Colombia está en fase de regulación. La Circular 004/2024 estableció las bases de Open Finance, pero el decreto que habilitará el PISP obligatorio (URF, 2025) está en proceso de implementación con cronograma de 12 meses desde su promulgación formal. Los pasos aquí descritos mezclan lo que ya está activo y lo que está en la hoja de ruta inminente.

Esto debería pasar, paso a paso:

1. Definir el modelo de participación: Determina si actuarás como Proveedor de Servicios de Iniciación de Pagos (PISP) —que ordena pagos— o como Agregador de Información (AISP) —que solo lee datos de cuentas. Para Bre-B, el caso de uso es PISP. Si no estás vigilado por la SFC, necesitarás operar a través de un Tercero de Confianza (EASPBV certificada: ACH Colombia, Redeban, Credibanco).

   • El modelo indirecto (vía EASPBV) es la ruta práctica para startups y comercios hoy. El modelo directo requiere registro en el Directorio de Participantes de la SFC.

2. Revisión regulatoria y constitución legal: Si actúas como PISP directo, necesitas inscripción formal en el Directorio de Participantes de la SFC. Requisitos previos: personería jurídica constituida en Colombia, políticas documentadas de tratamiento de datos personales (Ley 1581/2012 y Ley 1266/2008), política de ciberseguridad alineada con la Circular Básica Jurídica de la SFC, y suscripción al marco de consentimiento del ecosistema.

   • Para PISP indirecto (vía nodo): firma de contrato comercial y técnico con el EASPBV elegido (ej. ACH Colombia / Transfiya, Credibanco). Ellos actúan como tu puerta de entrada y validan tu cumplimiento.

3. Obtención de certificados digitales homologados: Todas las comunicaciones entre tu sistema y el ecosistema Open Finance / Bre-B deben ir firmadas y cifradas con certificados emitidos por Entidades de Certificación Digital habilitadas en Colombia:

   • Camerfirma Colombia — Cámara de Comercio de Bogotá (token + HSM)

   • GSE (Gestión de Seguridad Electrónica) — token + servidor HSM

   • Andes SCD — Certificación digital en token

   • Certicámara — Entidad de certificación SIC-homologada

   • Necesitarás: un certificado de autenticación de cliente (mTLS) para las llamadas a APIs, y un certificado de firma de mensajes (JWS) para firmar los payloads ISO 20022.

4. Configuración de la infraestructura técnica base: El stack técnico mínimo para participar en el ecosistema.

   • Seguridad:

     • TLS 1.3 en todos los endpoints expuestos

     • mTLS para llamadas hacia APIs de bancos / EASPBV

     • HSM o equivalente para almacenamiento de claves privadas

     • Rotación de certificados: máx. 1 año (Circular 004)

   • API Gateway:

     • OAuth 2.0 Authorization Server (ej: Keycloak, Auth0, AWS Cognito)

     • FAPI 2.0 Security Profile (recomendado; FAPI 1.0 Adv. como mínimo)

     • Rate limiting + circuit breakers

   • Mensajería:

     • ISO 20022 parser/builder (librería: isoxml, Prowide, etc.)

     • JWS signing con RS256 o PS256

     • Idempotency keys en todos los POST de pago

   • Trazabilidad:

     • endToEndId único por transacción (UUID v4)

     • Logs inmutables (audit trail) — retención mín. 5 años

     • Webhook receptor con retry exponencial + dead-letter queue

5. Integración con el nodo EASPBV o con las APIs bancarias: Vía ACH Colombia / Transfiya: ofrecen un SDK y documentación API REST. El flujo para pago P2P incluye: resolución de llave (GET /alias/{key}), creación de orden de pago (POST /transfers), y consulta de estado (GET /transfers/{id}).

   • Vía Credibanco: integración orientada a e-commerce y comercios físicos, con soporte QR. Dock (su socio tecnológico) provee la plataforma cloud-native que simplifica la integración.

6. Implementar el flujo de consentimiento del usuario: La Guía de Experiencia de Usuario publicada por la SFC (disponible en finanzasabiertas.superfinanciera.gov.co) establece lineamientos obligatorios para la pantalla de consentimiento: lenguaje claro, datos mínimos necesarios, duración del consentimiento visible y mecanismo de revocación accesible. No es opcional: el incumplimiento es sancionable.

   1. El flujo mínimo de consentimiento para un PISP: (1) Presentar claramente “quién pide el acceso y para qué”, (2) El usuario selecciona el banco donde está su cuenta, (3) Redirección segura al banco para autenticación fuerte (SCA), (4) Retorno a tu app con el token de autorización, (5) Ejecución del pago, (6) Notificación de resultado.

7. Pruebas en sandbox y certificación técnica: Cada EASPBV mantiene su propio ambiente de pruebas. Con respecto a Open Finance, la SFC tiene un sandbox temporal en fase de construcción. Los casos de prueba obligatorios incluyen: pago exitoso, pago rechazado por fondos insuficientes, llave no encontrada, timeout del banco, intento de pago duplicado (idempotency), y revocación de consentimiento en tránsito.

   1. Adicionalmente, la Circular 009/2025 estableció que las entidades deben completar sus ajustes de arquitectura, seguridad y tecnología. Para TRDs nuevos, el EASPBV, que actúa como Tercero de Confianza, realiza una validación técnica de onboarding antes de habilitar el acceso a producción.

8. Go-live y monitoreo continuo: En producción, el monitoreo es parte del cumplimiento regulatorio. Debes tener: alertas en tiempo real para transacciones fallidas, tasas de éxito por banco (>95% es el benchmark del sector), latencia P95 por endpoint, y un proceso documentado de gestión de incidentes con notificación a la SFC en eventos mayores. Los logs deben conservarse por un mínimo de 5 años.
   

   Sé parte de los que apoyan con su suscripción más contenido especializado como este.

Certificaciones necesarias para operar dentro de Bre-b

Operar en el ecosistema de Open Finance y Bre-B en Colombia requiere el cumplimiento que combina registros regulatorios, certificaciones técnicas internacionales y adherencia a normas de seguridad de la información. Las certificaciones necesarias son:

1. Registro Directorio de Participantes SFC: Emitido por la Superintendencia Financiera de Colombia, la inscripción obligatoria para operar como TRD (Tercero Receptor de Datos) o PISP en el ecosistema. La SFC administra el directorio y define los requisitos. Aplica el marco del Decreto 1297/2022 y la Circular 004/2024.

2. Registro RNNP / SIC: Emitido por la Superintendencia de Industria y Comercio, el Registro Nacional de Bases de Datos ante la SIC. Obligatorio para cualquier entidad que trate datos personales de colombianos. Base legal: Ley 1581/2012 y Decreto 1074/2015. Incluye política de privacidad, aviso de privacidad y contratos de encargo de tratamiento.

3. Certificado Digital mTLS + Firma JWS: Emitido por Camerfirma (GSE, Certicámara o Andes SCD) el Certificado X.509 es emitido por entidad de certificación digital homologada en Colombia. Requerido para autenticación mutua en las APIs del ecosistema. Vigencia máxima: 1 año. Requiere HSM para las claves privadas en entornos de producción.

4. Habilitación EASPBV (si aplica): Emitido por el Banco de la República para entidades que quieran operar como nodo conector del sistema (EASPBV). Requiere autorización del BanRep, capital mínimo demostrado, infraestructura técnica certificada y plan de continuidad de negocio en un proceso de 6–12 meses.

5. Vigilancia SFC (entidades reguladas): Emitido por la Superintendencia Financiera para bancos, billeteras electrónicas (SEDPE), compañías de financiamiento y fintechs con captación. Requiere autorización de funcionamiento, relaciones de solvencia, y cumplimiento de la Circular Básica Contable y Financiera. No aplica a todos los participantes.

Esto sin incluir las certificaciones técnicas internacionales (fuertemente recomendadas), como:

1. ISO/IEC 27001:2022: Sistema de Gestión de Seguridad de la Información. La Circular 004/2024 exige controles alineados con esta norma. No es obligatoria la certificación formal, pero sí la implementación de sus controles. Para TRDs directos, la certificación es virtualmente requisito de facto para el onboarding con bancos.

2. PCI DSS v4.0: Si tu plataforma también procesa tarjetas o almacena datos de tarjeta (CHD), PCI DSS es obligatorio. Para iniciación de pagos Bre-B puro, no aplica directamente, pero la mayoría de los integradores de pagos lo tienen como estándar de referencia para la evaluación de riesgo.

3. FAPI 2.0 Conformance (OpenID): Financial-grade API Security Profile. Es el estándar de seguridad de OAuth 2.0 para APIs financieras que exige la SFC. La certificación formal de conformidad con OpenID Foundation demuestra que tu servidor de autorización cumple el perfil FAPI 2.0, lo que simplifica la negociación técnica con bancos.

4. SOC 2 Type II: Auditoría de controles de seguridad, disponibilidad, integridad de procesamiento y confidencialidad. Muy solicitado por bancos colombianos en sus procesos de due diligence para fintechs que quieren integrar sus APIs. No es regulatorio, pero es el estándar de facto del sector.

5. ISO 22301 — Continuidad de negocio: La SFC exige planes documentados de continuidad de operaciones para entidades del ecosistema de pagos. La norma ISO 22301 es el marco de referencia. Para EASPBV, el BanRep exige disponibilidad mínima documentada del 99.9%.

Teniendo en cuenta todo lo anterior, crear una infraestructura de este nivel es construir una autopista digital. Es complejo, requiere certificaciones rigurosas y una arquitectura de nube tolerante a fallos. Sin embargo, el esfuerzo técnico se justifica por el resultado: tomar un sistema financiero históricamente lento y fragmentado y convertirlo en una herramienta ágil que empodera la economía de toda una región, conectando cuentas corporativas extranjeras con el talento local en cuestión de segundos.

Este tipo de implementaciones es viable y sería sumamente productivo, sobre todo para pasarelas de pago que ya operan en el país, y cuentan con gran parte de los requisitos técnicos y legales para comenzar a ejecutar este tipo de servicios a usuarios finales naturales o jurídicos. Sé que este tema puede ser extenso y sobre todo te agradezco leer hasta aquí; la invitación es a dejar tu comentario y compartir.

Referencias documentales de este artículo

Este cronograma refleja el paso de un modelo de adopción voluntaria (iniciado en 2022) hacia un esquema de obligatoriedad que alcanzará su madurez entre 2025 y 2026. Para los equipos técnicos, el reto inmediato es el cumplimiento de la Circular 009 de 2025, que establece las bases de seguridad necesarias para la interoperabilidad total que propone Bre-B.

Ministerio de Hacienda y Crédito Público (MinHacienda / URF)

• Decreto 1297 de 2022: Reglamentación de la arquitectura de finanzas abiertas (Open Finance) e interoperabilidad en el sistema financiero.

• Unidad de Proyección Normativa y Estudios de Regulación Financiera (URF): Proyectos normativos para la transición hacia la obligatoriedad del ecosistema Open Finance (H1 2026).

Superintendencia Financiera de Colombia (SFC)

• Circular Externa 004 de 2024: Estándares técnicos, tecnológicos y de seguridad para la implementación de APIs.

• Circular Externa 009 de 2025: Instrucciones sobre el cumplimiento de arquitectura de seguridad y estándares técnicos mínimos.

• Normativa de Open Finance: Compendio de instrucciones para entidades vigiladas sobre la adopción de finanzas abiertas.

Banco de la República (BanRep)

• Circular Reglamentaria Externa DSP-465: Operación del Sistema de Pagos Inmediatos (SPI) y registro de llaves en Bre-B.

• Sistemas de Pago - Bre-B: Información general sobre la infraestructura de pagos de bajo valor y el go-live transaccional.

• Foros de Sistemas de Pago: Documentación técnica y presentaciones sobre la hoja de ruta de interoperabilidad y QR.

La inteligencia artificial no es una tecnología nueva; de hecho, surgió en 1956 desde el Dartmouth Summer Research Project on Artificial Intelligence, realizado en Dartmouth College, una universidad privada de artes liberales e investigación ubicada en Hanover, Nuevo Hampshire, Estados Unidos.

La idea, en principio, y en términos fáciles de entender, era que “cada aspecto del aprendizaje o cualquier otra característica de la inteligencia puede describirse con tal precisión que una máquina puede ser construida para simularlo”.

En la actualidad

El resurgimiento moderno de la IA se asocia principalmente a un paper de 2017 de Google titulado Attention Is All You Need. Ese paper introdujo la arquitectura Transformer, que cambió completamente cómo se entrenan los modelos de lenguaje.

Todo lo demás inició en 2018 con BART (padre del actual Gemini) y luego en 2019 con la salida de GPT-2, hasta el 2022 cuando OpenAI lanza ChatGPT. La primera inteligencia artificial realmente completa y funcional, con la que se podía conversar mediante lenguaje natural en un chat.

¿Por qué la inteligencia artificial es tan importante?

Sucede que desde 2022 la inteligencia artificial no ha dejado de crecer, evolucionar y aumentar su capacidad. Eso no es un secreto oculto para nadie, tanto, que se han escuchado casos donde incluso se ha usado para consulta por profesionales altamente calificados como jueces e incluso médicos.

Eso en sí mismo no es algo malo. La inteligencia artificial es, a día de hoy, una herramienta sumamente potente que permite extender las capacidades de cualquier profesional.

Eso hace que, para muchos oficios, la inteligencia artificial se convierta en un punto crítico de aprendizaje. Empleos como los de traductores a día de hoy no se ven tan necesarios, sobre todo porque hasta las inteligencias artificiales más básicas son capaces de hacer traducciones altamente exactas y adecuadas de muchos idiomas.

Estas traducciones, por poner un ejemplo, van desde el mismo idioma pero con diferente acento o dialecto, hasta idiomas altamente completos como el japonés y el mandarín, o idiomas más universales como el inglés, de forma simple y directa.

¿Y por qué son los programadores los que se van a quedar sin empleo?

Así como el ejemplo anterior de los traductores (que es un ejemplo muy frecuente en este tipo de debates), otros oficios son vistos como “prontos a desaparecer”, pero ¿es esto posible?

Bueno, desde mi punto de vista, NO. No creo que esto pase. Pero es naturaleza humana buscar posibles puntos de destrucción y alertarse, por ello. Y no está mal, pero tampoco es bueno dejarse llevar por el descontrol masivo sin tener un contexto adecuado.

Cuando se habla de trabajos altamente especializados, estos no van a desaparecer, es prácticamente imposible y te doy un ejemplo:

En muchos países del mundo, de primer, segundo y tercer mundo. Existe el “Originalism” o “interpretación auténtica”. Donde, si una ley es (principalmente) antigua o desconocida, se puede consultar con el propio legislador; puede aclarar su significado, porque fue quien la creó.

En estos casos, siempre se necesita interpretación directa de un humano. Por lo que la inteligencia artificial se vuelve una herramienta muy potente para entender contextos generales; sin embargo, específicamente, en casos como este, se necesita (según sea el caso) un traductor o intérprete.

Entonces, ¿por qué surge este mito?

Puede ser por la alta capacidad de las inteligencias artificiales en generar código; son capaces de hacerlo, pero en teoría un chimpancé también podría escribir la Biblia según el teorema del mono infinito.

Aquí la pregunta es: ¿realmente estamos en ese punto donde la inteligencia artificial nos puede reemplazar?, y la respuesta práctica es NO. Mi observación al respecto es que, en el momento en que la inteligencia artificial sea capaz de hacer eso, el mundo colapsará sobre sí mismo.

En un mundo donde todos los trabajos los puede hacer una inteligencia artificial sin intervención humana y con alta eficiencia, ¿qué sentido tiene la humanidad si todo lo puede hacer una inteligencia artificial?

Pues, quien no se adapta está condenado a la extinción; no lo digo yo, lo dijo Darwin. Y hoy más que nunca tiene un gran sentido.

Pero, ¿qué podemos hacer?

Como te dije, adaptarnos. La inteligencia artificial es una herramienta excepcional, altamente capaz (aunque su eficiencia no es óptima), que nos permite ir más allá, con mayor capacidad.

Mira que los ciclos se repiten; con la invención de la computadora se creía que no era necesario ya un matemático o físico. Lo que antes era algo altamente reservado como el estudio de estas ciencias puras y su especialización, a día de hoy es considerado un requerimiento obligatorio y universal desde niños en la escuela.

Como programador y profesional altamente calificado, mi recomendación es: ¡Adáptate! Si dejas pasar la oportunidad de hacerlo, estarás condenado a perder tu trabajo, pero no por la inteligencia artificial, sino por alguien que sí es capaz de usarla de forma eficiente.

Cuanto más especializado estés en un área en particular, entenderás que la inteligencia artificial sabe menos de lo que creemos.

¿Cuántos empleos se van a perder por la inteligencia artificial en el sector tecnológico?

Muchos, realmente, se van a perder muchos empleos; eso no es algo que esté en discusión. Pero lo que también pasará es que se generarán muchos más, incluso más de los que se van a perder.

Yo particularmente, conozco personas que han perdido su trabajo como diseñadores y desarrolladores de sitios web en WordPress por el hipe que tiene la inteligencia artificial. Pero en su totalidad, esos mismos amigos ahora hacen flujos completos, altamente complejos en N8N usando inteligencia artificial para todo tipo de cosas.

Incluso, ahora ganan más que antes y tienen ingresos de forma estable y constante, y claramente son más que antes. Pero ellos se adaptaron; solo conozco a una persona que no lo hizo y realmente cambió de carrera. Sin embargo, bueno, no lo juzgo, realmente no le gustaba programar; ahora está haciendo lo que le gusta como Trader, e incluso él usa un bot de inteligencia artificial.

Ya para finalizar, solo te puedo decir: Comienza hoy mismo a aprender a usar la inteligencia artificial a tu favor, porque si no, alguien la usará en tu contra. Muchas gracias por tu atención, espero que este post sea de tu agrado y no dudes en dejar tu comentario y compartir.

Apóyame para seguir generando contenido

Suscríbete y recibe contenido nuevo de forma prioritaria, público contenido nuevo con mucha frecuencia y suscribiendote me permites llegar a más personas.

Subscribe now