This page describes Calíope 1.7, the version I am building right now. 1.6 is on the App Store for the Mac, iPad, iPhone, Apple Watch, Apple TV and Apple Vision Pro. The changelog says which version each feature landed in.
Adds an “Open in Calíope” button to every topic. It only works with the app installed.
In the Connection Manager, tap + in the left sidebar. Enter a descriptive name, the server family (the protocol it speaks) and the product within it, then host, port, user and password. The "Default database" field is optional.
The Environment row gives the profile one of your environment tags —None by default—, and Environment Tags… opens the catalog where you create them.
In the Server Options section you can configure the character set, collation, and enable SSL/TLS. If SSL is enabled, fields will appear to select the client certificate and key.
ClickHouse
With ClickHouse the section has no charset or collation, and no client certificate or key, and ticking SSL/TLS moves the port from 8123 to 8443 if it was the default, and back again when you untick it.
Oracle
With Oracle Database the database field is called Service and asks for the service name (SERVICE_NAME, FREEPDB1 on a Free installation), not a SID. The section has no charset or collation, and no client certificate or key, and ticking SSL/TLS moves the port from 1521 to 2484 if it was the default, and back again when you untick it.
MySQLMariaDBAurora
How it signs in. Calíope supports the five MySQL and MariaDB methods: caching_sha2_password (the default since MySQL 8), mysql_native_password, MariaDB's client_ed25519 and parsec, and mysql_clear_password, which sends the password in clear text and is therefore only used with SSL/TLS on: without it, Calíope does not send it and says so. It is the one PAM, LDAP and Aurora IAM authentication ask for. The method is set by the account on the server, not by the profile.
PostgreSQL
How it signs in. Calíope supports the three PostgreSQL methods that use a password: SCRAM-SHA-256 (the default since PostgreSQL 14), md5, and the clear-text password (password in pg_hba.conf), which is only sent with SSL/TLS on: without it, Calíope does not send it and says so. It is the one LDAP, PAM, RADIUS and RDS and Aurora IAM authentication ask for. Kerberos (GSSAPI) and SSPI are not supported: with a server that only allows those, the connection fails saying Calíope cannot use that method.
Keywords: profile, new connection, save server, host, configure, authentication, caching_sha2_password, mysql_native_password, ed25519, parsec, mysql_clear_password, SCRAM-SHA-256, md5, PAM, LDAP, IAM
Select the profile in the sidebar list. The form on the right loads with its current data and you can edit any field directly. There is no Save button: every change is saved as you make it.
Deleting a profile has a topic of its own, because it cannot be undone and takes more with it than you would expect: see Delete a connection.
The three places a profile can be deleted from, what goes with it, and why it cannot be undone.
Where it is: Sidebar › − button (delete connection)
Deleting a connection does not just remove its address and its username: it takes everything Calíope had saved about that server. That is why it asks first, and why the question says the connection's name — if it is not the one you thought, that is the moment to find out.
Where from
- macOS: select the profile and click − in the bar below the list, next to the +. Or right-click the row and choose Delete.
- iPad: select the profile and tap − in the bottom bar; or press and hold the row and choose Delete; or swipe the row from right to left. The swipe does not delete when you let go: it reveals the button, and the question comes all the same. Swiping the other way — left to right — is Move to group.
What goes with it
- The profile and all its data.
- Its password in the Keychain, and also its SSH password and the passphrase of its private key.
- Its query history, and its rows in the error log and in the server message log.
- The SQL it had saved in that connection's editor, and its schema cache.
It cannot be undone. There is no trash and no undo: the confirmation is the only chance to back out.
On your other devices. With iCloud sync on, the deletion travels and the connection disappears there too. The other way round nothing odd happens: a profile you created on the other machine that this one has not seen yet is not read as a deletion, so it is not removed on its own.
A whole group. Deleting a group also deletes the connections inside it, with the same question and the same reach; that is explained in Organizing profiles into groups.
How to use the alternate host when the server address depends on the device you connect from.
Where it is: Sidebar › Connections › Alternate host
The profile’s “Alternate host” field is for a server you can reach at two different addresses. The typical case is a development machine: from the computer itself it answers at 127.0.0.1, while from the iPad you have to use its address on the local network. Because profiles sync across your devices, a single host field cannot be right in both places.
When connecting, the main host is tried first. If it does not answer, the alternate one is tried with the same port, the same user, the same password and the same options: only the address changes. If you also need a different port, write “address:port” (for example, 10.0.0.20:3307).
When the session comes in through the alternate address, a marker appears next to the server name and “Test connection” reports which address answered, so you always know which machine you are working against.
With an SSH tunnel the field is ignored, and that is deliberate: there the server address is resolved by the tunnel machine, not by your device, so it does not change with where you connect from.
Keywords: alternate host, second address, local ip, local network, failover, 127.0.0.1, ipad, two addresses
When you need to write one, which fields Calíope stops using when you do, and where the password ends up.
Where it is: Sidebar › Connections › Connection string
The “Connection string” field only appears when the profile's engine is MongoDB, and it is optional. Leave it empty and Calíope builds the connection from the fields above: address, port, username, password, TLS and database. For an ordinary server that is enough.
Write one when the connection cannot be described with those fields. There are three cases: a replica set, which needs several addresses and the set's name; an authentication database other than the usual one, which is set with authSource; and an Atlas cluster, whose address starts with mongodb+srv:// and has no port to type. With mongodb+srv://, Calíope asks your system's DNS for the cluster's servers — the same one the rest of the device uses, VPN included.
When you write one, whatever the string says overrides the fields above: the addresses, username, password, whether TLS is used, and the options. Whatever it leaves out comes from the profile: if it has no username or password, the fields' ones are used, and if it names no database, the profile's one is used, or admin if there isn't one either. With several addresses and replicaSet, Calíope finds which member is the primary and works with it. Two things the string never decides. If the profile uses an SSH tunnel, the address comes from the tunnel and not from the string, because the server the string names is the one the tunnel machine sees, not your device. And certificates always come from the profile: the string can turn TLS on or off and ask for the certificate not to be verified, but the CA Certificate (.pem) and the Client Certificate (.pem) are chosen under SSL Certificates.
If the string doesn't say authSource, authentication goes against admin. That is where administrative accounts live and what both mongosh and Compass assume when someone just types a username and a password; if yours are in another database, say so with authSource.
Some options the string accepts and does not use. tlsCAFile and tlsCertificateKeyFile are ignored: they are paths to a file, and Calíope only opens files you choose yourself, so the certificate goes in the profile. Read and write options such as readPreference, w or retryWrites are accepted so that a string copied from Atlas works as is, but they change nothing in what Calíope does.
A warning about the password: the one in the field above is stored in the Keychain, but a password written inside the string is not. The string is saved with the rest of the profile and, if you have iCloud sync on, it travels with it. If that matters to you, leave the password in its own field and use the string only for everything else.
If the string is malformed the connection fails and says so: it is a form error, so it is fixed there rather than by retrying.
Tap Test connection in the profile form. Calíope attempts to open a real connection with the entered details and displays the result in a green banner (success) or red banner (error with description).
The test is especially useful for validating SSL credentials, firewalls, or host configurations before saving the profile.
Keywords: test, verify, check connection, test connection
Once the profile details are complete, tap the Connect button (lightning bolt icon). Calíope opens the connection pool with the engine's driver and loads the schema tree.
If the connection fails, a sheet opens saying what happened and what to check. View solution, when it appears, takes you to the topic of this Help that explains it, and Technical details shows the server's or the network's text, as is. The form repeats it in the box where the result of Test connection appears, as “Connection error: …”. Check the host, credentials, and that the server is running and reachable from your network.
Keywords: connect, open workspace, pool, connection
Switch the session's database from the schema panel.
Where it is: SQL Editor › Schema panel › Set as active database
In the SQL Editor's schema panel, right-click a database (on iPad, touch and hold it) and choose Set as active database. The session switches to it without reconnecting — it is the same as running USE database_name — and the server menu shows its name next to the server's. The change only affects the current session.
Oracle
With Oracle the tree lists schemas, not databases: a schema is a user, and the database is the service you connected to. Oracle has no USE: the schema you pick is the one where the editor resolves unqualified names, and each run sets it on the session, like ALTER SESSION SET CURRENT_SCHEMA. The profile does not change: its service stays the same.
Keywords: use database, change database, select database, switch database
Automatically reconnect if the server closes the session.
Where it is: Sidebar › Profile form › Auto reconnect
In the connection profile form, enable the Auto-reconnect toggle. Calíope uses it when you change the active database (Set as active database in the schema panel): if the connection is cut at that moment —the server closed it for inactivity or restarted, or the SSH tunnel dropped—, it reopens the whole session, tunnel included, and repeats the change.
It does not retry queries from the editor or the tools: the cut is shown as a connection cut.
With an SSH tunnel, that same moment is what triggers the tunnel dropped and reconnected notifications (see SSH tunnel notifications).
Work with multiple servers at the same time without losing context.
Where it is: Workspace › Server menu
Calíope supports having multiple active server connections at the same time. Each server has its own independent session with its own schema tree, open SQL tabs, query history, and AI assistant state.
How it works:
Every time you tap Connect in the Connection Manager, a new session is opened without closing the previous ones. All sessions coexist and you can switch between them without losing anything.
Each session's state:
- SQL tabs and their content are preserved when switching servers.
- The schema tree shows the databases of the active server.
- The AI assistant maintains its conversation history per session.
You can open as many sessions as needed — for example, to compare data across development, staging, and production environments simultaneously.
Keywords: multi-server, multiple connections, simultaneous, several connections, sessions, multiserver
Switch between connected servers from the Workspace dropdown menu.
Where it is: Workspace › Server menu
The server selector menu shows the active server name and a connection status indicator (green dot = connected, red = error). Tapping it opens a menu with all open sessions.
On macOS: the selector appears in the window toolbar, in the upper-left corner. It shows the server name, active database, and the dropdown arrow.
On iPad: the selector appears to the left of the tab bar, always visible at the top of the Workspace.
On iPhone: it is also at the top of the Tools list, so you can switch sessions, add a server or disconnect from any screen of the Workspace.
Menu options:
- Tap or click any server name to activate that session.
- The active session is marked with a ✓.
- Add server opens the Connection Manager over the current Workspace to connect another server without losing open sessions.
- Disconnect closes the active server's session.
Keywords: server menu, selector, switch server, switcher, active session, connection indicator
Connect to an additional server without leaving your current work.
Where it is: Workspace › Server menu › Add server
To add a new connection while already working on another server:
1. Open the server selector menu (in the window toolbar on macOS, the tab bar on iPad).
2. Choose Add server.
3. The Connection Manager opens: in a window of its own on macOS, as a sheet on iPad.
4. Select an existing profile or create a new one and press Connect.
5. The Connection Manager closes by itself and the new session is available in the selector.
Previous sessions remain open and intact throughout the process.
Keywords: add server, new session, second connection, connect another server
Close one server's session without affecting other active connections.
Where it is: Workspace › Disconnect
When you have multiple sessions open, you can close any of them independently:
Active server:
- Open the server selector menu and tap Disconnect, or use the red disconnect button in the toolbar.
Any session (switch to it first):
1. Open the server selector menu.
2. Select the server you want to close to activate it.
3. Tap Disconnect.
When a session is closed, Calíope automatically activates the last available session. If it was the only open session, it returns to the Connection Manager.
Keywords: disconnect server, close session, close connection, disconnect, remove server
Encrypt the connection to the server with SSL certificates.
Where it is: Sidebar › Profile form › SSL
In the connection profile form, enable the SSL toggle in the Server Options section. Three optional fields appear for client certificates:
- CA Certificate — certificate file from the Certificate Authority (.pem or .crt). Calíope uses this file to verify the server's identity.
- Client Certificate — the client's certificate file for mutual authentication.
- Client Key — the private key corresponding to the client certificate.
If you enable SSL without specifying a CA certificate, Calíope verifies the server certificate against the system trust roots (secure default). If the server uses a self-signed certificate, the connection will fail unless you provide the corresponding CA.
Accept untrusted certificate (insecure): enable this checkbox only if you connect to a development server with a self-signed certificate and cannot provide the CA. The connection remains encrypted but is vulnerable to man-in-the-middle attacks. Do not enable for production servers.
Where the file lives: when you choose a CA, a certificate or a client key — or paste it, away from the Mac — Calíope keeps its own copy on this device, never in iCloud Drive, and the profile points to that copy. You can move or delete the original afterwards, and on the Mac it is still read after relaunching. To renew a certificate, choose it again, even if it has the same name. The file stays on the device where you chose it, and so does its location: a profile set up on another device arrives without it. Before you connect, the connection list shows Choose its files on this device and the form says “This profile uses a certificate chosen on another device: choose it here.”; choose it there, and from then on that device keeps its own copy.
If a file cannot be read, Calíope does not connect without it: it stops with “Couldn’t read a TLS file”, naming the file and which of the three it is.
The SSL connection is tested when you tap Test connection; the green banner will confirm whether encryption is active.
ClickHouse
With ClickHouse there is only CA Certificate and the box to accept an unverified certificate: ClickHouse signs in with a user and password, so the form doesn't draw Client Certificate or Client Key, and a profile that carries them won't connect until they are removed. Turning SSL on moves the port from 8123 to 8443 if it was the default. Through an SSH tunnel, the certificate is checked against the profile's host.
Oracle
With Oracle there is only CA Certificate and the box to accept an unverified certificate: Oracle signs in with a user and password over one-way TLS (TCPS), so the form doesn't draw Client Certificate or Client Key. Turning SSL on moves the port from 1521 to 2484 if it was the default: the listener serves TCPS on another port. The certificate is checked against the profile's host, through an SSH tunnel too and with your own CA too: the server's name has to be in the certificate. If a profile carries a client certificate or key —imported, or inherited from another family— the connection doesn’t open and the error says so: remove them from the profile.
Require Touch ID, Face ID or Optic ID before connecting to any server.
Where it is: Sidebar › Settings › General › Security
Calíope can ask for the device's biometrics before opening any connection: Touch ID on the Mac and on the iPads that have it, Face ID on the iPhone and the other iPads, and Optic ID on Apple Vision Pro. It is one switch for the whole app, not a setting of each profile.
Where to turn it on
- Settings › General › Security › Require Touch ID to connect (or Require Face ID to connect, or Require Optic ID to connect: the switch names the biometrics the device has), the same on every platform. It only appears if the device has biometrics available.
With it on, Connect asks first, and if the authentication fails the connection does not proceed. Testing a profile does not ask. Check the permissions in System Settings › Touch ID & Password (Mac), Settings › Face ID & Passcode or Settings › Touch ID & Passcode (iPad and iPhone), or Settings › Optic ID & Passcode (Apple Vision Pro).
How to group your connections (Production, Development, Client X, etc.) and move profiles between groups on macOS, iPad, iPhone and Apple Vision Pro.
Where it is: Connection Manager › right-click › Move to group
As your list of connections grows, you can group them by environment, client, or any other criterion. Groups are collapsible and persist in connections.json as ordered collections.
Create a group
- macOS: right-click on any existing group (or on the sidebar header) and choose New group. It's created with the default name New group and enters edit mode immediately for you to rename.
- iPad, iPhone and Apple Vision Pro: in the Connection Manager, tap Manage groups (the folder with a gear in the bottom bar) and, in the sheet, New group.
Rename / delete
- macOS: right-click on the group name → Rename group or Delete group.
- iPad: to rename, tap the pencil on the row in the Manage groups sheet; to delete, swipe that row right to left. You can also long-press the group header in the list.
- Deleting a group also deletes the connections inside it, along with their saved passwords, their query histories and any SQL they had saved. Before deleting anything, Calíope asks, and tells you how many connections are going and what they are called. This cannot be undone: if what you want is to undo the grouping, move the profiles out first with Move to group ▸ No group.
Move a profile
- macOS: right-click on the profile → Move to group ▸ → choose the target group or No group to remove it from any grouping.
- iPad: swipe the profile left-to-right to reveal the Move action (folder icon, indigo color); the group selection sheet opens.
Reorder groups (iPad)
- Open Manage groups and drag with the ☰ handle to reorder. The order persists in each group's sortOrder field.
Expand/collapse
- Each group has a ▸ to collapse/expand its profile list. The state is saved per group.
Persistence
- Groups and their assignments live in the connections.json file on the current device. If iCloud sync is enabled, they are shared across your devices.
Filtering
- The field above the list leaves only the connections that match; while it has text every group is drawn open without changing what you saved (see Filtering the connections list).
Keywords: group, groups, organize, folder, category, production, development, move profile, drag, swipe, new group, rename, delete group, no group, connections.json
Mark each connection as local, staging, production or whatever you need, with the name and the color you choose, and see it as a band over every tool.
Where it is: Connection Manager › right-click › Environment Tags…
An environment tag says where a connection points — local, staging, production, or anything you decide — with a name and a color you choose. Once you connect, the tag shows as a band in its color above the tool, in every tool, and in the server menu: before running anything, you can see which server you are on.
The catalog
- Tags live in a single catalog, Environment tags. Open it with the Environment Tags… button in the profile form, next to Environment, or from the context menu of the No group header or of any group header: right-click on macOS, touch and hold on iPad, iPhone and Apple Vision Pro.
- The catalog starts empty. New tag opens the form, and Start from offers three one-tap templates: Local (green, no protection), Staging (amber, confirms writes) and Production (red, confirms writes). Then change whatever you like: Tag name, Color and Protection.
- Drag the rows to change the order in which the tags appear in the picker; on iPad, iPhone and Apple Vision Pro, tap Edit first.
- Delete tag asks first and says how many connections use it. Those connections are left without a tag; they are not deleted.
Tagging a profile
- In the profile form, the Environment picker offers None and the tags in the catalog. The connection lists in the Connection Manager and in Settings show a swatch of the color before the name.
The level belongs to the tag, not to the profile
- Each tag carries a Protection level: no protection, confirms writes, or read-only. Twenty connections tagged “Production” take its name, color and level from it, so changing the tag changes all twenty. If one connection needs a different level, create another tag. What each level does is explained in the topic “Protection levels”.
- A group inherits nothing: groups and tags are independent. Inside the group “Client X” there can be a “Local” connection, a “Staging” one and a “Production” one.
Where it is stored
- The catalog is saved in connections.json, next to the groups and the profiles: it travels through iCloud Drive with them when sync is on, and the export in Settings › Connections includes it.
What each environment tag’s protection level does: none, confirm what writes, or read-only.
Where it is: Connection Manager › right-click › Environment Tags…
Every environment tag carries a Protection level that you choose in its form, in Environment tags. The level belongs to the tag: every connection that carries it shares it.
The three levels
- No protection: statements run as usual; the tag only marks the connection with its band.
- Confirms writes: before running something that writes, Calíope asks “Write to …?”, with where it came from and how many statements, and goes on only if you press Run on … with the tag’s name. It asks once per run: a twenty-statement script is a single question. What already had its own confirmation —running the whole script, restoring, deleting an object in Catalogs, terminating a process, deleting a user— carries the tag’s name in its title and doesn’t ask twice. If a sheet is open, the question appears on top of it. Cancelling in the SQL Editor leaves the query stopped; anywhere else, a notice says it didn’t run because you cancelled, and it doesn’t go to the error log.
- Read-only: what writes isn’t sent to the server, and the error names the tag. On top of that, the tools that only write —Table Builder, User admin, Table maintenance and Data migration— aren’t offered, and inside the others what writes isn’t drawn: restoring, replacing, importing, populating, creating and deleting objects, terminating processes, editing and deleting rows of a result.
What counts as a write
- Everything that isn’t a read or transaction control. Opening, committing or rolling back a transaction and switching databases (USE) don’t write. SET does, and so does transaction control that asks for READ WRITE: it is what a session would use to take the server’s read-only off. A BEGIN … END block counts as a write.
- The check reads the text, not what the server will do: a SELECT that calls a function with side effects, like SELECT nextval('s'), goes through as a read.
- Undoing or redoing a cell edit are new writes, and with “confirms writes” they ask every time.
Where it applies
- The SQL Editor —Run, the terminal and the SQL Player— and what the AI assistant leaves in the editor go through the same check. The assistant also knows the tag’s level and takes it into account when it suggests.
- The SQL Editor’s Safe mode comes first and doesn’t change: what it blocks never reaches the question.
- Siri and Shortcuts can’t show the question: with a tag that confirms writes, a write through Siri isn’t run, and with a read-only one it fails. The MCP server was always read-only.
- A database linked in the editor and the target of Data migration are protected by the tag of their own profile.
- Reports only read. On a read-only connection, a report can create its temporary tables; nothing else.
- A SQL alert whose rule writes doesn’t run with a tag that protects, at either level.
The server layer
On read-only, where the engine can put itself in read-only per session, Calíope asks it to as well: whatever slips past the check, the server refuses.
MySQLMariaDBAurora
Every connection works with SET SESSION TRANSACTION READ ONLY. The server refuses with error 1792 INSERT, UPDATE, DELETE, CREATE and DROP —a temporary table too— and SELECT … FOR UPDATE. It lets through SET GLOBAL, KILL and FLUSH, which Calíope’s check already refuses first, and ANALYZE TABLE, which Calíope doesn’t refuse either because it changes no rows.
PostgreSQL
Every connection starts with default_transaction_read_only = on. The server refuses with error 25006 what writes, a temporary table too, SELECT nextval(…) and SELECT … FOR UPDATE: here the function with side effects that the check lets through is stopped. It lets through ALTER SYSTEM, which Calíope refuses first, and SELECT pg_terminate_backend(…), which neither refuses. A SET default_transaction_read_only = off would switch the layer off: that is why Calíope refuses SET.
ClickHouse
Every request carries readonly=2. The server refuses with code 164 INSERT, mutations (ALTER TABLE … UPDATE), CREATE, DROP, TRUNCATE, OPTIMIZE and SYSTEM FLUSH LOGS. It lets through SET, the SETTINGS clause, KILL QUERY —Stop still works— and the temporary tables of a batch. SET readonly = 0 can’t switch it off.
SQL Server
No server layer: T-SQL has no per-session read-only state, and ApplicationIntent=ReadOnly only routes to a readable replica of an availability group; against a standalone server it prevents nothing. Calíope’s check is what protects.
Oracle
No server layer: SET TRANSACTION READ ONLY holds for one transaction and ends at the next COMMIT or ROLLBACK; there is no per-session equivalent. Calíope’s check is what protects.
Redis
No server layer: Redis has no per-connection read-only (READONLY is something else: it lets you read from a cluster replica). In the console, Calíope asks the server what writes, and administrative commands the server doesn’t mark —CONFIG SET, CLIENT KILL…— count as writes anyway. The details are in the topic “The command console”.
MongoDB
No server layer: MongoDB has no per-connection read-only; what there is are the account’s roles (read). A command in MongoDB commands is judged against a list of the ones that read, and an aggregation with $out or $merge writes. The details are in the topic “Send commands to the server”.
What it isn’t
It is a protection against accidents, not security. Security is a read-only user on the server.
Keywords: protection, level, read-only, confirm, write, environment, tag, production
Type in the field above the list to leave only the connections that match, by name, host or group.
When you have thirty or forty profiles, opening a group is no longer enough. The field at the top of the sidebar leaves only the connections that match what you type.
What it searches: the profile's name, its host and its alternative host, the default database, the user name, the engine's name and the name of its group. Typing a group's name therefore shows that group whole — it is how you say show me production. Accents and capitals don't matter.
Groups open by themselves while you are filtering, including the ones you had collapsed, so nothing that matches can stay hidden inside a closed group. That expansion is not saved: clear the field and every group goes back exactly as you left it.
The selection doesn't move. If the profile you were editing falls outside the filter, the form on the right keeps showing it — losing what you were editing because you typed in a search box would be worse than the problem the box solves.
Press Esc or the × to clear the field. The filter is not remembered when you close the app.
What a family is, what a product is, and how Calíope proposes the product the server says it is when you test the connection.
Where it is: Sidebar › Connection Manager
Calíope groups servers by family, which is the protocol it speaks: MySQL / MariaDB, PostgreSQL, SQL Server, Oracle Database, ClickHouse, MongoDB and Redis. Within each family you choose the product: the specific name of what you have in front of you.
Families and products
- MySQL / MariaDB: MySQL, MariaDB, Amazon Aurora MySQL and "Other MySQL-compatible".
- PostgreSQL: PostgreSQL, Amazon Aurora PostgreSQL and "Other PostgreSQL-compatible".
- SQL Server: Microsoft SQL Server.
- Oracle Database: Oracle Database.
- ClickHouse: ClickHouse.
- MongoDB: MongoDB and "Other MongoDB-compatible".
- Redis: Redis.
What each one decides. The family decides which engine Calíope connects with and which tools are offered. The product sets the name, the terminal prompt and the snippets that get seeded; Aurora MySQL, for instance, brings its own. A product that is not its family's reference shows a notice in the form as a reminder; you can hide it with Don't show again.
Creating the profile
1. Under Server (Type on iPad and iPhone), choose the family.
2. Under Product, which on the Mac is the menu next to it, choose the product. If yours is not listed, choose "Other … compatible". A family with a single product —SQL Server, Oracle Database, ClickHouse, Redis— shows no Product menu.
3. Fill in host, port, user and password as usual. With Aurora, paste the cluster endpoint and enable SSL/TLS.
The server says who it is. When you press Test connection or load the list of databases, Calíope asks the server and, if it identifies itself as another product of the same family, proposes it below the selector: press Use … to correct the profile, or ignore it. It never changes it on its own. MongoDB is not asked.
Note
Product-specific features (Aurora IAM authentication, differentiated endpoints, aurora_% metrics) get no special treatment: Calíope handles the server as a standard member of its family. So an IAM token gets in the way it would on MySQL 8 or PostgreSQL: as a clear-text password, which Calíope only sends with SSL/TLS on. Whoever connects generates the token, not Calíope.
SQL Server connects to version 2022 or later, always encrypted. A SQL Server profile synced to a device that still has Calíope 1.4 shows there as MariaDB, because that version doesn't know the family; opening it there won't work until that device updates.
ClickHouse connects to version 25.3 or later through its HTTP interface —port 8123, or 8443 with TLS—, also through an SSH tunnel. A ClickHouse profile synced to a device with an earlier version of Calíope shows there as MariaDB; once that device updates, you get it back by choosing ClickHouse again in the profile.
Redis numbers its databases instead of naming them, so the form asks for a Database number —0 to 15, unless the server is configured with more— and has no encoding or collation. The Username is optional: the password alone signs in, and the user is only needed with ACL users (Redis 6 or later).
Oracle Database connects to a service, not to a database: the form asks for the Service —the SERVICE_NAME, FREEPDB1 on a Free installation— on port 1521, or 2484 with SSL/TLS. A SID will not do; enter the service name. To find it, lsnrctl status on the server lists the services it listens for. Calíope is measured against Oracle AI Database 26ai, the Free version Docker downloads without an account; 19c and 23ai speak the same protocol, but are not measured. You sign in with user and password, also over one-way TLS; token authentication (OCI IAM, OAuth), Kerberos, operating-system authentication and the wallet with a client certificate are not there —with Autonomous you sign in over TLS without a wallet—. An Oracle profile synced to a device that has an earlier version of Calíope shows there as MariaDB; once that device is updated, you recover it by choosing Oracle Database again in the profile.
Keywords: family, product, aurora, amazon aurora, aws, rds, mysql, mariadb, postgresql, mongodb, compatible, protocol, detect, server type
Clone copies the selected profile in full, with its password, and leaves the clone selected so you can change what you need.
Clone copies the selected profile in full —fields, group, environment tag, and the TLS files and SSH key chosen on this device— and its password. The clone is named like the original with “Copy of” in front, starts with its use counter at zero and stays selected so you can change what you need.
It is in the bar of the connection list, in the context menu of each row and, outside the Mac, by swiping the row.
Load server data asks the server which databases, character sets and collations it has, so you pick them from a list instead of typing them.
The circular-arrow button next to the database and the character set, Load server data, asks the server which databases, character sets and collations it has, so you pick them from a list instead of typing them. It is off while the host or the user is missing.
If the profile’s default database is not on the server, the form says so. The character set and the collation appear only for engines that use them when connecting: not for ClickHouse, Oracle or Redis. If the profile goes through an SSH tunnel, the bastion’s key is asked for just as when connecting.
Keywords: database, character set, collation, server, load, profile
Calíope alerts you when the SSH tunnel drops and when it reconnects automatically.
Where it is: Calíope › Settings › General → Notifications
When a profile has SSH Tunnel and Auto-reconnect enabled, Calíope sends local notifications at two moments:
- Tunnel dropped — when it finds the connection cut, before attempting to reconnect.
- Tunnel reconnected — when the reconnection restores the tunnel.
Both come from the automatic reconnection, and Calíope attempts it when you change the active database: a query that finds the tunnel down does not notify here. Without Auto-reconnect none is sent.
Enable or disable:
Go to Settings › General › Notifications and use the SSH tunnel dropped / reconnected toggle.
If the reconnection fails, no reconnection notification is sent; the drop was already notified. The minimum interval between notifications for the same host is 60 s.