Sq.io: jq for databases and more

Original Article ↗ Hacker News Discussion ↗

A new command-line tool called sq aims to bring jq-style, pipeable querying to databases and structured files, letting users inspect schemas, diff database metadata, and export or transform data into formats like JSON and CSV. Commenters are split on whether this adds enough value beyond standard SQL clients and tools such as psql, DuckDB, or clickhouse-local, especially for complex joins and large schemas. The exchange surfaces a broader tension between learning SQL directly versus adopting higher-level abstractions and alternative query languages to simplify day-to-day data wrangling.

Overview & Purpose of sq.io

  • Command-line tool “sq” (pronounced “seek”) aims to be “jq for databases and more.”
  • Provides a unified way to query and transform data from relational DBs and file formats (CSV, JSON, Excel, etc.).
  • Uses its own query language (SLQ, “sleek”) but also allows running raw SQL (sq sql).

Key Features Highlighted

  • Easy export of DB rows to JSON / JSONL / CSV without verbose SQL constructs.
  • Schema and metadata inspection (sq inspect) across databases, which some find hard in standard CLIs.
  • Ability to diff schemas/metadata between DB instances (sq diff @pg_prod @pg_qa).
  • Treats non-DB sources (CSV, JSON stdin) as queryable data sources.
  • Keeps connection state in a config file for convenience.

Use Cases vs Existing Tools

  • Supporters like it for:
    • Quick CLI munging, ad‑hoc queries, log-style formatting.
    • Lightweight alternative to heavier GUIs and DB-specific CLIs.
  • Critics argue:
    • Anything shown can be done with SQL + tools like psql, jq, DuckDB, clickhouse-local, OctoSQL.
    • DuckDB and others already support many data sources and SQL over JSON/CSV.
    • For complex joins and queries, users would rather write SQL directly.

JQ / SLQ vs SQL Debate

  • Some users like jq-style, pipeable, incremental query building and want one mental model across JSON and DBs.
  • Others dislike jq’s syntax, find it hard to learn/maintain, and prefer SQL or SQL-like languages for JSON instead.
  • Several note PRQL, KQL, nushell, and similar “pipe” or higher-level query syntaxes as related directions.

Critiques & Concerns

  • Perceived as yet another “thin abstraction” that may add complexity instead of just learning SQL.
  • Concerns about statefulness, naming clash with another “sq,” and jq/SLQ scripts being hard to read.
  • Some feel the innovation bar for replacing mature SQL workflows is high; others welcome experimentation regardless.

General Sentiment

  • Mixed but engaged: enthusiasm from people who like jq/pipes and CLI tools; skepticism from those who favor standard SQL and existing ecosystems.