I'm the creator of dbcli. I can give you my perspective.
usql is a great tool if you're familiar with Postgres' psql client and wish you could use it for other databases like MySQL, Cassandra etc.
dbcli tools are designed to preserve the usage semantics of the existing tools but improve on them by providing auto-completion. For instance you can use `\d` in pgcli and `SHOW TABLES` in mycli. This was a conscious decision to make pgcli and mycli drop in replacements for of MySQL and psql. I was also working under the assumption that people rarely use multiple databases, you're either a postgres shop or a MySQL shop. If you have a mix of both, there is a good chance that not a single person is interacting with both of them on a daily basis. You have different teams using different databases. But my reasoning there could be flawed.
There is nothing stopping someone from adding an adapter to the usql tool to make it behave like MySQL (because they like the mysql client better) based on a command line argument, for instance.
As a data point, it seems to be reasonably common for people to use both SQLite + <some other database> (eg PG).
Probably because they have different use cases that don't overlap too much. eg SQLite is great for single file info storage and passing around. The others - being competing multi user servers - don't do that. :)
Up until very recently I used to regularly hop between sqlite3, Informix (don't hear much about that these days), MySQL (or compatible) and some key/value stores like Redis and memcache. Occasionally used to dip into MSSQL too but that wasn't often.
As what amjith said -- however, I personally find myself working with upwards of 3+ different databases in a single day. I may not be the use case, but eventually I realized it would have been easier to write a single, consistent client that works across all databases the same, as opposed to learning yet another broken, random client.
Since usql is written in Go, it compiles to a single static executable, and as such you don't need any extra dependencies. {pg,my,db}cli requires pip + python, which is usually broken on many systems that I've been an admin on. Also, good luck getting pip working properly on Windows. Also, since its written in Go, its likely significantly faster.
is usually broken on many systems that I've been an admin on. Also, good luck getting pip working properly on Windows.
I appreciate your point, but your experiences with pip + Python sound unusual and does not track with mine. I manage Windows and Linux machines with the Anaconda distribution, and pip works almost all the time. I don't think that argument should be deployed in this context.
Comments
How would this compare to DBCLI?
http://www.dbcli.com/
pgcli
https://www.pgcli.com/
mycli
https://www.mycli.net/
I'm the creator of dbcli. I can give you my perspective.
usql is a great tool if you're familiar with Postgres' psql client and wish you could use it for other databases like MySQL, Cassandra etc.
dbcli tools are designed to preserve the usage semantics of the existing tools but improve on them by providing auto-completion. For instance you can use `\d` in pgcli and `SHOW TABLES` in mycli. This was a conscious decision to make pgcli and mycli drop in replacements for of MySQL and psql. I was also working under the assumption that people rarely use multiple databases, you're either a postgres shop or a MySQL shop. If you have a mix of both, there is a good chance that not a single person is interacting with both of them on a daily basis. You have different teams using different databases. But my reasoning there could be flawed.
There is nothing stopping someone from adding an adapter to the usql tool to make it behave like MySQL (because they like the mysql client better) based on a command line argument, for instance.
As a data point, it seems to be reasonably common for people to use both SQLite + <some other database> (eg PG).
Probably because they have different use cases that don't overlap too much. eg SQLite is great for single file info storage and passing around. The others - being competing multi user servers - don't do that. :)
Up until very recently I used to regularly hop between sqlite3, Informix (don't hear much about that these days), MySQL (or compatible) and some key/value stores like Redis and memcache. Occasionally used to dip into MSSQL too but that wasn't often.
As what amjith said -- however, I personally find myself working with upwards of 3+ different databases in a single day. I may not be the use case, but eventually I realized it would have been easier to write a single, consistent client that works across all databases the same, as opposed to learning yet another broken, random client.
Since usql is written in Go, it compiles to a single static executable, and as such you don't need any extra dependencies. {pg,my,db}cli requires pip + python, which is usually broken on many systems that I've been an admin on. Also, good luck getting pip working properly on Windows. Also, since its written in Go, its likely significantly faster.
I appreciate your point, but your experiences with pip + Python sound unusual and does not track with mine. I manage Windows and Linux machines with the Anaconda distribution, and pip works almost all the time. I don't think that argument should be deployed in this context.