---
title: "Prepared statements"
sidebarTitle: "Prepared Statements"
description: "What a deployment does when a Flight SQL client prepares a statement or binds parameter values."
icon: bolt
keywords: ["prepared statement", "flight sql", "parameters", "bind"]
---

<Badge color="red">Enterprise</Badge> [SQL runs in LanceDB Enterprise.](/sql)

A Flight SQL client can prepare a statement before it runs it. A deployment
accepts that, but it keeps no plan between runs and does not accept parameter
values.

## Prepare through a Flight SQL client {#protocol}

<Warning>
There is no SQL `PREPARE` / `EXECUTE` here. Preparation is part of the
**Arrow Flight SQL protocol**, so you reach it through your client rather than
by sending a statement.
</Warning>

That distinction matters when porting SQL from another engine: a script
containing `PREPARE name AS SELECT ...` will not run.

## Prepare and execute {#flow}

A Flight SQL client takes these steps, whatever it calls them:

1. **Prepare:** send the SQL and get back a handle and the result schema. The
   statement is parsed and planned at this point, so a syntax or name error
   surfaces here rather than at execution.
2. **Execute:** run the handle and read the result. The deployment plans the
   statement again each time it runs, so reusing a handle does not save
   planning time.
3. **Close:** release the handle.

## Parameters {#parameters}

A deployment does not accept parameter values for a prepared statement. A
client that binds values to placeholders such as `$1` and `$2` gets a "not
implemented" error when it executes the statement. A statement with fixed,
trusted values written into it runs as usual:

```sql
SELECT id, title FROM documents WHERE category = 'news' AND score > 0.5
```

Do not put untrusted input, such as a value from a user or a request, directly
into the statement text. Quoting it does not protect the statement the way
binding a parameter would.

## When to use prepared statements {#when}

Prepare a statement when your client requires it, or to get a statement's
result schema and catch syntax and name errors without running it. Preparing
does not make a repeated statement faster.

To give a reusable query a name, create a [view](/management/view). To store
its result for later queries, create a
[materialized view](/management/materialized-view).