> ## Documentation Index
> Fetch the complete documentation index at: https://docs.onebucket.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Parquet across clouds, one bucket

> Tabular data in several stores, queried together by any S3-reading engine

## The situation

Tabular data lands as Parquet in different places: one business unit on AWS, another on GCS, history on-premises. Every analysis starts by exporting, copying and stitching sources together.

## What OneBucket changes

All of it appears under one bucket and one prefix layout. Any S3-reading engine reads the files together in one query. Nothing is copied first. The join across stores disappears because there is nothing to stitch.

```sql theme={null}
select * from read_parquet('s3://onebucket/sales/*');
```

![A query engine reads one bucket through OneBucket; the sales prefix resolves to Parquet files on AWS S3, GCS and on-prem](https://mintcdn.com/onebucket/IRmZGtHTOOl3yo0n/images/scenarios/parquet.png?fit=max\&auto=format\&n=IRmZGtHTOOl3yo0n\&q=85\&s=9610e6c0c05999e650838a1bb5b1ae70)

## How it works

* **The engine runs the query; OneBucket serves the namespace.** The engine sees one bucket, so one statement spans Parquet that physically sits in two clouds and an on-prem store.
* **Read and write.** The S3 endpoint supports full read and write, so results can be written back to the same namespace, and policy decides where they land.
* **Unchanged tools.** Any engine that reads S3 works as is: point it at the OneBucket endpoint with a OneBucket key.

## Related

* [S3 API compatibility](https://docs.onebucket.io/reference/s3-api.md)
* [Placement by policy](https://docs.onebucket.io/scenarios/placement.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.