6 comments

  • password4321 47 minutes ago
    Golang: https://github.com/xo/usql

    Reviewing the issues and PRs there provides a clue what to expect as this project matures.

  • wodenokoto 1 hour ago
    My biggest pain point with using different cli to connect to different databases is that they all do things like listing tables differently.

    Another nice feature one would want from such a program is of course auto complete.

    • data_ders 17 minutes ago
      Yeah for me standardization is the big win. But not just output formatting but cli commands and a guarantee that they’re as past as possible given that all the connectors use ADBC
  • whinvik 2 hours ago
    Sorry, just trying to understand. Why would I use this over duckdb. duckdb already has plugins for a lot of databases. Is the syntax the advantage?
    • f311a 2 hours ago
      ClickHouse also supports a lot of data sources and has a local mode where you just use a single binary with local-only access.

      Coincidentally, I wrote an article today on how I use it for similar scenarios. It can fetch from S3, multiple databases at once, and so on.

      And you get all the benefits of a database when you need to join or postprocess data from multiple sources.

      https://rushter.com/blog/clickhouse-data-processing/

    • data_ders 15 minutes ago
      I think the advantage is simplicity. Why connect first to duckdb and attach the db when you can query it directly with ADBC which is guaranteed to be fast
    • bunsenhoneydew 2 hours ago
      It’s going to have a very big hill to climb if it’s playing in a space where duckdb already has a hold. Duck has probably been my favourite technology find in the last few years. Awesome tech.

      I’ll still check this out though.

  • ifh-hn 1 hour ago
    This is excellent! I'm not a data engineer or SRE or whatever other commenters have mentioned. But part of my job is accessing data in various formats from various places, mostly offline. This in gonna be part of my toolset and I can pipe the output into other tools like nushell too.
  • aleda145 2 hours ago
    Cool! But as a data engineer I don't know when I would ever use this. Getting data into a centralized place so it can be joined and queried easily is like prio 1 for any data team.

    I'm sure SREs will really love me doing expensive adhoc queries against production postgres /s

    I've yet to work in enterprises big enough to have multi cloud data warehouses though, maybe it's more useful in that setting?

    • tonnydourado 1 hour ago
      As a consultant data engineer (ish), I think it has potential. You're right that any company doing data analytics is gonna be prioritizing a single source of truth and a unified platform, but each one will choose a different set of tools, which I'll have to learn, install, and even teach, for each new client. If I can use this to both explore AND implement stuff for clients regardless of their underlying database, that would be a pretty significant win.
      • aleda145 1 hour ago
        That's a great point! "Speed to insight" feels more important than ever
    • wodenokoto 1 hour ago
      Isn’t it useful for when you are getting things into a central DW?

      E.g, you don’t need a million tools to connect to the million different application databases when inspecting sources as part of setting up pipelines.

      • jnewton_dev 18 minutes ago
        Thanks for sharing — this clears up a misconception I've had for a while.
  • godisagirl 1 hour ago
    this is my first comment