Esta página describe Calíope 1.7, la versión que estoy construyendo ahora mismo. La 1.6 está en la App Store para Mac, iPad, iPhone, Apple Watch, Apple TV y Apple Vision Pro. El changelog dice en qué versión llegó cada función.
Añade un botón «Abrir en Calíope» a cada tema. Sólo funciona con la app instalada.
En el Gestor de Conexiones, pulsa + en la barra lateral izquierda. Introduce un nombre descriptivo, la familia del servidor (el protocolo con el que habla) y el producto dentro de ella, el host, puerto, usuario y contraseña. El campo "Base de datos por defecto" es opcional.
La fila Entorno le pone al perfil una de tus etiquetas de entorno —Ninguna por omisión—, y Etiquetas de entorno… abre el catálogo donde se crean.
En la sección Opciones del servidor puedes configurar el charset, la cotejación y activar SSL/TLS. Si SSL está activo aparecerán campos para seleccionar el certificado y la clave del cliente.
ClickHouse
Con ClickHouse la sección no trae charset ni cotejación, ni certificado ni clave de cliente, y al marcar SSL/TLS el puerto pasa de 8123 a 8443 si era el de omisión, y al revés al desmarcarlo.
Oracle
Con Oracle Database el campo de la base se llama Servicio y pide el nombre del servicio (SERVICE_NAME, FREEPDB1 en una instalación Free), no un SID. La sección no trae charset ni cotejación, ni certificado ni clave de cliente, y al marcar SSL/TLS el puerto pasa de 1521 a 2484 si era el de omisión, y al revés al desmarcarlo.
MySQLMariaDBAurora
Cómo se autentica. Calíope entra con las cinco maneras de MySQL y MariaDB: caching_sha2_password (la de omisión desde MySQL 8), mysql_native_password, client_ed25519 y parsec de MariaDB, y mysql_clear_password, que manda la contraseña en claro y por eso sólo se usa con SSL/TLS activo: sin él, Calíope no la envía y lo dice. Es la que piden PAM, LDAP y la autenticación IAM de Aurora. La manera la decide la cuenta en el servidor, no el perfil.
PostgreSQL
Cómo se autentica. Calíope entra con las tres maneras de PostgreSQL que usan contraseña: SCRAM-SHA-256 (la de omisión desde PostgreSQL 14), md5, y la contraseña en claro (password en pg_hba.conf), que sólo se envía con SSL/TLS activo: sin él, Calíope no la envía y lo dice. Es la que piden LDAP, PAM, RADIUS y la autenticación IAM de RDS y Aurora. Kerberos (GSSAPI) y SSPI no están: con un servidor que sólo admita esos, la conexión falla diciendo que Calíope no sabe usar ese método.
Palabras clave: perfil, nueva conexión, guardar servidor, host, configurar, autenticación, caching_sha2_password, mysql_native_password, ed25519, parsec, mysql_clear_password, SCRAM-SHA-256, md5, PAM, LDAP, IAM
Selecciona el perfil en la lista de la barra lateral. El formulario de la derecha se carga con sus datos actuales y puedes editar cualquier campo directamente. No hay botón de guardar: cada cambio se guarda en cuanto lo haces.
Para eliminar un perfil hay un tema propio, porque no se puede deshacer y se lleva más de lo que parece: ver Eliminar una conexión.
Eliminar una conexión no borra sólo su dirección y su usuario: se lleva todo lo que Calíope había guardado de ese servidor. Por eso pregunta antes, y por eso la pregunta dice el nombre de la conexión — si no es la que creías, ése es el momento de enterarte.
Desde dónde
- macOS: selecciona el perfil y pulsa − en la barra de abajo de la lista, junto al +. O haz clic derecho sobre la fila y elige Eliminar.
- iPad: selecciona el perfil y pulsa − en la barra inferior; o mantén pulsada la fila y elige Eliminar; o desliza la fila de derecha a izquierda. El deslizamiento no borra al soltar: revela el botón, y la pregunta llega igual. Deslizar en el otro sentido —de izquierda a derecha— es Mover a grupo.
Qué se va con ella
- El perfil, con todos sus datos.
- Su contraseña del Llavero, y también la de SSH y la frase de paso de su clave privada.
- Su historial de consultas, y sus filas del registro de errores y del registro de mensajes del servidor.
- El SQL que tuviera guardado en el editor de esa conexión, y su caché de esquema.
No se puede deshacer. No hay papelera ni deshacer: la confirmación es la única oportunidad de echarse atrás.
En tus otros dispositivos. Con la sincronización de iCloud activada la baja viaja, y la conexión desaparece también allí. Al revés no pasa nada raro: un perfil que creaste en el otro equipo y que éste todavía no había visto no se lee como una baja, así que no se borra solo.
Un grupo entero. Eliminar un grupo elimina también las conexiones que tiene dentro, con la misma pregunta y el mismo alcance; se explica en Organizar perfiles en grupos.
El campo «Host alternativo» del perfil sirve para un servidor al que se llega por dos direcciones distintas. El caso típico es una máquina de desarrollo: desde el propio equipo responde en 127.0.0.1, y desde el iPad hay que usar su dirección en la red local. Como los perfiles se sincronizan entre tus dispositivos, un solo campo de host no puede ser correcto en los dos sitios.
Al conectar se intenta primero el host principal. Si no responde, se intenta el alternativo con el mismo puerto, el mismo usuario, la misma contraseña y las mismas opciones: lo único que cambia es la dirección. Si necesitas también otro puerto, escribe «dirección:puerto» (por ejemplo, 10.0.0.20:3307).
Cuando la sesión entra por el alternativo, aparece una marca junto al nombre del servidor y «Probar conexión» dice a qué dirección respondió, para que sepas siempre contra qué máquina estás trabajando.
Con un túnel SSH el campo se ignora, y no es un olvido: ahí la dirección del servidor la resuelve la máquina del túnel, no tu dispositivo, así que no cambia según desde dónde te conectes.
Palabras clave: host alternativo, segunda dirección, ip local, red local, failover, 127.0.0.1, ipad, dos direcciones
Cuándo hace falta escribirla, qué campos deja de usar Calíope cuando lo haces y dónde queda la contraseña.
Dónde está: Panel lateral › Conexiones › Cadena de conexión
El campo «Cadena de conexión» aparece solo cuando el motor del perfil es MongoDB, y es opcional. Si lo dejas vacío, Calíope arma la conexión con lo que hay arriba: dirección, puerto, usuario, contraseña, TLS y base de datos. Para un servidor normal eso basta.
Escríbela cuando la conexión no se pueda describir con esos campos. Son tres casos: un conjunto de réplica, que necesita varias direcciones y el nombre del conjunto; una base de autenticación distinta de la habitual, que se indica con authSource; y un clúster de Atlas, cuya dirección empieza por mongodb+srv:// y no lleva puerto que teclear. Con mongodb+srv://, Calíope pregunta los servidores del clúster al DNS de tu sistema, el mismo que usa el resto del dispositivo, VPN incluida.
Cuando la escribes, lo que la cadena dice manda sobre los campos de arriba: las direcciones, el usuario, la contraseña, si se usa TLS y las opciones. Lo que no dice lo pone el perfil: si no lleva usuario ni contraseña, se usan los de los campos, y si no nombra ninguna base de datos, la del perfil, o admin si tampoco la hay. Con varias direcciones y replicaSet, Calíope busca cuál es el primario y trabaja con él. Hay dos cosas que la cadena no decide nunca. Si el perfil usa un túnel SSH, la dirección la pone el túnel y no la cadena, porque el servidor que nombra la cadena es el que ve la máquina del túnel y no tu dispositivo. Y los certificados salen siempre del perfil: la cadena puede encender o apagar TLS y pedir que no se verifique el certificado, pero el Certificado CA (.pem) y el Certificado de cliente (.pem) se eligen en Certificados SSL.
Si la cadena no dice authSource, la autenticación va contra admin. Es donde viven las cuentas administrativas y es lo que asumen mongosh y Compass cuando alguien teclea usuario y contraseña sin más; si las tuyas están en otra base, indícalo con authSource.
Hay opciones que la cadena acepta y no usa. tlsCAFile y tlsCertificateKeyFile se ignoran: son rutas a un archivo, y Calíope solo abre los archivos que eliges tú, así que el certificado se pone en el perfil. Las opciones de lectura y escritura, como readPreference, w o retryWrites, se aceptan para que una cadena copiada de Atlas funcione tal cual, pero no cambian lo que hace Calíope.
Una advertencia sobre la contraseña: la del campo de arriba se guarda en el Llavero, pero una contraseña escrita dentro de la cadena no. La cadena se guarda con el resto del perfil y, si tienes activada la sincronización con iCloud, viaja con él. Si eso te importa, deja la contraseña en su campo y usa la cadena solo para lo demás.
Si la cadena está mal escrita, la conexión falla diciéndolo: es un error del formulario, así que se arregla ahí y no reintentando.
Palabras clave: cadena de conexión, mongodb, uri, srv, atlas, conjunto de réplica, replica set, authSource, mongodb+srv
Verifica los datos del servidor antes de conectar.
Dónde está: Gestor de Conexiones › Probar conexión
Pulsa Probar conexión en el formulario del perfil. Calíope intenta abrir una conexión real con los datos introducidos y muestra el resultado en un banner verde (éxito) o rojo (error con descripción).
La prueba es especialmente útil para validar credenciales SSL, firewalls o configuraciones de host antes de guardar el perfil.
Establece la conexión y abre el Espacio de Trabajo.
Dónde está: Gestor de Conexiones › Conectar
Una vez completados los datos del perfil, pulsa el botón Conectar (con ícono de rayo). Calíope abre el pool de conexiones con el controlador del motor y carga el árbol de esquemas.
Si la conexión falla, se abre una hoja que dice qué pasó y qué revisar. Ver solución, cuando aparece, lleva al tema de esta Ayuda que lo explica, y Detalles técnicos enseña el texto del servidor o de la red, tal cual. El formulario lo repite en el recuadro donde sale el resultado de Probar conexión, como «Error al conectar: …». Revisa el host, las credenciales y que el servidor esté activo y accesible desde tu red.
Palabras clave: connect, conectar, abrir workspace, pool
Cambia la base de datos de la sesión desde el panel de esquema.
Dónde está: Editor SQL › Panel de esquema › Usar como base de datos activa
En el panel de esquema del Editor SQL, haz clic derecho en una base de datos (en iPad, mantenla pulsada) y elige Usar como base de datos activa. La sesión pasa a ella sin reconectar —equivale a ejecutar USE nombre_bd— y el menú de servidor enseña su nombre junto al del servidor. El cambio afecta solo a la sesión actual.
Oracle
Con Oracle el árbol lista esquemas, no bases: un esquema es un usuario, y la base es el servicio al que te conectaste. Oracle no tiene USE: el esquema que eliges es en el que el editor resuelve los nombres sin cualificar, y cada ejecución lo fija en la sesión, como ALTER SESSION SET CURRENT_SCHEMA. El perfil no cambia: su servicio sigue siendo el mismo.
Palabras clave: use database, cambiar bd, seleccionar base de datos
Desconecta del servidor y vuelve al Gestor de Conexiones.
Dónde está: Espacio de Trabajo › Desconectar
Pulsa el botón Desconectar en la cabecera del Espacio de Trabajo. Calíope cierra el pool de conexiones y regresa a la pantalla del Gestor de Conexiones con animación.
La desconexión es automática al cerrar la ventana principal de la aplicación.
En el formulario de perfil de conexión, activa el interruptor Reconexión automática. Calíope lo usa al cambiar la base de datos activa (Usar como base de datos activa en el panel de esquema): si en ese momento la conexión está cortada —el servidor la cerró por inactividad o se reinició, o se cayó el túnel SSH—, vuelve a abrir la sesión entera, túnel incluido, y repite el cambio.
No reintenta las consultas del editor ni de las herramientas: el corte se enseña como corte de conexión.
Con túnel SSH, ese mismo momento es el que dispara los avisos de túnel caído y reconectado (ver Notificaciones de túnel SSH).
Trabaja con varios servidores al mismo tiempo sin perder el contexto.
Dónde está: Espacio de Trabajo › Menú de servidor
Calíope soporta tener varias conexiones a servidores activas al mismo tiempo. Cada servidor tiene su propia sesión independiente con su propio árbol de esquemas, pestañas SQL abiertas, historial de consultas y estado del asistente IA.
Cómo funciona:
Cada vez que pulsas Conectar en el Gestor de Conexiones, se abre una nueva sesión sin cerrar las anteriores. Todas las sesiones coexisten y puedes alternar entre ellas sin perder nada.
Estado de cada sesión:
- Pestañas SQL y su contenido se conservan al cambiar de servidor.
- El árbol de esquemas muestra las bases de datos del servidor activo.
- El asistente IA mantiene su historial de conversación por sesión.
Puedes abrir tantas sesiones como necesites, por ejemplo para comparar datos entre entornos de desarrollo, staging y producción al mismo tiempo.
Palabras clave: multi-servidor, múltiples conexiones, simultáneo, varias conexiones, sesiones, multiserver
Cambia entre servidores conectados desde el menú desplegable del Espacio de Trabajo.
Dónde está: Espacio de Trabajo › Menú de servidor
El menú selector de servidor muestra el nombre del servidor activo y un indicador de estado de conexión (punto verde = conectado, rojo = error). Al pulsarlo se despliega un menú con todas las sesiones abiertas.
En macOS: el selector aparece en la barra de herramientas de la ventana, en la esquina superior izquierda. Muestra el nombre del servidor, la base de datos activa y la flecha desplegable.
En iPad: el selector aparece a la izquierda de la barra de pestañas, siempre visible en la parte superior del Espacio de Trabajo.
En iPhone: también está arriba de la lista Herramientas, así que puedes cambiar de sesión, añadir un servidor o desconectar desde cualquier pantalla del Espacio de Trabajo.
Opciones del menú:
- Toca o haz clic en el nombre de cualquier servidor para activar esa sesión.
- La sesión activa aparece marcada con un ✓.
- Añadir servidor abre el Gestor de Conexiones sobre el Espacio de Trabajo actual para conectar otro servidor sin perder las sesiones abiertas.
- Desconectar cierra la sesión del servidor activo.
Conecta a un servidor adicional sin abandonar el trabajo actual.
Dónde está: Espacio de Trabajo › Menú de servidor › Añadir servidor
Para añadir una nueva conexión mientras ya estás trabajando en otro servidor:
1. Abre el menú selector de servidor (en la barra de la ventana en macOS, en la barra de pestañas en iPad).
2. Elige Añadir servidor.
3. Se abre el Gestor de Conexiones: en una ventana propia en macOS, como hoja en iPad.
4. Selecciona un perfil existente o crea uno nuevo y pulsa Conectar.
5. El Gestor de Conexiones se cierra solo y la nueva sesión queda disponible en el selector.
Las sesiones previas permanecen abiertas e intactas durante todo el proceso.
Palabras clave: añadir servidor, nueva sesión, segunda conexión, agregar servidor, conectar otro
Cierra la sesión de un servidor sin afectar las demás conexiones activas.
Dónde está: Espacio de Trabajo › Desconectar
Cuando tienes varias sesiones abiertas, puedes cerrar cualquiera de ellas de forma independiente:
Servidor activo:
- Abre el menú selector de servidor y pulsa Desconectar, o usa el botón rojo de desconexión en la barra de herramientas.
Cualquier sesión (para cambiar primero):
1. Abre el menú selector de servidor.
2. Selecciona el servidor que quieres cerrar para activarlo.
3. Pulsa Desconectar.
Al cerrar una sesión, Calíope activa automáticamente la última sesión disponible. Si era la única sesión abierta, regresa al Gestor de Conexiones.
Cifra la conexión al servidor con certificados SSL.
Dónde está: Panel lateral › Formulario de perfil › SSL
En el formulario del perfil de conexión, activa el interruptor SSL en la sección Opciones del servidor. Aparecen tres campos opcionales para los certificados del cliente:
- Certificado CA — archivo del certificado de la Autoridad Certificadora (.pem o .crt). Con este archivo Calíope verifica la identidad del servidor.
- Certificado cliente — archivo del certificado del cliente para autenticación mutua.
- Clave cliente — clave privada correspondiente al certificado del cliente.
Si activas SSL sin especificar el certificado CA, Calíope verifica el certificado del servidor contra las autoridades certificadoras del sistema (comportamiento por defecto seguro). Si el servidor usa un certificado autofirmado, la conexión fallará a menos que proporciones el CA correspondiente.
Aceptar certificado sin verificar (inseguro): marca esta casilla solo si te conectas a un servidor de desarrollo con certificado autofirmado y no puedes proporcionar el CA. La conexión seguirá cifrada pero será vulnerable a ataques man-in-the-middle. No la actives para servidores de producción.
Dónde queda el archivo: al elegir un CA, un certificado o una clave de cliente —o pegarlo, fuera del Mac— Calíope guarda su propia copia en este aparato, nunca en iCloud Drive, y el perfil apunta a esa copia. Puedes mover o borrar el original después, y en el Mac se sigue leyendo tras relanzar. Para renovar un certificado, vuelve a elegirlo, aunque se llame igual. El archivo se queda en el aparato donde lo elegiste, y su ubicación también: un perfil configurado en otro aparato llega sin él. Antes de conectar, la lista de conexiones muestra Elige sus archivos en este aparato y el formulario dice «Este perfil usa un certificado elegido en otro aparato: elígelo aquí.»; elígelo allí, y desde entonces ese aparato guarda su propia copia.
Si un archivo no se puede leer, Calíope no conecta sin él: se detiene con «No se pudo leer un archivo TLS», que nombra el archivo y cuál de los tres es.
La conexión SSL se prueba al pulsar Probar conexión; el banner verde confirmará si el cifrado está activo.
ClickHouse
Con ClickHouse sólo hay Certificado CA y la casilla de aceptar sin verificar: ClickHouse entra con usuario y contraseña, así que el formulario no dibuja Certificado cliente ni Clave cliente, y un perfil que los traiga no conecta hasta que se quiten. Activar SSL pasa el puerto de 8123 a 8443 si era el de omisión. Con túnel SSH, el certificado se valida contra el host del perfil.
Oracle
Con Oracle sólo hay Certificado CA y la casilla de aceptar sin verificar: Oracle entra con usuario y contraseña por TLS en una sola dirección (TCPS), así que el formulario no dibuja Certificado cliente ni Clave cliente. Activar SSL pasa el puerto de 1521 a 2484 si era el de omisión: el listener sirve TCPS en otro puerto. El certificado se valida contra el host del perfil, también con túnel SSH y también con un CA propio: el nombre del servidor tiene que estar en el certificado. Si un perfil trae certificado o clave de cliente —importado, o heredado de otra familia—, la conexión no se abre y el error lo dice: quítalos del perfil.
Requiere Touch ID, Face ID u Optic ID antes de conectar a cualquier servidor.
Dónde está: Panel lateral › Ajustes › General › Seguridad
Calíope puede pedir la biometría del aparato antes de abrir cualquier conexión: Touch ID en el Mac y en los iPad que lo llevan, Face ID en el iPhone y en los demás iPad, y Optic ID en Apple Vision Pro. Es un interruptor de toda la app, no un ajuste de cada perfil.
Dónde se activa
- Ajustes › General › Seguridad › Requerir Touch ID para conectar (o Requerir Face ID para conectar, o Requerir Optic ID para conectar: el interruptor nombra la biometría que tiene el aparato), igual en todas las plataformas. Solo aparece si el dispositivo tiene biometría disponible.
Con él activado, Conectar pregunta primero, y si la autenticación falla la conexión no procede. Probar un perfil no pregunta. Revisa los permisos en Ajustes del Sistema › Touch ID y contraseña (Mac), Ajustes › Face ID y código o Ajustes › Touch ID y código (iPad y iPhone), u Ajustes › Optic ID y código (Apple Vision Pro).
Cómo agrupar tus conexiones (Producción, Desarrollo, Cliente X, etc.) y mover perfiles entre grupos en macOS, iPad, iPhone y Apple Vision Pro.
Dónde está: Gestor de conexiones › clic derecho › Mover a grupo
Cuando la lista de conexiones crece, puedes agruparlas por entorno, cliente o cualquier otro criterio. Los grupos son plegables y persisten en connections.json como colecciones ordenables.
Crear un grupo
- macOS: clic derecho sobre cualquier grupo existente (o sobre la cabecera de la barra lateral) y elige Nuevo grupo. Se crea con el nombre por defecto Nuevo grupo y entra directamente en modo de edición para que lo renombres.
- iPad, iPhone y Apple Vision Pro: en el Gestor de conexiones, toca Gestionar grupos (la carpeta con engranaje de la barra de abajo) y, en la hoja, Nuevo grupo.
Renombrar / eliminar
- macOS: clic derecho sobre el nombre del grupo → Renombrar grupo o Eliminar grupo.
- iPad: para renombrar, toca el lápiz de la fila en la hoja Gestionar grupos; para eliminar, desliza esa fila de derecha a izquierda. También puedes mantener pulsada la cabecera del grupo en la lista.
- Eliminar un grupo elimina también las conexiones que tiene dentro, con su contraseña guardada, su historial de consultas y el SQL que tuvieran guardado. Antes de borrar nada, Calíope pregunta y te dice cuántas conexiones se van y cómo se llaman. No se puede deshacer: si lo que quieres es deshacer la agrupación, saca antes los perfiles con Mover a grupo ▸ Sin grupo.
Mover un perfil
- macOS: clic derecho sobre el perfil → Mover a grupo ▸ → elige el grupo destino o Sin grupo para sacarlo de cualquier agrupación.
- iPad: desliza el perfil de izquierda a derecha para revelar la acción Mover (icono de carpeta, color índigo); se abre la hoja de selección de grupo.
Reordenar grupos (iPad)
- Abre Gestionar grupos y arrastra por el manillar ☰ para reordenar. El orden persiste en el campo sortOrder de cada grupo.
Expandir/plegar
- Cada grupo tiene un ▸ para plegar/expandir la lista de perfiles. El estado se guarda por grupo.
Persistencia
- Los grupos y su asignación viven en el archivo connections.json bajo el dispositivo actual. Si tienes activada la sincronización con iCloud, se comparten entre tus dispositivos.
Filtrar
- El campo de encima de la lista deja sólo las conexiones que coinciden; mientras tiene texto, todos los grupos se dibujan abiertos sin cambiar lo que guardaste (ver Filtrar la lista de conexiones).
Marca cada conexión como local, pruebas, producción o lo que necesites, con el nombre y el color que elijas, y mírala como una franja sobre cada herramienta.
Dónde está: Gestor de conexiones › clic derecho › Etiquetas de entorno…
Una etiqueta de entorno dice adónde apunta una conexión —local, pruebas, producción o lo que tú decidas— con un nombre y un color que eliges tú. Al conectar, la etiqueta se ve como una franja de su color encima de la herramienta, en todas las herramientas, y en el menú del servidor: antes de ejecutar nada ves en qué servidor estás.
El catálogo
- Las etiquetas viven en un solo catálogo, Etiquetas de entorno. Se abre con el botón Etiquetas de entorno… del formulario del perfil, al lado de Entorno, o desde el menú contextual de la cabecera Sin grupo o de la de cualquier grupo: clic derecho en macOS, mantener pulsado en iPad, iPhone y Apple Vision Pro.
- El catálogo nace vacío. Nueva etiqueta abre el formulario, y Empezar con ofrece tres plantillas de un toque: Local (verde, sin protección), Pruebas (ámbar, confirma lo que escribe) y Producción (rojo, confirma lo que escribe). Después cambias lo que quieras: Nombre de la etiqueta, Color y Protección.
- Arrastra las filas para cambiar el orden en que salen en el selector; en iPad, iPhone y Apple Vision Pro, toca antes Editar.
- Eliminar etiqueta pregunta antes y dice cuántas conexiones la usan. Esas conexiones se quedan sin etiqueta; no se borran.
Ponerle una etiqueta a un perfil
- En el formulario del perfil, el selector Entorno ofrece Ninguna y las etiquetas del catálogo. Las listas de conexiones del Gestor de conexiones y de Ajustes enseñan delante del nombre una muestra del color.
El nivel es de la etiqueta, no del perfil
- Cada etiqueta lleva un nivel de Protección: sin protección, confirma lo que escribe o solo lectura. Veinte conexiones con «Producción» toman de ella el nombre, el color y el nivel, así que cambiar la etiqueta las cambia a las veinte. Si una conexión necesita otro nivel, crea otra etiqueta. Qué hace cada nivel lo cuenta el tema «Niveles de protección».
- El grupo no hereda nada: grupo y etiqueta son independientes. Dentro del grupo «Cliente X» puede haber una conexión «Local», otra «Pruebas» y otra «Producción».
Dónde se guarda
- El catálogo se guarda en connections.json, junto a los grupos y los perfiles: viaja por iCloud Drive con ellos cuando la sincronización está activada, y la exportación de Ajustes › Conexiones lo lleva.
Qué hace el nivel de protección de cada etiqueta de entorno: ninguno, confirmar lo que escribe o solo lectura.
Dónde está: Gestor de conexiones › clic derecho › Etiquetas de entorno…
Cada etiqueta de entorno lleva un nivel de Protección que eliges en su formulario, en Etiquetas de entorno. El nivel es de la etiqueta: lo comparten todas las conexiones que la llevan.
Los tres niveles
- Sin protección: las sentencias se ejecutan como siempre; la etiqueta sólo marca la conexión con su franja.
- Confirma lo que escribe: antes de ejecutar algo que escribe, Calíope pregunta «¿Escribir en …?», con el origen y cuántas sentencias, y sólo sigue si pulsas Ejecutar en … con el nombre de la etiqueta. Pregunta una vez por ejecución: un script de veinte sentencias es una sola pregunta. Lo que ya tenía su propia confirmación —ejecutar el script completo, restaurar, borrar un objeto en Catálogos, terminar un proceso, borrar un usuario— lleva el nombre de la etiqueta en el título y no pregunta dos veces. Si hay una hoja abierta, la pregunta sale encima. Cancelar en el Editor SQL deja la consulta detenida; en otro sitio, un aviso dice que no se ejecutó porque cancelaste, y no va al registro de errores.
- Solo lectura: lo que escribe no se envía al servidor, y el error nombra la etiqueta. Además, las herramientas que sólo escriben —Constructor de tablas, Administración de usuarios, Mantenimiento de tablas y Migración de datos— no se ofrecen, y dentro de las demás no se dibuja lo que escribe: restaurar, reemplazar, importar, poblar, crear y borrar objetos, terminar procesos, editar y borrar filas de un resultado.
Qué cuenta como escritura
- Todo lo que no es una lectura ni control de transacción. Abrir, confirmar o deshacer una transacción y cambiar de base (USE) no escriben. SET sí, y también el control de transacción que pide READ WRITE: es lo que usaría una sesión para quitarse el solo lectura del servidor. Un bloque BEGIN … END cuenta como escritura.
- La comprobación lee el texto, no lo que hará el servidor: un SELECT que llama a una función con efectos, como SELECT nextval('s'), pasa como lectura.
- Deshacer o rehacer una edición de celda son escrituras nuevas, y con «confirma lo que escribe» preguntan cada vez.
Por dónde entra
- El Editor SQL —Ejecutar, el terminal y el SQL Player— y lo que el asistente de IA deja en el editor pasan por la misma comprobación. El asistente, además, conoce el nivel de la etiqueta y lo tiene en cuenta al proponer.
- El Modo seguro del Editor SQL va delante y no cambia: lo que bloquea no llega a la pregunta.
- Siri y Atajos no pueden enseñar la pregunta: con una etiqueta que confirma lo que escribe, una escritura por Siri no se ejecuta, y con una de solo lectura falla. El servidor MCP siempre fue de solo lectura.
- Una base vinculada en el editor y el destino de la Migración de datos los protege la etiqueta de su propio perfil.
- Reportes sólo lee. En una conexión de solo lectura, un reporte puede crear sus tablas temporales; nada más.
- Una alerta SQL cuya regla escribe no se ejecuta con una etiqueta que protege, en ninguno de los dos niveles.
La capa del servidor
En solo lectura, donde el motor sabe ponerse en solo lectura por sesión, Calíope se lo pide también: lo que escape a la comprobación lo rechaza el servidor.
MySQLMariaDBAurora
Cada conexión trabaja con SET SESSION TRANSACTION READ ONLY. El servidor rechaza con el error 1792 INSERT, UPDATE, DELETE, CREATE y DROP —también de una tabla temporal— y SELECT … FOR UPDATE. Deja pasar SET GLOBAL, KILL y FLUSH, que la comprobación de Calíope ya rechaza antes, y ANALYZE TABLE, que tampoco rechaza Calíope porque no cambia filas.
PostgreSQL
Cada conexión arranca con default_transaction_read_only = on. El servidor rechaza con el error 25006 lo que escribe, también una tabla temporal, SELECT nextval(…) y SELECT … FOR UPDATE: aquí se para la función con efectos que la comprobación deja pasar. Deja pasar ALTER SYSTEM, que Calíope rechaza antes, y SELECT pg_terminate_backend(…), que no rechaza ninguno de los dos. Un SET default_transaction_read_only = off apagaría la capa: por eso Calíope rechaza SET.
ClickHouse
Cada petición lleva readonly=2. El servidor rechaza con el código 164 INSERT, las mutaciones (ALTER TABLE … UPDATE), CREATE, DROP, TRUNCATE, OPTIMIZE y SYSTEM FLUSH LOGS. Deja pasar SET, la cláusula SETTINGS, KILL QUERY —Detener sigue funcionando— y las tablas temporales de un lote. SET readonly = 0 no puede apagarlo.
SQL Server
Sin capa del servidor: T-SQL no tiene un estado de solo lectura por sesión, y ApplicationIntent=ReadOnly sólo lleva a una réplica legible de un grupo de disponibilidad; contra un servidor suelto no impide nada. Protege la comprobación de Calíope.
Oracle
Sin capa del servidor: SET TRANSACTION READ ONLY vale para una transacción y termina en el siguiente COMMIT o ROLLBACK; no hay un equivalente por sesión. Protege la comprobación de Calíope.
Redis
Sin capa del servidor: Redis no tiene solo lectura por conexión (READONLY es otra cosa: deja leer de una réplica de un clúster). En la consola, qué escribe se lo pregunta Calíope al servidor, y lo administrativo que el servidor no marca —CONFIG SET, CLIENT KILL…— cuenta igual como escritura. El detalle está en el tema «La consola de comandos».
MongoDB
Sin capa del servidor: MongoDB no tiene solo lectura por conexión; lo que hay son los roles de la cuenta (read). Un comando de Comandos MongoDB se juzga con una lista de los que leen, y una agregación con $out o $merge escribe. El detalle está en el tema «Enviar comandos al servidor».
Lo que no es
Es una protección contra accidentes, no seguridad. La seguridad es un usuario de solo lectura en el servidor.
Palabras clave: protección, nivel, solo lectura, confirmar, escribir, entorno, etiqueta, producción
Escribe en el campo de encima de la lista para dejar sólo las conexiones que coinciden, por nombre, servidor o grupo.
Cuando tienes treinta o cuarenta perfiles, abrir un grupo ya no basta. El campo de arriba de la barra lateral deja sólo las conexiones que coinciden con lo que escribes.
Qué busca: el nombre del perfil, su servidor y su servidor alternativo, la base de datos por omisión, el nombre de usuario, el nombre del motor y el nombre de su grupo. Escribir el nombre de un grupo lo enseña entero — es la forma de decir enséñame producción. Las tildes y las mayúsculas no importan.
Mientras filtras, los grupos se abren solos, también los que tenías plegados, para que nada que coincida se quede escondido dentro de un grupo cerrado. Esa apertura no se guarda: vacía el campo y cada grupo vuelve exactamente a como lo dejaste.
La selección no se mueve. Si el perfil que estabas editando queda fuera del filtro, el formulario de la derecha sigue enseñándolo: perder lo que estabas editando por teclear en un buscador sería peor que el problema que el buscador resuelve.
Pulsa Esc o la × para limpiar el campo. El filtro no se recuerda al cerrar la app.
Qué es la familia, qué es el producto, y cómo Calíope propone el producto que el servidor dice ser al probar la conexión.
Dónde está: Panel lateral › Gestor de conexiones
Calíope agrupa los servidores por familia, que es el protocolo con el que habla: MySQL / MariaDB, PostgreSQL, SQL Server, Oracle Database, ClickHouse, MongoDB y Redis. Dentro de cada familia eliges el producto: el nombre concreto de lo que tienes delante.
Familias y productos
- MySQL / MariaDB: MySQL, MariaDB, Amazon Aurora MySQL y «Otro compatible con MySQL».
- PostgreSQL: PostgreSQL, Amazon Aurora PostgreSQL y «Otro compatible con PostgreSQL».
- SQL Server: Microsoft SQL Server.
- Oracle Database: Oracle Database.
- ClickHouse: ClickHouse.
- MongoDB: MongoDB y «Otro compatible con MongoDB».
- Redis: Redis.
Qué decide cada uno. La familia decide con qué motor se conecta Calíope y qué herramientas se ofrecen. El producto pone el nombre, el prompt de la terminal y los fragmentos que se siembran; Aurora MySQL, por ejemplo, trae los suyos. Un producto que no es el de referencia de su familia enseña un aviso en el formulario que lo recuerda; puedes ocultarlo con No volver a mostrar.
Crear el perfil
1. En Servidor (Tipo en iPad y iPhone), elige la familia.
2. En Producto, que en el Mac es el menú de al lado, elige el producto. Si el tuyo no está, elige «Otro compatible con…». Una familia de un solo producto —SQL Server, Oracle Database, ClickHouse, Redis— no enseña el menú Producto.
3. Rellena host, puerto, usuario y contraseña como siempre. Con Aurora, pega el endpoint del clúster y activa SSL/TLS.
El servidor dice quién es. Al pulsar Probar conexión o al cargar la lista de bases, Calíope le pregunta al servidor y, si se identifica como otro producto de la misma familia, lo propone bajo el selector: pulsa Usar … para corregir el perfil, o ignóralo. Nunca lo cambia por su cuenta. En MongoDB no se pregunta.
Nota
Las funciones propias de un producto (autenticación IAM de Aurora, endpoints diferenciados, métricas aurora_%) no se tratan de forma especial: Calíope maneja el servidor como uno estándar de su familia. Por eso un token de IAM entra como lo haría en MySQL 8 o en PostgreSQL: como contraseña en claro, que Calíope sólo envía con SSL/TLS activo. El token lo genera quien conecta, no Calíope.
SQL Server se conecta a la versión 2022 o posterior, siempre cifrado. Un perfil de SQL Server sincronizado con un aparato que todavía tiene Calíope 1.4 se enseña allí como MariaDB, porque esa versión no conoce la familia; abrirlo allí no funcionará hasta que ese aparato se actualice.
ClickHouse se conecta a la versión 25.3 o posterior por su interfaz HTTP —el puerto 8123, o el 8443 con TLS—, también a través de un túnel SSH. Un perfil de ClickHouse sincronizado con un aparato que tiene una versión anterior de Calíope se enseña allí como MariaDB; cuando ese aparato se actualice, se recupera eligiendo ClickHouse otra vez en el perfil.
Redis numera sus bases en vez de nombrarlas, así que el formulario pide un Número de base —de la 0 a la 15, salvo que el servidor se configure con más— y no tiene codificación ni colación. El Usuario es opcional: se entra con la contraseña sola, y el usuario sólo hace falta con usuarios ACL (Redis 6 o posterior).
Oracle Database entra a un servicio, no a una base: el formulario pide el Servicio —el SERVICE_NAME, FREEPDB1 en una instalación Free— en el puerto 1521, o el 2484 con SSL/TLS. Un SID no vale; escribe el nombre del servicio. Para saber cuál es, lsnrctl status en el servidor lista los servicios que escucha. Calíope se mide contra Oracle AI Database 26ai, la versión Free que Docker descarga sin cuenta; 19c y 23ai hablan el mismo protocolo, pero no están medidos. Se entra con usuario y contraseña, también por TLS en una dirección; no están la autenticación por token (OCI IAM, OAuth), Kerberos, la del sistema operativo ni el wallet con certificado de cliente —con Autonomous se entra por TLS sin wallet—. Un perfil de Oracle sincronizado con un aparato que tiene una versión anterior de Calíope se enseña allí como MariaDB; cuando ese aparato se actualice, se recupera eligiendo Oracle Database otra vez en el perfil.
Palabras clave: familia, producto, aurora, amazon aurora, aws, rds, mysql, mariadb, postgresql, mongodb, compatible, protocolo, detectar, tipo de servidor
Clonar copia el perfil elegido entero, con su contraseña, y deja el clon elegido para que le cambies lo que haga falta.
Clonar copia el perfil elegido entero —campos, grupo, etiqueta de entorno, y los archivos TLS y la clave SSH elegidos en este aparato— y su contraseña. El clon se llama como el original con «Copia de» delante, empieza con el contador de uso a cero y queda elegido para que le cambies lo que haga falta.
Está en la barra de la lista de conexiones, en el menú contextual de cada fila y, fuera del Mac, deslizando la fila.
Cargar datos del servidor pregunta al servidor qué bases, juegos de caracteres y cotejaciones tiene, para elegirlos de una lista en vez de escribirlos.
El botón de la flecha circular junto a la base de datos y al juego de caracteres, Cargar datos del servidor, pregunta al servidor qué bases, juegos de caracteres y cotejaciones tiene, para que los elijas de una lista en vez de escribirlos. Se apaga mientras falten el host o el usuario.
Si la base por omisión del perfil no está en el servidor, el formulario lo avisa. El juego de caracteres y la cotejación sólo salen en los motores que los usan al conectar: no en ClickHouse, Oracle ni Redis. Si el perfil va por un túnel SSH, la clave del bastión se pide igual que al conectar.
Palabras clave: base de datos, juego de caracteres, cotejación, servidor, cargar, perfil
Calíope avisa cuando el túnel SSH se cae y cuando se recupera automáticamente.
Dónde está: Calíope › Ajustes › General → Notificaciones
Cuando un perfil tiene Túnel SSH y Reconexión automática activados, Calíope envía notificaciones locales en dos momentos:
- Caída del túnel — al encontrar la conexión cortada, antes de intentar reconectar.
- Reconexión exitosa — cuando la reconexión recupera el túnel.
Las dos salen de la reconexión automática, y Calíope la intenta al cambiar la base de datos activa: una consulta que encuentra el túnel caído no avisa por aquí. Sin Reconexión automática no se envía ninguna.
Activar o desactivar:
Ve a Ajustes › General › Notificaciones y usa el interruptor Túnel SSH caído / reconectado.
Si la reconexión falla, no se envía la notificación de reconexión; la caída ya fue notificada. El intervalo mínimo entre notificaciones del mismo host es de 60 s.