Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.summand.com/llms.txt

Use this file to discover all available pages before exploring further.

A view is a named SQL query Summand runs against your curated data. Views can:
  • Filter, project, or aggregate a single dataset.
  • Join across datasets — including across different connectors, since everything’s curated to the same Parquet store and registered in the same Glue catalog.
  • Be edited visually with a drag-and-drop builder, hand-edited as raw SQL, or drafted by Summand in chat.
  • Be used downstream — as a source in experiments, as grounding in further chat sessions, or shared on their own with grant + visibility semantics.

​
Visual builder vs. raw SQL

Views ship with two editing modes that share the same underlying query:
  • Visual — pick datasets, drag in joins and filters, define aggregations. The builder writes SQL underneath, and live previews against Athena update as you change things.
  • Code — drop into a SQL editor for anything the visual builder can’t express. Live preview is the same.
When you switch from Code back to Visual, Summand confirms before resetting hand-edits — there’s no automatic round-trip from arbitrary SQL back into the builder’s structured representation.

​
Where views live

Views are stored under the user who created them: 
PK: USER#{userId}
SK: VIEW#{viewId}
There’s no cross-user view share today — to give someone else access to your view’s output, materialize it (run the SQL once and save), or share the underlying datasets and let them rebuild it.

​
Chat-created views

Summand can draft a view for you. Ask in chat — “build me a view that shows monthly active customers from the orders dataset” — and Summand returns a proposed SQL view rendered with a save button. Approve and it lands in your views list. Views Summand creates inside a chat session are pinned to that session as chat views until you explicitly save them. Chat views aren’t addressable by experiments and aren’t shareable; they’re scratch.

​
Performance

Views run on Athena over the curated Parquet partitions. For most analytical patterns this is fast — Athena scans only the columns the SQL touches. For very large joins, consider materializing the view as part of an experiment (the experiment writes the result back as a new dataset on a schedule).

​
Limits

  • One schema per view today. Views are queries, not multi-statement scripts.
  • No mutations. SQL is read-only — INSERT / UPDATE / DELETE aren’t supported.
  • Glue-table references. Views reference datasets by their Glue table name, not their ID. If you rename a dataset (display name change) the view is unaffected; if you delete a dataset, dependent views break with a clear error.