Calíope app icon

Roadmap

What is being built, what is being weighed, what I have decided not to build, and what has just landed.

This page describes Calíope 1.7. It is the version I am building right now; 1.6 is on the App Store on every device, the Mac included, so everything listed below as shipped in 1.6 can be downloaded; what is marked 1.7 comes with the next update.

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.

Status legend · jump to a section

🟣 In progress — committed and underway

Live Activities and the Dynamic Island

In progress

A backup — a scheduled one included —, a restore or a long query will show its progress live on the iPhone’s Lock Screen and Dynamic Island, and on the Apple Watch: the tables already processed, what is left, and a warning the moment something fails. It builds on the backup scheduler and the SQL alerts Calíope already has, so a long job can be followed without staying on its screen.

1.7 · iPhone and Apple Watch

A 3D ER diagram on Apple Vision Pro

In progress

Tables become cards in the space around you and foreign keys become lines between them; you pick them up and move them with your hand, and each schema can sit on its own layer. It builds on the native visionOS version that arrives with 1.6: a schema with dozens of tables is easier to read when it has room to spread out.

1.7 · Apple Vision Pro

Cassandra and ScyllaDB

In progress

A new engine with its own tool, the way MongoDB and Redis are. It needs a driver for Cassandra’s native protocol (CQL), which I will write from the public Apache Cassandra specification, like every other driver in Calíope. ScyllaDB speaks the same protocol, so one driver serves both.

1.7 · New engine · its own tool and its own driver

Elasticsearch and OpenSearch

In progress

Their own tool, over HTTP or HTTPS as ClickHouse is. The client will be written only from the official REST API specification, without borrowing from Kibana or other tools. OpenSearch began as a fork of Elasticsearch, and the tool will cover both.

1.7 · New engine · its own tool, over HTTP

Japanese interface

In progress

Japanese will be the sixth interface language, translated in full like the other five rather than machine-localised.

1.7 · Sixth language
🔵 Planned — decided, with the reason; work has not started yet. No date implied

Masked backups

Planned

One more option in Backup to take a copy with personal data replaced by fake but realistic values, meant for development and testing.

Probably in 1.8 · in Backup

Automatic backup verification

Planned

After each backup, Calíope would restore it on a test connection you choose, check that it is complete and delete it.

Probably in 1.8 · in Backup

Schema change audit

Planned

A record of every CREATE, ALTER and DROP, with who and when, that also flags changes made outside Calíope.

Probably in 1.8 · in Query log

Live lock analysis

Planned

See who is blocking whom right now and end the session causing the block, with a history of deadlocks.

Probably in 1.8 · in Process list

User security review

Planned

A button that reviews account privileges and tells you what is worth fixing, without changing anything on its own.

Probably in 1.8 · in User admin
🟡 Under consideration — weighing scope, technical fit and demand. No date implied

Portuguese interface

Under consideration

Portuguese as the seventh interface language, after Japanese.

Seventh language
🔴 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

Quick Look for database and data files

Shipped

Select a .sqlite, .duckdb or Parquet file in the Finder and press the space bar, or tap it in the Files app on the iPad and the iPhone, and you see its tables, their columns with types and their first 20 rows without opening Calíope. On the Mac, TSV files too; CSV files keep the system’s own preview. The extension reads with the DuckDB engine the app already carries — shared with it, not a second copy —, never writes to the file, and if it runs out of time after about three seconds it says so. Apple Vision Pro has no Quick Look preview from Calíope: visionOS does not load other apps’ preview extensions. More in the Help.

Version 1.7 · Mac, iPad and iPhone

TiDB

Shipped

TiDB joins through the MySQL engine Calíope already speaks, and what TiDB does not have is hidden rather than greyed out: no triggers, routines, events, binary log or replication monitor, but sequences in Catalogs and AUTO_RANDOM and clustered keys in the Table Builder. What works differently follows TiDB: the slow query log reads SLOW_QUERY, with its threshold in milliseconds, and STATEMENTS_SUMMARY; the visual EXPLAIN reads TiDB's own plan and its index advisor proposes from it; the Dashboard shows what TiDB publishes over SQL and n/a for the rest; and the SQL Editor has TiDB's reserved words and function reference. Test connection recognizes TiDB and offers “Use TiDB”. Ten TiDB chapters in the DBA Handbook. TiDB 8.5 and newer.

Version 1.7

Valkey

Shipped

Valkey joins through the client written for Redis, with its seven tools: Keys, Server, Memory, Slow Log, Clients, Console and Topology, cluster included. The Server panel shows Valkey's own version and mode, the Console prompt says valkey>, and Test connection recognizes Valkey and offers “Use Valkey”. Snippets, Reports and the AI Assistant work with Valkey too. The twelve Redis chapters of the DBA Handbook say where Valkey differs, and a new chapter sums it up. Valkey 8.0 and newer.

Version 1.7

How this roadmap works

In progress means I have committed and work is underway.

Planned means I have decided to build it and say why; work has not started yet. No delivery date is implied.

Under consideration means I am weighing scope, technical fit and demand. No delivery date is implied.

Not planned means I decided against it. The entry stays visible with its reason, so the decision is transparent rather than silent.

Shipped means it is in the app today. The version it landed in is on each entry — and note that the newest version may not be on the App Store yet; the notice at the top says which one is.

Looking for the full list of what has shipped? See the changelog →