Moving From SQLite
Map SQLite storage, SQL, backup, and extension assumptions to embedded PostgreSQL.
Oliphaunt is embedded PostgreSQL, so migration from SQLite starts by mapping a single-file database model to PostgreSQL roots, WAL, extensions, and PostgreSQL SQL semantics.
Use this guide when an app already uses SQLite and you are evaluating whether a PostgreSQL-compatible embedded runtime is worth the extra footprint.
Migration map
Start by replacing SQLite assumptions with PostgreSQL and SDK-owned app boundaries.
SQLite assumption
One database file
Oliphaunt model
PostgreSQL root directory
Migration action
Move data movement to SDK backup and restore APIs.
SQLite assumption
Pragmas
Oliphaunt model
PostgreSQL settings and durability profiles
Migration action
Choose startup and durability configuration through the SDK.
SQLite assumption
SQLite extensions
Oliphaunt model
Exact PostgreSQL extension names
Migration action
Select extensions before opening and verify package contents.
SQLite assumption
Multiple library handles
Oliphaunt model
Mode-specific sessions
Migration action
Use server mode when independent PostgreSQL clients are required.
| SQLite assumption | Oliphaunt model | Migration action |
|---|---|---|
| One database file | PostgreSQL root directory | Move data movement to SDK backup and restore APIs. |
| Pragmas | PostgreSQL settings and durability profiles | Choose startup and durability configuration through the SDK. |
| SQLite extensions | Exact PostgreSQL extension names | Select extensions before opening and verify package contents. |
| Multiple library handles | Mode-specific sessions | Use server mode when independent PostgreSQL clients are required. |
Concept Map
| SQLite concept | Oliphaunt concept |
|---|---|
| One database file | One PostgreSQL root directory |
| Pragmas | PostgreSQL settings and SDK durability profiles |
| SQLite transaction | PostgreSQL transaction |
| SQLite extension loading | Exact PostgreSQL extension selection before open |
| File copy backup | SDK backup/export API |
| Multiple library handles | Mode-specific Oliphaunt handles and session semantics |
Schema And SQL Differences
PostgreSQL is stricter and richer than SQLite:
- column types and casts matter more;
SERIAL,IDENTITY, sequences, arrays, JSONB, and enums replace many SQLite-specific conventions;- PostgreSQL query parameters are
$1,$2, and so on; - constraints, indexes, and generated columns follow PostgreSQL syntax;
- extension-backed types and operators require exact extension selection.
Start with a small schema slice. Port table definitions, then migrate one query path at a time so type and constraint differences are visible early.
Storage And Backup
SQLite apps often back up by copying one file. Oliphaunt live storage is a PostgreSQL root directory, so data movement goes through SDK backup and restore APIs. That keeps locks, WAL, selected extensions, archive format, and restore target checks together.
For mobile apps, keep the root in app-private storage and use the platform's normal user-data protection choices. For desktop apps, choose direct, broker, or server mode based on the concurrency and process-isolation model your app needs.
Migration Path
- Choose the SDK for the app target.
- Open a temporary Oliphaunt root and port the schema.
- Port read paths before write-heavy sync/import paths.
- Add selected extensions explicitly.
- Add backup/restore and package-size checks before shipping.
- Compare app-start, first-query, memory, and package-size numbers against the SQLite baseline.
When SQLite Is Still The Better Fit
Use Oliphaunt when PostgreSQL compatibility, richer SQL, extensions, and server-compatible workflows are worth the larger runtime and directory storage model. Use SQLite when a tiny single-file dependency and SQLite-specific semantics are the better fit.