refactor(sdk): remove obsolete SQLite WASM path

.changeset/remove-sdk-sqlite-wasm.md

@@ -0,0 +1,5 @@
+---
+"@inlang/sdk": patch
+---
+
+Remove the obsolete SQLite WASM dependency, public schema initializer, and special handling for unsupported legacy database artifacts. The SDK database API uses Lix through Kysely's PostgreSQL query compiler.

docs/architecture.md

@@ -4,7 +4,7 @@ Inlang is the open-format TMS (translation management system) for software teams
 
 ```
 ┌─────────────────────────────────────────────┐
-│  Storage (SQLite + version control via Lix) │
+│  Storage and version control (Lix)          │
 ├─────────────────────────────────────────────┤
 │  Data Model (Bundle, Message, Variant)      │
 ├─────────────────────────────────────────────┤
@@ -14,9 +14,9 @@ Inlang is the open-format TMS (translation management system) for software teams
 
 ## Storage
 
-An `.inlang` project is canonically a single binary file: a SQLite database with version control via [lix](https://lix.dev). Like `.sqlite` for relational data, `.inlang` packages localization data into one file that tools can share.
+An `.inlang` project is canonically a portable snapshot backed by [Lix](https://lix.dev). It packages localization data and project files into one file that tools can share.
 
-For Git repositories, the binary file can be unpacked into a directory of plain files so changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
+For Git repositories, the packed file can be unpacked into a directory of plain files so changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
 
 Inlang defines the localization format and TMS surface. Lix provides the underlying versioning, history, review, change proposals, rollback, and merging infrastructure.
 

docs/getting-started.md

@@ -6,7 +6,7 @@ Store translations in your repo as a vendor-neutral file format, so developers,
 
 Use inlang when localization data needs to be shared across tools, teams, automations, or coding agents. If you only need an app runtime with a couple of translation files, your current i18n setup may already be enough.
 
-An `.inlang` project is canonically a single binary file: a SQLite database with version control via [lix](https://lix.dev). Inlang defines the localization format and TMS surface. Lix provides the underlying versioning, history, review, change proposals, and rollback infrastructure.
+An `.inlang` project is canonically a portable snapshot backed by [Lix](https://lix.dev). Inlang defines the localization format and TMS surface. Lix provides the underlying storage, versioning, history, review, change proposals, and rollback infrastructure.
 
 For Git repositories, the file can be unpacked into a directory of plain files. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
 

docs/introduction.md

@@ -6,7 +6,7 @@ Inlang is the open-format TMS (translation management system) for software teams
 
 Store translations in your repo as a vendor-neutral file format, so developers, translators, CI, translation tools, and AI agents can read and update the same localization source of truth.
 
-An `.inlang` project is canonically a single binary file: a SQLite database with version control via [lix](https://lix.dev). Like `.sqlite` for relational data, `.inlang` packages localization data into one file that tools can share.
+An `.inlang` project is canonically a portable snapshot backed by [Lix](https://lix.dev). It packages localization data and project files into one file that tools can share.
 
 The `@inlang/sdk` is the reference implementation for reading and writing `.inlang` projects.
 
@@ -16,7 +16,7 @@ Inlang defines the localization format and TMS surface. [Lix](https://lix.dev) p
 
 Messages, variants, and locale data live in the `.inlang` database. External translation files such as `messages/en.json` are compatibility files outside `project.inlang/`, connected through plugins.
 
-For Git repositories, the binary file can be unpacked into a directory of plain files so changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
+For Git repositories, the packed file can be unpacked into a directory of plain files so changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
 
 The SDK has two main parts:
 

docs/unpacked-project.md

@@ -2,7 +2,7 @@
 
 ## What is an unpacked project?
 
-An unpacked project is the Git-friendly representation of an `.inlang` file. The canonical `.inlang` format is a single binary file: a SQLite database with version control via [lix](https://lix.dev). The unpacked directory exists so changes can be reviewed alongside code.
+An unpacked project is the Git-friendly representation of an `.inlang` file. The canonical `.inlang` format is a portable snapshot backed by [Lix](https://lix.dev). The unpacked directory exists so changes can be reviewed alongside code.
 
 Messages, variants, and locale data live in the `.inlang` database. In unpacked Git projects, `settings.json` is the only tracked project file by default; translation files such as `messages/en.json` live outside `project.inlang/` and are connected through plugins.
 
@@ -21,8 +21,8 @@ project.inlang/
 
 |                  | Packed (`.inlang` file)           | Unpacked (directory)                  |
 | ---------------- | --------------------------------- | ------------------------------------- |
-| **Format**       | Canonical single binary file      | Git-friendly directory representation |
-| **Git-friendly** | No (binary)                       | Yes (diffable, mergeable)             |
+| **Format**       | Canonical portable snapshot       | Git-friendly directory representation |
+| **Git-friendly** | Limited                           | Yes (diffable, mergeable)             |
 | **Portable**     | Yes (one file to share)           | No                                    |
 | **Use case**     | Sharing, backups, tools like Fink | Storing in git repos                  |
 
@@ -32,12 +32,12 @@ project.inlang/
 
 Most codebases use git for version control. Developers want their translations co-located with their code — not in a separate system.
 
-### Git doesn't handle binary files well
+### Packed snapshots are difficult to review in Git
 
-An `.inlang` file is binary. Git can store binary files, but you lose:
+Git can store a packed `.inlang` snapshot, but it is not organized for review:
 
-- **Readable diffs** — Binary changes show as "file changed", not what changed
-- **Merge conflict resolution** — Git can't merge binary files
+- **Readable diffs** — Snapshot changes do not map cleanly to project files
+- **Merge conflict resolution** — Snapshot-level conflicts are difficult to resolve
 - **Code review** — Teammates can't review translation changes in PRs
 
 An unpacked project solves this for the project configuration. The generated `.gitignore` keeps `settings.json` in Git and ignores generated/cache files. Translation files are stored outside `project.inlang/` according to plugin configuration.

docs/version-control.md

@@ -4,7 +4,7 @@ Inlang uses [Lix](https://lix.dev) for versioning, history, review, change propo
 
 Inlang defines the localization format and TMS surface. Lix provides the version-control layer underneath the `.inlang` project, so localization changes can be reviewed and merged without turning a vendor database into the source of truth.
 
-An `.inlang` project is canonically a single binary file. For repositories, it can be unpacked into plain files so localization changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the repository-friendly representation.
+An `.inlang` project is canonically a portable snapshot. For repositories, it can be unpacked into plain files so localization changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the repository-friendly representation.
 
 Use this layer for:
 

docs/write-tool.md

@@ -6,7 +6,7 @@ This guide walks through building a tool that flags missing translations. By the
 
 Tools read and write translations through the `.inlang` format via the CRUD API. Because plugins handle conversion at the boundary, your tool works with any translation format — JSON, XLIFF, i18next, etc. — without parsing each one directly.
 
-An `.inlang` project is canonically a single binary file. In Git repositories, it is often unpacked into a directory; `loadProjectFromDirectory()` loads that Git-friendly representation.
+An `.inlang` project is canonically a portable snapshot. In Git repositories, it is often unpacked into a directory; `loadProjectFromDirectory()` loads that Git-friendly representation.
 
 If a `project.inlang/` directory already exists, load it with `loadProjectFromDirectory()`. If your tool is generating a new localization project from scratch, start with `newProject()` and save the packed file with `project.toBlob()`; see [Getting Started](/docs/getting-started) for a runnable create-save-reload example.
 

packages/sdk/README.md

@@ -22,9 +22,9 @@ The inlang SDK is the reference implementation for reading and writing `.inlang`
 
 `.inlang` files are designed to become the open standard for localization data and make i18n tools work together. Build editors, CLIs, runtimes, agents, and plugins on the same shared project format instead of inventing another file structure.
 
-An `.inlang` project is canonically a single binary file: a SQLite database with version control via [lix](https://lix.dev). Like `.sqlite` for relational data, `.inlang` packages localization data into one file that tools can share.
+An `.inlang` project is canonically a portable snapshot backed by [Lix](https://lix.dev). It packages localization data and project files into one file that tools can share.
 
-For Git repositories, the binary file can be unpacked into a directory of plain files so changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
+For Git repositories, the packed file can be unpacked into a directory of plain files so changes can be reviewed alongside code. The packed file is the canonical format; the unpacked directory is the Git-friendly representation.
 
 `.inlang` is the canonical project format. Plugins import and export formats like JSON, ICU MessageFormat v1, i18next, and XLIFF for compatibility with existing translation files and runtimes. Version control via lix adds file-level history, merging, and change proposals to `.inlang` projects.
 
@@ -68,7 +68,7 @@ For coding agents:
 ## Getting Started
 
 > [!Note]
-> Inlang files are single binary files. They can be unpacked and [stored as directories](#unpacked-inlang-files-directories) when you want to review changes in Git. The packed file remains the canonical format.
+> Inlang projects are portable snapshots. They can be unpacked and [stored as directories](#unpacked-inlang-files-directories) when you want to review changes in Git. The packed file remains the canonical format.
 
 ### Installation
 
@@ -259,7 +259,7 @@ await project.settings.set(settings)
 > [!NOTE]  
 > Unpacked inlang files are the Git-friendly representation of packed `.inlang` files.
 >
-> Git can store binary files, but plain-file review and merge workflows work better with the unpacked directory. **If you don't intend to store the inlang file in git, use the packed binary file.**
+> Git can store packed snapshots, but plain-file review and merge workflows work better with the unpacked directory. **If you don't intend to store the inlang file in git, use the packed file.**
 > 
 > Unpacked inlang files are not portable. They depend on plugins and do not persist [version control via lix](https://lix.dev/) data.