Request collections
Save named PartiQL operations into folders and share them as git-native JSON.
Collections let you save named PartiQL statements into folders, run them with one click, and share a whole folder as plain JSON you can commit to a repo and hand to teammates.
What a collection is
A collection is a named folder of operations. Each operation is a saved PartiQL statement with a name and an optional description:
Reports/ (collection)
├── Open orders this week (operation → SELECT … )
├── Top customers (operation → SELECT … )
└── Audit: failed payments (operation → SELECT … )It’s a lightweight, Postman-style organizer for the queries your team runs over and over, built around Tablyne’s PartiQL editor.
Opening the panel
Open collections from the Coleções button in the toolbar, the command palette (/docs/command-palette/), or the search panel. The panel has the folder list on the left and the selected operation on the right.
Building a collection
- New collection — create an empty folder and name it.
- Save the current SQL — the + on a collection saves whatever statement is in the editor right now as a new operation; you give it a name. This is the fast path: write a query, get it working, drop it into a folder.
- Remove — delete an operation, or an entire collection (with a confirm).
Each collection header shows its operation count.
Running an operation
Select an operation to see its name, description, and the full SQL. Click ▶ rodar to load the statement into the editor and run it against the current table — the panel closes and the results fill the grid, exactly as if you’d typed and run it yourself. Because collections store PartiQL text, an operation runs against whichever table is open, so the same statement is reusable across tables that share a shape.
Running an operation is the same execution path as typing the query by hand: results paginate with PartiQL’s NextToken via the grid’s load more button, and the run is recorded in the table’s history. Like the PartiQL editor, collections are read-oriented — they store and replay SELECT statements; writes still go through the grid’s staged edits, the item editor, import, or bulk operations.
Git-native sharing
Collections are made to live in version control. Export (the ⇪ on a collection) produces clean, id-free JSON and copies it to your clipboard:
{
"name": "Reports",
"ops": [
{
"name": "Open orders this week",
"sql": "SELECT * FROM \"orders\" WHERE begins_with(sk, 'ORDER#')",
"desc": "Orders created in the current week"
}
]
}The exported shape carries no internal ids and no machine state — just names, SQL, and descriptions — so it diffs cleanly, reviews well in a pull request, and is safe to commit alongside your code. Import pastes a JSON blob back in as a new collection; malformed JSON is rejected with a message.
Where they’re stored
Collections are kept locally on your machine (in the app’s browser storage), per install. They aren’t synced to AWS or to a Tablyne account — sharing is entirely through the export/import JSON. That’s the point: you own the file, and git is the sync layer.
Limitations
- PartiQL only. Operations store SQL-mode statements; the Busca query builder isn’t saved as a collection operation.
- Local storage. Collections live on this machine; to move them to another machine or teammate, export and import the JSON (or commit it).
- No variables. An operation is a literal statement — there’s no parameter substitution; edit the SQL after loading if you need to tweak a value.
- Closely related but separate: per-statement saved queries and history are covered in /docs/saved-queries-history/.