QAIL Philosophy

The Struggle: "Polyglot Hell"

We are polyglot developers. On Monday, we write Rust. On Tuesday, Go. On Wednesday, we maintain a legacy PHP system.

Every time we switch languages, we have to switch our paradigms:

• In Rust, we choose between Diesel's strict compile-time types or SQLx's raw flexibility.
• In Go, we balance GORM's convenience with the performance of raw database/sql.
• In Node.js, we rely on Prisma for safety but pay the cost of heavy binary sidecars.
• In Python, we leverage Django's speed of development but hit performance walls at scale.
• In PHP, we love Eloquent's expressiveness but sometimes need lighter, faster query options.

The problem isn't the data. The problem is the string layer. Every ORM generates SQL strings. Every driver parses them again. Why not skip strings entirely?

The Origin: "I Don't Want You to Suffer"

"I originally built QAIL for internal use to solve my own polyglot headaches. But I realized that keeping it private meant letting other engineers suffer through the same 'Database Dilemma'. I decided to open-source it so we can all skip app-side SQL string plumbing."

The Realization: "SQL is Assembly"

We realized something profound: SQL is not source code. SQL is Assembly.

SQL is verbose, powerful, and dangerous. It is the low-level instruction set of the database engine.

• Raw SQL offers ultimate control, but maintaining raw strings across a large codebase requires immense discipline.
• ORMs provide fantastic productivity, but the abstraction sometimes comes at the cost of fine-grained performance control.

We didn't need a compromise. We needed a Universal AST.

The Savior: QAIL

QAIL is the "Universal AST for Databases". It is not a text syntax that compiles to SQL—it is a native data structure that encodes directly to database wire protocols.

It separates the Code (your query AST) from the Data (your parameters). It creates a unified structure that works the same way in Rust, Go, Node, and PHP.

Qail::get("users")
  .columns(["id", "email"])
  .filter("active", Eq, true)
  .limit(10)

SELECT id, email
FROM users
WHERE active = true
LIMIT 10

Now, your team builds with one AST. The Rust dev, the Go dev, and the Frontend dev all use the same data structure.

"Safety shouldn't require a prison of boilerplate. We moved validation from the 'String' layer to the 'AST' layer. Code is data. Data is typed. Injection risk is reduced on the AST path."

By preventing SQL injection at the AST level, QAIL ensures your queries are safe before they even reach the database. Unlike ORMs that generate strings at runtime, QAIL encodes directly to wire protocol bytes—without app-side SQL string interpolation on the AST path.

Important: this does not mean PostgreSQL stops parsing. PostgreSQL still runs its normal parse/plan/execute stages on the server.

The Vision: Facts, Meaning, and Time

"Postgres stores facts, Qdrant stores meaning — QAIL decides."

Modern applications don't run on a single database. They need specialized engines for specialized workloads:

QAIL is the decision layer that unifies these engines. One AST. Two powerhouses. Cache built-in.

The Architecture: Native Power

QAIL is written in Pure Rust. It exposes:

• A C-API for Go, Python, and Java (via FFI).
• A WASM Module for Node.js and Browsers.
• A Native Crate for Rust users.

It runs in-process. It has zero network overhead. It turns your query generation into a simple CPU function call.

The AST Builder API

We designed the builder API for Type Safety and Clarity. Every method is purposeful. No hand-built SQL-string plumbing.

🛡️ Why No Raw Strings?

QAIL intentionally does not provide a "Raw SQL" escape hatch. This is not a missing feature—it's a deliberate design choice.

The Promise

"If it compiles in QAIL, it is a valid, safe protocol packet."

Soundness by Construction

By forcing queries through the AST path, QAIL enforces strong invariants:

• SQL Injection Risk Removed on AST Path — Code and data are never mixed. Parameters are always separate from query structure.
• Syntax Errors at Construction Time — Invalid query structures fail when building the AST, before ever touching the database.
• Global Safety Invariant — Every query that executes was validated at the type level (compiled languages) or construction time (dynamic languages).

The Rust vs C++ Analogy

For Those Who Need Raw SQL

If you need raw SQL strings, use sqlx or another driver. QAIL is for those who want strong invariants, not string-level flexibility.

"QAIL: Sound by Construction."

🚫 Why QAIL is NOT an ORM

QAIL is not an Object-Relational Mapper. It does not provide lazy loading or magic .include() methods. This is not a limitation—it's a deliberate architectural choice backed by hard data.

What QAIL Is

Why No Lazy Loading? The Evidence.

We benchmarked six patterns for the same endpoint objective and canonical payload against a real PostgreSQL dataset (`odyssey_connections` + `harbors`, 2x LEFT JOIN). This is a pattern benchmark: single-query JOIN vs batched lookups vs N+1 fan-out.

Loopback can make single-query and DataLoader appear equivalent. As RTT grows, extra round trips dominate, and one-query plans pull ahead.

"Method first: same canonical payload, equivalence gate enabled, randomized run order, and explicit RTT profile (`BATTLE_SIMULATED_RTT_US`) in the benchmark harness."

Full benchmark methodology & source code →

Typed Schema Codegen

QAIL does provide optional compile-time type safety via TypedQail<T> and schema codegen:

• TypedQail — Table-typed queries. Invalid joins fail at compile time via RelatedTo<T>.
• Schema codegen — qail types schema.qail generates typed column accessors.
• Protected columns — Capability witnesses guard sensitive fields at compile time.

But unlike ORMs, these are opt-in safety layers on top of the core AST — not mandatory boilerplate.

user.posts().comments().author()
// 3+ hidden queries?

Qail::get("posts")
  .left_join("comments", "post_id", "id")
  .left_join("users", "author_id", "id")

What QAIL Focuses On

• ✅ Best-in-class query syntax — 3-5x shorter than SQL
• ✅ Direct wire protocol encoding — No app-side SQL interpolation on AST path
• ✅ Migration tooling with impact analysis — Unique to QAIL
• ✅ Multi-database AST portability — Write once, run anywhere

"QAIL is the query transport layer, not an ORM. If you need magic lazy loading, use Prisma. If you want the high-performance, safety-focused way to talk to your database — with proof — use QAIL."

🚀 QAIL Gateway — Production Today

QAIL Gateway is an auto-REST API server that turns your PostgreSQL database into a full-featured API — with zero backend code. Point it at a database, get instant CRUD, real-time subscriptions, and enterprise security.

"Full-featured data API — without GraphQL complexity. Binary AST protocol with safer defaults than hand-built query strings."

What You Get

Security Is Compiled In

Read the Gateway documentation →

QAIL Gateway powers Sailtix — a multi-operator maritime booking platform with full RLS tenant isolation across 27+ tables.