I tried to identify the engine (Cassandra, Scylla, AstraDB, CosmosDB, Yugabyte, …) based on Cassandra Query Language (CQL). I focused on tables system.local and system.peers, see the sample:
SELECT release_version FROM system.local;
and
SELECT release_version FROM system.peers;
but I did not get relevant information about system/engine. Did you solved this problem?
1
FWIW, you can also run a show version; from within CQLSH, and it will provide all version information (also seen at CQLSH connect-time):
aaron@cqlsh> show version;
[cqlsh 6.1.0 | Cassandra 4.0.11-e373a428fd26 | CQL spec 3.4.5 | Native protocol v5]
None of the versions of Cassandra (or distributions) that I’m aware of report the type of “engine” it is.
In Apache Cassandra, the release_version is simply the release version, for example:
cqlsh> SELECT release_version FROM system.local;
release_version
-----------------
4.1.5
DataStax’s Astra DB report the release version as:
release_version
-----------------
4.0.0.6816
Without knowing your use case, I can’t think of a situation where reporting the distribution/fork would make sense because this is something you would already know in advance when you connect to the database.
For example, you need the secure bundle plus the application token to connect to Astra DB. This isn’t something required by other versions of Cassandra. Similarly, you would already know from the contact points that you are connecting to a ScyllaDB Cloud instance.
I can think of limited cases where you wouldn’t know up-front what kind of Cassandra fork or distribution you’re connecting to. Cheers!
1
Good question, I was surprised there isn’t a more organized, or at least documented, way to do this.
Regarding ScyllaDB, unfortunately if you do select release_version from system.local in ScyllaDB the result will not be useful: You will get back is “3.0.8” – which is some old Cassandra version which once-upon-a-time the Cassandra drivers expected in order to allow some features to be used correctly – see discussion in https://github.com/scylladb/scylladb/issues/8740. That discussion also mentions how you can get the ScyllaDB version:
SELECT version FROM system.versions WHERE key='local' ;
You can also recognize ScyllaDB as distinct from other CQL engines by noticing there are Scylla system tables; For example,
select table_name from system_schema.tables where keyspace_name = 'system' and table_name='scylla_local';
Will return a non-empty result only on ScyllaDB.
2