Oliphaunt

SDKs And Platforms

Compare Oliphaunt SDK package names, target apps, runtime ownership, and platform responsibilities.

Oliphaunt ships as peer SDKs for the platforms where developers build apps. Each SDK uses the conventions of its ecosystem while keeping the same database concepts: open a root, run SQL, manage lifecycle, select exact extensions, and back up or restore data.

Rust is the SDK for Tauri and Rust desktop apps. React Native is the TypeScript/TurboModule SDK over the Swift and Kotlin SDKs. TypeScript is the SDK for Node.js, Bun, and Deno. Tauri apps currently keep Oliphaunt in Rust state behind narrow app-owned commands; a direct JavaScript adapter is planned.

Choose an SDK

Rust

oliphaunt

Tauri and native Rust desktop apps

directbrokerserver

Swift

Oliphaunt

iOS and macOS apps

direct

Kotlin

dev.oliphaunt:oliphaunt-android

Android apps

direct

React Native

@oliphaunt/react-native

Expo and React Native New Architecture apps

direct

TypeScript

@oliphaunt/ts

Node.js, Bun, and Deno

brokerserverdirect adapter

WASM

oliphaunt-wasix

WASM/WASIX hosts

WASIX

C ABI

liboliphaunt

New language bindings

direct ABI

React Native delegates database execution to the platform SDKs: Apple calls flow through the Swift SDK, and Android calls flow through the Kotlin SDK. That keeps resource packaging, lifecycle, and native crash behavior predictable for mobile apps.

TypeScript broker mode uses a published broker helper, so JavaScript desktop apps resolve the helper through package configuration. Native Node.js, Bun, and Deno installs use the npm package; the JSR distribution is deliberately limited to portable protocol/query helpers.

Shared Concepts

The SDKs intentionally use matching names for the concepts developers need to move between platforms:

  • nativeDirect for the lowest-latency embedded session.
  • nativeBroker for helper-process isolation and multi-root desktop apps.
  • nativeServer when real PostgreSQL clients, pools, or tools need independent sessions.
  • capabilities() to check what a selected runtime can do.
  • backup and restore for app-friendly data movement.
  • structured PostgreSQL errors with SQLSTATE and backend fields where available.

SDK capability reports describe which modes are available on the selected platform. Mobile SDKs expose direct mode first; broker and server support appear when the platform SDK advertises those runtimes.

nativeDirect

Embedded latency

Use it when

One app database needs the lowest overhead path.

Boundary

One physical PostgreSQL session with serialized work.

nativeBroker

Desktop isolation

Use it when

A desktop app needs helper-process ownership, multiple roots, or recovery.

Boundary

Helper process boundary for desktop SDKs.

nativeServer

Client compatibility

Use it when

Existing PostgreSQL clients, ORMs, psql, or pg_dump need real sessions.

Boundary

PostgreSQL-compatible process boundary with independent client sessions.

WASM

WASIX runtime

Use it when

The app targets a WASM/WASIX host.

Boundary

Separate build and packaging rules from native SDKs.

Extensions

Extension selection is exact SQL extension name only.

If an app selects vector, the app artifact contains vector and its declared dependencies. Unrelated search, geo, graph, or development-only extension files stay out of that app artifact.

Extension selection is exact-name only: app configuration names PostgreSQL extensions such as vector directly.

That model matters for mobile and desktop distribution: app developers decide which PostgreSQL extensions their app uses, and Oliphaunt packaging makes that choice auditable before release.

On this page

Choose an SDKShared ConceptsExtensions