Quick reference

A one-page reference for running Dataglot: runtime options, the process topology, the dashboard, and auth modes.

Dataglot is a Rust-native federated SQL engine that queries across Postgres, MySQL, Oracle, Snowflake, Iceberg/lakehouse, object storage, and OData/REST — over the PostgreSQL wire protocol, with plan-time governance (column masks, row filters). No JVM.

Everything on this page assumes the prebuilt artifacts: stock release binaries and the container image ship with the dashboard and all pure-Rust connectors (postgres, mysql, iceberg, snowflake, odata, rest) enabled. A few extras are compile-time options (Oracle via the native OCI client, bring-your-own ADBC drivers) — see Building from source if you need those.

Runtime options

Every flag has a DATAGLOT_* env-var equivalent. Precedence: CLI > env > config file > default.

Subcommands: dataglot init (write a starter config) · dataglot query "<SQL>" (one-shot, in-process, no server) · dataglot shell (REPL) · dataglot completions.

Binaries & topology

How the binaries interact in distributed mode (single-node = the same server with the scheduler + one in-process executor, no external workers):

   psql / JDBC / BI tool          dataglot-testbench
   (any pg client)                (dev dashboard + load-gen)
           │                              │
           │  pgwire (SQL, :5432)         │  pgwire + reads status
           └──────────────┬───────────────┘
                          ▼
        ┌───────────────────────────────────────────┐
        │  dataglot            (dataglot-server bin)  │
        │  pgwire · query planner · policy            │
        │  cluster scheduler   (in-process)           │
        └───────┬───────────────────────────┬─────────┘
        dispatch│ register  gRPC :50051      │ status  REST :50050
                ▼                            ▼
    ┌───────────────────────┐   ┌───────────────────────┐
    │ dataglot-ballista-    │◄─►│ dataglot-ballista-    │
    │ executor  (worker 1)  │   │ executor  (worker N)  │
    └───────────┬───────────┘   └───────────┬───────────┘
       Arrow Flight shuffle between workers (:50061/50071 …)
                │                            │
                │  federated scans (each worker connects to sources)
                ▼                            ▼
        ┌─────────────────────────────────────────────┐
        │ Sources: Postgres · MySQL · Oracle ·         │
        │ Snowflake · Iceberg/lakehouse · object store │
        │ · OData/REST                                 │
        └─────────────────────────────────────────────┘

• dataglot — the only user-facing binary: pgwire ingress, planning, policy enforcement, and (with a [ballista] config block) the in-process scheduler. Single-node servers do the source scans themselves.
• dataglot-ballista-executor — external worker; registers with the scheduler (gRPC), runs plan stages, connects to the federated sources directly (hence its own catalogs config), and shuffles intermediate data to peer executors over Arrow Flight.
• dataglot-ballista-scheduler — standalone scheduler binary, optional: the server already hosts one in-process, so it's only for a fully-external cluster deployment.
• dataglot-testbench — internal tooling, not part of the public repository and not something you can build from it. Shown here only because it appears in the diagram above: it connects over pgwire like any other client and reads the server's status/REST API. Nothing in the engine depends on it.

Dashboard

The operational dashboard is served by the engine at http://127.0.0.1:9090/ui — cluster, running queries, sessions, governance/security posture, connector health, query history. Served out of the box by stock release binaries and the container image (for local source builds it's a compile-time option — see Building from source). Bound at --metrics-addr (default :9090); Prometheus metrics at :9090/metrics.

Auth modes

Selected by the [auth] mode config key (full detail: authentication).

Options:

• Identities (md5/scram): declared under identities in config; the password is never in the file — password_env names an env var read at boot. Optional org and groups.
• Runtime users: CREATE USER … WITH PASSWORD '…' adds identities live (no restart; stored encrypted in the meta store — needs DATAGLOT_SECRET_KEY).
• Multi-org: identities carry an org; usernames are globally unique; sessions are org-scoped.
• TLS: add a [pgwire_tls] block with mode = "require" to encrypt the session. The server warns if a password mode runs without ingress TLS.
• Groups / LDAP: groups drive group-conditional masks/row-filters and can be populated from LDAP/IdP.

Note. Authorization (what an authenticated user may see — masks, row filters, GRANT/REVOKE) is separate; see access control and runtime configuration.