144verificaciones: 52 Oracle, 35 PostgreSQL, 56 SQL Server y 1 común a los tres
36segundos por hora como techo de carga por base
17segundos por hora medidos en el piloto Oracle
0escrituras en sus bases de datos (salvo el bloqueo opcional que usted ordena)
- Motores
- Oracle 19c y PostgreSQL 16, verificados contra bases reales. Oracle 12.1 y 12.2 (soporte limitado) y SQL Server 2016 o superior, aún sin probar en una base real. Conector para Aurora PostgreSQL escrito, aún sin probar en un clúster real.
- Acceso
- Handlers REST de ORDS preaprobados o conexión directa en Oracle; rol de solo lectura en PostgreSQL; login de solo lectura y conexión cifrada en SQL Server.
- Usuarios
- SELECT_CATALOG_ROLE y AUDIT_VIEWER en Oracle; pg_monitor en PostgreSQL. Las pruebas automáticas intentan escribir con ese usuario y deben fallar.
- Carga
- Máximo 36 segundos de tiempo de base por hora (≈1 % de una CPU), vigilado por el propio PulseDB.
- Bloqueo opcional
- Con el módulo opcional instalado, el DBA puede bloquear una cuenta sospechosa y cortar sus sesiones con un clic desde el ticket, con motivo y segunda confirmación. PulseDB nunca lo hace por su cuenta: usa una cuenta aparte que solo puede ejecutar ese procedimiento y rechaza SYS, SYSTEM, postgres y las cuentas de PulseDB.
- Diagnóstico
- Lo activa usted, por una ventana limitada. ASH y AWR solo si la licencia del Diagnostics Pack lo permite.
- Modelo de IA
- Vía API (hoy Qwen, DeepSeek y Kimi según la tarea) o un modelo compatible con la API de OpenAI en su propia infraestructura. Los datos de sus tablas no salen en ningún caso.
- Auditoría
- Cada acción, suya o de los agentes, queda registrada con el estado anterior y posterior en un registro encadenado por hashes.