Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
159 changes: 159 additions & 0 deletions src/content/ensayos/turso-base-datos-agentes-mcp.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
---
title: "Turso: la base de datos que tus agentes de código deberían usar"
description: "20K estrellas, SQLite-compatible, escrita en Rust, con MCP server nativo. Turso resuelve el problema más ignorado de los agentes de código: dónde guardar estado de forma fiable, portable y consultable por el propio agente."
fecha: 2026-06-20
tags: ["herramientas", "agentes", "mcp", "base-de-datos", "rust", "arquitectura"]
autor: "Alejandro de la Fuente"
---

Cada agente de código tiene un problema de estado. Lo notes o no.

Cuando le pides a un agente que "recuerde los tests que fallaron la semana pasada", o "dame todos los usuarios que creé en este proyecto", o "¿qué esquema tiene la tabla de permisos?", el agente hace una de tres cosas:

1. **Lo guarda en el chat** — y lo pierde cuando el contexto se compacta.
2. **Lo guarda en un archivo JSON** — y reza para que no se corrompa con escrituras concurrentes.
3. **No lo guarda** — y tú repites la misma pregunta tres sesiones después.

Ninguna de las tres es aceptable para un agente que pretendes usar en serio. Y sin embargo, es el estado del arte en 2026.

[Turso](https://github.com/tursodatabase/turso) propone una cuarta opción: **una base de datos SQL in-process, compatible con SQLite, con un servidor MCP nativo**. El agente no escribe archivos. Le habla a la base de datos como si fuera una herramienta más.

---

## Qué es Turso

Turso es un rewrite de SQLite en Rust. No es un fork — es una reimplementación desde cero, con el mismo formato de archivo, el mismo dialecto SQL y la misma API en C. Pero con cosas que SQLite no tiene: I/O asíncrono con `io_uring`, MVCC para escritura concurrente (`BEGIN CONCURRENT`), vectores, FTS con Tantivy, CDC (change data capture), y bindings para 7 lenguajes.

¿Por qué reescribir SQLite en Rust? La respuesta corta: porque SQLite es la base de datos más desplegada del planeta, pero su modelo de concurrencia —un solo escritor, múltiples lectores— limita lo que puedes hacer con agentes que escriben en paralelo. Turso añade MVCC sin sacrificar compatibilidad.

Pero lo que me interesa aquí no es el motor de base de datos. Es el **servidor MCP**.

---

## El MCP server: tu base de datos como herramienta del agente

Turso incluye un servidor [Model Context Protocol](https://modelcontextprotocol.io/) en su CLI. Lo ejecutas así:

```bash
tursodb mi-base.db --mcp
```

Y tu agente —Claude Code, Claude Desktop, Cursor, cualquier cliente MCP— gana 9 herramientas nuevas:

| Herramienta | Qué hace |
|---|---|
| `open_database` | Abre una base de datos nueva |
| `current_database` | Describe la base de datos actual |
| `list_tables` | Lista todas las tablas |
| `describe_table` | Describe la estructura de una tabla |
| `execute_query` | Ejecuta SELECTs de solo lectura |
| `insert_data` | Inserta datos |
| `update_data` | Actualiza datos |
| `delete_data` | Borra datos |
| `schema_change` | Modifica el esquema (CREATE/ALTER/DROP TABLE) |

Esto significa que tu agente puede, sin salir de su flujo normal:

```text
Tú: "Guarda en la base de datos todos los tests que han fallado hoy,
con el nombre del archivo, el error y la fecha"

Agente: [llama a insert_data 12 veces]
"He guardado 12 fallos en la tabla test_failures.
¿Quieres que los agrupe por tipo de error?"

Tú: "Sí, y dime cuál es el error más frecuente"

Agente: [llama a execute_query con GROUP BY]
"El error más frecuente es 'timeout' con 5 ocurrencias,
seguido de 'assertion error' con 4."
```

No es magia. Es una base de datos con una interfaz que el agente entiende.

---

## Configuración en 30 segundos

Añadir Turso como MCP server en Claude Code es un comando:

```bash
claude mcp add mi-proyecto -- tursodb ./data/app.db --mcp
```

En Claude Desktop, añades esto a tu configuración:

```json
{
"mcpServers": {
"turso": {
"command": "/path/to/tursodb",
"args": ["./data/app.db", "--mcp"]
}
}
}
```

Y en Cursor, lo añades desde la UI de extensiones MCP.

El punto importante: **no necesitas un servidor aparte**. Turso es in-process. El binario `tursodb` es la base de datos y el servidor MCP a la vez. No hay Redis. No hay PostgreSQL. No hay Docker. Un binario de Rust que pesa unos pocos megas.

---

## Por qué esto importa para agentes de código

Los agentes de código necesitan tres cosas de su almacenamiento:

1. **Persistencia fiable**: los datos sobreviven a reinicios, compactaciones de contexto y cambios de sesión. SQLite (y Turso) usan un solo archivo. Haces backup copiando un archivo. No necesitas un clúster.

2. **Consultable por el agente**: el agente no puede hacer `grep` sobre un JSON de 50 MB cada vez que necesita un dato. Con SQL, haces `SELECT * FROM test_failures WHERE date > '2026-06-01'` y obtienes exactamente lo que necesitas.

3. **Escribible sin corrupción**: si dos slices de tu orquestador intentan escribir a la vez, necesitas que la base de datos lo maneje. Turso añade `BEGIN CONCURRENT` con MVCC para exactamente este caso.

El patrón es claro: **una base de datos SQL por proyecto, expuesta como herramienta MCP, usada por el agente como memoria estructurada**.

No es un reemplazo del chat. Es un complemento. El chat es para el contexto inmediato. La base de datos es para lo que necesitas recordar entre sesiones, entre slices, entre semanas.

---

## Lo que NO es Turso (y por qué no pasa nada)

Turso **no es** una alternativa a PostgreSQL o MySQL para tu backend de producción. Es una base de datos in-process, como SQLite. Si necesitas réplicas, sharding, o cientos de conexiones concurrentes, necesitas otra cosa.

Turso **no es** una base de datos vectorial especializada. Tiene soporte para vectores (exact search) y planea añadir índices vectoriales (approximate search), pero si tu caso de uso es RAG con millones de embeddings, necesitas Pinecone, Qdrant o Milvus.

Turso **está en beta**. El propio README lo advierte: "This software is in BETA. It may still contain bugs and unexpected behavior." Para una demo de agente, va sobrado. Para datos de misión crítica, haz backups.

---

## El ecosistema: no es solo la DB

Turso no es solo el motor. Es un ecosistema:

- **Bindings para 7 lenguajes**: Python (`pyturso`), JavaScript (`@tursodatabase/database`), Java (JDBC), Go, .NET, Rust, y WebAssembly. Si tu agente está en Python pero tu app está en TypeScript, ambos pueden leer la misma base de datos.
- **Turso Cloud**: el mismo equipo ofrece una versión cloud con replicación, branching y sync. No es open source, pero el formato de archivo es compatible.
- **Extensions**: crypto, regexp, CSV, fuzzy search, direcciones IP, percentiles. Todo lo que esperas de SQLite, pero en Rust.
- **Deterministic Simulation Testing**: el equipo usa Antithesis para probar concurrencia. No es un proyecto de fin de semana.

20.000 estrellas en GitHub, 1.000 forks, commits diarios, releases frecuentes. MIT license. No es un proyecto que vaya a desaparecer.

---

## El ángulo para Código Sin Siesta

Cada vez que evalúo una herramienta para desarrollo agentico, me hago la misma pregunta: **¿resuelve un problema real de workflow o solo añade complejidad?**

Turso con MCP resuelve un problema real: **dónde guardan estado los agentes**. No es un "framework de agentes". No es un "orquestador". Es una base de datos. Pero es exactamente la pieza que falta en la mayoría de los setups de coding agents que veo.

El patrón que propongo:

```text
Agente de código → MCP → Turso (SQL in-process)
Archivo .db en el repo
(se versiona o se ignora según el caso)
```

Para un agente local que está iterando sobre un proyecto, tener una base de datos SQL a la que pueda consultar con lenguaje natural —"¿qué tests fallaron ayer?"— cambia la experiencia de "asistente que olvida" a "compañero que recuerda".

Y lo mejor: no necesitas configurar nada. Un binario, un flag `--mcp`, y tu agente ya sabe hablar SQL.
109 changes: 109 additions & 0 deletions src/content/ensayos/worldmonitor-palantir-open-source.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
---
title: "WorldMonitor: el Palantir open source que no sabías que existía"
description: "57K estrellas en GitHub, 500+ fuentes de noticias, mapas 3D, IA local con Ollama, 24 idiomas y una app de escritorio. WorldMonitor es el dashboard de inteligencia global más ambicioso del open source y merece un vistazo."
fecha: 2026-06-20
tags: ["herramientas", "dashboard", "osint", "open-source", "ia", "monitorización"]
autor: "Alejandro de la Fuente"
---

Hay proyectos open source que explican su valor en la primera frase del README. WorldMonitor lo hace: _"Real-time global intelligence dashboard — AI-powered news aggregation, geopolitical monitoring, and infrastructure tracking in a unified situational awareness interface."_

Traducción: un Palantir, pero open source, con 57.000 estrellas en GitHub, app de escritorio nativa y una ejecución técnica que roza lo obsesivo.

No es un juguete. No es un "clon de X con IA". Es un sistema de inteligencia global que agrega 500+ fuentes de noticias curadas, las sintetiza con IA, las despliega sobre mapas 3D con 56 tipos de capas, y lo empaqueta todo en una sola codebase que genera seis variantes distintas del producto.

Y puedes ejecutarlo localmente, sin API keys, usando Ollama.

---

## Qué hace realmente

El dashboard se organiza en paneles. Cada panel es una ventana al mundo en tiempo real:

- **Mapa dual**: un globo 3D (globe.gl) y un mapa plano WebGL (deck.gl) con 56 capas — desde actividad militar hasta rutas marítimas, pasando por ciberataques, clima severo, tráfico aéreo y sanciones económicas.
- **Feed de noticias**: 500+ fuentes RSS curadas en 15 categorías, sintetizadas por IA en briefs. No es un agregador de titulares: es un pipeline que extrae entidades, geolocaliza eventos y los correlaciona entre fuentes.
- **Country Instability Index (CII v8)**: un scoring de estrés para 31 países Tier-1, calculado en servidor con datos de 35 fuentes agrupadas. No es un número mágico: el código del algoritmo está en el repo.
- **Radar financiero**: 29 bolsas, commodities, crypto, y un composite de 7 señales de mercado. Con sparklines, heatmaps y correlación cruzada.
- **Correlación cross-stream**: convergencia de señales militares, económicas, de desastre y de escalada. Si tres fuentes independientes reportan actividad inusual en el Estrecho de Ormuz, el dashboard lo cruza y lo eleva.
- **6 variantes desde una sola codebase**: `worldmonitor.app` (completa), `tech.worldmonitor.app` (tecnología), `finance.worldmonitor.app` (mercados), `commodity.worldmonitor.app` (materias primas), `happy.worldmonitor.app` (solo noticias positivas), `energy.worldmonitor.app` (seguridad energética, chokepoints, disrupciones).

Y todo esto corre en el navegador. La app de escritorio —Tauri 2, nativa para macOS, Windows y Linux— es la misma SPA empaquetada con un sidecar Node.js para operaciones que necesitan sistema de archivos.

---

## La arquitectura: 155 componentes, 80+ endpoints, protobufs

Una cosa es tener ambición. Otra es ejecutarla con disciplina. WorldMonitor hace ambas.

La codebase tiene ~25 millones de bytes de TypeScript/JavaScript, organizados en capas con una dirección de dependencia estricta:

```text
types → config → services → components → app → App.ts
```

- `types/` tiene cero imports internos. Es la base de todo.
- `config/` solo importa de `types/`. Define paneles, capas, variantes y símbolos de mercado.
- `services/` contiene 185 módulos de lógica de negocio: fetching, caching, parsing, scoring.
- `components/` son 155 componentes TypeScript (clases, no funciones — han optado por un estilo más cercano a Java/C# que al React hooks típico).
- `app/` orquesta componentes y servicios.

La API son 80+ Vercel Edge Functions autocontenidas (JavaScript plano, sin imports de `src/`), con handlers en `server/` que se empaquetan en el deploy usando un gateway factory. La comunicación está tipada con **protobufs** — sí, protobufs en un proyecto TypeScript de frontend. Usan `buf` para generar stubs de cliente y servidor, y los handlers de dominio (aviation, climate, energy, finance, maritime, military, cyber) se cablean contra esos contratos.

No es "un proyecto con TypeScript". Es un proyecto con TypeScript **y contratos formales**.

---

## IA local: Ollama, sin API keys

Uno de los detalles más interesantes es que puedes ejecutar todo el pipeline de IA localmente con Ollama. Sin OpenAI. Sin Anthropic. Sin API keys.

El proyecto incluye workers para ML (ONNX en el navegador), análisis y una base de datos vectorial en el frontend. Los briefs de noticias, la extracción de entidades y la correlación de señales pueden correr contra un modelo local.

Esto es importante por dos razones:

1. **Privacidad**: los datos no salen de tu máquina. Si estás haciendo OSINT en un contexto sensible, esto es crítico.
2. **Resiliencia**: el dashboard funciona sin conexión a servicios cloud de IA. Si mañana OpenAI cambia sus precios o sus términos, WorldMonitor sigue funcionando.

Y no es un afterthought. El soporte para Ollama está integrado en el pipeline de síntesis, no es un "chatbot en una esquina".

---

## Lo que dice de hacia dónde va el desarrollo de software

WorldMonitor es relevante para esta comunidad no por lo que hace —inteligencia global— sino por **cómo está construido**.

Primero: **disciplina arquitectónica sin hype**. No usa React Server Components, no usa Next.js, no usa IA para todo. Usa Vite + Preact porque es lo que necesita. Usa clases de TypeScript porque les funciona. Usa protobufs porque necesitan contratos. Cada decisión técnica está justificada por el problema, no por la tendencia.

Segundo: **variantes desde una sola codebase**. Seis productos distintos —world, tech, finance, commodity, happy, energy— compilados desde el mismo código. La configuración de variantes es un sistema de feature flags que selecciona paneles, capas y fuentes de datos. Esto es lo que los equipos enterprise intentan hacer con microfrontends y acaban con 14 repos y un orchestra de CI/CD. Aquí está resuelto con archivos de configuración y `VITE_VARIANT`.

Tercero: **la app de escritorio es un ciudadano de primera**. Tauri 2 empaqueta la misma SPA con un sidecar Node.js. No hay "versión móvil reducida" ni "experiencia desktop limitada". La misma codebase, el mismo feature set, distribuido como web y como binario nativo.

Cuarto: **57K estrellas en 5 meses**. El repo se creó en enero de 2026. En junio tiene 57.000 estrellas y 9.000 forks. El ritmo de commits es diario, con PRs que arreglan bugs de seguridad, mejoran rendimiento y añaden fuentes de datos. No es un proyecto que apareció y se estancó: es un proyecto que crece.

---

## Lo que no es

WorldMonitor no es para todos. Si tu interés es el desarrollo web tradicional —formularios, CRUDs, dashboards de negocio— este proyecto te parecerá excesivo. Pero si trabajas en:

- **OSINT** (inteligencia de fuentes abiertas)
- **Ciberseguridad** (monitorización de amenazas, superficie de ataque global)
- **Análisis geopolítico** (riesgo país, sanciones, conflictos)
- **Trading o finanzas** (señales de mercado, correlación de eventos)
- **Logística y supply chain** (rutas marítimas, disrupciones, chokepoints)

...entonces WorldMonitor es una herramienta que probablemente deberías conocer, aunque solo sea para estudiar su arquitectura.

---

## El ángulo para Código Sin Siesta

No voy a escribir una review de features. Eso lo hace cualquiera. Lo interesante aquí es lo que WorldMonitor demuestra sobre **cómo se construye software ambicioso en 2026**:

1. **TypeScript estricto con contratos formales** (protobufs) funciona en la práctica. No necesitas Rust o Go para tener type safety extremo a extremo.
2. **Una sola codebase, múltiples productos** no es un sueño — es un sistema de configuración bien diseñado.
3. **IA local con Ollama** es viable hoy para pipelines de síntesis y extracción. No es solo para chatbots.
4. **Tauri 2** está listo para aplicaciones de escritorio complejas. Si tu SPA funciona en el navegador, funciona como app nativa.
5. **El open source puede competir con Palantir**. No en ventas enterprise ni en contratos gubernamentales, pero sí en capacidad técnica y velocidad de iteración.

WorldMonitor no es el futuro. Es el presente, y está en GitHub con licencia AGPL v3.
Loading