<!-- Generated from the rendered page by scripts/write-llm-mirrors.mjs. Do not edit by hand. -->
Canonical: https://molo17.com/lake-queries/
Markdown mirror: https://molo17.com/lake-queries/index.md
Title: Lake queries · Gluesync · MOLO17
Description: Query Parquet, CSV and JSON files on S3, WebDAV and NFS with SQL, in place, on the DuckDB-based lake engine inside Gluesync Core Hub.

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](#how-it-works) [Talk to our team](/contacts/?topic=gluesync-platform#contact-form-section)

 Lake queries

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 ↗](https://docs.molo17.com/gluesync/latest/gs-modules/query-studio.html)

 Lake queries

### 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 ↗](https://docs.molo17.com/gluesync/latest/gs-modules/query-forge.html)

Federated SQL · a lake dataset joined with a live database

**JDBC client**`jdbc: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 Outfitters**418,905.20**
-   Harbourline Foods**196,744.80**
-   Brightwater Clinics**181,060.15**

Core Hub**One JOIN across the lake and the live database**The lake engine embedded in Core Hub reads the files in place · nothing copied

1.  ![](/media/integrations/awss3-glyph.svg)
    
    **AWS S3**Lake dataset · Parquet, read in place`"orders_to_lake"."default"."orders"`
    
2.  ![](/media/integrations/postgresql-cdc-glyph.svg)
    
    **PostgreSQL**Live 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 ↗](https://docs.molo17.com/gluesync/latest/)

 Lake queries

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-studio/) [### Query Forge

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

Explore Query Forge →](/query-forge/) [### Data lake ingestion

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

Explore Data lake ingestion →](/solutions/data-lake/) [

### PII discovery & masking

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

Explore PII discovery & masking →](/pii-discovery-and-masking/)

Resources

## Guides, roadmap and support

Documentation 

### Documentation

Technical guides, API reference, deployment tutorials.

[Read documentation ↗](https://docs.molo17.com)

Roadmap 

### Public Roadmap

What we're building next. Submit feature requests.

[View roadmap ↗](https://roadmap.molo17.com)

Support 

### Support

Access technical support and operational assistance.

[Get support →](/support/)

Status 

### Service Status

Real-time platform availability and incident history.

[Check status ↗](https://status.molo17.com)

## 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](/get-gluesync/) [Talk to our team](/contacts/?topic=gluesync-platform#contact-form-section) [Docs](https://docs.molo17.com/gluesync/latest/gs-modules/query-studio.html)
