LakeQL
Introduction
  • Overview
  • Why LakeQL
  • Key Concepts
Getting Started
  • Prerequisites
  • Quickstart
  • Environment
  • First Run
Architecture
  • System Overview
  • Data Flow
  • Request Lifecycle
Configuration
  • Config File
  • Runtime Lifecycle
  • Environment Variables
create-app
  • Usage
  • Template Structure
  • Post-Creation
Guides
  • Custom Resolvers
  • Extending the Schema
  • Mutations
  • Set Up a Trino Mutation
  • Deploying
Endpoints
  • Definition Format
  • Field Types
  • Nested Fields
  • Mutations
  • Glossary
Contributing
  • Local Development
  • Contribution Guide
  • Architecture
GitHub
LakeQL
  1. LakeQL
  2. Introduction
  3. Overview

On this page

  1. What is LakeQL?
  2. The Problem
  3. How LakeQL Solves It
  4. The Shape of a Project
  5. How It Works
  6. Where to Next

Overview

LakeQL is a universal data access layer that generates type-safe GraphQL APIs across your data stack. No hand-written resolvers.

What is LakeQL? #

LakeQL is a universal data access layer for modern platforms. It generates a type-safe GraphQL API across your data stack. You point its CLI at a data source, generate typed schema files from the real table metadata, and serve them through a GraphQL server you compose from explicit building blocks.

LakeQL is adapter-agnostic. An adapter teaches it how to talk to one query engine. Adapters for Trino and Microsoft Fabric are available today. ClickHouse and DuckDB are on the roadmap. A single project can register multiple adapters and route queries to different engines from one API.

The Problem #

Building a GraphQL API over your data tables is repetitive. Every table needs a TypeScript interface, resolver logic, filter and sort definitions, pagination, and permission checks. Change a table — add a column, rename a field, alter a type — and you update all of those layers by hand. Schema drift and broken types pile up fast across dozens of tables and several schemas.

How LakeQL Solves It #

LakeQL inverts the workflow. You introspect the data source and generate the typed layer instead of writing resolvers by hand:

  • TypeScript interfaces derived from column metadata
  • GraphQL query schemas with filtering, sorting, and pagination built in
  • JSON schemas that drive runtime response transformation
  • Config files that register each generated endpoint

You commit the generated code to your repository, and the API server loads it at startup. When a table changes, re-run the introspection command to regenerate the typed layer.

The Shape of a Project #

A LakeQL project is an ordinary TypeScript application with three parts:

lakeql.config.tsAdapters and data sources
  1. lakeql.config.ts declares which adapters are available and which named data sources exist. See Configuration .
  2. src/index.ts loads that config, builds a runtime that owns the data source connections, and starts the GraphQL server. See Server Setup .
  3. src/schemas/generated/ holds the typed files the CLI writes when you introspect a table. See the CLI commands .

Scaffold a project to get all three at once:

pnpm create @lakeql/app my-api

How It Works #

introspect generate load Data Source CLI Typed schema files API server GraphQL endpoint
Click to focus
← ↑ → ↓pan+ / −zoom0reset
0.90x
  1. Introspect — the CLI connects through an adapter and discovers table structures.
  2. Generate — typed files are written: interfaces, query schemas, and configs.
  3. Serve — the server loads the generated schemas and exposes a GraphQL endpoint.
  4. Query — clients send GraphQL queries that translate into adapter-specific SQL.

Where to Next #

Key Concepts

Data sources and adapters, schema generation, the runtime, and GraphQL-to-SQL translation.

Getting Started

Scaffold a project, configure it, and make your first request.

Previous page

Introduction

Next page

Why LakeQL