Sqldelight wasm searches often assume that an existing JavaScript or native database setup can be moved directly to WebAssembly. That assumption is risky. Generated Kotlin APIs may compile for a target while the database driver, storage backend, threading model or browser persistence layer still requires separate validation.
Separate code generation from runtime storage
Sqldelight has two important layers. The compiler reads SQL and generates Kotlin interfaces. A runtime driver executes statements and manages a real database. A successful wasm compilation does not automatically prove that a suitable driver exists for the browser or host environment.
Review the current platform matrix
The public platform overview highlights JavaScript browser and Node targets alongside Android, JVM and Native platforms. Treat wasm as a target-specific integration project. Confirm support in the exact Sqldelight, Kotlin and driver versions you intend to ship.
Questions to answer before implementation
- Which persistent storage API is available in the host environment?
- Does the selected driver explicitly support the wasm target?
- How are database files or browser storage initialized and upgraded?
- Are transactions, concurrency and query listeners supported?
- Can automated tests run in the same environment as production?
Keep common code driver-agnostic
Shared code should depend on the generated database interface, not on a browser-specific constructor. Define a small driver factory interface in common code and implement it per platform. This makes it possible to use a JavaScript driver, a wasm-capable driver or an in-memory test driver without changing repository logic.
interface DatabaseDriverFactory {
fun createDriver(): SqlDriver
}
fun createDatabase(factory: DatabaseDriverFactory): AppDatabase {
val driver = factory.createDriver()
AppDatabase.Schema.create(driver)
return AppDatabase(driver)
}Plan persistence and upgrades
Browser storage can be cleared by users or policies, and persistence guarantees differ from a native file system. Define how the product behaves when storage is unavailable, reset or migrated. Do not assume a mobile backup strategy applies to a web deployment.
Testing strategy
Run shared query tests against a dependable temporary driver, then add integration tests in the actual wasm or browser environment. Include page reloads, multiple tabs, migration from an older schema, storage denial and interrupted writes.
Fallback options
If the required driver is not mature, keep the repository interface stable and use a supported JavaScript target, a remote service or a simpler browser storage adapter until the wasm database stack meets reliability requirements.