How to Use GlareDB: The Beginner’s Guide (First Query, the Federation Lesson, First Source, and the No-ETL Arc)

CodexFuse Team · 2026-11-02T13:21:37.227Z · 14 min read min read

GlareDB is the federated query engine that queries Postgres, Snowflake, BigQuery, and S3 in place with no ETL. This beginner’s guide covers install, your first local query, registering an external database, cross-source joins, the PRQL dialect, and the dbt arc.

What Is GlareDB, Exactly?

Learning how to use GlareDB starts with one idea: GlareDB is a database system that makes it easy to query distributed data without going through the pain of setting up ETL pipelines. The vendor puts it this way: "GlareDB is a cloud-based query execution engine that hooks directly into your data sources (databases, data warehouses, object storage) and makes it fast (like, really fast) to use a SQL-based interface to query across data sources" (glaredb.com/blog/introducing-glaredb).

The mental model that makes GlareDB click: it is a single pane of glass over your data — "it treats all of your data as if they were SQL-addressable, and as if they were all in the same place" (glaredb.com/blog/dbt-multiple-sources). Your data stays where it lives — Postgres, Snowflake, BigQuery, S3 — and you query it in place, including cross-source joins. No extract, no transform, no load. If you searched "glaredb tutorial" or "how to use glaredb", you are in the right place: this guide covers the federated query engine — not the storage-format demos and not the other GlareDB-named projects.

One fact to get right from the start: GlareDB went open source on June 2, 2023 (Sean Smith, "GlareDB Goes Open Source"), not recently — it is an MIT-licensed Rust project, created in 2022, with 1,025 stars and 55 forks on GitHub at the time of writing. The latest release is v25.6.3 (June 19, 2025), shipping binaries for Linux x86_64, Linux ARM64, and macOS ARM64. And because GlareDB also speaks a second query dialect, our PRQL beginner guide is the natural companion to this page — PRQL has been a supported dialect in GlareDB since v0.6.0.

How Do You Use GlareDB? A Beginner's 7-Step Arc

There is no simpler answer to "how to use glaredb" than this sequence. Follow it in order and you will have run your first federated query in under half an hour.

1. Install it. Run curl https://glaredb.com/install.sh | sh on Linux or macOS, or grab the binary for your platform from the GitHub releases page.
2. Query a local file first. Run glaredb local to drop into a shell, then point a query at a Parquet file. Zero setup, zero servers.
3. Register your first source. Use CREATE EXTERNAL DATABASE to attach your Postgres (or MySQL, Snowflake, BigQuery, MongoDB) to the GlareDB shell.
4. Run a cross-source join. Query the Postgres users table joined against Snowflake tracking data in one SQL statement — no data movement.
5. Switch dialects once. Run set dialect = 'prql'; to write pipeline-style queries, and set dialect = 'sql'; to come back.
6. Use the language bindings. Install pip install glaredb to query dataframes from Python, or npm install @glaredb/glaredb for Node.js.
7. Wire it into dbt. Point dbt's standard Postgres adapter at GlareDB's proxy and build models that span multiple sources — the NO-ETL arc.

How Do You Install GlareDB?

The short answer to every "glaredb install" search: run curl https://glaredb.com/install.sh | sh on Linux or macOS, or download the binary for your platform from the releases page in the GlareDB repository (glaredb.com/blog/glaredb-goes-open-source).

There are four install routes, and they serve different jobs. The install script is the fastest path to the CLI. The release binaries (glaredb-linux-x86_64, glaredb-linux-arm64, glaredb-macos-arm64 — v25.6.3 assets at the time of writing) are for air-gapped or pinned installs. The Python and Node bindings are for application code. And the managed route, console.glaredb.com, is a fully-managed deployment with a free serverless tier and a paid dedicated tier — no infrastructure of your own.

The binary gives you two modes. "Need to run adhoc queries on a local Parquet file? Run GlareDB using the glaredb local subcommand. This will drop you into a shell for running SQL commands" (glaredb.com/blog/glaredb-goes-open-source). Server mode is the other: "Run GlareDB in server mode using the glaredb server subcommand. This will spin up a deployment allowing any number of Postgres compatible clients to connect" — and yes, Postgres compatibility means your existing BI and visualization tooling works against it. If you plan to run server mode on your own infrastructure, our what VPS hosting is guide explains the hosting shape most small deployments use.

How Do You Query Your First Local File?

The answer: run glaredb local and query a Parquet file directly — no database to create, no server to start. The local subcommand drops you into a SQL shell pointed at nothing, and you run adhoc queries against files as if they were tables. This is the beginner's on-ramp the vendor itself documents, and it is the fastest way to feel GlareDB's model: the data does not move; the query comes to it.

A realistic first session looks like this: install with the script, run glaredb local, and run a SQL query over a local Parquet file. That is the whole ceremony. Once the shell feels familiar, you are ready for the step that actually defines GlareDB — attaching a live database and querying across sources without ETL.

How Do You Register an External Database?

The short answer: in the GlareDB shell, run CREATE EXTERNAL DATABASE with a FROM postgres (or mysql, snowflake, bigquery, mongodb) clause and your connection options. The vendor's own demo uses a public demo Postgres (glaredb.com/blog/introducing-glaredb):

CREATE EXTERNAL DATABASE my_pg FROM postgres OPTIONS (
  host = 'pg.demo.glaredb.com',
  port = '5432',
  user = 'demo',
  password = 'demo',
  database = 'postgres',
);

There is also a connection-string form, which the vendor documents for the same demo database: CREATE EXTERNAL DATABASE my_postgres FROM postgres OPTIONS( connection_string = 'postgres://demo:[email protected]:5432/postgres' ); (glaredb.com/blog/working-with-python).

The registration is a pointer, not a copy — GlareDB queries the source in place. That is the whole federation lesson in one command: you declare where the data lives, and GlareDB treats the tables inside it as addressable SQL tables. At launch the supported set was Postgres, MySQL, Snowflake, BigQuery, MongoDB, and Parquet and CSV files on S3 and GCS (glaredb.com/blog/introducing-glaredb) — so your first source is probably already on the list.

How Do You Run a Federated Query Across Sources?

The answer: reference each source's fully-qualified tables in one SQL statement and join them — GlareDB executes the query across the sources without moving the data first. This is the heart of "glaredb federated queries", and the vendor's own examples make it concrete. A Snowflake tracking table joined against a Postgres users table (glaredb.com/blog/introducing-glaredb):

SELECT *
  FROM my_snowflake.public.user_tracking AS t
  INNER JOIN my_postgres.public.users AS u ON t.user_id = u.id;

And a BigQuery metrics table joined against Postgres users (glaredb.com/blog/introducing-glaredb):

SELECT u.email, AVG(m.elapsed_compute_ns)
FROM bq.glaredb_prod.execution_metrics m
  INNER JOIN prod.public.users u ON m.user_id = u.id;

Notice what is missing: there is no CREATE TABLE, no staging schema, no nightly job. The joins name the sources as prefixes (my_snowflake, my_postgres, bq, prod) and GlareDB resolves each one against its registered external database. That single pattern — register sources once, join freely — replaces the ETL pipeline most analytics stacks are built around.

Which Data Sources Does GlareDB Support?

The vendor's documented set, from the launch materials (glaredb.com/blog/introducing-glaredb):

The Postgres compatibility deserves emphasis: "It's Postgres-compatible, and you can use your existing BI/visualization tooling" (glaredb.com/blog/introducing-glaredb). That compatibility is also what makes the dbt story work — you connect with dbt's standard Postgres adapter, not a GlareDB-specific one.

How Do You Switch Between SQL and PRQL in GlareDB?

The answer: run set dialect = 'prql'; in the GlareDB shell to switch to PRQL, and set dialect = 'sql'; to switch back. PRQL support shipped experimentally in GlareDB v0.6.0 (glaredb.com/blog/prql-announcement).

PRQL, in the vendor's own words, is "a domain-specific language for querying and transforming data, built around the metaphor of a pipeline" (glaredb.com/blog/prql-announcement). After setting the dialect, you write queries like FROM my_table | take 1 — each pipeline stage transforms the last, and GlareDB executes it the same way it would the equivalent SQL. In Python bindings the same switch looks like con.execute('set dialect = prql'): "All subsequent .sql() calls on this connection object will use PRQL, until the dialect is changed" (glaredb.com/blog/prql-announcement). If you have never seen the language before, our guide to the PRQL pipeline syntax teaches it from zero — and the pairing is worth learning, because it is the closest thing GlareDB has to a native feel.

One caution, once: the PRQL dialect arrived experimental, and the SQL dialect remains the primary, fully-supported one. Treat PRQL as the expressive option, not the default.

How Do You Wire GlareDB Into dbt?

The answer to every "glaredb dbt" query: point dbt's standard Postgres adapter at GlareDB — no GlareDB-specific adapter exists or is needed — and your dbt models can span Snowflake, BigQuery, Postgres, Parquet on S3, and even Excel files uploaded to GlareDB Cloud, without extraction or loading tools. As the vendor puts it: "with GlareDB and dbt, you can just stay close to the data" (glaredb.com/blog/dbt-multiple-sources).

The vendor's walkthrough, condensed to the load-bearing steps (glaredb.com/blog/dbt-multiple-sources): sign up for GlareDB Cloud; in the GlareDB SQL workspace, materialize the tutorial data with CREATE TABLE IF NOT EXISTS dbt_nyc_sales AS SELECT * FROM read_parquet('https://github.com/GlareDB/tutorial_data/raw/main/nyc_sales/...'); install dbt's Postgres adapter with pip install dbt-postgres; run dbt init my_glaredb_project; configure profiles.yml with type: postgres, host: proxy.glaredb.com, port: 6543, and dbname: org_name/deployment_name (note the connection-string quirk: glaredb://user_name:<password@org_name.proxy.glaredb.com>:6543/deployment_name); verify with dbt debug; then write models that reference GlareDB tables with {{ source('glaredb', 'dbt_nyc_sales') }}.

Cross-source models use the same two idioms you already learned: read_postgres('postgres://demo:[email protected]/postgres', 'public', 'borough_lookup') for a direct function read, or a registered external database with JOIN my_postgres.public.borough_lookup lookup (glaredb.com/blog/dbt-multiple-sources). The key architectural fact, once: "GlareDB is able to work with the Postgres protocol. This means that instead of needing a designated GlareDB adapter for dbt, you can instead connect to GlareDB using dbt's Postgres adapter" (glaredb.com/blog/dbt-multiple-sources). If dbt itself is new to you, our dbt beginner guide covers the model/test/docs workflow from the first command.

GlareDB vs Trino: What's the Difference?

The short answer: both are federated query engines that query multiple data sources without ETL, but GlareDB is a lightweight, Rust-built engine you can run locally or managed, while Trino is a heavier distributed system that is more work to operate. GlareDB is not Trino, and the vendor says the operational difference is the point: "You could also use something like Trino, which enables you to connect to multiple data sources without needing to configure those data extraction steps, but due to the way that Trino functions, it can still be quite laborious and complex to set up, debug, and maintain" (glaredb.com/blog/dbt-multiple-sources).

That is a vendor claim, so read it as one — but the shape is verifiable from the product itself: glaredb local queries a Parquet file with no cluster to stand up, whereas Trino assumes a coordinator plus workers. If your need is "query my Postgres and my warehouse from my laptop or one deployment", GlareDB is the smaller hammer; if your need is petabyte-scale distributed SQL with a team to run it, Trino's weight is the feature.

GlareDB vs DuckDB: What's the Difference?

The short answer: DuckDB is an embedded in-process database for local analytics; GlareDB is a server or cloud engine for querying data across many remote sources in place. GlareDB is not DuckDB, and the lineage is honest — GlareDB is built on Apache DataFusion, and team member Sean Smith explained the choice himself on the DataFusion mailing list: "The main alternative we looked at was DuckDB. But opted to go for it since it was written in C++ (not a bad thing, just I was much more familiar with Rust and I was focused on building a Rust team) and it seemed a bit less extensible than DataFusion for our needs" (mail-archive.com, DataFusion mailing list, via a 2026-11-02 search fetch).

Practically: DuckDB is what you embed in a process to query local files fast; GlareDB is what you point at your Postgres, Snowflake, and S3 so one SQL statement joins across all three. The two are complementary — GlareDB's own install flow even suggests DuckDB-adjacent local-dev patterns via Parquet. If you want the embedded side of the story, our DuckDB beginner guide starts from a single file and grows outward.

What Are the 7 Beginner Mistakes With GlareDB?

The seven ways beginners trip, all avoidable:

Sources

Every fact in this guide comes from a source fetched on 2026-11-02: the GlareDB vendor blog, the GlareDB GitHub repository, and the PyPI package page.

1. https://glaredb.com/blog/introducing-glaredb — vendor definition ("cloud-based query execution engine"), data-source list, CREATE EXTERNAL DATABASE syntax, Snowflake+Postgres and BigQuery+Postgres join SQL, Postgres compatibility
2. https://glaredb.com/blog/glaredb-goes-open-source — open-source announcement (June 2, 2023), glaredb local / glaredb server subcommands, binary download, Cloud free serverless and paid dedicated tiers
3. https://glaredb.com/blog/working-with-python — pip install glaredb, dataframe querying (con.sql("select * from df where fruits = 'banana'").to_pandas()), Postgres registration connection-string form
4. https://glaredb.com/blog/prql-announcement — PRQL dialect (experimental since v0.6.0), set dialect = 'prql' / set dialect = 'sql', curl https://glaredb.com/install.sh | sh
5. https://glaredb.com/blog/dbt-multiple-sources — dbt walkthrough (profiles.yml, dbt init, dbt debug, read_parquet/read_postgres, external-database joins), Trino comparison quote, single-pane-of-glass quote
6. https://api.github.com/repos/GlareDB/glaredb — MIT license, 1,025 stars, 55 forks, Rust, created 2022-05-27, "A light and fast SQL database for analytics"
7. https://api.github.com/repos/GlareDB/glaredb/releases/latest — latest release v25.6.3 (published 2025-06-19), binary assets (linux x86_64/ARM64, macOS ARM64)
8. https://pypi.org/project/glaredb/0.10.7/ — latest Python binding 0.10.7 (wheels uploaded April 21, 2025; via search listing)
9. https://glaredb.com/blog/node-bindings-announcement — npm install @glaredb/glaredb and Node usage (via search listing)
10. https://www.mail-archive.com/[email protected]/msg28623.html — Sean Smith (scsmithr) on choosing DataFusion over DuckDB (via search listing)
11. https://datamonkeysite.com/2023/09/24/glaredb-storage-format/ — third-party 2023 demo corroborating the DataFusion/Arrow/Delta assembly (via search listing)

Frequently Asked Questions

Is GlareDB open source?

Yes. GlareDB was open-sourced on June 2, 2023 under the MIT license. It is a Rust project (created 2022), with 1,025 stars and 55 forks on GitHub and a latest release of v25.6.3 at the time of writing.

What's the difference between GlareDB and Trino?

Both query multiple data sources without ETL, but they operate at different weights: Trino is a distributed engine with a coordinator and workers to stand up and maintain, while GlareDB can run as a single local shell (glaredb local) or a managed deployment. The vendor's own take is that Trino "can still be quite laborious and complex to set up, debug, and maintain" (glaredb.com/blog/dbt-multiple-sources).

Can GlareDB replace my dbt setup?

No — it pairs with it. GlareDB is the execution engine that runs the queries; dbt is the transformation layer that organizes them into models, tests, and docs. The vendor walkthrough runs dbt models directly on GlareDB by connecting dbt's standard Postgres adapter to GlareDB's proxy, so your dbt project gets multi-source models without a dedicated adapter.

Does GlareDB copy my data into itself?

No. Registration (CREATE EXTERNAL DATABASE) is a pointer, not a copy: GlareDB queries Postgres, Snowflake, BigQuery, and object storage in place. It treats all of your data "as if they were SQL-addressable, and as if they were all in the same place" (glaredb.com/blog/dbt-multiple-sources).

Can I write queries in PRQL instead of SQL?

Yes, experimentally: run set dialect = 'prql'; in the shell and write pipeline-style queries like FROM my_table | take 1, then set dialect = 'sql'; to switch back. PRQL support shipped experimentally in GlareDB v0.6.0, and SQL remains the primary dialect.