Gluesync Module · SQL on your data lake

Lake queries

Query Parquet, CSV and JSON files in your data lake with SQL, in place. The lake engine embedded in Core Hub, built on DuckDB, makes the file agents you already run queryable from Query Studio and Query Forge.

Explore Lake queries Talk to our team
Lake queries
Query Studio
  1. SELECT status,
  2. count(*) AS orders,
  3. sum(total) AS revenue
  4. FROM parquet('orders/2026/*.parquet')
  5. GROUP BY status
  6. ORDER BY revenue DESC;
4 rows · 212 ms · read-only
statusordersrevenue
DELIVERED48,2156,914,480.55
SHIPPED3,902571,206.10
OPEN1,147160,935.40
CANCELLED61874,511.85
  1. 01 Point at the file agents you already run
  2. 02 Query Parquet, CSV and JSON in place
  3. 03 Join the lake with live databases

Why Lake queries

Your lake should answer in SQL, not after another load

01 / Copy first

Files must move before anyone can ask

Data lands in the lake, then gets loaded into a warehouse or a database just so someone can check a count, inspect a row or run a join. Every question waits for another load.

02 / Side engines

Another engine, another key

A separate query service or a notebook cluster needs its own setup and its own copy of storage credentials. It also sits outside the roles and masking that govern the rest of your data.

03 / The platform outcome

The lake is part of the platform

The lake engine embedded in Core Hub reads your files where they are, through the agents and permissions Gluesync already manages. Ask the lake a question right after the pipeline writes.

How it works

From landed files to answers in three steps

  1. 01

    Point

    Use the agents you already run

    Pick the S3, S3-compatible, WebDAV or NFS agent that already lands your data. It appears in the Query Studio connection picker with the credentials it already holds.

  2. 02

    Query

    Datasets by name, files by path

    Select a dataset like a table, or read any file with parquet(), csv() and json(), globs included. Use files() to see what a folder holds.

  3. 03

    Join

    Lake and live data in one query

    Through Query Forge, join lake datasets with live databases in one federated query from any JDBC client or BI tool.

Capabilities

SQL over the files Gluesync lands, and any file next to them

Lake queries run on a read-only lake engine embedded in Core Hub, based on DuckDB. It is not a new agent and there is nothing to configure: the agent's file type decides how each file is read.

Query Studio

Your lake in the SQL workbench

Datasets as tables, any file by path

Pick a lake-enabled agent in the connection picker and the schema browser shows schema default, with one table per dataset and columns read from the files. JSON can be a single document, an array, or one document per line. CSV files Gluesync wrote keep the types from the entity definition, so leading zeros, NULLs and exact decimals survive.

  • S3, S3-compatible (such as MinIO), WebDAV and NFS agents in the Query Studio connection picker
  • Every replicated entity is a table under schema default, with columns and types read from the files
  • parquet(), csv() and json() with paths relative to the store and globs, plus files() to list a folder
  • Full read-only SQL: joins, CTEs, window functions, UNION and subqueries, including joins between your own CSV and a replicated dataset
  • The existing result grid, with export to CSV, XLSX and JSON

View Query Studio docs ↗

Lake queries
Query Studio
  1. SELECT status,
  2. count(*) AS orders,
  3. sum(total) AS revenue
  4. FROM parquet('orders/2026/*.parquet')
  5. GROUP BY status
  6. ORDER BY revenue DESC;
4 rows · 212 ms · read-only
statusordersrevenue
DELIVERED48,2156,914,480.55
SHIPPED3,902571,206.10
OPEN1,147160,935.40
CANCELLED61874,511.85

Every version, not just the latest

Parquet and CSV change files keep every version of a row, and deletes appear as rows with _operation = 'D'. Query the history of an order, not only its current state. Snapshot and change files are combined by column name, so one query reads both.

Query Forge

Lake and live databases in one query

Lake datasets alongside every agent on jdbc:gluesync://

Query Forge exposes lake datasets on the same jdbc:gluesync:// connection as every other agent. BI tools address them by dataset name, like any table, and join them with live databases. For file-by-file exploration, open the same agent in Query Studio.

  • Lake datasets appear as "<catalog>"."default"."<dataset>" next to your live databases
  • Join a lake dataset with a live source such as PostgreSQL in one federated query
  • Works from any JDBC client or BI tool connected to Query Forge
  • Personal API Token scopes decide which agents each caller sees

View Query Forge docs ↗

Federated SQL · a lake dataset joined with a live database

JDBC clientjdbc:gluesync://corehub:8765

SELECT a.name, SUM(o.total) AS revenue_2026FROM "orders_to_lake"."default"."orders" oJOIN "crm_replication"."public"."accounts" a  ON a.account_id = o.customer_idGROUP BY a.name
  • Larchmont Outfitters418,905.20
  • Harbourline Foods196,744.80
  • Brightwater Clinics181,060.15
Core HubOne JOIN across the lake and the live databaseThe lake engine embedded in Core Hub reads the files in place · nothing copied
  1. AWS S3Lake dataset · Parquet, read in place"orders_to_lake"."default"."orders"
  2. PostgreSQLLive source database"crm_replication"."public"."accounts"

No warehouse copy to keep in sync

Copying files into a warehouse just to join them with operational data adds a pipeline and a stale copy. Query Forge joins the lake and the live database when the query runs.

Governance

Read-only, scoped and masked

The same rules as every Core Hub query

Lake queries follow the rules that govern every other query in Core Hub. Roles, data-access policies and token scopes decide who sees what, and a lake query never changes a file.

  • Read-only always: no writes, DDL or exports back to storage
  • Queries stay inside the store root of the agent
  • Core Hub roles and table-level data-access policies apply
  • PII masking applies, and masked values stay masked through lake queries
  • Secrets never appear in errors or logs, and each query runs in its own isolated in-memory session inside Core Hub

Browse Gluesync docs ↗

Lake queries
Settings · Query data access

Query data access

Connection mode

Schema and table rules

public *
erp customers

PII unmask grants

Viewers can never unmask, even with a grant.

FAQ

Frequently asked questions

Which file formats and storage can I query?

Parquet, CSV and JSON files on AWS S3 and S3-compatible object storage such as MinIO, and on WebDAV, WebDAVS and NFS. JSON can be a single document, an array, or one document per line. The agent's file type decides how each file is read.

Which engine runs lake queries?

Lake queries run on DuckDB, embedded in Core Hub. Each query gets its own isolated, read-only session, governed by Core Hub roles, data-access policies and PII masking.

Do I need a new agent or connection?

No. Lake queries run on the lake engine embedded in Core Hub. The S3, WebDAV and NFS agents you already run become queryable with the credentials they already hold, so there is no new connection screen and no second copy of credentials.

Can I query the change history of a row?

Yes. Parquet and CSV change files keep every version of a row, and deletes appear as rows with _operation = 'D'. Snapshot and change files are combined by column name, so one query returns the full history of a row, deletes included.

Can I join lake data with my operational databases?

Yes, through Query Forge. Lake datasets appear as "<catalog>"."default"."<dataset>" next to your live databases, so one federated query can join a lake dataset with PostgreSQL or any other agent, from any JDBC client or BI tool.

Which SQL can I use?

Full read-only SELECT and WITH: joins, CTEs, window functions, UNION and subqueries. In Query Studio you can also read files by path with parquet(), csv() and json(), list a folder with files(), and join your own CSV with a replicated dataset.

How is access controlled?

Lake queries follow Core Hub roles and table-level data-access policies, PII masking applies and cannot be lifted through a lake query, and Personal API Token scopes decide which agents a Query Forge caller sees. Every query is read-only and stays inside the agent's store root.

Explore the platform

Continue exploring Gluesync

Lake queries extend Query Studio and Query Forge to the files Gluesync lands. Explore how the data gets there and who can see it.

Query Studio

The SQL workbench where lake datasets and file functions sit next to your databases.

Explore Query Studio →

Query Forge

Federated SQL that joins lake datasets with live databases from any JDBC client.

Explore Query Forge →

Data lake ingestion

Land snapshots and continuous changes in object storage as Parquet, CSV or JSON.

Explore Data lake ingestion →

PII discovery & masking

Classify columns and mask at read time, including in lake queries.

Explore PII discovery & masking →

Resources

Guides, roadmap and support

Roadmap

Public Roadmap

What we're building next. Submit feature requests.

View roadmap ↗
Support

Support

Access technical support and operational assistance.

Get support →
Status

Service Status

Real-time platform availability and incident history.

Check status ↗

Ask your lake, not your warehouse

Request a free trial or talk with the MOLO17 team about querying the files your pipelines land.

Request a free trial Talk to our team Docs