lancedb/docs/web/basics/sdk.mdx

---
title: "SDKs"
sidebarTitle: "SDKs"
description: "The language clients — Python, TypeScript, Rust — and what stays true across all of them."
icon: code-compare
keywords: ["python", "typescript", "rust", "java", "sdk", "rest", "api reference"]
availability:
  oss: available
  enterprise: available
  summary: >-
    The Python, TypeScript and Rust SDKs work with embedded databases and,
    through `db://`, with Enterprise deployments; the Java SDK reaches
    deployments only. What each can do differs by language and connection.
---

A language SDK is the primary way to work with LanceDB: create and manage
tables, write and query data, build indexes, run feature engineering.

Start locally, then connect to Enterprise by changing your connection URI. Keep
the same core table and search code as your application grows: creating a
table, adding, updating and deleting rows, and searching and filtering it are
the same calls on either connection. What else changes when you move is in
[Moving to LanceDB Enterprise](#moving-to-enterprise).

## Officially supported SDKs {#supported-sdks}

Python, TypeScript and Rust are supported against both embedded and deployed
LanceDB.

| Reference | Description |
|:--------------|-------------------|
| <Icon icon="python" /> [Python](https://lancedb.github.io/lancedb/python/python/) | Full-featured Python client with pandas and numpy integration |
| <Icon icon="square-js" /> [TypeScript](https://lancedb.github.io/lancedb/js/) | A TypeScript wrapper around the Rust library, built with `napi-rs` |
| <Icon icon="rust" /> [Rust](https://docs.rs/lancedb/latest/lancedb/index.html) | Native Rust library with persistent storage and high performance |

Not every SDK covers the same surface, though:

| | Python | TypeScript |
| --- | :---: | :---: |
| Create and manage catalog objects | yes | yes |
| Insert, merge, update, delete | yes | yes |
| Filter, project | yes | yes |
| Vector search | yes | yes |
| Full-text search | yes | yes |
| Feature engineering, jobs | yes | partly |
| Runs against a local database | yes | yes |

Neither SDK aggregates or joins.
TypeScript has no methods for [functions](/management/function). {/* if functions launched */}
Reach those with SQL on a deployment instead -- see [SQL](/basics/sql).

## REST API {#rest}

<Badge color="red">Enterprise</Badge> A deployment implements the
[Lance REST Namespace](/basics/lance#enterprise), so the catalog is reachable
over HTTP by anything that speaks it -- see the
[REST API reference](/api-reference/rest).

| Reference | Description |
|:--------------|-------------------|
| <Icon icon="java" /> [Java](https://lancedb.github.io/lancedb/java/java/) | REST API Enterprise SDK in Java |

## Community SDKs {#community-sdks}

Contributed by the community rather than supported by LanceDB, so feature parity
and release cadence vary.

| Reference | Description |
|:--------------|-------------------|
| <Icon icon="golang" /> [Go](https://pkg.go.dev/github.com/lancedb/lancedb-go/pkg/lancedb) | Community-contributed Go SDK |
| <Icon icon="gem" /> [Ruby](https://github.com/scientist-labs/lancelot) | Community-contributed Ruby bindings |
| <Icon icon="swift" /> [Swift](https://github.com/RyanLisse/LanceDbSwiftKit) | Community-contributed Swift SDK |
| <Icon icon="R" /> [R](https://github.com/CathalByrneGit/lancedb) | Community-contributed R package |
| <Icon icon="flutter" /> [Flutter](https://github.com/Alexcn/flutter_lancedb) | Community-contributed Flutter bindings |

For any other language, [SQL](/basics/sql) on a deployment reaches the same
tables without a LanceDB-specific SDK at all.

## Python multiprocessing {#multiprocessing}

<Warning>
Do not use `fork` as the start method with Python's `multiprocessing` module.
Lance is multi-threaded internally, and `fork` with alive threads is unsafe --
use `spawn` instead. See
[this discussion](https://discuss.python.org/t/concerns-regarding-deprecation-of-fork-with-alive-threads/33555)
for why.
</Warning>

## Moving to LanceDB Enterprise {#moving-to-enterprise}

The [quickstart](/quickstart)'s core steps -- create a table, add rows, search,
filter -- run unchanged once the connection points at a deployment. Four things
around them change:

**Connection settings and credentials.** A deployment takes a `db://` URI, its
endpoint and an API key, which its administrator gives you; keep the key in the
environment or a secret manager. See
[Connect to LanceDB Enterprise](/quickstart#connect-to-lancedb-enterprise), and
[Authentication](/enterprise/authentication) for OAuth.

**Methods that are missing or behave differently.** A `db://` connection
returns a remote table, which lacks some local methods and changes others. For
example, in Python `table_exists` raises, a whole-table `to_arrow()` or
`to_pandas()` raises -- query the table instead, as in
`table.search().to_arrow()` -- and listing tables returns one page at a time.
Some features also have to be enabled on the deployment before they work:
computed columns, views, materialized views and SQL among them. Each page's
label says where its feature applies, and
[OSS and Enterprise](/basics/offerings) compares them all.

**Maintenance.** Embedded, compaction, cleanup and index updates happen when
you call `optimize()`. On a deployment they are the deployment's work, and its
configuration decides when they run; calling `optimize()` against it does not
start them. Synchronous Python warns and returns `None`, while asynchronous
Python and TypeScript raise. See [Background jobs](/maintenance/background-jobs).

**Long-running work.** On a deployment, building an index, refreshing a
computed column and similar operations run on the server as
[jobs](/basics/jobs). The `_async` form submits one and returns the job, which
you can wait on, check later from another process, or cancel; the blocking form
of a refresh raises there. Running on the server does not make derived data
keep itself current: a computed column is filled only when you submit a
refresh.

The [Enterprise overview](/enterprise) describes how a deployment is put
together.

## What stays the same {#invariants}

Whichever you pick:

- **Types are Arrow types.** A vector column is a `FixedSizeList<Float32>`
  everywhere, not a SQL type mapped onto storage. See
  [Functions and types](/sql/functions).
- **Reads are Arrow.** Nothing is serialized into language objects on the way out
  unless you convert it.
- **The catalog is one catalog.** A table created from TypeScript is visible to
  Python and to SQL immediately -- there is no per-language namespace.

## What to read next {#next}

<CardGroup cols={2}>
  <Card title="SQL" icon="table-list" href="/basics/sql">
    The same tables, reached by any Flight SQL client -- and the one way in for a language with no SDK.
  </Card>
  <Card title="Agentic Skills" icon="robot" href="/basics/agentic-skills">
    Give a coding agent a current reference to this same API surface.
  </Card>
</CardGroup>