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 GitHubAPI 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.
Which package should I choose for queries?
Which package should I choose for queries?
For React or React Native apps:
-
The
@powersync/reactpackage 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-querypackage extends theuseQueryhook from@powersync/reactwith 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).
@powersync/vue.Installation
Add the PowerSync Web NPM package to your project:- npm
- yarn
- pnpm
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. The available column types aretext, 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. Example:3. Integrate with Your Backend
The backend connector connects the PowerSync client SDK to your application backend. The SDK uses it to:- Get an auth token to connect to the PowerSync instance.
- 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.
- 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. - 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.
4. Subscribe to Sync Streams
Streams defined withauto_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.
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:- PowerSyncDatabase.get - get (
SELECT) a single row from a table. - PowerSyncDatabase.getAll - get (
SELECT) a set of rows from a table. - PowerSyncDatabase.watch - execute a read query every time a dependent table changes.
- PowerSyncDatabase.execute - execute a write (
INSERT/UPDATE/DELETE) query.
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 (returnsnull 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.- AsyncIterator approach
- Callback approach
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, If you need direct table writes, use raw tables.
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:Configure Logging
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:- npm
- yarn
- pnpm
Developer Notes
Connection Methods
This SDK supports two methods for streaming sync commands:- HTTP Streaming (Default)
- This is the default and recommended connection method.
- WebSocket
- This implementation uses RSocket over WebSocket connections.
- To customize window sizes for flow control and back-pressure, set
fetchStrategytoBuffered(default) orSequential. - On the web, there is no compelling reason to use WebSockets over HTTP response streams.
PowerSyncDatabase.connect() method uses HTTP streaming. You can optionally specify the connectionMethod to override this:
SQLite Virtual File Systems
This SDK supports multiple Virtual File Systems (VFS), each responsible for storing the local SQLite database. The VFS you choose determines where data persists, how multiple browser tabs interact with the database, and whether concurrent reads are possible.1. IDBBatchAtomicVFS (Default)
The default VFS for applications that need the broadest browser compatibility. It uses IndexedDB for storage. Multiple tabs are fully supported across most modern browsers, and no additional configuration is needed.2. OPFS-Based Alternatives
PowerSync supports three OPFS (Origin Private File System) implementations that are generally faster than IndexedDB: OPFSCoopSyncVFS Recommended for applications requiring multi-tab support, especially on Safari/iOS. This implementation provides multi-tab support across all major browsers and offers the most reliable compatibility with Safari and Safari iOS. Example configuration:additionalReaders option (defaults to 1) controls how many extra read-only database connections PowerSync opens alongside the primary connection. Increase it when you routinely run many read queries at once; each extra reader uses more memory. The useWebWorker flag must not be set to false, because this setup relies on web workers.
Example configuration with 2 additional readers (3 total concurrent reads):
3. In-Memory VFS
Since version 1.39.0 of the@powersync/web package, you can use an in-memory database with WASQLiteVFS.InMemoryVfs. It runs queries faster than any other single-threaded VFS (both IndexedDB and OPFS, except the write-ahead VFS).
No data is persisted: local writes are lost if they aren’t uploaded before the tab is closed, and all data is resynced whenever
a tab is opened. This makes it unsuitable for apps that need to work offline, but a good fit for:
- Development, where starting from a fresh database on every load makes it easy to reproduce issues from a clean state.
- Online-only apps with very frequent queries and small datasets.
enableMultiTabs flag.
If support for multi-tabs is not desired, consider giving each tab a uniquely-named PowerSync instance. The in-memory database
would not be shared across tabs in either case, but only one PowerSync database with the same name can sync at a time.
Unique names ensure databases across tabs are fully independent:
VFS / Option Compatibility Matrix
There are known issues with OPFS (all variants) in Safari’s incognito mode.
Multi-Threaded In-Memory SQLite Connection Pool
Since version 2.2.0, the@powersync/web package provides an experimental, per-tab in-memory SQLite connection pool for highly concurrent query workloads. It uses a design inspired from OPFSWriteAheadVFS, but relies on SharedArrayBuffer to coordinate an in-memory database instead of persisting to OPFS. It is available under a separate import and is thus configured via the opened option on PowerSyncDatabase instead of database.vfs.
This setup is experimental and might change in the future.
numWorkers SQLite connections in dedicated web workers. One worker is the designated writer, while the remaining workers are used as additional readers. The writer can also serve reads while it is idle.
Read-only transactions can execute in parallel, including while the writer appends changes to a custom in-memory write-ahead overlay. The database and write-ahead-log buffers are backed by growable SharedArrayBuffer objects shared across the workers. This parallelism benefits workloads with overlapping queries. It does not inherently make an individual sequential query faster, and additional workers increase startup time and memory usage.
Each pool instance is independent and belongs to one tab. Its data is not persisted or shared across tabs, and the application cannot assign it a database filename. Opening or refreshing a tab creates a fresh database that must be resynced. Any local writes that have not been uploaded are lost when the tab closes.
This option requires cross-origin isolation and browser support for growable SharedArrayBuffer.
This connection pool is primarily relevant when all of the following apply:
- You need highly concurrent, high-performance queries in your app.
- At the same time, the overall database size (or at least the actively synced part of the database) is relatively small, as it gets synced every time a tab is opened.
- You don’t need persistence.
- You can enable cross-origin isolation by using the appropriate headers. Without cross-origin isolation and shared array buffers, constructing the pool will throw.
- You don’t need multiple tabs to share offline state.
Managing OPFS Storage
Unlike IndexedDB, OPFS storage cannot be managed through browser developer tools. The following utility functions can help you manage OPFS storage programmatically:Multiple Tab Support
Using PowerSync between multiple tabs is supported on most desktop browsers. Multiple tab support relies on shared web workers for database and sync operations. When enabled, the SDK creates a shared web worker namedshared-powersync-[dbFileName].
The shared sync worker connects to the PowerSync Service and applies changes to the database on behalf of all tabs. It calls the fetchCredentials and uploadData methods of the most recently opened tab. When that tab closes, the worker uses the previously opened tab instead. When using an IndexedDB-based VFS, the SDK can also open database connections in a shared worker so that writes made in one tab are instantly available in the others.
Multi-tab support is enabled by default where available. You can disable it with the enableMultiTabs flag:
Behavior Without Shared Workers
When multi-tab support is disabled, whether explicitly or because the platform does not support it, each tab spawns a standard web worker for database operations. These workers can safely operate on the database concurrently. Only one tab connects and syncs at a time, and only that tab’sfetchCredentials and uploadData methods are called.
The SDK still tries to share state across tabs using broadcast channels (since version 2.1.0 of the SDK): update notifications for watched queries, the sync status (fields like hasSynced and download progress), and sync stream subscriptions made in any tab. This is less reliable than shared workers, so updates may not reach every tab.
Using PowerSyncDatabase Flags
ThePowerSyncDatabase constructor accepts the following flags. Use them to enable or disable specific features.
Configuring Options
You can configure these options during the initialization ofPowerSyncDatabase as top-level constructor properties.
Available Flags
default:
true (false on Android, iOS, and Safari)Enables support for multiple tabs using shared web workers. When enabled, multiple tabs share the same database and sync connection.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:
falseEnables SSR mode. In this mode, only empty query results will be returned, and syncing with the backend is disabled.default:
trueEnables the use of web workers for database operations. Disabling this flag also disables multi-tab support.Flag Behavior
Example 1: Multi-Tab Support By default, multi-tab support is enabled if supported by the browser. To explicitly disable this feature:Recommendations
- Set
enableMultiTabstotrueif your application shares data across multiple tabs. - Set
broadcastLogstotrueduring development to troubleshoot and monitor database and sync operations.