Skip to main content
Yes — if your Parquet files just sit under a bucket prefix with nothing else in front of them, StarTree can query them directly as an External Table. No Iceberg metadata, no Glue database, no catalog REST endpoint, no separate registration step. Point StarTree at the bucket and prefix and it discovers the files itself.

​
When this is the right fit

  • You have a data pipeline (Spark, Flink, a batch job) that lands Parquet files in S3 or GCS, with no catalog layer on top.
  • You want to try External Tables against a sample dataset before setting up a full Iceberg catalog.
  • Your data lake uses a catalog for other consumers, but you’d rather point StarTree straight at the underlying files.
If your data is already registered in a catalog — AWS Glue, Amazon S3 Tables, Databricks/OSS Unity Catalog, or Nessie — skip ahead to Connect a Catalog instead; StarTree can use the catalog’s schema and file-listing directly rather than re-discovering it from raw files.

​
Two sources, same shape

Both scan a bucket prefix, infer a schema by sampling the Parquet files, and sync on a schedule — the only difference is which object store and credential type you use.
SourceObject storeCredentialsOnboarding guide
S3 Data LakeAmazon S3Assumed IAM role, cluster node role, or static access keysS3: Onboarding via API · via Data Portal
GCS Data LakeGoogle Cloud Storage (via its S3-compatible interop endpoint)HMAC keys (inline or via GCP Secret Manager)GCS: Onboarding via API · via Data Portal
Prefer the REST API for automation and scripting multiple tables; use the Data Portal wizard for a one-off table with no JSON to write.
Also see the SQL DDL shortcut — CREATE TABLE ... WITH (type = 's3', ...) creates the same table in one statement instead of the 4-step REST flow.

​
What’s next

Once the table is created, add indexes for the columns you filter and group by, enable caching so repeat queries don’t re-fetch from object storage, and track sync health through Observability.