Skip to main content
The PowerSync JavaScript Web SDK runs SQLite in the browser and keeps it in sync with your backend database. Your UI reads and writes local data directly, so interactions feel instant because they do not wait on network round trips. Watch queries emit new results as local or synced data changes, keeping the UI current without polling. With Sync Streams, you define the subset of backend data each client receives rather than replicating the entire database into every browser. This partial sync reduces data transfer and local storage use by keeping unrelated data out of the client database. Reading from a reactive local database also reduces the need for per-screen read APIs, cache invalidation, and client-side state plumbing. Synced data remains available even when connectivity is interrupted, enabling offline-first PWAs.
Build with AI

PowerSync SDK on NPM

This SDK is distributed via NPM

Source Code

Refer to packages/web in the powersync-js repo on GitHub

API Reference

Full API reference for the SDK

Example Projects

Gallery of example projects/demo apps built with JavaScript Web stacks and PowerSync

Changelog

Changelog for the SDK

SDK Features

  • Real-time streaming of database changes: Changes made by one user are instantly streamed to all other users with access to that data. This keeps clients automatically in sync without manual polling or refresh logic.
  • Direct access to a local SQLite database: Data is stored locally, so apps can read and write instantly without network calls. This enables offline support and faster user interactions.
  • Asynchronous background execution: The SDK performs database operations in the background to avoid blocking the application’s main thread. This means that apps stay responsive, even during heavy data activity.
  • Query subscriptions for live updates: The SDK supports query subscriptions that automatically push real-time updates to client applications as data changes, keeping your UI reactive and up to date.
  • Automatic schema management: PowerSync syncs schemaless data and applies a client-defined schema using SQLite views. This architecture means that PowerSync SDKs handle schema changes without explicit migrations on the client side.

Single-Page Application (SPA) Frameworks

The PowerSync JavaScript Web SDK is compatible with popular Single-Page Application (SPA) frameworks like React, Vue, Angular, and Svelte. Integration packages are provided specifically for the following:

React Hooks

Wrapper package to support reactivity and live queries.

Vue Composables

Wrapper package to support reactivity and live queries.

TanStack Query & DB

PowerSync integrates with TanStack Query and TanStack DB for reactive data management.

Nuxt Module

PowerSync Nuxt module to build offline/local first apps using Nuxt.
For React or React Native apps:
  • The @powersync/react package is best for most basic use cases, especially when you only need reactive queries with loading and error states.
  • For more advanced scenarios, such as query caching and pagination, use TanStack Query. The @powersync/tanstack-react-query package extends the useQuery hook from @powersync/react with functionality from TanStack Query.
  • For reactive data management and live query support across multiple frameworks, consider TanStack DB. PowerSync works with all TanStack DB framework adapters (React, Vue, Solid, Svelte, Angular).
If you have a Vue app, use the Vue-specific package: @powersync/vue.

Installation

Add the PowerSync Web NPM package to your project:

Getting Started

Prerequisites: Before you start, connect your source database to the PowerSync Service and deploy Sync Streams. These are steps 1-4 in the Setup Guide.

1. Define the Client-Side Schema

The client-side schema defines the tables and columns of the SQLite database that the PowerSync client SDK manages and that your app reads from and writes to. It is usually derived from your backend database schema and your Sync Streams, and it can also include local-only tables. You apply the schema when you instantiate the database in the next step. Schema migrations are not required. The SDK syncs schemaless data and applies the schema to that data with SQLite views. The exception is raw tables, which you create and migrate yourself.
Generate schema automaticallyIn the PowerSync Dashboard, select your project and instance and click the Connect button in the top bar to generate the client-side schema in your preferred language. The schema is generated from your Sync Streams. The CLI offers the same function.The generated schema does not include an id column. The client SDK creates an id column of type text automatically, so you do not need to declare it. See Client ID for details.
The available column types are text, integer, and real. These should match the values produced by your Sync Streams. If a value does not match, it is cast automatically. For details on how source database types map to SQLite types, see Types. Example:
You do not need to declare an id column. PowerSync creates it automatically.

2. Instantiate the PowerSync Database

Next, instantiate the PowerSync database. PowerSync streams changes from your backend source database into the client-side SQLite database, based on your Sync Streams. Your app reads from and writes to this local database whether the user is online or offline. The example selects vfs: 'auto' (@powersync/web version 2.7.0 and later). If you omit vfs, the SDK uses IndexedDB for backward compatibility. Review VFS selection for guidance. Example:
After you instantiate the PowerSync database, call the connect() method to sync data with your backend.
This section assumes that you use PowerSync to sync your backend source database with SQLite in your app. To manage a local SQLite database without sync, instantiate the PowerSync database without calling connect() and see the Local-Only guide.

3. Integrate with Your Backend

The backend connector connects the PowerSync client SDK to your application backend. The SDK uses it to:
  1. Get an auth token to connect to the PowerSync instance.
  2. Upload client-side writes to your backend API. The SDK places every write to the SQLite database in an upload queue and uploads the queue to your backend when the user is connected. Your backend then applies the changes to the source database.
The connector must implement two methods:
  1. PowerSyncBackendConnector.fetchCredentials - The SDK calls this method to get authentication credentials. It caches the credentials and calls the method again only when needed, for example on the first connection or when the token is near expiry. See When fetchCredentials() is Called for details and Authentication Setup for how to generate credentials.
  2. PowerSyncBackendConnector.uploadData - The SDK calls this method whenever it has client-side writes to upload to your backend API. Implement how those writes are processed and uploaded. See When uploadData() is Called for triggers, throttling, and retry behavior, and Writing Client Changes for the app backend implementation.
Example:

4. Subscribe to Sync Streams

Streams defined with auto_subscribe: true start syncing as soon as the client connects. For all other streams, your app must subscribe before their data downloads. The basic pattern is: subscribe to a stream, wait for its data to sync, then unsubscribe when the data is no longer needed.
If you use React, the useQuery hook accepts a streams option and the useSyncStream hook manages a subscription for you. See Framework Integrations. After you unsubscribe, the synced data stays in the local database for the stream’s time-to-live (TTL), which is 24 hours by default. If the app subscribes again within that time, the data is already available. See Client-Side Usage for framework hooks, per-subscription sync status, custom TTLs, priority overrides, and connection parameters.

Using PowerSync: CRUD Functions

Once the PowerSync database is connected and your streams have synced, the data is in the local SQLite database. The most commonly used CRUD functions to interact with your SQLite data are:

Fetching a Single Item

The get method executes a read-only (SELECT) query and returns a single result. It throws an exception if no result is found. Use getOptional to return a single optional result (returns null if no result is found).

Querying Items (PowerSync.getAll)

The getAll method returns a set of rows from a table.

Watching Queries (PowerSync.watch)

The watch method executes a read query whenever a change to a dependent table is made.
For advanced watch query features such as incremental updates and differential results, see Live Queries / Watch Queries.

Mutations (PowerSync.execute, PowerSync.writeTransaction)

The execute method can be used for executing single SQLite write statements.
When using the default client-side JSON-based view system, writes are applied to a view, with triggers writing to the underlying table. Because of this, result.rowsAffected from db.execute() can be 0 even when an UPDATE or DELETE succeeds.When you need to confirm whether a mutation changed any rows, add a RETURNING clause and check the returned rows:
If you need direct table writes, use raw tables.

Waiting for the Latest Server Data

The queries and mutations above run against the local database. PowerSync uploads local writes and downloads server changes in the background, so local data can briefly lag behind the server. To make sure local data is up to date at a specific moment, such as on pull-to-refresh or when a user opens a link to a record, create a checkpoint request and wait for it to sync. The wait also covers pending local writes: it completes after they have uploaded and their result has synced back. This alpha API requires PowerSync Service v1.24.0 or later and a supported SDK version.

Configure Logging

Enable verbose output in the developer tools for detailed logs. Note that the PowerSync SDK relies on web workers, which inherit the logger from the main database while using a separate log level. To pass a consistent log level to workers, also pass it to the sync and database workers:
Additionally, the WASQLiteOpenFactory opens SQLite connections inside a shared web worker. This worker can be inspected in Chrome by accessing:

Additional Usage Examples

For more usage examples including accessing connection status, monitoring sync progress, and waiting for initial sync, see the Usage Examples page.

ORM Support

See JavaScript ORM Support for details.

Vite Quickstart Tutorial

Template repo: vite-react-ts-powersync-supabase

Troubleshooting

See Troubleshooting for pointers to debug common issues.

Supported Platforms

See Supported Platforms -> JS/Web SDK.

Upgrading the SDK

Run the following command in your project folder:

Developer Notes

Browser Storage and Multiple Tabs

For storage recommendations, persistence, and browser compatibility, see SQLite Virtual File Systems. For how tabs share local data and sync connections, see Multiple Tab Support.

Connection Methods

This SDK supports two methods for streaming sync commands:
  1. HTTP Streaming (Default)
    • This is the default and recommended connection method.
  2. WebSocket
    • This implementation uses RSocket over WebSocket connections.
    • To customize window sizes for flow control and back-pressure, set fetchStrategy to Buffered (default) or Sequential.
    • On the web, there is no compelling reason to use WebSockets over HTTP response streams.
By default, the PowerSyncDatabase.connect() method uses HTTP streaming. You can optionally specify the connectionMethod to override this:

Using PowerSyncDatabase Flags

The PowerSyncDatabase constructor accepts the following flags. Use them to enable or disable specific features.

Configuring Options

Set database options inside database. Set broadcastLogs at the top level of the PowerSyncDatabase constructor options:

Available Flags

default: true when shared workers are available, except on Android, iOS, and SafariControls whether tabs share one sync connection through a shared worker. Depending on the VFS, they may also share a database connection. Setting this option to false does not prevent a supported VFS from providing multi-tab database access. Requires browser support for shared workers.
default: trueEnables the broadcasting of logs for debugging purposes. This flag helps monitor shared worker logs in a multi-tab environment.
default: falseDisables warnings when running in SSR (Server-Side Rendering) mode.
default: false in the browser; true when window is not definedEnables SSR mode. In this mode, only empty query results will be returned, and syncing with the backend is disabled.
default: trueRuns database operations in web workers. If you disable this option, also set enableMultiTabs: false.

Flag Behavior

Example 1: Disable Shared-Worker Mode To give each tab its own sync implementation instead of using a shared sync worker:
When disabled, each tab manages its own sync implementation, but only one tab syncs at a time for a given database name. See Behavior Without Shared Workers. Example 2: Verbose Debugging To enable detailed logging for debugging:
Logs include details of database and sync operations.

Recommendations

  1. Choose a VFS that supports multi-tab database access if tabs must use the same local data.
  2. Leave enableMultiTabs at its default to use shared-worker mode where the SDK enables it. Setting it to false disables shared workers, not all multi-tab database access.
  3. Set broadcastLogs to true during development to troubleshoot and monitor database and sync operations.