NinjaTrader 8 lento o con las velas congeladas: por qué pasa, qué te cuesta y cómo solucionarlo
Si tu NinjaTrader 8 se ha vuelto lento, las velas dejan de actualizarse en pleno mercado o la plataforma se cierra sola, lo más probable es que el problema no esté en tu conexión ni en tu ordenador: está en la base de datos interna de NinjaTrader. Y no es una molestia técnica — es un riesgo financiero medible.
En esta guía te explicamos, con documentación oficial y estudios revisados por pares, por qué ocurre, qué te cuesta de verdad, qué puedes hacer tú mismo y cómo evitar que vuelva a pasar.
Qué es la base de datos de NinjaTrader y por qué se degrada
NinjaTrader 8 guarda tus órdenes, ejecuciones, posiciones e histórico de precios en una base de datos SQLite local (carpeta Documentos\NinjaTrader 8\db). SQLite es fiable en miles de millones de despliegues, pero su propia documentación enumera las condiciones exactas que la corrompen[1] — y varias son habituales en un entorno de trading intensivo.
Por qué NinjaTrader 8 es especialmente vulnerable
| Condición (SQLite oficial) | Presente en trading real |
|---|---|
| Bloqueo de fichero defectuoso / acceso concurrente | Varias instancias o cuentas comparten los mismos ficheros a la vez |
Fallo de fsync (el disco "miente" sobre la escritura) | Alto volumen de órdenes: miles de escrituras por sesión |
| Apagado o crash a mitad de una transacción | Caídas de feed, reconexiones, cierres forzados |
| Copia de seguridad durante una transacción activa | Herramientas que copian la carpeta con NinjaTrader abierto |
fsync() funcione correctamente — justo el perfil de un copiador multicuenta que emite miles de órdenes al día.Síntomas: cómo saber si es tu base de datos
- Las velas se quedan quietas aunque el precio en el DOM sí se mueve.
- Abrir un gráfico o cambiar de instrumento tarda mucho más que antes.
- NinjaTrader consume cada vez más memoria y va "a tirones".
- Cierres inesperados, sobre todo al arrancar o al cargar datos.
La cadena causal: del fichero a la pérdida
El daño sigue una secuencia mecánica y reproducible:
| # | Eslabón | Qué ocurre |
|---|---|---|
| 1 | DB corrupta o enorme | Errores de datos (IDs duplicados) o fichero dañado; lecturas lentas |
| 2 | La plataforma recarga la DB en el hilo de la pantalla | Al reconectar el feed, el gráfico intenta recargar las ejecuciones desde la DB |
| 3 | Congelación | El hilo de pantalla se bloquea; las velas se paran, la operativa sigue por otro hilo |
| 4 | Ejecución dañada | Órdenes tardías, duplicadas o imposibles; posición sin gestionar |
| 5 | Pérdida financiera | Slippage, posición atrapada, riesgo sin stop |
No es una molestia técnica: es riesgo financiero medible
Una congelación es, en el fondo, latencia extrema. Y la latencia tiene un coste cuantificado por la literatura académica.
Si 500 ms ya representan un coste sustancial, una congelación de segundos o minutos convierte ese coste en una pérdida de primer orden. Y ocurre justo cuando el mercado es más volátil — que es cuando el feed cae y la DB se estresa.
Un estudio del Journal of Financial Economics (2022) sobre caídas de brókers documenta además que, cuando tu plataforma te bloquea, pierdes el control de tu riesgo en el peor momento; no es una anécdota, es un efecto medido a escala de mercado[3].
Cómo se traduce en tu P&L
| Daño | Efecto en tu cuenta |
|---|---|
| Slippage por congelación | Peor precio de entrada/salida en cada operación afectada |
| Posición atrapada | Pérdida por el lado adverso mientras no puedes cerrar |
| Órdenes duplicadas / fantasma | Exposición no deseada, posición invertida |
| Datos históricos corruptos | Backtests y estadísticas mal calculados → decisiones erróneas |
| Registros erróneos | Disputas con prop firms, errores fiscales/contables |
Soluciones manuales (y por qué no bastan)
- Reducir el histórico que guardas (menos días de datos a mano).
- Hacer copia de seguridad de tu carpeta de NinjaTrader antes de tocar nada.
- Compactar o reconstruir la base de datos siguiendo la documentación oficial[5].
El problema es que esto es manual, ocasional y arriesgado: hay que acordarse, elegir el momento (mercado cerrado) y un paso mal dado puede dejarte sin histórico. La mayoría solo reacciona cuando ya se ha roto algo.
La forma de que no vuelva a pasar: automatizar el mantenimiento
En lugar de apagar fuegos, la solución sostenible es que el mantenimiento ocurra solo, en segundo plano y en el momento adecuado. Para eso creamos TSD DB Guardian, un programa externo a NinjaTrader que se ocupa de la salud de su base de datos sin que tengas que hacer nada:
- Detecta la corrupción y el sobrecrecimiento de forma continua.
- Respalda con una copia verificada antes de actuar.
- Repara cuando hace falta y espera a mercado cerrado para no molestar tu operativa.
- Deja un informe de auditoría firmado de cada intervención.
Funciona de forma programable (semanal, cada 15 o cada 30 días) y trae un botón de pánico para lanzar el mantenimiento al instante. Es software de Windows que convive con NinjaTrader 8; no es un complemento que cargue dentro de la plataforma.
Deja de pelearte con la base de datos de NinjaTrader
Prueba TSD DB Guardian 14 días gratis, con todas las funciones y sin tarjeta.
Ver TSD DB Guardian Probar gratis 14 días
Preguntas frecuentes
¿Perderé mi histórico de datos al reparar la base?
No, si se hace con una copia de seguridad previa. DB Guardian siempre respalda antes de actuar; si lo haces manualmente, haz tú la copia primero.
¿Tengo que parar de operar para hacer el mantenimiento?
No. DB Guardian espera a mercado cerrado y trabaja en segundo plano. El mantenimiento manual sí conviene hacerlo con la plataforma cerrada.
¿Esto es un indicador de NinjaTrader?
No. Es un programa de Windows independiente que convive con NinjaTrader 8 y se ocupa de su base de datos desde fuera.
¿Por qué se congela justo en los momentos de más movimiento?
Porque la volatilidad trae más órdenes, más escrituras y más reconexiones de feed — las condiciones exactas que estresan la base de datos SQLite y disparan la recarga en el hilo de la pantalla.
Referencias
- SQLite. How To Corrupt An SQLite Database File. sqlite.org/howtocorrupt.html
- Moallemi, C. C., & Saglam, M. (2013). The Cost of Latency in High-Frequency Trading. Operations Research, 61(5).
- Retail trader sophistication and stock market quality: Evidence from brokerage outages. Journal of Financial Economics (2022).
- NinjaTrader Support Forum. Issue with Order Flow Market Depth Map Freezing Platform — significant loss incurred.
- NinjaTrader Help Guide. Operations > Database Operations (Reset DB / Repair DB).