This page describes Calíope 1.5. It is the version I am building right now; 1.4 is on the App Store on every device, the Mac included. So the 1.5 items below are listed as shipped because they are finished in the version I am building, but you cannot download them until 1.5 reaches the App Store.
Calíope grows from three things: what arrives through support, the diagnostic reports people choose to share, and daily work against real databases. This page says where each item stands — including the ones I decided not to build, with the reason, because a roadmap that only lists promises is not telling you much. Something missing? Suggest a feature.
🟡 Under consideration
— weighing scope, technical fit and demand. No date implied
More engines: the seam is already in place
Under consideration
Adding an engine to Calíope is implementing a set of protocols, not editing the tools. That work is done and proven: the backup engine, the schema comparator and the error catalogue already run through it, and no engine name is written anywhere outside its own folder — not even in the five translation files. PostgreSQL was the first engine to arrive that way, in 1.3, without a single tool being rewritten. SQL Server followed the same way in 1.5; which engine comes next is still being weighed.
Groundwork in 1.2 · first new engine in 1.3
Redis
Under consideration
An in-memory key-value store, which is a different shape from a table: a key browser with the patterns you actually type, the time to live of each key visible and editable, a viewer that draws every value by its type — string, list, set, sorted set, hash, stream — and a server panel with memory, keyspace and clients. There is no SQL here, so it would arrive as its own tool, the way MongoDB did.
ClickHouse
Under consideration
Columnar analytics on a server, over its HTTP interface. What it adds is the scale a row-oriented engine does not reach: aggregations over billions of rows, and materialized views that keep the expensive part precomputed. It reuses the SQL editor and the schema browser, with its own dialect and its own vocabulary for what a table is made of. Columnar analytics in a local file arrived with the DuckDB Editor in 1.5; ClickHouse would bring the same shape to a server, and Redis would add key-value.
More interface languages
Under consideration
Calíope ships in five: English, Spanish, French, German and Italian. Portuguese and Japanese have both come up. Tell me which one you would like next — the app is fully translated rather than machine-localised, so each new language is real work and I would rather do the right one.
🔴 Not planned
— decided against, with the reason. These stay visible on purpose
Encrypted SQLite databases (SQLCipher)
Not planned
The SQLite Editor opens unencrypted databases only. Supporting SQLCipher means shipping and maintaining a fork of SQLite inside a sandboxed App Store app, and the tool is meant for inspecting Core Data stores and embedded application databases, which are not encrypted.
Reason: scope and maintenance
Your location on the spatial map
Not planned
Showing where you are would require a location permission and a matching entry in the App Store privacy label, in exchange for something this tool does not need: what matters on the map is where your data is, not where you are.
Reason: privacy cost with no benefit
Probing both addresses before connecting
Not planned
It would be tempting to test the main and the alternate host in parallel and pick the fastest. Opening and dropping TCP connections without completing the handshake increases aborted_connects on the server and can end in Host is blocked because of many connection errors. The failover happens on the real attempt instead.
Reason: it harms the server you are trying to reach
MongoDB through the relational layer
Not planned
MongoDB is a self-contained tool with its own session and its own set of tabs, not a new engine behind the existing ones. The relational abstraction models foreign keys, binlogs, replication and EXPLAIN; a document database would leave most of that empty, and every tool would have to start asking what kind of session it is looking at.
Reason: it would be the wrong shape
🟢 Shipped recently
— the three most recent; the full list is in the changelog
SQL Server
Shipped
Microsoft SQL Server, through the same seam PostgreSQL came through and over a driver I wrote from the protocol Microsoft publishes. Connection profiles, schema browser with its schemas, SQL editor with its own snippets, keywords and function reference, visual EXPLAIN, backups and restores, maintenance, logins and permissions with DENY shown as such, and server monitoring. Version 2022 or newer, always encrypted. Replication stays a MySQL and MariaDB matter, and what the engine does not have is hidden rather than greyed out.
Version 1.5
DuckDB Editor
Shipped
A second local engine compiled into the app, next to the SQLite Editor and with no connection to set up. Open a .duckdb file with no server to install, or query a Parquet, CSV or JSON where it already is — nothing is imported and nothing is copied. Schema tree with sequences, types and macros, data grid, SQL with a row cap and Stop, SUMMARIZE, whole-database export and import, attaching another database read-only, and DuckDB files as a source for Reports.
Version 1.5
Calíope on your iPhone
Shipped
Calíope lays itself out for the phone and installs from the same App Store page as the Mac and the iPad. It is the whole client, not a viewer: it connects to your servers and runs your queries, with the same tools as the iPad and no device check anywhere in the tree. Your profiles, snippets, history and assistant conversations arrive through your own iCloud, and when that switch is closed it names it instead of showing an empty screen and letting you conclude there is nothing wrong.
Version 1.4
