Overview

This section describes how the provider models Linear and how to query and modify Linear data with SQL.

Key Features

• The provider models Linear entities such as Issues, Projects, Teams, Users, and IssueLabels as relational tables, so you can work with Linear data in SQL.
• The data model is discovered dynamically from the Linear GraphQL schema, so the available tables and columns reflect your Linear workspace at connection time.
• Live connectivity means changes in your Linear account are reflected immediately.
• SQL operations are pushed to Linear wherever the API supports them; anything the API cannot do is handled in memory by the provider, so the full SQL surface is still available.

Tables

Tables are derived dynamically from the Linear GraphQL schema. Each top-level object is exposed as a table:

• Root entities: Each queryable Linear object (for example, Issues, Projects, Teams, Users, IssueLabels) is a table. Scalar fields become columns, and a single-object (many-to-one) relationship becomes a foreign-key column named after the relationship (for example, an issue's team is exposed as teamId).
• Junction tables: A many-to-many relationship is exposed as a separate composite-key table (for example, IssueLabels with issueId and issueLabelId) that links the two sides.
• Child tables: An object that is reachable only through a parent (for example, an issue's history) is exposed as a child table keyed by the parent's id.

Selecting Data

The provider pushes the following to Linear for efficiency, fetching only the rows and fields you ask for:

• Column projection: Only the selected columns are requested from the API.
• Filters (WHERE): Comparisons (=, !=, <, <=, >, >=), IN, LIKE (mapped to the appropriate Linear string match), and IS NULL / IS NOT NULL are pushed where Linear supports them, including on foreign-key columns.
• Ordering (ORDER BY): Pushed for columns whose Linear sort orders by the column value (for example, dates and titles). Columns whose Linear sort uses a different order, such as priority (sorted by urgency) and foreign-key columns (sorted by the related object), are ordered by the provider instead, so results follow the column value.
• LIMIT: Pushed as the page size so the provider fetches only as many rows as requested.
• Joins: An INNER JOIN of two entities through their junction table is pushed as a single nested query.

Linear uses cursor pagination with a per-query complexity limit. The provider automatically pages through results and sizes each request to stay within that limit, so large result sets are assembled transparently.

Modifying Data

The provider supports INSERT, UPDATE, and DELETE on tables whose Linear API exposes the corresponding mutation:

• INSERT / UPDATE / DELETE on a root-entity table map to the entity's create, update, and delete Linear mutations. DELETE permanently removes the record; to archive instead, use the archiving stored procedures.
• Many-to-many associations: INSERT a row into a junction table to create an association between two existing records, and DELETE a junction row to remove it. Insert the records into their own tables first, then associate them through the junction table.

Stored Procedures

Stored procedures are function-like interfaces to Linear that perform operations beyond standard table queries, such as the OAuth authentication exchange (GetOAuthAuthorizationURL, GetOAuthAccessToken, RefreshOAuthAccessToken) and other Linear actions that are not simple create, update, or delete operations.