# PowerSync — full text

Every blog post and legal page on https://powersync.com, concatenated.
Individual documents are served as markdown at the same URL with a `.md` suffix (for example https://powersync.com/blog/<slug>.md).

# How smry.ai Fixed Agentic Development Velocity Using PowerSync

> smry’s founder built his own sync engine which started feeling like a quagmire for his coding agents. Shipping code changes was slow and brittle. He replaced it with PowerSync.

- Published: 2026-10-19
- Author: Kobie Botha
- Category: Showcase
- Source: https://powersync.com/blog/how-smry-replaced-its-homegrown-sync-engine-with-powersync

---

Michael is the founder of [smry](http://smry.ai), an all-in-one clean reader, read-it-later and archiving tool with >300k MAUs. Michael was inspired by Linear’s UX, and built smry with instant reactivity at the core of the app. To achieve this, he cobbled together his own sync engine using IndexedDB, R2 and Redis. He ran into a bunch of issues with this architecture. In this post, we’ll be describing why and how he switched to PowerSync, and what the outcome was.

## How smry began

Michael had one primary requirement for smry’s web UI from day one: everything the user did needed to be instant. Opening of history? Clicking on an article? Navigation? All instant. Additionally, he had a long term vision of a mobile app for smry, which would need to support offline reading mode. It was also important to him that users of smry felt like they owned the content, and the best way to achieve that was to store the data in the browser using IndexedDB, as well as his backend DB (Neon).

His initial architecture was quite simple:

![smry’s initial architecture, with custom article sync code connecting IndexedDB and Neon Postgres](https://powersync.com/images/blog/smry/smry-initial-sync-architecture.png)

One issue with this architecture was that it wasn’t feasible to sync attachments into Postgres, so R2 was used for attachments on the backend, and `localStorage` on the client:

![smry’s attachment architecture, adding custom sync code between browser storage, Neon Postgres and R2](https://powersync.com/images/blog/smry/smry-attachment-sync-architecture.png)

This architecture still didn’t deliver on the instant UI promise though, so Redis was added to speed up DB queries:

![smry’s expanded architecture, with separate article, content cache, and chat, highlights and notes sync code connecting browser storage to Neon Postgres, R2 and Redis](https://powersync.com/images/blog/smry/smry-redis-sync-architecture.png)

At this point, everything was miraculously working. There was one snag, however. The system was incredibly complex and hard to reason about, and coding agents would constantly be breaking stuff.

In Michael’s own words:

> Honestly, Redis was the thing that made this work, because basically Redis was caching everything, and even if something broke, Redis would just cache it and the user would get something in a reasonable amount of time. Much faster than a database call. But it's still not fast enough. Redis isn't literally instant. There's still latency, especially depending on where the user is in the world. A lot of users are not in the US, so they don't have good internet connections.
>
> The biggest problem for me was development velocity, to be honest. And whenever I'd deploy, I'd be like, "Where are my agents breaking something?” Honestly, the code got really, really messy.
>
> Also, whenever I would change my database schema, IndexedDB would also be very, very annoying and break, right? Because I was doing database migrations, but IndexedDB doesn't care about your database. So, that was a massive problem. So I knew I needed some sync layer created with a little bit more foresight.

## Michael sends out an SOS

![Michael’s post on X asking for stable IndexedDB-to-Postgres sync that works with his existing database, similar to Linear’s sync engine with less custom code](https://powersync.com/images/blog/smry/smry-michael-sync-sos.png)

After a casual chat between Michael and Kobie on X, Michael was intrigued:

> My goals for a migration to PowerSync was, hey, massively simpler code, right?

The PowerSync FDE team jumped in to show Michael what smry could look like with PowerSync, and the app was migrated to a PowerSync architecture:

![smry’s PowerSync architecture: Neon Postgres syncs through the PowerSync Service to the Web SDK, writes use the existing Next.js app, and built-in attachment management connects to R2](https://powersync.com/images/blog/smry/smry-powersync-architecture.png)

We’ll let Michael describe the benefits of this architecture in his own words:

> With PowerSync at the core of smry, it made me much more excited about expanding the product. Now efforts are going into a mobile app because, hey, this is now much easier to think about with a mobile app, right? Now that we have PowerSync, it allows for a lot more developer velocity. Now I don't check my sync layer every time I want to push a fix.
>
> And yes, the biggest thing for me was agents. So smry, a one-person project, I don't have time to learn new PowerSync skills. Agents seem to grok PowerSync. And at this point I can make changes without worrying that an agent's going to f\*\*\* up my DB or f\*\*\* up my sync or f\*\*\* up something else, which is quite nice. And so overall, the biggest unlock with PowerSync was development velocity. Because now I could, like, change things on my app.
>
> Actually, there was a massive set of migrations that I needed to do, and I was delaying them because of the sync layer problem, because these migrations would make the sync layer just, like, much more complex. And now, with PowerSync, I could actually, like, redesign the app, make migrations, make massive changes. People who aren't me can push code without me worrying that something massive just broke that I have to spend, you know, hours or days fixing. So right now, like, the app went through some major app redesigns, and this was actually, like, pretty much enabled by PowerSync, if I'm being perfectly honest.

If you’re considering adding sync to the core of your product, or if you rolled your own sync and any of this resonates - we’d love to [hear from you](https://calendly.com/powersync/powersync-chat).

## App Details

<div className="ps-cream-mdx-scroll" role="region" aria-label="smry app details" tabIndex="0">
  <table className="min-w-[720px] table-fixed! [&_th]:static! [&_th]:bg-transparent! [&_th]:text-sm! [&_th]:font-bold!">
    <colgroup>
      <col className="w-1/3 sm:w-1/2" />
      <col className="w-1/3 sm:w-1/4" />
      <col className="w-1/3 sm:w-1/4" />
    </colgroup>
    <tbody>
      <tr>
        <th scope="row">App Name</th>
        <td colSpan="2"><a href="https://smry.ai" target="_blank" rel="noopener noreferrer">smry</a></td>
      </tr>
      <tr>
        <th scope="row">Platforms</th>
        <td colSpan="2">Web, iOS Extension</td>
      </tr>
      <tr>
        <th scope="row">Source Database</th>
        <td colSpan="2">Neon</td>
      </tr>
      <tr>
        <th scope="row">Backend API Stack</th>
        <td colSpan="2">Next.js</td>
      </tr>
    </tbody>
    <tbody>
      <tr>
        <th scope="rowgroup" rowSpan="2">AI Services via Vercel AI SDK</th>
        <td>OpenRouter</td>
        <td>Main model gateway: Remy chat, summaries, explanations, and text-to-speech</td>
      </tr>
      <tr>
        <td>Groq</td>
        <td>Fast inference for article cleanup, translation, quizzes, mind maps, and briefings</td>
      </tr>
    </tbody>
    <tbody>
      <tr>
        <th scope="rowgroup">External AI Services</th>
        <td>Context.dev</td>
        <td>Article extraction, file parsing, web search, page reads, and research</td>
      </tr>
      <tr>
        <td rowSpan="5"></td>
        <td>Classifier.dev</td>
        <td>Article completeness checks, automatic tags, and feed relevance classification</td>
      </tr>
      <tr>
        <td>Configure.dev</td>
        <td>Remy’s personalization, user memory/profile context, and connected tools</td>
      </tr>
      <tr>
        <td>Cloudflare Workers AI</td>
        <td>File/image conversion and audio transcription using Whisper</td>
      </tr>
      <tr>
        <td>Pulpie</td>
        <td>ML-based extraction of an article’s main content from HTML</td>
      </tr>
      <tr>
        <td>Pangram</td>
        <td>AI authorship detection</td>
      </tr>
    </tbody>
    <tbody>
      <tr>
        <th scope="row">Client-side Frameworks</th>
        <td colSpan="2">React<br />PowerSync React hooks (<code>@powersync/react</code>)</td>
      </tr>
      <tr>
        <th scope="row">ORMs</th>
        <td colSpan="2">Drizzle<br />PowerSync Drizzle Driver (<code>@powersync/drizzle-driver</code>)</td>
      </tr>
      <tr>
        <th scope="row">Auth Provider</th>
        <td colSpan="2">Clerk</td>
      </tr>
      <tr>
        <th scope="row">PowerSync Deployment</th>
        <td colSpan="2">PowerSync Cloud</td>
      </tr>
    </tbody>
  </table>
</div>

---

# How HosTalky Uses PowerSync as the Sync Layer for Its AI-Powered Healthcare Platform

> I first met the HosTalky team in March of 2025 when they were looking for a Realm replacement. We’ve had a long working relationship and they’ve helped us make various product improvements during that time. In this post I chat to them about their healthcare platform.

- Published: 2026-09-28
- Author: Kobie Botha
- Category: Showcase
- Source: https://powersync.com/blog/how-hostalky-uses-powersync-ai-healthcare-platform

---

I first met the HosTalky team in March of 2025 when they were looking for a Realm replacement. We’ve had a long working relationship and they’ve helped us make various product [improvements](https://github.com/powersync-ja/powersync-js/issues/553) during that time. In this post I chat to them about their healthcare platform.

## Background

HosTalky is a clinical workflow intelligence platform for healthcare teams: secure one-to-one and group messaging between clinicians, organization-wide announcements, shared reminders and tasks, personal notes, and CareID, a verifiable digital identity for healthcare professionals. Its core feature is an AI-assisted clinical scribe that turns a spoken clinical encounter into a structured clinical note in formats such as SOAP, H&P, Physiotherapy, DAP and BIRP; the same pipeline can also produce meeting summaries, follow-ups and results reviews. The apps run on iOS, Android and desktop, and HosTalky has been accepted into a leading U.S. health-system accelerator program.

When the team first mapped every vendor that stores or transmits PHI, the obvious subsystems were considered - transcription, the LLM, cloud hosting and the database, but the sync layer wasn’t part of the list:

“Candidly, PowerSync was not on the first version of that map,” the team told us. “We added PowerSync once we recognized that syncing note and message data to client devices means PHI transits, and is processed by, the sync service — which makes it a business associate.” In this interview, HosTalky’s engineers explain how they closed that gap with a Business Associate Agreement (BAA) and a HIPAA compliant configuration, and why they deliver AI-generated notes to devices through sync rather than polling.

Two things make HosTalky an attractive PowerSync case study. The first is that the team uses sync as the delivery channel for AI output: when a clinician stops recording, the note is generated asynchronously on the server, and the device learns that it is finished the same way it learns about any other change — the record updates. I call this inference-in-the-loop sync: it’s essentially synced event sourcing. The second is that they had to fit a sync engine into a HIPAA compliance architecture, and they were candid with us about where that was harder than expected. The interview below has been lightly edited for length and clarity.

## App Details

| | |
| :- | :- |
| **App Name** | HosTalky |
| **Platforms** | iOS, Android, Desktop |
| **Source database** | MongoDB Atlas |
| **Bucket storage database** | MongoDB Atlas |
| **Backend API Stack** | GraphQL |
| **AI services** | Deepgram (real-time speech-to-text), OpenAI (note generation) |
| **Client-side frameworks** | Mobile: React Native (`@powersync/react-native`)<br />Desktop: Electron (`@powersync/web`)<br />PowerSync React hooks (`@powersync/react`) |
| **ORMs** | Drizzle |
| **Auth Provider** | AWS Cognito |
| **PowerSync Deployment** | PowerSync Cloud, HIPAA-compliant configuration with BAA |

## Interview

### The AI scribe

**PowerSync**  
Walk us through the AI note feature end to end: a clinician taps record, and then what happens? What runs on-device vs. server-side, and how do Deepgram + OpenAI fit in?

**HosTalky**  
A clinician taps record, and audio is captured on-device and streamed live to a dedicated WebSocket transcription service, which forwards it to Deepgram's real-time speech-to-text API. Deepgram streams back live captions during the recording, so the clinician sees text appear as they talk. When they stop, the client sends the accumulated transcript to our backend, which queues an async job and calls OpenAI to turn that transcript into a structured clinical note. The note updates in place once generation finishes.

In short: Deepgram handles live transcription in real time; OpenAI handles note generation afterward, asynchronously, server-side. The device captures the audio and displays the captions as Deepgram streams them back; the speech-to-text itself and the note generation both happen server-side.

![HosTalky’s AI scribe pipeline: live transcription during recording, asynchronous note generation when the clinician stops, and delivery of the finished note to every device via PowerSync](https://powersync.com/images/blog/how-hostalky-uses-powersync-ai-healthcare-platform-inline-architecture.png)

**PowerSync**  
Is one note backed by multiple recordings (for example, a clinician adding to the same note across a shift)?

**HosTalky**  
Yes. Each recording pass is its own session, and a single note can be backed by several of them. If a clinician records again later in the same shift, the new session is appended rather than overwriting what came before, and the note is regenerated from the full history each time.

**PowerSync**  
Do you keep the verbatim transcript or only the generated note?

**HosTalky**  
We keep both, so the clinician can check the transcript if they have any doubt about the note. We keep the verbatim, speaker-labeled transcript on the note indefinitely, alongside the generated note, with no automatic expiry. The raw audio itself is not persisted on our side: it is used momentarily for transcription and then discarded.

**PowerSync**  
Does the app treat an AI-generated note differently from one a clinician typed by hand?

**HosTalky**  
Yes, and whether a note was AI-generated is recorded on the note itself rather than inferred. It drives the client UI: the transcript tab, and on desktop a confirmation before recording over a manually typed note. Server-side it determines how a note update is processed, since a manually typed note is handled differently from an AI-generated one being regenerated.

**PowerSync**  
What are clinicians actually dictating - patient handovers, shift notes, personal reminders? Does any of it contain PHI?

**HosTalky**  
The substance of a clinical encounter - patient history, conditions, medications, assessment and plan - so yes, it routinely contains PHI. That is precisely why the scribe path is treated as an in-scope PHI flow end to end.

**PowerSync**  
Is AI anywhere in the messaging path, or only in notes?

**HosTalky**  
Only in the notes and scribe path; clinician messaging is a separate path with no AI in it. We do have a separate AI assistant in the app, Medigenie, but that is its own feature rather than something layered onto chat.

### Sync as the delivery channel for AI output

**PowerSync**  
When a note is being generated, the client doesn’t poll an endpoint for status, the generating state is stored on the note and syncs to the device like any other data. Was that a deliberate architectural choice, and what did it get you?

**HosTalky**  
Yes, deliberate. Generation status lives as a normal field on the note record and syncs down like any other data, rather than the client polling an endpoint for status. That gets us several things at once with no extra plumbing. The “generating” state survives an app restart, because it is just persisted data, not in-memory state tied to a live request. It works across devices automatically, since notes are scoped to the user rather than the device — if a note is generated on one device, any other device the clinician is logged into sees the same status update. And it needed no separate polling loop, retry logic, or push notification system, since PowerSync already handles keeping the client in sync.

**PowerSync**  
Did you build it that way from the start, or did you begin with request/response and move to sync after something broke?

**HosTalky**  
It started using synchronous API calls. Notes were originally generated through the same blocking request/response endpoint as everything else, so the clinician’s screen was stuck waiting until generation finished. For longer transcripts that wait got noticeably worse, since generation time scales with transcript length. That is what pushed us to move note generation onto an async job with status delivered via sync, so the client isn’t blocked waiting on the response and can move on while the note finishes generating in the background.

**PowerSync**  
Do you stream partial output into the note as tokens arrive, or write the whole note once generation completes?

**HosTalky**  
The whole note once generation completes — no token-by-token streaming. The generation step produces the full note text, then a single write updates the note’s content and flips its generating flag to false in one update. The client sees the finished note appear once, rather than watching it build up piece by piece.

**PowerSync**  
What happens when generation fails or times out?

**HosTalky**  
Generation is retried automatically up to three times; after that the job moves to a dead-letter queue and we get an internal alert. There was a real gap there, and we have a fix in review: originally no error or failure state was written back to the note, so if all retries were exhausted a note could keep showing “generating”. Sync only tells the client when generation finishes, not when it fails. The fix adds proper status and failure handling on the note itself, plus a timeout watchdog as a backstop.

_**Editor’s note:** This lesson generalizes: if you deliver job status through sync, model and sync a failure status as data too._

**PowerSync**  
What does the experience look like when a clinician records in a dead spot — cold storage, basement radiology, an ambulance?

**HosTalky**  
Recording requires a live connection today, since audio streams to our speech-to-text service in real time rather than being saved locally first. If connectivity drops partway through, we stop the recording and generate a note from what was transcribed up to that point, with a clear error and restart prompt for the clinician. Fully offline recording (capturing audio locally and generating once connectivity returns) isn’t there yet. We are looking into ways to close that gap, including queuing the recording locally for processing once back online, and on-device transcription models so recording wouldn’t need a network connection at all.

**PowerSync**  
Roughly how much of this would you have had to build yourselves if PowerSync weren’t in the loop? Things like a job queue, status polling, reconnect, dedupe logic, etc.

**HosTalky**  
A fair amount. The AI job processing itself, namely the queue, workers, retries and dead-lettering, is something we built regardless since that is our own AI pipeline, not something PowerSync does. What PowerSync replaces is everything on the delivery side: a polling endpoint the client would hit repeatedly to check whether a note is ready, backoff and retry logic for that polling, reconnect handling so polling resumes correctly after a network drop, and deduping so the client doesn’t re-show a completion notification it already handled. Multi-device consistency would also be extra work, since we would need to make sure every device a clinician is logged into learns that a note finished, not just the one that requested it. With PowerSync, all of that collapses into watching a local database table for changes, since the sync engine already handles the connection, retry and delivery guarantees underneath it.

### HIPAA and the compliance architecture

**PowerSync**  
You have BAAs in place with Deepgram, OpenAI and MongoDB. How did you approach mapping which vendors touch PHI, and where did a sync engine fit in that map? Did you initially think of PowerSync as a data processor at all?

**HosTalky**  
We built a vendor-by-vendor map of every service that creates, receives, stores or transmits PHI, and required either a BAA or a design that keeps PHI out of scope for each one. Candidly, PowerSync was not on the first version of that map. Our initial list focused on the obvious PHI touchpoints: transcription (Deepgram), the LLM (OpenAI), cloud hosting (AWS) and the database (MongoDB). We added PowerSync once we recognized that syncing note and message data to client devices means PHI transits, and is processed by, the sync service — which makes it a business associate. Closing that gap, with the BAA plus a compliant configuration, is a big part of why this exercise mattered to us.

**PowerSync**  
What has been hardest about assembling HIPAA coverage? The paperwork, the per-vendor plan-tier gates, or the engineering controls?

**HosTalky**  
A mix, but the per-vendor plan-tier gates were the most recurring friction. HIPAA features — BAAs, zero-retention options, dedicated infrastructure — often sit on a higher plan than our actual usage needs, so we repeatedly had to weigh paying for a tier we didn’t technically need against the compliance requirement. The engineering controls were substantial but tractable, because roughly 70% of the safeguards were already covered by our existing ISO 27001/27701-aligned policy set. The paperwork was the least of it.

**PowerSync**  
Under PowerSync’s shared-responsibility model, the client side (the local SQLite database and what happens to it over a device’s lifecycle) is the customer’s to secure. What does that look like in HosTalky?

**HosTalky**  
The mobile apps use SQLCipher, compiled into the native build, with an encryption key that is generated on-device and stored in the OS keychain. On the device lifecycle side, an explicit logout clears the local database through PowerSync’s `disconnectAndClear`, wiping the synced data off the device. The same happens on login and on account switch, so a new user never sees a previous user’s data.

**PowerSync**  
How do you think about HIPAA’s “minimum necessary” standard when deciding what each device syncs? Has asking “what does this device actually need offline?” changed how you scope things?

**HosTalky**  
The design already reflects that thinking. Personal notes, for example, are scoped to their own clinician rather than the whole care team or organization, so a device only ever holds the notes that clinician created, not a shared pool. Ownership-based scoping like that is the default pattern across the app, which lines up well with minimum necessary.

_**Editor’s note:** This kind of ownership-based scoping is expressed in PowerSync Sync Streams with a few lines of SQL and enforced server-side, so a device only ever receives the rows its user is entitled to._

**PowerSync**  
Was anything about PowerSync’s HIPAA shared-responsibility model unclear, or something you’d want documented better?

**HosTalky**  
The split was clear on the big structural pieces — the dedicated Atlas bucket-storage cluster in our own account, the network restrictions, and that client-side controls like local database encryption and device wipe sit with us. Two things we would have valued earlier or more explicitly. First, that HIPAA eligibility — BAA availability — is gated to the Team and Enterprise tiers; surfacing that path, and the requirement to bring your own dedicated bucket-storage cluster, right at the start of scoping would have saved us a cycle. Second, clearer guidance on the client-side expectations under the shared model. The docs are strong on the infrastructure side, but a checklist of what the customer owns on-device — local encryption, logout and wipe behavior, de-provisioning — would help teams self-audit against the model rather than inferring it.

_**Editor’s note:** We’ve updated our docs based on this feedback._

### Reliability, and what could be better

**PowerSync**  
Is HosTalky reliable for your users today? Any sync- or data-related reliability issues?

**HosTalky**  
Overall, yes — reliable for day-to-day use. That said, we do have a handful of known sync edge cases we are actively working through, mostly around reconnect timing: a dropped connection during resync, or a cold start after being idle for a while, plus a couple of cross-device message delivery gaps. None of these are widespread, but they are real and tracked. We have also started implementing background updating on mobile to help with some of these cases.

_**Editor’s note:** We’re working with the HosTalky team to see whether our recently released [Checkpoint Requests](https://docs.powersync.com/client-sdks/advanced/checkpoint-requests#sync-catch-up-checkpoint-requests) can help iron out these edge cases._

**PowerSync**  
What do you wish were different or better in PowerSync today?

**HosTalky**  
Constructively: the main thing is that HIPAA eligibility — the BAA — sits on a higher plan tier than our usage otherwise requires. Surfacing the HIPAA-eligibility path and pricing earlier, and offering a route for pre-commercial teams that need the BAA but not the rest of the tier, would help companies at our stage.

## Closing thoughts

The main thing that stuck with me from this conversation is how little AI-specific infrastructure HosTalky needed on the delivery side. Once “this note is still generating” became a field on the note rather than the state of an in-flight HTTP request, PowerSync did the rest: the state survives restarts, reaches every device the clinician is signed into, and needed no polling, retry, backoff or data dedupe code.

---

# New Streamlined Pricing Model for PowerSync Cloud Enterprise

> We are aligning the pricing metrics between the Pro, Team and Enterprise plans of PowerSync Cloud. Going forward, they will mostly use the same set of metrics. The result is pricing that is more transparent and easier to estimate up front.

- Published: 2026-09-21
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/powersync-cloud-enterprise-pricing-model

---

Since we launched PowerSync Cloud in 2023, we gathered some good learnings that allowed us to simplify our pricing models for customers. In late 2025, we announced [simplifications](https://powersync.com/blog/simplified-cloud-pricing-based-on-data-synced) to our Pro and Team plans, and now, we are announcing a simplified PowerSync Cloud Enterprise pricing model.

## What is changing

The headline is that we are aligning the pricing metrics between the Pro, Team and Enterprise plan. Going forward, they will mostly use the same set of metrics:

| Metric | Pro and Team Plans | Enterprise Plan |
| :---- | ----- | ----- |
| Data Synced | ✓ | ✓ |
| Data Hosted | ✓ | ✓ |
| PowerSync Service Instances | ✓ | ✓ |
| Peak Concurrent Clients | ✓ |  |
| Average Concurrent Clients |  | ✓ |

As you can see, the only difference is the billing metric for concurrent clients:

- Our Pro and Team plans will continue to use **Peak Concurrent Clients**. These plans are typically used for smaller deployments with relatively volatile usage patterns. Considering how our cloud system tends to provision infrastructure resources for these types of workloads, our costs are mainly correlated with the _peak_, and that is therefore the most appropriate metric for billing.
- Our Enterprise plan will use **Average Concurrent Clients**. This plan is typically used for larger-scale deployments with more predictable workloads. Here, billing on the _average_ makes the most sense for us and our customers.

## How the new Enterprise pricing works

To price your PowerSync Cloud Enterprise subscription, we will take the following approach:

**1) Usage commitment:** You decide on a monthly usage commitment for each of the metrics:

- Data Synced
- Data Hosted
- PowerSync Service Instances
- Average Concurrent Clients

**2) Discounted usage rates:** We provide you with a custom quote for your subscription, which includes:

- A discounted rate for each of the billing metrics, relative to the rate on the Pro and Team plans. This means that Enterprise customers get economies of scale on their usage fees compared to the Pro and Team plans. For example, the reference rate on our Pro and Team plans for Data Hosted is $1 per GB per month. Let's say we quote you a 25% discount for Data Hosted. Your usage rate on the Enterprise plan would therefore be $0.75 per GB per month for that metric.
- A base fee for the Enterprise plan. This is based on the scale of your deployment, and is calculated as a fixed percentage of the total usage-based fees per your usage commitment.

**3) Monthly measurement:** If you exceed your committed usage on one of the metrics in a monthly period, overages will be billed based on an overage rate which is calculated as: your discounted usage rate plus 20%, or the reference rate for the Pro and Team plan – whichever is less. For example, let's say you committed to 15 GB of Data Hosted and your discounted usage rate is $0.75 per GB, and you have an overage of 2 GB in a month. That overage would be billed at $0.75 plus 20% = $0.90 per GB.

## Contract and billing periods

By default, our Enterprise subscriptions involve an annual contract. The committed usage and base fee are therefore typically billed annually, and any usage overages are billed monthly in arrears if it meets a significance threshold (otherwise the overage billing is postponed to the following month).

If you need to upgrade the baseline usage commitment in your subscription, we prepare a new quote and sign a new agreement that prorates fees for the remainder of your subscription term.

## Benefits to customers

The main benefit to customers is that our new Enterprise pricing model is more transparent and easier to understand, compared to our previous custom pricing model which was admittedly somewhat of a 'black box'.

We also expect it to be easier for customers to estimate their usage before committing to the Enterprise plan. We recommend that customers use the Free, Pro or Team plan to build a proof-of-concept and measure their metrics with small-scale testing, and then extrapolate those results to calculate the usage commitment required for the Enterprise subscription. We have added _Average Concurrent Clients_ as a metric we measure in PowerSync Cloud, and will soon expose it on the _Metrics_ section of the PowerSync Dashboard.

## Finer detail: dedicated storage clusters

If you're familiar with our PowerSync Cloud Enterprise plan, you may know that we provide the option of provisioning a dedicated storage cluster for specific PowerSync Service instances where high scale is expected.

In our new Enterprise pricing model, you have the option of selecting a dedicated storage cluster for one of your instances for every 200 GB of committed Data Hosted in your subscription.

## Migration of existing customers

If you already have a PowerSync Cloud Enterprise agreement in place on a legacy pricing model, we will discuss migrating you to the new pricing model at the time of your agreement expiry/renewal.

## Questions? Feedback?

If anything is unclear, if you need more information, or have any feedback, please [get in touch](https://powersync.com/contact).

---

# Introducing Checkpoint Requests

> Checkpoint Requests answer: has the local database caught up to the source database right now? This lets your app wait for the data it needs before proceeding.

- Published: 2026-09-09
- Author: Steven Ontong
- Category: Engineering
- Source: https://powersync.com/blog/checkpoint-requests-client-synced-now

---

## Background

PowerSync partially syncs your source database to a local in-app SQLite database. Partial sync is defined by a Sync Config: a YAML configuration containing Sync Stream definitions with SQL-like parameterized queries that describe the data to sync to each user.

The PowerSync Service replicates relevant data from the source database, based on the Sync Config, into precomputed "buckets". Connecting clients receive bucket operations through a stream connection organized around **checkpoints**. A checkpoint usually maps to a set of complete source database transactions. A transaction's operations will never be split between checkpoints.

The PowerSync Service and client SDK automatically synchronize the local SQLite with the source database. Developers can generally rely on local state being applied consistently at the next safe checkpoint.

Reactive queries typically automatically update in-memory state when local SQLite changes are made. This is convenient for reacting to changes from both local (the current user) and externally sourced operations.

For externally sourced operations, PowerSync guarantees that those remote changes would be applied at *some* point in the future, but historically there wasn't an easy way to definitively answer the question of "is the client fully synced *now*?"

In the next section we explore this problem in a bit more detail.

## Wait for first sync

PowerSync has historically exposed indicators for when the **first complete sync** has finished (to a freshly-initialized SQLite database). The client-side PowerSync database exposes a global `waitForFirstSync` method which resolves once the first complete sync has been applied locally.

```javascript
// App initialization code
await powerSync.waitForFirstSync()
// App now knows the initial completely-synced data is available in SQLite
// Queries should now reflect the user's data at this point in time
```

We also expose the first sync's completion on a per-stream basis:

```javascript
const streamSubscription = await db
  .syncStream("todos", { list_id: "abc123" })
  .subscribe();
await streamSubscription.waitForFirstSync();
await streamSubscription.waitForFirstSync();
```

Those APIs are great for the specific use case of waiting on the *first complete sync*. However, what we've found from developer feedback is that apps often need to ensure that the local database has been synced *again* after the first complete sync.

For example, consider this flow:

- A user uses a PowerSync-enabled app.
  - App code which relies on `waitForFirstSync` gates certain logic, delaying until the sync completes.
- The user closes the app.
- The source database now contains changes which need to be synced to the user.
- The user re-opens the app.
  - The first sync has already completed, so `waitForFirstSync` resolves.
  - The user has pending operations to sync, but the app has no clean way of waiting for those changes to be applied.
  - The app typically routes the user to specific views.

For some workflows, the above is fine. Reactive queries typically update with the latest data once the incoming changes have been synced.

For some other workflows, an application might **need** the latest data to be synced before allowing the user to proceed. A classic example of this could be push notifications. Let's say the application backend committed a change to the source database, which triggered a push notification to the device. The user tapped the notification related to the specific data, opening the application. App logic most likely will need the corresponding data to be queryable once handling the notification tap. Developers often find themselves needing an additional gating mechanism: waiting for the **next** checkpoint to be synced.

## Checkpoints

### (Legacy) Write Checkpoints

An internal mechanism called Write Checkpoints is what the PowerSync client SDKs use to ensure data consistency. The general rule for consistency in PowerSync is:

> An SDK client won't apply incoming sync operations until all its local mutations have been completed **and** the source database operations related to those mutations have been received back through the latest checkpoint. This [guarantees](https://docs.powersync.com/architecture/consistency#powersync-designed-for-causal+-consistency) causal consistency.

The only exception to this is if [sync priority 0](https://docs.powersync.com/sync/advanced/prioritized-sync#special-case-priority-0) is used, but we'll ignore that for this explanation.

The rule above is quite a mouthful, so we can break it down into an example.

As a reminder, the PowerSync Service consumes a CDC replication stream from the source database and replicates its operations into precomputed [bucket storage](https://docs.powersync.com/architecture/powersync-service#bucket-storage). Consuming this stream requires some form of positional information.

A typical mutation flows through PowerSync as follows:

1. The app makes the mutation via a SQLite query, e.g. `INSERT INTO my_table(...) VALUES (...)`.
2. The PowerSync client SDK queues this operation and other transaction operations in the upload queue.
3. The PowerSync client SDK calls the `BackendConnector` `uploadData` method at appropriate times, allowing the application code to fetch `CrudTransaction`s or `CrudBatch`es.
   - The connector passes the mutations to the application backend, where the application backend may modify, persist or deny those mutations from entering the source database.
   - The `.complete()` method is called on the `CrudTransaction` or `CrudBatch`. This removes the entries from the upload queue.
4. Once the upload queue is empty, the PowerSync client SDK requests a Write Checkpoint from the PowerSync Service.
   - The PowerSync Service associates the current source database replication position with the user and client that requested the Write Checkpoint.
   - The PowerSync Service returns a marker to the client, which is a target the SDK uses to wait for the corresponding checkpoint to be received from the PowerSync Service. The SDK won't apply any incoming operations to the local SQLite tables until it has fully received the corresponding checkpoint.

You might ask yourself, why are we talking about uploads when we want to know when the PowerSync client SDK has synced a checkpoint? The reason for all that context is that historic Write Checkpoints have been answering that question all along. It's just been an internal facet of PowerSync. Write Checkpoints have allowed the client SDK to wait for a specific source database state to be present locally; we'd need something similar if we'd like to wait for subsequent checkpoint syncs.

### Checkpoint Requests

We recently released the Checkpoint Request API across all SDKs, requiring PowerSync Service version 1.24.0 or later. It allows developers to answer the question, "Has the application synced all relevant changes in the source database up to now?"

Checkpoint Requests use the PowerSync Service to make an association with the source database's current replication position. This association is tracked on the client and service side. The PowerSync Service reports to the SDK once the data related to the association has been sent to the client. The client can then notify application code once the Checkpoint Request has been applied. After it's applied, the local SQLite tables will contain all relevant state corresponding to the source database at the time of the association.

Checkpoint Requests require a connected or connecting PowerSync SDK client. A request cannot be created while the client is fully disconnected. While the client is connecting, request creation waits until the PowerSync Service is reachable. If the connection drops while waiting for a created request, the app can reconnect and wait on the same request again.

```javascript
// Make sure to connect using the new `checkpointMode`
await db.connect(connector, {
  checkpointMode: 'requests'
});

// Perform some operation
// ...

// Create a checkpoint request
const checkpoint = await db.requestCheckpoint();

// Wait for the checkpoint to sync, with a 30-second timeout
await checkpoint.waitForSync({
  signal: AbortSignal.timeout(30_000)
});

// Now the data is available in the local SQLite database
```

> **Note**
>
> **Note:** Checkpoint Requests are currently in alpha. Write Checkpoints still exist, but in the future we will completely replace legacy Write Checkpoints with Checkpoint Requests.

## Use cases

### Waiting for the next sync

For the notification example mentioned, an app can now create a Checkpoint Request and wait for it to be synced when handling the notification app-open event:

```javascript
async function handleNotification() {
  // ... logic

  const checkpoint = await db.requestCheckpoint();
  await checkpoint.waitForSync({
    signal: AbortSignal.timeout(30_000)
  });

  // The app can now query for data related to the notification event
  // and navigate to specific views if necessary.
}
```

### How we use Checkpoint Requests in the Dashboard

We're using Checkpoint Requests in the PowerSync Dashboard itself to handle a subtle timing issue: a management API call could succeed before the resulting change reached the browser's local database. After creating an instance, for example, the dashboard could try to open its page before its data was available locally. Requesting a checkpoint after the API call lets us wait for local sync to catch up before navigating.

### Waiting for writes

The PowerSync client SDK uses the same mechanism for Checkpoint Requests as it does for the historic Write Checkpoint gates mentioned above. This means that the existing consistency gates and Checkpoint Requests are inherently linked. For Write Checkpoints:

> An SDK client won't apply incoming sync operations until all its local mutations have been completed **and** the source database operations related to those mutations have been received back through the latest checkpoint.

This ties Checkpoint Requests and local mutations. A user can now write code like this:

```javascript
async function someMutation() {
  // Perform some local writes
  await db.execute(
    `INSERT INTO ${TODOS_TABLE}
      (id, created_at, created_by, description, list_id, completed)
     VALUES (uuid(), datetime(), ?, ?, ?, ?)`,
    [
      connector.currentUserID,
      todo.description,
      listId,
      todo.isComplete ? 1 : 0
    ]
  );

  // This queues the local write for asynchronous upload.

  // Create a checkpoint request and wait for it to sync.
  const checkpoint = await db.requestCheckpoint();
  await checkpoint.waitForSync({
    signal: AbortSignal.timeout(30_000)
  });

  // The PowerSync client SDK and Service associate the request with the
  // current database replication position and wait for that data to be
  // synced and applied locally.
  //
  // The consistency barriers also ensure that the wait completes only
  // after the local write has been uploaded and the corresponding
  // checkpoint has been synced and applied locally.
  //
  // The application backend has now processed the local write above,
  // and the result of that processing is available locally.
  // We can query the database for any additional changes the backend
  // made when creating the TODO record.
}
```

The code above is possible due to our gating logic for applying incoming changes while local mutations are in the upload queue. Essentially, we perform a local mutation which queues the item for upload. We also create a Checkpoint Request after the mutation. If that explicit request is created while the upload is pending, the SDK creates a newer internal request after the upload queue empties. We'll only get a resolve once the effective checkpoint has been synced.

**Note:** The exact request ordering is not deterministic. The upload may complete and create its internal Checkpoint Request before the explicit `db.requestCheckpoint()` call. In either order, the checkpoint gate remains valid and the wait only completes after the relevant upload state and requested source database state have been applied locally.

This assumes that `uploadData()` returns only after the application backend has committed the uploaded changes to the source database. Application backends that process uploads asynchronously should use Custom Checkpoint Request handlers by implementing `CustomCheckpointRequestConnector`, so the checkpoint is created only after the queued work has been processed. See additional details in our [documentation](https://docs.powersync.com/client-sdks/advanced/checkpoint-requests#asynchronous-upload-backends).

This effectively provides a means for waiting for the upload queue to drain and the next checkpoint to be synced.

### Intermittent sync

Now that we can wait for the next sync, we can temporarily connect a client to PowerSync, wait until the requested checkpoint has been fully applied, then disconnect. This could be useful in cases where apps don't need to be permanently connected to the PowerSync Service.

```javascript
async function sync() {
  await db.connect(connector, {
    checkpointMode: 'requests'
  });

  const checkpoint = await db.requestCheckpoint();
  await checkpoint.waitForSync({
    signal: AbortSignal.timeout(30000)
  });

  // No need to stay connected after we've got the latest data
  await db.disconnect();
}
```

## Conclusion

PowerSync already keeps the local SQLite database continuously and reactively in sync. Checkpoint Requests add an explicit synchronization boundary: an application can ask the PowerSync Service to capture the source database's current replication position, then wait until all relevant data through that position has been applied locally.

`waitForFirstSync` answers, "Has this database completed its initial sync?" A Checkpoint Request answers, "Has this database caught up to the relevant source database state *now*?" That distinction makes flows such as notification handling, explicit refreshes, write-dependent actions and intermittent sync easier to coordinate without polling or relying on arbitrary delays.

In short, Checkpoint Requests turn an eventual catch-up into an observable application event. When an app needs to know that relevant source data is locally available before it proceeds, it can now wait for that point directly.

---

# Offline-First at National Scale

> Four public-sector deployments — a national school meals program, a government retail network, a telecoms field workforce and a social housing repairs operation — and the shared constraints behind them: no network, in-country data, and scale proven before development starts.

- Published: 2026-08-17
- Author: Conrad Hofmeyr
- Category: Showcase
- Source: https://powersync.com/blog/offline-first-at-national-scale

---

A field test of PowerSync for a government project last year covered five schools in a mountainous region in Asia. One school had around 20 Mbps of connectivity. Two ran between zero and one megabit. Two had no coverage at all, and in those the procedure was for a staff member to travel to a location with signal roughly once every ten days and sync from there. Guaranteed local retention for extended offline durations (weeks) was baked into the requirements, so that a missed trip would not cost anyone their records.

Testing ran on low-end Android handsets and on recent iPhones, and the application performed well across all five sites.

Requirements like that are ordinary in the public sector. Connectivity is rarely negotiable, because a government application has to cover everyone within a jurisdiction, including the parts of it where the network has not been built. In-country data residency is non-negotiable. And the user count is derived from the size of the population being served, which means it is known before development starts and scalability has to be demonstrated early on during evaluation.

## PowerSync Public-Sector Deployment Examples

Here are a few anonymized representative examples of PowerSync public-sector deployments:

### A National School Program, Asia

A national education authority is implementing a PowerSync-enabled software application that records daily attendance and meal distribution at schools. The application aggregates those figures up through a regional hierarchy all the way to the national level. It is built in Flutter and runs on Android and iOS devices already owned by school staff.

The upcoming national rollout will involve hundreds of millions of records captured per day across millions of students and thousands of schools.

The team initially intended for senior administrators to sync a single summary table of roughly two million rows, with a target initial sync under two minutes. That target was not achievable at that row count with PowerSync. The workable approach was restructuring: separate aggregated tables per administrative level, so an administrator syncs a few dozen rows per day and a regional administrator syncs under a thousand. The data volume on the wire dropped by three orders of magnitude.

The scale of this project breaks assumptions outside the sync layer as well. The team had been using a commercial hosted identity provider and dropped it once the per-user pricing was extrapolated to a national rollout, replacing it with their own JWT signing. PowerSync is not an identity provider. It verifies JWTs from whatever mints them, which means the identity system each organization already runs.

Accuracy is what a program like this gets judged on, and that is the citizen-facing outcome here. A meal served in a school without connectivity is recorded at the point of service, and it reaches the government as captured data instead of being reconstructed from paper or memory some weeks later.

Parents will eventually get a view of the same records. A parent account will only sync its own children's data, enough to show whether a child was marked present and received a meal on a given day. Parent logins are scheduled for a release after the school-level features that make up the first rollout, and they change the shape of the load considerably. Parent sessions are short, a few minutes each, and they cluster almost entirely between the start of the school day and mid-morning, so the deployment has to absorb millions of brief connections inside a few hours.

### Nationwide Government Retail Locations, Asia

A technology partner is building an offline-first point-of-sale system for a government program that involves tens of thousands of retail locations across the country. The software is built in Flutter and runs on low-cost Android point-of-sale terminals.

Connectivity at these sites is intermittent, often for hours at a time, and a point-of-sale system that depends on a live server connection stops operating during those windows. With PowerSync, transactions complete on the terminal and reconcile when the link returns, so retail locations keep trading and citizens are served. The deployment is self-hosted on managed Kubernetes, with Postgres as both the source database and the bucket storage.

### Field Technicians, Asia-Pacific

A government-owned telecommunications infrastructure operator is building a native iOS application for its field workforce, numbering in the thousands of technicians. The previous application was a PWA. It handled offline conditions poorly, and iOS updates periodically broke the runtime beneath it.

The replacement is written in Swift and SwiftUI, with PowerSync self-hosted inside the operator's own cloud environment to satisfy in-country data residency requirements. Work orders, calendars, messages and notifications sync to the device. Writes are uploaded through the operator's existing API gateway and backend services, which allows the existing authentication and security model to remain unchanged.

For households waiting on a connection or a repair, the effect is fewer repeat visits. The technician arrives with the complete job record regardless of coverage at the site and can close the work on the first appointment.

### Social Housing Maintenance, Europe

The same pattern turns up again in a housing and care provider that maintains tens of thousands of homes on behalf of local and central government. Its repairs and maintenance application runs on thousands of devices and several of its contracts carry data sovereignty terms that require hosting within the country.

Repairs are recorded at the property, including inside buildings with no reception, which keeps tenant repair histories accurate and complete.

## Security Review and Continuity Risk

In a public-sector deal, the information security review usually asks for things like a SOC 2 report, third-party penetration test results, static analysis and dependency scan output, and a vendor willing to work through a long security questionnaire.

A harder question that often comes up is what happens if the vendor discontinues the product. That is a fair question to put to us, and two of the four customers above are here because it happened to them: both were running MongoDB Atlas Device Sync when it was deprecated.

PowerSync inherently provides continuity guarantees. The PowerSync client SDKs are Apache 2.0 licensed. The PowerSync Service is available as Open Edition under the Functional Source License, which converts to Apache 2.0 over time, so a self-hosted deployment does not depend on our continued existence to keep running.

## Resilience on the Device

PowerSync is designed to support devices offline for extended periods — weeks at a time or even longer.

It is also built to assume unreliable client-side storage. PowerSync maintains checksums per bucket of data on both the client and the server, and validates them as part of every checkpoint. A mismatch should never happen during normal operation, but local storage on inexpensive Android hardware does fail, and processes get killed mid-write. When a bucket checksum does not match, PowerSync re-downloads that bucket automatically.

## Running the Service

A single PowerSync instance supports on the order of 50,000 to 100,000 concurrently connected clients depending on the shape and volume of the synced data, and deployments beyond that use a sharded architecture.

All four example deployments above run PowerSync self-hosted, in each case for residency or sovereignty reasons. It is the same service image with the same sync semantics as PowerSync Cloud, configured through YAML files or admin APIs rather than a dashboard, and it exposes Prometheus metrics and a diagnostics endpoint for monitoring in Grafana or an equivalent. Teams that already run their own infrastructure tend to want their sync layer visible in the same dashboards as everything else.

## What These Deployments Have in Common

A school meals program, a government retail network, a telecoms field workforce and a social housing repairs operation have very little to do with one another, but their requirements are similar nevertheless. Each one needed the application to keep working with no network, the data to stay inside the country, and scalability and reliability to be demonstrated early on.

If you are scoping something with these characteristics, our team is available to work through sizing and architecture before you commit to a design.

---

# Migrate from Electric Cloud to PowerSync Cloud

> A guide for teams moving from Electric Cloud to a managed, non-Electric cloud provider: PowerSync Cloud. It covers the key concepts and migration steps.

- Published: 2026-08-12
- Author: Kobie Botha
- Category: Tutorial
- Source: https://powersync.com/blog/migrate-from-electric-cloud-to-powersync-cloud

---

Electric [announced](https://electric.ax/blog/2026/08/11/electric-joining-databricks) that it has joined Databricks and Electric Cloud has shut down. The announcement guidance includes self-hosting Electric with another cloud provider. This guide is for teams that instead want to move to a managed cloud provider that is not Electric: PowerSync Cloud.

This implementation guide is for teams already using Electric's current Postgres Sync service that want an alternative managed cloud service, rather than self-hosting Electric or using Neon. It assumes Postgres remains the system of record and covers the high-level concepts and steps needed to migrate.

## Concepts

PowerSync Sync Streams are analogous to Electric Shapes, not Electric Streams. Electric Streams is a separate product and is out of scope for this guide.

While Electric Shapes and PowerSync Sync Streams both control partial sync, there are significant differences meaning that Shape to Sync Stream migration will most likely not be 1-for-1, and re-designing partial sync will most likely be required.

A key architectural difference between Electric Shapes and Sync Streams is that Shapes are created on demand from the client, per request, while Sync Streams are declared as named queries ahead of time that clients then dynamically subscribe to when needed, each subscription passing its own parameters. This architecture drives how authorization, offline behavior, and writes work. The table below summarizes the specific differences between Electric Shapes and Sync Streams across these and other key dimensions:

| Dimension | Electric (Shapes) | PowerSync (Sync Streams) |
| --- | --- | --- |
| Definition | Client-side, per request. Using `table` and optional `where`, `columns`, and `queryable_columns` parameters. Each parameter set identifies a distinct Shape. | Server-side, names SQL queries in a deployed YAML config. Clients subscribe by name and supply parameters; `auto_subscribe` starts a stream automatically. |
| Relational scope | Single table only. Use subqueries to filter, or multiple Shapes to sync related data. | `JOIN` supported. One stream can carry multiple queries. |
| Filter language | Supported PostgreSQL `WHERE` expressions, positional parameters, arrays, and subqueries. No non-deterministic functions. [[ref](https://electric.ax/docs/sync/guides/shapes#supported-operators)] | SQL subset with inner joins, subqueries, CTEs, and transformations; no `GROUP BY`, `ORDER BY`, `LIMIT`, or `UNION`. No non-deterministic functions. [[ref](https://docs.powersync.com/sync/supported-sql)] |
| Authorization model | "Production apps should request shapes through your backend API for authorization and security". [[ref](https://electric.ax/docs/sync/guides/shapes#defining-shapes)] | Sync Stream queries define download access using signed JWT claims. Treat client-provided subscription parameters as untrusted. |
| Client store | In-memory rows by default. Persistence and offline behavior require a separate client store or integration, such as PGlite or TanStack DB collections. | SQLite with a declared `AppSchema`. The Web SDK uses persistent IndexedDB by default; additional VFSes are available, and an in-memory VFS is optional. |
| Local queries | `shape.rows`, `useShape`, TanStack DB live queries. | SQL against SQLite (`useQuery`, `watch()`). Also supports the TanStack DB interface and SQLite ORMs like Drizzle. |
| Writes | Electric provides read-path sync only. The app defines its write path. | Local `INSERT`, `UPDATE` and `DELETE` operations enter a FIFO upload queue. Developer-defined `uploadData()` applies mutations via the developers' existing backend which authorizes and applies them. |
| Primary keys and types | Must always include Postgres primary key columns. | Each synced table requires a single unique text `id` column. Columns can be aliased, concatenated or casted [[ref](https://docs.powersync.com/sync/advanced/client-id#client-id)]. The PowerSync TanStack DB integration provides automatic support for rich types. [[ref](https://tanstack.com/db/latest/docs/collections/powersync-collection)] |
| Performance consideration | Shape filter design affects throughput. [[ref](https://electric.ax/docs/sync/guides/shapes#throughput)] | Bucket cardinality affects sync performance. [[ref](https://docs.powersync.com/sync/rules/organize-data-into-buckets#limit-on-number-of-buckets-per-client)] |

## Migration

Note that both Electric Sync and PowerSync codebases are public, so agents should generally not struggle with implementing migrations. Also see the PowerSync [agent resources](https://docs.powersync.com/tools/ai-tools). If you need assistance, join the [PowerSync Discord](https://discord.gg/powersync).

### Overview of Migration Steps

1. [Configure Postgres](#configure-postgres)
2. [Connect PowerSync](#connect-powersync-to-postgres)
3. [Define and test Sync Streams](#define-and-test-sync-streams)
4. [Set up Authentication](#set-up-authentication)
5. [Migrate the frontend code](#migrate-the-frontend-code)

### Configure Postgres

1. Create a Postgres role and publication as per [documentation](https://docs.powersync.com/configuration/source-db/setup#supabase).
   1. Note: it is not possible to reuse the Electric publication, since PowerSync requires a publication named `powersync`.
2. Note that `BYPASSRLS` is commonly used for the PowerSync role. This is because Sync Stream definitions enforce authorization.

### Connect PowerSync to Postgres

1. Connect your PowerSync instance to your Postgres environment
   1. Dashboard [instructions](https://docs.powersync.com/configuration/source-db/connection#supabase)
   2. CLI [instructions](https://docs.powersync.com/tools/cli#cloud-workflows)
2. Since the PowerSync Service connects directly to Postgres, various network-level security mechanisms are [supported](https://docs.powersync.com/configuration/source-db/security-and-ip-filtering#security-and-ip-filtering).

### Define and Test Sync Streams

In this step you will write your Sync Streams YAML. This will:

- Define how subsets of your Postgres data are synced to SQLite (on the client)
- Move download authorization into Sync Stream queries. You keep write authorization in your backend. PowerSync uses signed JWT claims for access checks. Sync Streams accept client parameters, but these should not be relied on for authorization checks.
- Refer to the Sync Streams [documentation](https://docs.powersync.com/sync/streams/overview)
- Note that if the [supported Sync Streams SQL](https://docs.powersync.com/sync/supported-sql) doesn't support the specific query you are trying to write, sync the required streams and then run `ORDER BY`, `LIMIT`, aggregates, joins, etc. in local SQLite.

#### Example

A Shape that syncs a user's projects as follows:

```typescript
const { data } = useShape({
  url: `http://localhost:3000/v1/shape`,
  params: {
    table: `projects`,
    where: `owner_id = ${currentSession().userId}`,
  },
})
```

Can be defined in Sync Streams as this `my_projects` stream:

```yaml
streams:
  my_projects:
    query: SELECT * FROM projects WHERE owner_id = auth.user_id()
```

You can then define a separate Sync Stream to sync each project's tasks (`project_tasks` stream), where the client provides the `project_id`:

```yaml
streams:
  my_projects:
    ...

  project_tasks:
    query: |
      SELECT * FROM tasks
      WHERE project_id = subscription.parameter('project_id')
        AND project_id IN (SELECT id FROM projects WHERE owner_id = auth.user_id())
```

#### Run a Sync Test from the PowerSync Dashboard

Once you've defined your Sync Streams, you can run a Sync Test in the PowerSync Dashboard to validate that data is syncing to the client as expected.

### Set Up Authentication

Electric relies on a backend to validate requests to Shapes. With PowerSync that logic is contained in your Sync Stream queries, and clients are then able to connect to the PowerSync Service with a JWT minted from your backend, instead of using the backend as a step in the middle.

`auth.user_id` illustrates this in the Sync Streams example from above:

```yaml
    query: SELECT * FROM projects WHERE owner_id = auth.user_id()
```

Our [authentication documentation](https://docs.powersync.com/configuration/auth/overview) covers how to set this up.

### Migrate the Frontend Code

The PowerSync client owns a local SQLite database that intelligently merges rows from all active Sync Streams. It exposes local SQL and live query (watch) APIs. It optionally records local writes into a FIFO upload queue. Note that migrations from PGlite to SQLite are possible but out of scope for this guide.

PowerSync provides SDKs for many platforms: Swift, Kotlin, Dart, .NET, Rust and JS/TS (Web, React Native, Node, Capacitor and Tauri). This section only covers Web JS/TS.

1. [Install](https://docs.powersync.com/client-sdks/reference/javascript-web#installation) the PowerSync Web SDK with `pnpm install @powersync/web`

2. Use the PowerSync Dashboard or CLI to generate the client-side SQLite schema ([docs](https://docs.powersync.com/client-sdks/reference/javascript-web#1-define-the-client-side-schema)). Note that an `id` column is added automatically. It will look similar to this:

   ```typescript
   import { column, Schema, Table } from '@powersync/web'

   const projects = new Table({
     name: column.text,
     owner_id: column.text,
   })

   const tasks = new Table({
     project_id: column.text,
     title: column.text,
     status: column.text,
   }, { indexes: { by_project: ['project_id'] } })

   export const AppSchema = new Schema({ projects, tasks })
   ```

3. [Instantiate](https://docs.powersync.com/client-sdks/reference/javascript-web#2-instantiate-the-powersync-database) the PowerSyncDatabase. Note that you must only create one `PowerSyncDatabase` instance for each database file

   ```typescript
   import { PowerSyncDatabase } from '@powersync/web'

   export const db = new PowerSyncDatabase({
     schema: AppSchema,
     database: { dbFilename: 'powersync-v1.db' },
   })
   ```

4. The Web SDK uses a persistent IndexedDB VFS by default. [Select another VFS](https://docs.powersync.com/client-sdks/reference/javascript-web#sqlite-virtual-file-systems) if you have specific browser, performance, or multi-tab requirements.

5. [Integrate](https://docs.powersync.com/client-sdks/reference/javascript-web#3-integrate-with-your-backend) with your backend. This requires implementing two methods for `PowerSyncBackendConnector`: `fetchCredentials` and `uploadData`
   1. `fetchCredentials()` returns the JWT used to authenticate against PowerSync with and download synced data, as well as the PowerSync Cloud endpoint
   2. `uploadData()` defines how local mutations are sent to your backend API - you should be able to re-use the existing backend you have in place today

6. Replace client-side queries. This is where the bulk of the work will take place, but agents should be pretty good at it. Below are some more tips to get you going:
   1. Replace shape [handle/offset usage](https://electric.ax/docs/sync/guides/shapes#subscribing-to-shapes) with [`waitForFirstSync()`](https://docs.powersync.com/client-sdks/usage-examples#wait-for-the-initial-sync-to-complete) and Sync Stream [status checks](https://docs.powersync.com/sync/streams/client-usage#checking-sync-status).
   2. Tie on-demand Sync Stream subscriptions to component or route lifetime. The PowerSync React Hooks can [automatically subscribe/unsubscribe](https://docs.powersync.com/sync/streams/client-usage#framework-integrations).
   3. Note that when subscribing to a Sync Stream on the client, the TTL can be overridden. The default is 24 hours: a shorter TTL reduces disk usage, a longer TTL improves page reload performance.
   4. When logging the user out or switching accounts, only use `disconnectAndClear()` once the upload queue has been emptied, otherwise local mutations will get discarded.

7. Implement writes
   1. Electric is read-path only, so this guide doesn't cover migrating a write path. However, it's highly recommended to use the PowerSync upload queue to ensure consistency instead of sending mutations directly to your backend. You might notice data flicker on the client if you write directly to your backend APIs / bypass the PowerSync upload queue.
   2. Follow [this guide](https://docs.powersync.com/configuration/app-backend/client-side-integration) for integrating the PowerSync upload queue with your backend APIs

---

# PowerSync Changelog: June & July 2026

> We released v2.0 of our JavaScript SDKs, added support for Azure DocumentDB and Convex as source databases, shipped an official Terraform provider, and merged some of the most substantial community contributions we've had yet.

- Published: 2026-08-11
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-changelog-june-july-2026

---

In the last edition I wrote about overhauling and shipping v2.0 of our Dart SDK. It's important to us that PowerSync is well-maintained, so this time we extended that effort to our JavaScript SDKs. We tackled a long laundry list of DX issues and released v2.0 of our web, React Native, Capacitor and Node.js SDKs. More on that in the feature story below.

Beyond that, we added support for new source databases (Azure DocumentDB and Convex), released an official Terraform provider, and shipped some of the most substantial community contributions we've had yet. Community members adding non-trivial features is becoming a trend, and we love it.

## Product updates shipped

**PowerSync Service:**

  * **Azure DocumentDB as a source database**: DocumentDB (formerly Azure Cosmos DB for MongoDB vCore) now works through our existing MongoDB connector: link your connection string and PowerSync detects it automatically. [Release notes](https://releases.powersync.com/announcements/announcing-azure-documentdb-support-experimental).
  * **Convex as a source database**: Building with Convex and need offline support? You can now connect your Convex database to PowerSync. Writes still go through your existing Convex mutations, and each client only syncs the data it needs. It's an experimental release, and your feedback shapes where we go from here. [Release notes](https://releases.powersync.com/announcements/announcing-convex-backend-support-experimental) and [design notes](https://powersync.com/blog/convex-powersync-design-notes).
  * **Sync Streams hardening**: The compiler now warns about queries that can silently sync rows under the wrong name (unquoted JOIN aliases, `SELECT *` after an aliased column). We also fixed several cases where our evaluator diverged from SQLite semantics (thanks @sravan27!). [Changelog](https://releases.powersync.com/announcements/powersync-service).

**Client SDKs:**

  * **JavaScript SDKs v2.0**: Focused on a more stable and intuitive public API, and simpler setup. See the feature story below or review the [release notes](https://releases.powersync.com/announcements/v2-0-of-powersync-javascript-sdks) for a complete summary and how to handle breaking changes.
  * **Multi-process SQLite access (Swift v1.15.0)**: App Extensions and App Groups are now supported: the database can live in an App Group container, with the SDK coordinating access between your app and its widgets or extensions. This is an early release with known footguns. We have an intuition that better DX is possible here, but we need your feedback to shape this. [Release notes](https://releases.powersync.com/announcements/powersync-swift-sdk) and [Docs](https://docs.powersync.com/client-sdks/reference/swift#app-groups-and-app-extensions).
  * **In-memory databases for the web (v1.39.0)**: `WASQLiteVFS.InMemoryVfs` keeps the whole database in memory with no persistence, which is useful for local development and online apps. [Docs](https://docs.powersync.com/client-sdks/reference/javascript-web#3-in-memory-vfs).
  * **Bring your own HTTP client (Dart/Flutter v2.3.0)**: `SyncOptions.httpClient` lets you add headers, trust self-signed certs, or swap in a faster client like `cronet_http`. SQLCipher is also back as a native encryption option. [Docs](https://docs.powersync.com/client-sdks/reference/flutter#custom-http-clients-and-headers).
  * **Room 3.0 (Kotlin v1.14.1)**: Our Room integration for Kotlin now uses Room 3.0. This is a breaking change: update your project to Room 3.0 when upgrading to v1.14.1. [Docs](https://docs.powersync.com/client-sdks/orms/kotlin/room).

**Tools:**

  * **Official Terraform provider**: Manage PowerSync Cloud projects and instances as Infrastructure-as-Code. [Release notes](https://releases.powersync.com/announcements/an-official-terraform-provider-for-powersync-1).
  * **Custom roles and permissions (Dashboard)**: Team and Enterprise customers can now create and assign custom Dashboard roles themselves, with project and instance scoping and fine-grained permissions. Previously this had to be configured by our team. [Docs](https://docs.powersync.com/tools/powersync-dashboard#roles-and-permissions).
  * **More ways to search instance logs (Dashboard)**: Building on May's [searchable logs release](https://releases.powersync.com/announcements/searchable-instance-logs-in-the-powersync-dashboard), we added additional quality-of-life improvements such as excluding terms with a `-` prefix and clicking a timestamp to set the range start or end. [Docs](https://docs.powersync.com/maintenance-ops/monitoring-and-alerting#instance-logs).
  * **Smarter CLI commands (v0.10.0)**: Commands that take `--instance-id` now resolve the project and org from it automatically (previously you had to add these as flags yourself). [Docs](https://docs.powersync.com/tools/cli).

**New demos & guides:**

  * [It's easier than ever to add your own source DB connector](https://github.com/powersync-ja/powersync-service/tree/main/docs/replication) to PowerSync. Steven documented how replication in the PowerSync Service works — knowledge that until now mainly lived in people's heads.
  * [Supported platforms reference](https://docs.powersync.com/resources/supported-platforms) — we fleshed out this page to include more detail, like minimum platform versions per SDK, so you can quickly check whether PowerSync runs on your target platform.
  * [.NET attachments demo](https://github.com/powersync-ja/powersync-dotnet/tree/main/demos/MAUITodo) — the MAUI To-Do demo now also shows offline-first file syncing with the attachment APIs from v0.1.2.
  * [Load custom SQLite extensions](https://docs.powersync.com/client-sdks/advanced/sqlite-extensions) — how to load custom SQLite extensions into the client-side database.

## Community feed

  * Conrad wrote about how we built our internal company brain: data from 14+ systems aggregated into Postgres, synced to local SQLite with PowerSync, and queried by agents from Slack, a CLI, or fully offline with local models. [Read the post](https://powersync.com/blog/building-our-company-brain-agents-sqlite-offline-capable).
  * Manrich shared the dogfooding story of rebuilding the PowerSync Dashboard on our own sync engine. [Read the post](https://powersync.com/blog/rebuilding-powersync-dashboard).
  * Dean, Christiaan, Steven, and Simon manned our booth at Local-First Conf in Berlin. Thanks to everyone who came to chat! [Talks are on YouTube](https://www.youtube.com/playlist?list=PLXxEKA_dxoH0).
  * [@sravan27](https://github.com/sravan27) fixed several cases where Sync Streams evaluation diverged from SQLite semantics, which could silently sync the wrong rows ([json_each](https://github.com/powersync-ja/powersync-service/pull/647), [division by zero](https://github.com/powersync-ja/powersync-service/pull/646), [signed casts](https://github.com/powersync-ja/powersync-service/pull/645), [alias warnings](https://github.com/powersync-ja/powersync-service/pull/662)). Disclosure: most of this came out of a paid hardening sprint we ran with Sravan. Thank you for the solid work.
  * [@asiergmorato](https://github.com/asiergmorato) added multi-process database support to the Swift SDK, which became the App Groups feature ([PR #147](https://github.com/powersync-ja/powersync-swift/pull/147)). He needed it for his own app, [Fitwoody](https://fitwoody.camp/). Also thank you for your [Swift Data integration](https://github.com/powersync-community/swift-data), which lets Swift Data models persist and sync through PowerSync.
  * [@mandrade2](https://github.com/mandrade2) tried out [our Tauri integration tests](https://powersync.com/blog/tauri-integration-tests), hit an error running them in Vitest's iframe, fixed it in [PR #991](https://github.com/powersync-ja/powersync-js/pull/991), and we've since updated the post with his fix. We love this kind of feedback loop, thank you!
  * Thank you also to [@henriquekraemer](https://github.com/powersync-ja/powersync-service/pull/734), [@marioortizmanero](https://github.com/powersync-ja/powersync-kotlin/pull/357), [@rumitvn](https://github.com/powersync-ja/powersync.dart/pull/432), [@delagen](https://github.com/powersync-ja/powersync-js/pull/1016), [@sincraianul](https://github.com/powersync-ja/powersync-js/pull/1051), [@daniel-vacic](https://github.com/powersync-ja/powersync-native/pull/23), [@Ishant5436](https://github.com/powersync-ja/powersync-cli/pull/56), [@shenlong-tanwen](https://github.com/powersync-ja/sqlite_async.dart/pull/145), and [@VIVAAN-DHAWAN](https://github.com/powersync-ja/powersync-js/pull/975) for your contributions — we're seeing more and more substantial features and fixes from the community and are loving it.
  * Yahya ([@whygee-dev](https://github.com/whygee-dev)) built [powersync-mdbx](https://github.com/whygee-dev/powersync-mdbx), a research reimplementation of the PowerSync replication protocol in Rust + MDBX, with promising benchmarks. It's not a drop-in replacement today, but as Ralf put it: "It's a very good observation that the PowerSync model fits quite well into a KV store, and does not need a full database like MongoDB or Postgres." The thread is in [`#engineering-discussions`](https://discord.com/channels/1138230179878154300/1504213613009834145/1527822415516663828).
  * New proposal: [SQLite as sync bucket storage](https://github.com/powersync-ja/powersync-service/pull/674). Steven is experimenting with SQLite (and MySQL) as bucket storage options, which would let self-hosted setups run the PowerSync Service without a separate MongoDB or Postgres storage database.
  * New proposal: [Connection count & error metrics](https://github.com/orgs/powersync-ja/discussions/661). This would add a counter to our existing sync API metrics for the total number of completed sync connections, labelled by outcome, error code, close reason, and transport. You'd then be able to answer questions like "were there recent sync error spikes?" with a simple Prometheus query.

## Feature story: JavaScript SDKs v2

Over time, our JavaScript SDKs accumulated a lot of DX issues, and more recently AX issues too. So we took a step back and asked: what would make these SDKs better to work with and contribute to, for both humans and agents? We kept looking at the public API itself. `@powersync/common` exposed the SDK's internals alongside its public classes, so routine changes on our side could break existing builds or produce confusing type errors. Taking `AbstractPowerSyncDatabase` as an example, which was both a class and an effective public interface: even adding a method to it counted as a breaking change under TypeScript's structural rules.

The day-to-day ergonomics had rough edges too. The options you passed to `PowerSyncDatabase` were spread across a nested chain of interfaces, so there was no single place to see what was available. The `database` field accepted a `DBAdapter`, an `SQLOpenFactory`, or open options all at once, so autocomplete showed every `DBAdapter` method instead of the options you wanted. The `js-logger` dependency caused problems when bundling. And WebSocket support was bundled whether you used it or not, which was not cheap: it relied on RSocket, whose packages are around 500 kB and need a custom build step to work outside Node.js.

None of these were dealbreakers on their own, but together they made the SDKs harder to work with than they should be. And not just for people: coding agents tripped over the same confusing types and scattered options. So we fixed the foundation. Benefits of the JavaScript SDKs v2.0 release include:

  * A cleaner, more stable API, with only public interfaces exposed and implementation details in a separate package
  * Simpler setup, with one clearly-typed set of options for the database, and one for `connect()`
  * Logging as a small `PowerSyncLogger` interface rather than a separate dependency
  * Smaller bundles, with WebSockets loaded lazily and the two web workers merged into one
  * OP-SQLite built into `@powersync/react-native` as the default driver, replacing React Native Quick SQLite

There are breaking changes, but for most apps the upgrade is a few mechanical edits to how you construct the database, connect, and set up logging. The [release notes](https://releases.powersync.com/announcements/v2-0-of-powersync-javascript-sdks) walk through every one. A lot of what went into v2.0 came straight out of your feedback and sharing how you're using these SDKs. Please keep it coming.

That's it for this issue.

---

# Building Our Company Brain: Agents + SQLite, Offline-Capable

> How we built an internal "company brain" by aggregating data from 14+ systems into Postgres, syncing it to a local SQLite database with PowerSync, and giving agents a skill to query it — usable from Slack, a CLI, and even offline with local models.

- Published: 2026-07-24
- Author: Conrad Hofmeyr
- Category: Showcase
- Source: https://powersync.com/blog/building-our-company-brain-agents-sqlite-offline-capable

---

By now you've probably heard of the idea of a "second brain" or "company brain". Here's [YCombinator's Summer 2026 Request for Startups](https://www.youtube.com/shorts/IaWIazkWWog):

> Every company has critical know-how scattered everywhere. Some of it lives in people's heads. Some of it is buried in old email accounts, Slack threads, support tickets, and databases. The company works because humans vaguely remember where that knowledge is and how to apply it. But AI agents can't operate like that. If we want every company to run on AI automation, we need a new primitive: a company brain. [...] A system that pulls knowledge out of all these fragmented sources, structures it, keeps it current, and turns it into an executable skills file for AI.

In April 2026, Andrej Karpathy's tweet about research-focused [LLM Knowledge Bases](https://x.com/karpathy/status/2039805659525644595?lang=en) inspired a lot of people to simply have their agent use a folder of Markdown files to create and maintain a kind of 'second brain' with a collection of useful knowledge. YCombinator CEO Garry Tan created his [GBrain](https://github.com/garrytan/gbrain) project directly inspired by Karpathy's idea, for example.

While a "folder of Markdown files" is elegant in its simplicity, there are many other ways to create a kind of 'second brain' using some combination of existing tools and technologies. There's now also dozens of companies aiming to solve this need, from startups building dedicated new AI brains and context layers, all the way to established database, ETL and data warehouse companies jumping on the bandwagon.

## Landing on SQLite

For any team that's amassed even a moderate amount of historic knowledge, a functional 'company brain' is clearly very valuable. That motivated us to create our own around April. We really liked the simplicity of combining "a folder of markdown files" with the agents of our choice. We had some specific requirements in mind, however, that took us in a somewhat unique direction:

1. We wanted to use structured data where possible (not just unstructured text) with proper querying ability.
2. We wanted the 'brain' to be collaborative: multiple people in the team should be able to access and manage the same knowledge.
3. We wanted something self-hosted rather than putting our sensitive data into a 3rd party SaaS product. Ideally we wanted to use open-source tools.

We have been a very pro-SQLite company since our founding, and so in light of our requirements, SQLite seemed like a natural choice as the foundation of the project. We know that agents grep'ing text files works superbly well, so our main question early on was: how well would it work if we *just gave an agent a SQLite database file*?

In this post I wanted to share the architecture and results. And let me just preface that by saying: This is a specific opinionated flavor of a company brain that works for us, as a team of about ~30 people. Your mileage may vary!

## TL;DR: What We Built

We built a set of simple Node.js-based ingesters that mostly use APIs & Webhooks to aggregate data from 14 (and counting) different systems like Google Drive, GitHub, Zendesk, Gong, HubSpot, Slack, etc. into a single Postgres database. The shape of the data is optimized for agent usability, using Markdown for free text, and rolling up data into columns in a single row containing JSON or Markdown where it makes sense. Then we used PowerSync to sync Postgres with a SQLite database, in which we create a full-text search (FTS) index. We dynamically generate a skill that gives any agent useful information about the schema and SQLite query conventions (including using the `sqlite3` CLI which ships with macOS and is readily available on Linux and Windows).

Then we created two tools for the team that can be used based on preference:

1. A Slack bot that has a real-time synced SQLite database (using the PowerSync Node.js SDK), and uses Claude in headless mode with our provided skill to answer prompts when tagged in public Slack channels[^1]; and
2. A CLI tool that provides a synced SQLite database and our skill, so that you can use the company brain on your own machine with the agent of your choice. Since it's just SQLite, you can use it offline with local models.

## TL;DR: The Results

This relatively simple architecture resulted in an incredibly useful tool. It turns out that the latest models and harnesses are really good at figuring out how to use a SQLite database. This includes running queries (including aggregations) over embedded JSON in the database – SQLite has really good built-in support for JSON.

![Screenshot of the company brain Slack bot answering a question about PostgreSQL failover support, citing a Zendesk ticket and an internal engineering document.](https://powersync.com/images/blog/building-our-company-brain-agents-sqlite-offline-capable-inline-slack-bot-answer.png)

Our team quickly adopted the tool and it has saved us a huge amount of time on doing any kind of work that benefits from stitching together context across siloed systems. Our experience was very similar to what the YCombinator team [spoke about](https://www.youtube.com/watch?v=B246K_G7mHU&t=455s) when they built something similar with Postgres:

> It didn't just make it easier to answer questions, it dramatically increased the number of questions that we would ask and dramatically increased the scale and complexity of the questions that we would dare to ask.

If you're interested in a deeper dive of how we put it together, read on.

## Data Ingesters

Here's a few examples of our ingesters to give you an idea of how we structure the data:

* **Slack**: We have one Slack bot that doubles as both a data ingester and a prompt-answerer. It uses Slack's [Socket Mode](https://docs.slack.dev/apis/events-api/using-socket-mode/) to ingest data in real-time in any channels it's added to, and to listen for prompts. In Postgres, we store one row per channel per day. Whenever there's an event in that channel, we update the existing roll-up for that day. The whole channel conversation is rendered in Markdown format, including the contents of threads. We convert attachments like PDFs and images to Markdown using an LLM API.
* **Google Drive:** For simplicity, we currently poll the Drive Changes API. We have a table with a column for the Markdown representation of each Drive file. Google Docs are easy to export as Markdown. We use the Sheets API to build nice Markdown tables of spreadsheets, which frontier LLMs do an excellent job of interpreting. PDFs get converted to Markdown too using an LLM API. For DOC/DOCX files, we use [Mammoth](https://www.npmjs.com/package/mammoth) to convert to HTML, and then convert that to Markdown. We also render all the comments on Drive files as Markdown, including their highlighted text.
* **HubSpot:** We ingest all the *Companies* in our HubSpot system (which represent our customers), and embed the contacts for each company as a JSON column on the company row. The HubSpot company IDs are an identifier shared across several of our systems, which makes it easier for agents to associate data across different systems.
* **Gong:** We ingest the transcripts of calls, and also use an LLM API to generate meeting notes in Markdown format.
* **Stripe:** We ingest customers from Stripe, and build JSON embedded representations of each customer's subscriptions and invoicing history. These are simply stored as columns on the customer rows.
* **GitHub:** We ingest Issues, PRs and Discussions – including their descriptions and comments.
* **Product Analytics:** We already had a homebrewed product analytics system that stores its data in a Postgres database. When ingesting that data, we transform it into a single row per customer organization, containing a few JSON columns that aggregate useful high-level analytics.
* **Gmail:** We ingest customer email threads, by comparing the domain names of the email participants with HubSpot Customers. Email conversations are rendered as Gmail-style threads, with quoted text and non-customer-facing messages stripped. PDF and image attachments are converted to Markdown using an LLM API.

There is a "meta" table in Postgres which contains descriptive information about the schema. Each ingester's `schema.sql` definition file is responsible for doing an upsert into that table with its metadata. These help the agent with interpreting the database and knowing where to find what information (more on that below).

![Screenshot of the Postgres "meta" table with columns for table name, source system, description, and column comments.](https://powersync.com/images/blog/building-our-company-brain-agents-sqlite-offline-capable-inline-meta-table.png "The 'meta' table describes the schema so agents know where to find what information.")

## Syncing to SQLite

For syncing from Postgres to SQLite, we define auto-subscribing [Sync Streams](https://docs.powersync.com/sync/streams/overview#sync-streams) in PowerSync for the relevant tables. We currently have a single company-wide dataset, but we could also use partial syncing for gating access to specific data. This would also allow scaling to a much larger total dataset – with users only syncing the part of the data that is relevant to them.

```yaml
 stripe_customers:
    auto_subscribe: true
    queries:
      - SELECT id, stripe_id, email, name, description, currency, balance, delinquent,
               created_at, subscriptions, invoices
          FROM stripe_customers
          WHERE archived = false
```

At our scale we currently have on the order of ~100k records being synced to SQLite, which takes about ~20 seconds for the initial sync, and then PowerSync keeps the SQLite database updated incrementally with deltas after that.

## Skill

We dynamically generate a skill (based on a template) containing information to help the agent with using the SQLite database:

* A schema description using the contents of the "meta" table mentioned above.
* Usage and input/output guidelines for the `sqlite3` CLI
* Guidelines on SQLite types, working with JSON, and using full-text search (FTS)
* Suggested workflow for answering a question
* Basic heuristics to decide what information is authoritative
* Matching related data about an organization or person across tables (prefer shared identifiers where available, or use company domain name or email address, or fall back to proper noun matching)
* Confidentiality note ("Do not transmit data outside the user's local environment without explicit permission")

It might actually be sufficient to have a static skill with instructions on retrieving the schema description from the "meta" table, to avoid the step of dynamically generating the skill. We haven't tested that yet.

## Slack Bot

The prompt-answering/Q&A part of the Slack bot is pretty straightforward. It listens for mentions of its name on any channels that it's a member of, and then launches `claude` in headless mode to execute prompts using the skill and SQLite database (which is synced in real-time using the PowerSync Node.js client SDK). If a schema change is detected, it currently resyncs the SQLite database (since this is a reasonably inexpensive operation).

For security reasons, we block the Slack bot from answering questions in any Slack Connect channel, or any channel with outside guests. We also limit the tool calls that Claude can execute (`sqlite3`), disable web search/fetch, provide minimal allowlisted env vars, and limit the outbound network access of the machine where the bot runs.

## CLI Tool

When the CLI tool is first launched, it opens an internal web app where the user has to sign in with their Google Workspace account (our main identity provider). That passes a longer-lived JWT back to the CLI. The CLI uses that longer-lived JWT with the internal web app's API to securely mint short-lived JWTs (valid for only 5 minutes) for PowerSync's authentication which allows syncing the SQLite database. If the longer-lived JWT expires or its associated session is revoked, the CLI wipes the SQLite database for security. Whenever the CLI is running, it keeps the SQLite database in sync in near real-time (we will probably turn this into a background daemon in the future).

Any decent agent can use the SQLite database and skill provided by the CLI.

## It Works Offline, Running Locally On-Device

Since we are giving the agent all the context it needs in a SQLite file, we can use the company brain offline with local models. We have used it with Ollama paired with either [Pi](https://pi.dev/) or [Claude Code](https://docs.ollama.com/integrations/claude-code).

With models like [Gemma4 26B](https://deepmind.google/models/gemma/gemma-4/) that we've been using so far, the quality of company brain answers are obviously not on par with frontier models like Opus, Fable and GPT5, but are still respectable and provide a solid fallback if we happen to not have Internet access at any point[^2].

When the user goes back online, PowerSync will sync the deltas to bring the SQLite database up to date.

This project serves as a reference implementation for how PowerSync can be used to provide a locally-available synced context layer (in SQLite) for "edge AI" / on-device AI use cases with local open-weight models. This was not specifically one of the original requirements for our 'company brain', but it turned out to be a useful benefit of the PowerSync-SQLite architecture.

## Roadmap

This is phase 1. There's a lot of things we want to explore further.

The first one will likely be bi-directional syncing. We can allow agents to codify knowledge in the database (e.g. customer intel, market knowledge, etc.). PowerSync allows us to control how SQLite mutations are processed into Postgres with server-authoritative logic in our backend application.

Another one is keeping fresh copies of all our product Git repos as references that can be consulted when answering questions and performing work. This would give us even richer context and more precision. Agents will be able to combine data from all our systems with the product source code as ground truth.

We have several other ideas that are percolating.

## Want to Use This?

If you would like to run your own version of this and would like to use our implementation as a baseline, we will open-source it. [Let me know](mailto:conrad@powersync.com) if you're interested.

## Postgres Alternative?

Instead of syncing the data from Postgres to SQLite, another possibility we superficially investigated is to define a skill that instructs the agent to query Postgres directly, using [`psql`](https://www.postgresql.org/docs/current/app-psql.html). We briefly tested this but didn't explore it deeply. With the PowerSync-SQLite approach, access control can be achieved by partially syncing the Postgres data to users based on their permissions, whereas for Postgres, [Row-Level Security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) may be suitable for access control. When using Postgres, the 'company brain' would also not be usable offline, and as mentioned above, an on-device AI reference implementation was one of the benefits we achieved with this project. However, using Postgres directly may be suitable for the needs of other companies.

[^1]: The experience is similar to [Claude Tag](https://www.anthropic.com/news/introducing-claude-tag), which was launched by Anthropic a few weeks after we launched our internal company brain Slack bot.

[^2]: Another idea we want to investigate is using something like [LiteLLM AI Gateway](https://docs.litellm.ai/docs/simple_proxy) to route prompts to cloud or local models based on their complexity.

---

# Convex + PowerSync: Design Notes from the Experimental Release

> Adding experimental Convex support: the design decisions we made, the parts of Convex that fit well, the rough edges, and the open questions we're still working through.

- Published: 2026-06-17
- Author: Kobie Botha
- Category: Engineering
- Source: https://powersync.com/blog/convex-powersync-design-notes

---

We've added experimental [Convex](https://www.convex.dev/) support to PowerSync, after a steady amount of requests for it from the community. This post is the engineering side of that work: the design decisions we made, the parts of Convex that fit PowerSync well, the rough edges, and the questions we're still working through.

## PowerSync in thirty seconds

If you haven't used PowerSync before, here's briefly how it works. PowerSync keeps a backend database in sync with a local SQLite database embedded in your app, so the app reads and writes locally, is highly responsive, and keeps working whether or not it's online.

There are two main pieces: the PowerSync Service, which runs on the server and connects to your source database, and a client SDK, which manages the local SQLite database on each device. On the read path, the Service sends each client only the rows it should see, based on *Sync Streams* you define. That's partial sync: every device holds its own subset of the data, not a copy of the whole database. On the write path, your app writes to local SQLite, the SDK queues the change, and that queue uploads through a path you control. For Convex, that path is your existing Convex mutations.

## Convex support is just another module

PowerSync is designed to be stack-agnostic and each supported source database (currently: Postgres, MongoDB, MySQL, SQL Server, and now Convex) is its own [module](https://github.com/powersync-ja/powersync-service/tree/main/modules) on top of a shared core. The core handles what's common to every backend: the sync protocol, bucket storage (how replicated data is partitioned for efficient syncing), and checkpointing (tracking how far replication has progressed). Each module handles the database-specific replication. So adding Convex support came down to writing the Convex-specific replication code, and that's mostly what the rest of this post covers.

## How the Convex module replicates data

PowerSync reads from Convex through its Streaming Export API, using three endpoints: `json_schemas` lists the tables, `list_snapshot` reads a full copy of a table, and `document_deltas` returns changes to data in the order they happened.

When PowerSync first connects, it pins a single snapshot timestamp and reads every selected table at that timestamp. Because the timestamp stays fixed, the copy is consistent even though `list_snapshot` reads the tables one at a time.

That initial copy is resumable. PowerSync records how far it got in each table, so a restart continues instead of starting over. This matters for large datasets, where the first copy can take a while.

Once the copy is done, PowerSync switches to streaming. It polls `document_deltas` for new changes, starting from the same timestamp the snapshot was taken at, so no rows are missed and nothing is copied twice. For each change, it uses your Sync Streams to decide which rows to keep, how to transform them, and which buckets they belong to. Buckets are the partitions PowerSync stores replicated data in, so that later, when a client connects, the Service can hand it just the buckets it needs.

## What fit well

A few things about Convex lined up well with how PowerSync already works.

A Convex mutation is atomic, and every write in it shares one commit timestamp (`_ts`). Convex never splits those writes across two `document_deltas` pages, so we receive them together and commit them as a single transaction. A client never sees half a mutation.

`document_deltas` also returns the complete document after each change, not just the fields that changed. That means we don't have to keep our own copy of the previous row to work out a diff, so we store less per row than we do for some other databases.

Another big win was having a stable ID. Convex gives every document an `_id` that never changes. Our Postgres, MySQL and SQL Server replicators all have to track replica identity, because the columns that identify a row are configured per table and a row's identity can change underneath you. With Convex, `_id` is always the identity, so we skipped that whole class of bookkeeping.

## The checkpoint table

PowerSync needs to know when a client's queued writes have been acknowledged by Convex. We get that signal from the Convex replication cursor: once replication reaches the cursor recorded for a write checkpoint, we can tell the client its write is durable. The catch is that the `document_deltas` cursor only advances when something writes to Convex. On an idle deployment, polling `document_deltas` returns the same cursor over and over, so a write checkpoint can sit in storage, correct but never delivered, because no later change ever moves replication up to it.

Our fix is to write to Convex ourselves. After we record a write checkpoint, we call a `createCheckpoint` mutation that upserts a row in a small `powersync_checkpoints` table. That write produces a new entry in `document_deltas`, which advances the cursor. When the replicator sees the marker row it ignores it as user data, but the new cursor position is enough to release the write checkpoint to the client. You deploy the mutation; we call it.

We're not doing anything unusual here, though on other backends this step is generally plumbing that the developer never has to touch. For example, in our Postgres replicator, we emit a logical replication message, which you never see, and with MongoDB we manage a `_powersync_checkpoints` collection for you. Ideally we'd like to remove this step. It would take a way to emit an ordered event into `document_deltas` without running a mutation, or a change to how we publish write checkpoints so we don't need the cursor to advance past an already-committed position. We wrote up our full analysis in [convex-write-checkpoints.md](https://github.com/powersync-ja/powersync-service/blob/main/docs/convex/convex-write-checkpoints.md).

## ID mapping with client-generated UUIDs

Convex generates document IDs server-side, so a client can't know a row's `_id` until after it's inserted. PowerSync needs the opposite: a stable local ID the moment a row is created, since the row lives in local SQLite and the app reads and writes it before the upload reaches Convex.

To bridge that, each replicated document carries a client-generated UUID, synced back to the client as `uuid AS id`. Convex keeps its own `_id`, the client uses the UUID, and your mutations map between the two on upload.

This is the most visible DX cost of the integration today since every mutation has to handle the mapping. We looked into whether Convex could take a client-supplied ID instead, but from our analysis it would need significant changes on the Convex side. For now, it seems the UUID pattern is here to stay.

## Schema changes

PowerSync reads each row's value straight from the JSON document in `list_snapshot` and `document_deltas`, not from Convex's `json_schemas` metadata. That's deliberate: `json_schemas` can omit a field until a document populates it, so reading types from it would tie a column's representation to whether Convex had reported that field yet.

A nice side effect is that schema changes mostly handle themselves. Adding a field, removing one, or changing a type flows through `document_deltas` as a normal document change, with no re-snapshot. The exception is dropped tables. Deleting a table emits no per-document deletes, so rows already on clients can linger. The workaround is to clear the table first, or delete its documents through a mutation. We've documented this limitation and plan to handle it properly in a later release.

## Sync Streams instead of Convex server functions

The Convex team has been candid that they're not fully comfortable with this part of the design, and we think it's worth discussing openly.

In a Convex app, reads are TypeScript query functions deployed to Convex. Authorization lives in those functions, and Convex's reactivity pushes updates to subscribed clients. With PowerSync, the read path for synced data moves out of those functions. Which rows sync to each client is defined in [Sync Streams](https://docs.powersync.com/sync/streams/overview) (SQL-like queries the Service evaluates), and client reads run as SQL against local SQLite. Authorization you have in query functions gets expressed again in Sync Streams for the synced data.

Sync Streams exist because of partial sync. A query function answers a query over the full database; a Sync Stream defines which subset reaches each device. Something has to declare that subset for offline-first, and server functions don't have a primitive for it today.

Writes are also affected. Because the client works against SQLite, values that Convex stores as structured data sync down as their SQLite equivalents. A Convex object field, for example, arrives as JSON text, so a mutation that writes it back has to convert it. The demo app has a [basic example](https://github.com/powersync-community/powersync-convex-todolist-demo/blob/main/src/library/powersync/ConvexDecoder.ts) of this.

So the tradeoff here is that you get SQL on the client (including joins), offline reads, and devices that only hold data they're allowed to see. You pay by reworking the read path of an existing app, the biggest piece of migration work, plus some conversion work on writes. New apps have less of this.

## Convex Components: the bigger open question

Components are Convex's mechanism for packaging reusable backend modules into a Convex app. What if the entire PowerSync service ran as a Convex component? This is not impossible, but it would be a lot of work for us to implement, and we don't yet know whether the consistency guarantees PowerSync relies on would hold up. Still, if the integration gets traction, we're open to exploring it further.

## Try it out

We shipped this early version to find out whether the current approach is good enough and to learn where the biggest gaps are. We want your feedback: it will directly influence whether – and how – this integration evolves.

Get started with our [Setup Guide](https://docs.powersync.com/intro/setup-guide). Share your feedback by opening an issue on [GitHub](https://github.com/powersync-ja/powersync-service/issues) or join us in [Discord](https://discord.gg/powersync).

---

# PowerSync Changelog: May 2026

> A wave of quality community PRs, open engineering discussions, Sync Streams reaching GA, and foundational work on the Dart and Swift SDKs.

- Published: 2026-06-09
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-changelog-may-2026

---

Community PRs have been strong lately, and we're doubling down on open-source transparency by moving more engineering discussions into `#engineering-discussions` on our [Discord](https://discord.com/powersync) server. Thanks to all the contributors!

On the product side, highlights were that Sync Streams reached GA, the Dart SDK got a major overhaul, the Swift SDK was rewritten in pure Swift, and you can now search and filter instance logs in the Dashboard.

Grab another coffee, here's everything that happened over the past couple of months.

## Product updates shipped

**PowerSync Service:**

  * **Sync Streams are now GA**: Since beta we added global CTEs, type-safe generated client wrappers, better error reporting with source offsets, and a long list of bug fixes. If you're still on Sync Rules, now's the time to migrate. Use the button in the dashboard or run `powersync migrate sync-rules` in the CLI. [Release notes](https://releases.powersync.com/announcements/sync-streams-are-now-generally-available) and [Docs](https://docs.powersync.com/sync/streams/overview).
  * **Earlier detection of Postgres WAL slot problems**: For Postgres source databases, if a replication slot is lost during initial replication, the Service now catches it early and stops rather than running to completion and failing. More importantly, WAL budget warnings now surface in the Dashboard and diagnostics API before a slot is lost, so you can fix the underlying conditions before they become a problem. [Docs](https://docs.powersync.com/maintenance-ops/replication-lag#postgres).
  * **HA replication for Pro plan+**: PowerSync Cloud instances on the Pro plan and above now get high-availability replication processes.

**Client SDKs:**

  * **Dart/Flutter SDK v2.0 — consolidated and faster**: `powersync` is now the only package you need. We removed `powersync_core`, `powersync_sqlcipher`, and `powersync_flutter_libs`. Encryption is built in, the native connection pool is Rust-backed for faster queries and multi-isolate support, and web databases now default to OPFS on Chrome and Firefox. Learn more in our feature story below.
  * **Inspect your database in DevTools (Dart/Flutter)**: v2.1.0 adds a PowerSync tab to Dart & Flutter DevTools. Inspect open `PowerSyncDatabase` instances, view active Sync Streams and sync status, and run queries against the local SQLite database while debugging. [Docs](https://docs.powersync.com/tools/dart-devtools-extension).
  * **Swift SDK rewritten in pure Swift (v1.14.0)**: Previous versions wrapped a Kotlin XCFramework. The SDK is now native Swift throughout: no Kotlin dependency, smaller binary, better debuggability in Xcode, and typed CRUD payload fields. There are no breaking changes to the public API, but parts of the SDK are a full rewrite so we recommend smoke-testing your queries after upgrading. [Release notes](https://releases.powersync.com/announcements/swift-sdk-1-14-0-now-pure-swift).
  * **Concurrent reads and faster web writes (Web SDK v1.38.0)**: Added support for `OPFSWriteAheadVFS`, a new synchronous VFS using write-ahead logging. Reads no longer block on writes and multiple read queries run in parallel. Currently Chromium-only (it relies on OPFS's readwrite-unsafe mode). [Docs](https://docs.powersync.com/client-sdks/reference/javascript-web#2-opfs-based-alternatives).
  * **Attachments and Mac Catalyst for .NET (v0.1.2)**: The .NET SDK gained attachment sync APIs matching the implementation in other SDKs, plus Mac Catalyst support. [Changelog](https://releases.powersync.com/announcements/powersync-net-sdk).
  * **Improved raw tables across all SDKs**: `put` and `delete` statements are now inferred automatically. You only need to provide the `tableName`. Local-only columns and other table options now work with raw tables too. [Docs](https://docs.powersync.com/client-sdks/advanced/raw-tables).
  * **Capacitor SDK reached beta**: Production-ready for tested use cases and covered by our SLAs. New since alpha: Swift Package Manager support for iOS (requires Capacitor 8+), and significantly faster sync on native platforms via NDJSON-HTTP. [Docs](https://docs.powersync.com/client-sdks/reference/capacitor).

**Tools:**

  * **Search and filter instance logs**: The Logs view in the PowerSync Dashboard now supports free-text search and structured `alias:value` filters (by `user_id`, `client_id`, error code, and more), plus CSV export. [Release notes](https://releases.powersync.com/announcements/searchable-instance-logs-in-the-powersync-dashboard) and [Docs](https://docs.powersync.com/maintenance-ops/monitoring-and-alerting#instance-logs).
  * **Self-service Private Endpoint setup**: Private Endpoints (AWS PrivateLink) can now be created and managed directly in the PowerSync Dashboard — no support ticket needed. Available on Team and Enterprise plans for Postgres and MongoDB Atlas. [Release notes](https://releases.powersync.com/announcements/self-service-private-endpoints-in-the-dashboard) and [Docs](https://docs.powersync.com/configuration/source-db/setup/private-endpoints).
  * **Trigger compaction from the CLI**: `powersync compact` triggers compaction on your linked PowerSync Cloud instance directly, with an optional `--timeout` flag for large datasets. [Docs](https://docs.powersync.com/tools/cli).

**New demos & guides:**

  * [Self-hosting on AWS EKS](https://docs.powersync.com/maintenance-ops/self-hosting/aws-eks) — step-by-step guide for deploying PowerSync on Kubernetes via Helm Charts.
  * [Dart/Flutter DevTools extension guide](https://docs.powersync.com/tools/dart-devtools-extension) — how to use the new database inspector for Dart/Flutter apps.
  * [Replication lag guide](https://docs.powersync.com/maintenance-ops/replication-lag) — what this metric means, common causes, and remediation steps.
  * [Diagnosing sync latency](https://docs.powersync.com/debugging/troubleshooting#diagnosing-sync-latency) — how to isolate which stage of the sync process is slow, and how to correlate user reports with sync session logs.

## Community feed

  * We added a [PowerSync add-on to the TanStack CLI](https://github.com/TanStack/cli/pull/407). Run `create powersync-app --framework react --add-ons powersync` to get a working PowerSync setup for React.
  * Steven built a [MikroORM + PowerSync PoC](https://github.com/powersync-community/mikro-orm-poc). [Here's the discussion](https://github.com/powersync-ja/powersync-js/discussions/896) if you have thoughts or want to help take it further.
  * Dev wrote a series on the role sync engines can play in AI apps: [most AI chat apps throw away in-flight responses on refresh or disconnect — treating LLM output as synced state fixes that](https://powersync.com/blog/most-ai-chat-apps-are-broken-sync-engines-are-the-fix), [why AI apps default to single-player and how sync engines bring multiplayer collaboration](https://powersync.com/blog/why-is-every-ai-app-single-player), and a [two-part practical guide](https://powersync.com/blog/building-ai-powered-apps-part-1) on building collaborative, synced AI apps ([Part 2](https://powersync.com/blog/building-ai-powered-apps-part-2)).
  * Simon wrote up [Easy Tauri Integration Tests with Vitest](https://powersync.com/blog/tauri-integration-tests) — useful if you're building with the Tauri SDK.
  * New engineering proposals:
    * **Write API** — Christiaan is exploring a first-class write protocol for PowerSync, covering mutators, conflict handling, and how writes flow from client to backend. This would be a significant change to how you build with PowerSync and we want input from people actually building with it. Join the [discussion in Discord](https://discord.com/channels/1138230179878154300/1504213613009834145/1504851899806126201).
    * **Raw Table High Performance Diffs** — trigger-based diffing specifically optimized for raw tables, where the current approach has limitations. [Proposal](https://docs.google.com/document/d/12bvZDJF2aaTOqkxHyo3W-TYGQTaS9FQFdu-MX2yOuqI/edit).
    * **Faster and incremental `sync_local`** — a more internal proposal, with the goal to make initial sync faster and eventually incremental, so it can report progress and avoid blocking writes for minutes on large datasets. [Discussion #178](https://github.com/powersync-ja/powersync-sqlite-core/discussions/178).
    * **Streaming attachments** — the attachment queue currently loads the entire file into JS memory, which can be a problem with large files. [Discussion #968](https://github.com/powersync-ja/powersync-js/discussions/968).
  * [@austinbhale](https://github.com/austinbhale): thank you for building out attachments support for the .NET SDK, bringing it to parity with our other SDKs! [PR #68](https://github.com/powersync-ja/powersync-dotnet/pull/68).
  * Thank you also to [@Shamyyoun](https://github.com/powersync-ja/powersync-kotlin/pull/352), [@sravan27](https://github.com/powersync-ja/powersync-service/pull/644), [@VIVAAN-DHAWAN](https://github.com/powersync-ja/powersync-js/pull/970), [@Sagbyy](https://github.com/powersync-ja/powersync-kotlin/pull/348), [@johnnysedh3lllo](https://github.com/powersync-ja/powersync-js/pull/925), and [@JexanJoel](https://github.com/powersync-ja/powersync-js/pull/924) for your contributions.
  * Built with PowerSync:
    * _Fig_ by the team at [figwealth.io](https://figwealth.io): freelancer finance — expense tracking, invoicing, P&L, and tax estimates. [App Store](https://apps.apple.com/us/app/fig-finance-for-freelancers/id6478242586) and [Google Play](https://play.google.com/store/apps/details?id=io.figwealth.app).
    * _Thunderbolt_ by the team behind Mozilla: an open-source, self-hostable enterprise AI client with chat, search, and research workflows across devices. [Blog post](https://www.thunderbolt.io/blog/mozilla-introduces-thunderbolt).
    * _Capubridge_ by [@aybinv7](https://github.com/aybinv7): a Tauri desktop devtool for debugging WebView-based Android apps, with direct SQLite inspection. Useful for anyone debugging PowerSync sync state on Capacitor or React Native. [GitHub](https://github.com/aybinv7/capubridge).

## Feature story: The Dart SDK gets a proper foundation

The Dart/Flutter SDK has in many ways been our flagship SDK. It was the first SDK we shipped, and it's still one of the most widely used. But it had accumulated a fair amount of technical debt: separate packages for core functionality, encryption, and Flutter libs that you had to wire up yourself; a legacy Dart sync client running in parallel with the Rust one; and some platform-specific rough edges we've been working around. On the web in particular, the setup was annoying: manual WASM file copying, and Safari requiring special cross-origin isolation headers just to use storage.

v2.0 addresses that. `powersync` is now the only package you need, whether you're building a Flutter app, a CLI tool, or a server-side Dart service. SQLite loading is now automatic through build hooks — you no longer need `powersync_flutter_libs` or a manual initialization step. Encryption is built in. On native, the connection pool is now Rust-backed, which makes queries faster and lets you safely open the same database across isolates or Flutter engines. On the web, new databases now default to the more performant OPFS on Chrome and Firefox. The sync and database workers are also merged into one file now, so there's less to configure and your compiled output is smaller.

We're now doing the same kind of work on the JavaScript SDK. A few open proposals and PRs give a sense of where it's headed: [merging the web workers](https://github.com/powersync-ja/powersync-js/discussions/949) into one (same as we did in Dart), [making WebSocket support an optional dependency](https://github.com/powersync-ja/powersync-js/discussions/950) so you don't bundle it if you don't need it, and [dropping js-logger](https://github.com/powersync-ja/powersync-js/pull/966) as a dependency in favor of letting you bring your own.

A good open-source SDK should be easy to use and easy to contribute to. We want both, and that's what inspired this.

That's it for this issue.

---

# The Journey of Rebuilding Our Dashboard

> How we rebuilt the PowerSync Dashboard by dogfooding our own sync engine in production.

- Published: 2026-06-04
- Author: Manrich van Greunen
- Category: Engineering
- Source: https://powersync.com/blog/rebuilding-powersync-dashboard

---

When we set out to rebuild the PowerSync Dashboard, we decided it would be more than a technical migration and UI refresh. It was a chance to dogfood our own product in production and share what we learned along the way. This post documents that journey.

# Why We Rebuilt: Learning from User Feedback

## Three Goals Driving the Rebuild

The most common feedback from users was that the original dashboard felt “confusing and unintuitive” compared to modern tools like Supabase.

The original dashboard was built using existing JourneyApps infrastructure and a framework designed for a different use case. The experience was fragmented: features like user account management and billing were relegated to a separate portal, forcing users to jump between tabs just to manage a single organization.

Driven by this feedback, we set out with three clear objectives for a new architecture. First, we wanted to replace the IDE-like complexity and problematic UX with something simpler. Second, we committed to dogfooding our own sync engine to power the dashboard’s data layer. Finally, we wanted this project to serve as a best practices reference for our community, demonstrating how to build a multi-tenant SaaS application with PowerSync on the web.

## Backend & API Architecture

### Our Existing Backend

The PowerSync Cloud control-plane is composed of **CRUD/RPC-style APIs** that are backed by our existing **MongoDB** databases.

### First Iteration of the New Dashboard

The new dashboard was built using a conventional Single Page Application (SPA) stack. This included **React 19** as the core library, **Vite** for efficient bundling, and **Turborepo** for managing the monorepo structure. For client-side routing, we first chose **React Router 7**, and the user interface was built with **shadcn/ui** components. Data fetching and mutation handling against the backend APIs were managed using **TanStack Query**, with **Axios** serving as the primary HTTP client.

## PowerSync Dogfooding

Using PowerSync for the dashboard required us to engage with the same documentation, use the same APIs, and confront the same decisions that our users face.

A critical decision to make when building with sync engines is defining sync boundaries. For the dashboard, we chose a **hybrid architecture** that plays to the strengths of both sync and traditional APIs.

### Decision: Read-Path Only Sync

The dashboard manages a sophisticated hierarchy of entities: **Users, Organizations, Plans, Projects, Instances, Operations, Logs, and Metrics**. Our backend provides APIs for mutations on these entities, but the read-path was where we saw the most potential for improvement with a sync engine.

The dashboard **read path** includes data that is read frequently but changed relatively rarely. 

Because the dashboard is responsible for managing critical infrastructure, we require server-side validation and auditing. While the PowerSync **write path** offers optimistic updates, the resulting complexity of handling asynchronous rollbacks and server-side validation can be significant. Therefore, we decided to initially go with the simpler API-first **write path** that provides synchronous server-side validation and auditing.

### What We Sync (And What We Don’t)

The current iteration syncs **Operations** and **Instance Configurations** to SQLite, which include **Sync Config** definitions. Entities like **User Profiles** and **Plans**, which are currently distributed across our microservices, remain on standard API calls, with a plan to unify and integrate them into the sync layer in the future.

By contrast, we do not sync high-volume or temporal data like **Logs** and **Metrics**. Sensitive authentication flows and **Billing and** **Usage** operations also remain behind standard API calls.

This hybrid approach makes navigating to an instance feel instantaneous because the data is already in the local SQLite database. Loading spinners have effectively vanished from the main navigation flow, and the UI updates in real-time.

### From Sync Rules to Sync Streams: A Real-World Evolution

The most significant learning came from actually using PowerSync at scale for our own dashboard. Here's how our approach evolved:

#### Sync Rules with JWT Parameters

Our first iteration utilized the classic [**Sync Rules**](https://docs.powersync.com/sync/rules/overview) system, the method for defining what data is synchronized to the client. We configured it to embed the required `project_id` in the JWT as shown in the configuration below:

```sql
bucket_definitions:
  project_data:
    parameters: select request.jwt() ->> 'project_id' as project_id
    data:
      - SELECT * FROM instances WHERE project_id = bucket.project_id
      - SELECT * FROM operations WHERE project_id = bucket.project_id
```

This worked, but critically, switching between projects required generating a new JWT, disconnecting and reconnecting to the PowerSync Service, and waiting for the full sync to complete. These delays and loading states were breaking the instant and fluid UI that sync engines are meant to deliver.

#### Next Iteration: Sync Streams

We migrated to our new [**Sync Streams**](https://docs.powersync.com/sync/streams/overview) system, which provides native support for on-demand syncing.

In the Sync Streams implementation, we pass an array of `project_ids`, and check it against the JWT for proper authorization. See [Sync Streams: Using Parameters](https://docs.powersync.com/sync/streams/parameters) for more detail.

```sql
streams:
  instances:
    query: SELECT * FROM instances WHERE project_id = subscription.parameter('project_id') AND project_id IN auth.parameter('project_ids')
  operations:
    query: SELECT * FROM operations WHERE project_id = subscription.parameter('project_id') AND project_id IN auth.parameter('project_ids')

# Note: at the time of writing, edition: 3 is available and recommended
config:
  edition: 2
```

Now, switching projects simply subscribes to a new stream. If a user switches back to a previous project, the data is already in SQLite and appears instantly

#### The “Too many parameter query results” issue

During migration, we hit an edge case where the service attempted to resolve our `IN` clauses as independent queries, leading to an explosion of intermediate results and a "Too many parameter query results" error.

We fixed this by converting the `IN` clause to a static check:

```sql
WHERE project_id = subscription.parameter('project_id') AND (subscription.parameter('project_id') IN auth.parameter('project_ids'))
```

This specific insight has directly informed our new [**Sync Streams Compiler**](https://github.com/powersync-ja/powersync-service/pull/451), which automatically optimizes these patterns for all users.

### Dogfooding Insights: Local-Only Tables

While building the Sync Config page, we needed a way to store local drafts as users were editing their Sync Config. We realized that we can unify our data layer and simplify state management by using a **Local-Only** table. In this way we can use the same `useQuery` hooks for both synced cloud data and temporary local drafts.

For reference here is the table definition:

```ts
export const DraftSyncStreamsTable = {
  tableDefinition: sqliteTable('draft_sync_streams', {
    id: text('id').primaryKey(),
    instance_id: text('instance_id'),
    valid: integer({ mode: 'boolean' }),
    definition: text('definition'),
    created_at: integer('created_at', { mode: 'timestamp' }),
    updated_at: integer('updated_at', { mode: 'timestamp' })
  }),
  options: { localOnly: true }
};
```

And the `useDraftSyncStreamQuery` hook:

```ts
import { db } from '~/lib/powersync';
import { useQuery } from '@powersync/tanstack-react-query';
import { toCompilableQuery } from '@powersync/drizzle-driver';

export const useDraftSyncStreamQuery = ({ instanceId }: SyncStreamVariable) => {
  const query = toCompilableQuery(
   db.select().from(DraftSyncStreamsTable).where(eq(DraftSyncStreamsTable.id, instanceId)).limit(1)
  );
  return useQuery({ queryKey: `${instanceId}-drafts`, query });
};
```

## Modern Web Stack: The TanStack Router Pivot Story

We started with React Router 7, but a hackday exploration of [TanStack Router](https://tanstack.com/router/latest) changed our trajectory. After migrating just two routes, we decided to switch. We get file-based routing that makes sense and type safety that makes it nearly impossible to break a link.

TanStack Router with its great TypeScript developer experience provides us 100% autocompletion for route paths and search parameters. It provides flexible route declarations of nested, layout or pathless routes. With automatic prefetching, it makes navigation feel local. We were really impressed and migrated the entire dashboard in a day.

## Development Velocity Through AI & Process

### v0 for Wireframes to Initial UI

We used [v0](https://v0.app/) to bridge the gap between wireframes and code. By feeding wireframes into v0, we generated shadcn-based components that got us most of the way to the finish line, allowing us to focus our energy on logic rather than CSS.

### Context Engineering with `AGENTS.md`

AI assistance is only as good as the context you provide. Maintaining a strict `AGENTS.md` file not only ensures that every AI output adheres to our technical standards (like strict TypeScript types and accessibility patterns) but also significantly increases development velocity by ensuring code consistency and reducing review time.

Here is a snippet of our AI guidelines:

```
# AI Assistant Guidelines

## Core Development Philosophy
- **KISS**: Keep It Simple, Stupid
- **YAGNI**: You Aren't Gonna Need It

## TypeScript Configuration (STRICT REQUIREMENTS)
- **NEVER use `any` type** - use `unknown` if type is truly unknown
- **MUST have explicit return types** for all functions
- **MUST use `ReactElement` instead of `JSX.Element`** for React 19

## Component Guidelines
- **MAXIMUM 200 lines** per component file
- **MUST handle ALL states**: loading, error, empty, and success
- **MUST verify actual prop names** before using components

## TanStack Query Patterns
- Query keys: Hierarchical factory pattern
- Mutations: Automatic cache invalidation
- Prefetch hooks for performance-critical paths

## Form Components
- **MUST use shadcn/ui Field components** for accessibility
- **Required Pattern**: `Field` + `FieldLabel` + `FieldDescription` + `FieldError`
- **Validation**: Zod schemas with `.catch()` for graceful failures
```

## Deployment: Managing Environment Variables

Shipping a modern SPA to multiple environments using a single Docker image presented a classic challenge: how to inject environment variables without rebuilding the image.

Standard Vite builds bake variables into the bundle at build time, but we wanted a more flexible approach. We used [import-meta-env](https://import-meta-env.org/) to inject these variables at runtime via a simple bash script. We used Node.js's **Single Executable Application** feature to bundle the injection script into a single binary, keeping our deployment pipeline fast and dependency-free.

## Conclusion

Rebuilding the PowerSync Dashboard was as much a product exercise as a frontend project, since it was a great chance to dogfood our own sync engine.

We are currently working toward the next phase, which includes open-sourcing the dashboard and preparing a version for self-hosted infrastructure.

If you have questions about our stack or our architecture, find us on [Discord](https://discord.gg/powersync).

---

# Easy Tauri Integration Tests with Vitest

> Having a hard time writing integration tests for Tauri? It's very easy with this little trick, even on macOS!

- Published: 2026-05-14
- Author: Simon Binder
- Category: Engineering
- Source: https://powersync.com/blog/tauri-integration-tests

---

Recently, we introduced our [PowerSync SDK for Tauri](https://releases.powersync.com/announcements/introducing-the-powersync-tauri-sdk-alpha).
The SDK is a Tauri plugin, meaning that it consists of two parts:

1. A Rust crate used to access a local SQLite database, sync changes via PowerSync, and notify JavaScript apps about changes.
2. A small JavaScript library acting as a type-safe wrapper around the raw Tauri IPC commands supported by our Rust crate.

As part of the development work, we also looked at ways to test our new SDK.
Tauri basically offers [three modes of testing](https://v2.tauri.app/develop/tests/):

1. A [`MockRuntime`](https://docs.rs/tauri/latest/tauri/test/struct.MockRuntime.html) for Rust, allowing us to write unit tests for our Rust crate by mocking out JavaScript.
2. A [fake Tauri environment](https://v2.tauri.app/develop/tests/mocking/) for JavaScript, allowing us to write unit tests for our JavaScript package by mocking out Rust.
3. A [WebDriver](https://v2.tauri.app/develop/tests/webdriver/) integration, allowing us to test everything together.

Especially when writing Tauri plugins, options 1 and 2 provide very little value.
How our JavaScript and Rust sources interact is the most interesting thing we want to test, as our SDK wouldn't work if anything about that was wrong.
Two tests each mocking the other half provide no guarantees.

So the only option left available to us was to spin up a demo app and use WebDriver support built into Tauri for integration tests.
However, that option has its own big issues:

1. It's designed to test Tauri apps, while we're interested in testing plugin functionality.
2. It doesn't work on macOS, which is what most of us use.

In the end, we found a neat way to very reliably test everything in our Tauri plugin nonetheless: Instead of driving an app through WebDriver,
what if we launched a Tauri app that simply... tested itself?
After all, this is exactly how we test most of our JavaScript nowadays: Instead of mocking web or React APIs to run tests in Node, we let vitest
spawn a browser and use the real thing. That loads a web page running our tests, reporting results back to a local vitest server which will print them and set
an appropriate exit code for CI.

## Using Tauri as a vitest browser

Starting from version 4, vitest has pretty decent support for custom browsers. So our plan to test our SDK was fairly straightforward:

1. Write a tiny Tauri app that allows loading any URL and loads the PowerSync Tauri plugin.
2. Tell vitest to launch that app with a custom URL instead of spawning a browser.

You can see the whole thing [in action here](https://github.com/powersync-ja/powersync-js/tree/main/packages/tauri).

The `main.rs` for our test app is very simple: It receives a URL as a CLI argument before opening a window with that URL.
Using `dev_url` skips some IPC checks and simplifies the setup:

```rust
use std::env;
use url::Url;

fn main() {
    // Use default options, but open window with URL from args.
    let mut context = tauri::generate_context!();
    if let Some(url) = env::args().skip(1).next() {
        let config = context.config_mut();
        config.build.dev_url = Some(Url::parse(&url).expect("Could not parse URL"));
    }

    tauri::Builder::default()
        .plugin(tauri_plugin_powersync::init())
        .run(context)
        .expect("error while running tauri application");
}
```

For permissions in `capabilities/default.json`, we used these:

```json
{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "description": "enables the default permissions",
  "windows": ["*"],
  "remote": {
    "urls": ["http://127.0.0.1:*"]
  },
  "permissions": [
    "core:default",
    "powersync:default",
    "core:webview:allow-create-webview-window",
    "core:window:allow-set-title"
  ]
}
```

This would not be a good idea for real Tauri apps, but permission checks would just stand in the way for integration tests.

To launch this app in vitest, we wrote a custom `BrowserProvider` in `vitest.config.ts`:

```ts
const serverFactory = preview().serverFactory;
// Relative path to the integration test runner app built with cargo.
const testRunnerExecutable = path.resolve('../../target/debug/test-runner');

class TauriBrowserProvider implements BrowserProvider {
  #tauriApp?: ChildProcess;
  #isClosing = false;

  // ... some boring methods omitted

  async openPage(_sessionId: string, url: string, _options: { parallel: boolean; }) {
    if (this.#tauriApp != null) {
      throw new Error('TODO: Calling openPage multiple times is not supported');
    }

    // Ensure the target app spawning webviews is up-to-date.
    const buildResult = spawnSync('cargo', ['build', '-p', 'test-runner'], { stdio: 'inherit' });
    if (buildResult.status !== 0) {
      throw new Error(`cargo build failed with exit code ${buildResult.status}`);
    }
    const app = spawn(testRunnerExecutable, [url]);
    this.#tauriApp = app;

    app.on('exit', (code) => {
      if (!this.#isClosing) {
        console.log('Test runner exited with code', code);
        process.exit(1);
      }
    });

    await new Promise<void>((resolve, reject) => {
      app.once('spawn', () => resolve());
      app.once('error', reject);
    });
  }

  async close() {
    this.#isClosing = true;
    this.#tauriApp?.kill();
  }
}
```

And that's it! In our `defineConfig` block, we can then use this provider as a custom browser:

```ts
export default defineConfig({
  test: {
    include: ['tests/**/*.test.ts'],
    isolate: false,
    browser: {
      enabled: true,
      provider: {
        name: 'tauri-app',
        options: {},
        providerFactory() {
          return new TauriBrowserProvider();
        },
        serverFactory
      },
      instances: [
        // We just need any bogus instance here
        {
          browser: 'chrome'
        }
      ]
    },
  }
});
```

This is enough to run tests, which now run within a real Tauri app:

![A tauri app running the vitest browser UI](https://powersync.com/images/blog/tauri-test-runner.png)

Actually using Tauri APIs requires a small workaround: Tauri installs global definitions
into the window which is then used as an IPC hook. Since vitest uses an `<iframe>` to host the test inside the
browser UI, we forward the definitions from the outer window:

```ts
import { vi, test as baseTest } from 'vitest';

async function installTauriInTestFrameHack() {
  // Tauri injects these getters on the top-level window so that it can communicate with Rust.
  // vitest runs this in an iframe though, so we forward definitions.
  const root = window.top as any;
  const current = window as any;

  await vi.waitFor(async () => {
    expect(root.__TAURI_INTERNALS__).toBeDefined();
    expect(root.__TAURI_EVENT_PLUGIN_INTERNALS__).toBeDefined();
  });

  current.__TAURI_INTERNALS__ = root.__TAURI_INTERNALS__;
  current.__TAURI_EVENT_PLUGIN_INTERNALS__ = root.__TAURI_EVENT_PLUGIN_INTERNALS__;

  // Use the ArrayBuffer class from the root scope, iframes have their own realm and
  // Tauri matches against root when interpreting binary requests and responses.
  current.ArrayBuffer = root.ArrayBuffer;
}

const test = baseTest.extend('tauriHack', { auto: true }, async () => {
  await installTauriInTestFrameHack();
});

// define tests here...
```

## Summary

Overall, this approach works very well for us! There are lots of things that are very easy with this that would
be tricky to set up with a WebDriver-based approach:

1. By using the `--watch` flag in vitest, the test runner stays open after the initial test run. This allows re-running
   tests from within the ~~browser~~ Tauri app, and attaching a JS debugger.
2. Because it's a simple process instead of something behind a proxy like the default WebDriver setup, we can also
   attach LLDB to the running Tauri app to debug our Rust code.
3. Most importantly, this approach works on all platforms supported by Tauri. We currently develop on Linux and macOS only, but the test
   setup should work on iOS, Android and Windows too.

If you're writing Tauri apps or plugins, we hope this gave you some helpful ideas on how to write integration tests!

---

# Building AI-Powered Apps: Part 2

> Part 1 covered the AI primitives: prompts, tools, and context. Part 2 moves into what happens when you wire them together — covering agents, deterministic workflows, and the hybrid agentic workflow pattern.

- Published: 2026-05-04
- Author: Dev Agrawal
- Category: Engineering
- Source: https://powersync.com/blog/building-ai-powered-apps-part-2

---

# Part 2: From Actions to Architecture

## The Agent Hype: What Are They Really?

"Agent" is the most overused word in AI right now. It communicates so much, and yet, not nearly enough about what is actually possible.

Some describe agents as "LLMs with agency to act in the real world" — which sounds more dangerous than useful. Others define them by their components: "LLM + System Prompt + Tools + Memory." While technically accurate, this doesn't explain their _architectural_ purpose.

The simplest definition is "an LLM in a loop with tools." But for software engineering purposes, an **Agent** is defined by three specific characteristics:

* **Multi-step:** A single LLM call is not an agent. Agents handle tasks that naturally require executing multiple sequential steps to reach a goal.
* **Integrated:** Agents need a harness —integrations and tools that allow them to read from and write to external systems, giving them the ability to act on the world.
* **Autonomous:** The LLM decides the execution flow. Within constraints (step limits, permissions, budgets), the agent has control over _which_ tool to call, _when_ to call it, and _when_ to stop. We rely on prompts and context to guide this autonomy.

In essence, **agents are a way to use an LLM's reasoning engine to navigate complex, unpredictable systems on behalf of a user.**

```javascript
// Pseudo-code for a basic Agent
async function runAgent(goal) {
  let context = [{ role: 'user', content: goal }];
  while (true) {
    const decision = await llm.decide(context, availableTools);
    if (decision.isComplete) return decision.finalAnswer;
    
    const toolResult = await executeTool(decision.tool, decision.args);
    context.push({ role: 'tool', content: toolResult });
  }
}
```

Because they are driven by natural language, agents make complex system navigation accessible to users who otherwise couldn't (or wouldn't want to) do it themselves.

But you can't talk about agents without immediately comparing them to their traditional counterpart...

## Deterministic Workflows: The Anti-Agent

Conceptually, **Workflows** are the inverse of agents, despite the terms often being confused.

Let's look at the properties of a traditional workflow:

* **Multi-step:** Like agents, workflows orchestrate multiple steps to accomplish a high-level goal.
* **Integrated:** Like agents, workflows integrate with external services to execute those steps.
* **Deterministic:** _Unlike_ agents, every step is strictly predefined. Given the same inputs and state, the execution path is guaranteed to be exactly the same.

**LLMs are to pure functions what Agents are to Workflows.**

You don't want an agent managing a predictable, procedural pipeline. And you don't want to write a rigid workflow for tasks that require fuzzy reasoning or handling unpredictable edge cases. Building durable, distributed workflows is a solved engineering problem. The real architectural challenge today is knowing when to use which.

Agents are easier to build for ambiguous tasks because you hand control to the LLM. But LLM inference is expensive and relatively slow. As a task becomes well-understood and predictable, it should be codified into a deterministic workflow, which is orders of magnitude faster, cheaper, and more reliable.

## Agentic Workflows: The Pragmatic Middle Ground

The reality is that "Agent vs. Workflow" is a false dichotomy. The most robust AI systems decompose tasks into hybrid execution graphs—sometimes orchestrated by procedural logic, sometimes by LLMs. This hybrid approach is what we call **Agentic Workflows**.

Instead of a black-and-white choice, you have a grayscale spectrum of autonomy. You can implement this in several ways:

* **Agents within Workflows:** A deterministic pipeline where specific, fuzzy steps are handed off to an LLM agent (e.g., a rigid CI/CD pipeline that uses an agent to summarize the blast radius of a PR).
* **Workflows within Agents:** An autonomous agent that can trigger predefined, deterministic workflows as tools (e.g., an agent deciding to trigger the rigid "Refund Processing" workflow).
* **Nested Hybrids:** Workflows inside agents inside workflows.

```javascript
// Pseudo-code for an Agentic Workflow
async function processCustomerTicket(ticket) {
  // Step 1: Deterministic routing (Workflow)
  const user = await db.getUser(ticket.userId);
  
  // Step 2: Fuzzy reasoning (Agent)
  const resolutionPlan = await supportAgent.draftPlan(ticket, user);
  
  // Step 3: Deterministic execution (Workflow)
  if (resolutionPlan.requiresRefund && resolutionPlan.refundAmount < 50) {
    await billingAPI.issueRefund(user.id, resolutionPlan.refundAmount);
  }
  
  // Step 4: Fuzzy generation (Agent)
  return await writingAgent.draftEmail(resolutionPlan);
}
```

Agentic workflows allow you to dial in the exact level of autonomy required. Almost every existing business workflow can benefit from an LLM handling the fuzzy, undefined edge cases while keeping the core procedural logic intact. The engineering challenge is finding the right amalgamation of code and prompts to build a cohesive, reliable system.

## Key Takeaways for Part 2

* **Agents are Autonomous Loops:** They use LLMs to decide the sequence of steps and tool calls required to achieve a goal.
* **Workflows are Deterministic Pipelines:** They execute a strict, predefined sequence of steps. Use them when the path is known.
* **Agentic Workflows are the Future:** The most robust systems mix both — embedding agents in workflows for fuzzy steps, or giving agents workflows as tools for reliable execution.

---

We now have the primitives (prompts, tools, context) and the architecture (agents, workflows). But to make these systems truly useful, they need access to knowledge.

In Part 3, we'll explore how to feed large amounts of data into these architectures using Retrieval Augmented Generation (RAG) and how to evaluate if the AI is actually doing a good job.

---

# Building AI-Powered Apps: Part 1

> Explore the foundational shift in AI engineering. Learn why LLMs should be treated as probabilistic pure functions and how to master prompts, tool calling, and context engineering to build robust AI-powered applications.

- Published: 2026-04-24
- Author: Dev Agrawal
- Category: Engineering
- Source: https://powersync.com/blog/building-ai-powered-apps-part-1

---

# Part 1: The New Primitives of AI Engineering

This post outlines everything I have learned about building AI-powered applications over the last year. In that time, I've built everything from a productivity bot that acts as an autonomous, multi-agent artificial teammate navigating organizational tools, to a no-code machine learning platform orchestrated entirely by generative UI, to a unified, multi-agent collaboration chat platform where agents interact directly alongside users in shared file systems.

Across all these projects, a central theme emerged: building AI-powered software requires a fundamental shift in how we think about system architecture. It's about moving away from strictly deterministic logic and learning how to seamlessly orchestrate probabilistic models within reliable, traditional systems.

This first part covers the foundational mental models you need to make that shift—starting with how to actually think about Large Language Models.

## Treating LLMs as Probabilistic Functions

The simplest way to think about LLMs is **pure functions**. Pure functions accept some input, and their output relies solely on the input and nothing else. Any state that should influence the output must be provided as an input.

While this is a very familiar concept, the pure functions we are used to also happen to be deterministic - the same input will always yield the same output.

LLMs, instead, are **probabilistic pure functions**, which means the same inputs might not give you the same output. They _probably_ will, and even if it's not the same, it's _probably_ going to be similar enough. But the exact same output is not a guarantee.

```javascript
// Deterministic pure function
function extractName(text) {
  return text.match(/Name:\s*(.*)/)[1];
}

// Probabilistic pure function (LLM)
async function extractName(text) {
  return await llm.generate(`Extract the name from this text: ${text}`);
}
```

So while architecturally we can treat LLMs the same as deterministic pure functions, they are built to serve completely different use cases. You don't want an LLM doing something that you can do with a deterministic function better. You also don't want a deterministic function to be doing what LLMs are good at.

## Programming via Natural Language

The biggest mistake developers make is treating LLMs like humans in a chat box rather than compilers interpreting natural language.

One of the most powerful and the most misleading properties of LLMs is the ability to follow instructions and generate output in natural language.

Well duh, they are large "language" models, of course they understand natural language.

But this lets people down the path of anthropomorphizing LLMs too much. At the end of the day, LLMs are still machines, and the "prompts" are a way to "program" the machines.

When we program deterministic functions, we write procedures of specific CPU instructions that give us the result we want.

With probabilistic functions (LLMs), our "programs" (prompts) are a way to increase the probability of the desired output.

Prompting is much closer to programming a computer than to talking to a human being. It comes with its own structure and keywords. It is modularized and fed into frameworks that orchestrate their usage.

Outputs of LLMs are quite often **structured JSON or XML data** that is parsed by those frameworks and interpreted as instructions, even control flow and execution.

Every LLM has different nuances to how they interpret the provided prompts, similar to how computing platforms differ from each other in subtle ways and require different instructions for the same results.

The most important aspect of natural language instructions is that they are **orders of magnitude more accessible** than code. You can read and tweak them and change the behavior of the machines with zero prior knowledge of computer science. Any product that cares about the user in any capacity should be looking at ways to incorporate LLMs and make their products more accessible and customizable.

Writing prompts that consistently yield specific, high-value outcomes is a rigorous engineering process. It requires iteration, testing, and debugging, much like writing low-level code. In the AI era, well-crafted prompts are core application logic and should be treated as highly valuable intellectual property.

## Executing Actions via Tool Calling

If natural language instruction is the first superpower of LLMs, **Tool Calling** is the second—and arguably the most important for software engineering. Tool calling is the ability to reliably generate structured data (like JSON) based on natural language intent. Or more importantly, to convert data between arbitrary and inconsistent formats, natural textual language, and precise well-defined structures.

This allowed LLMs to interact with software applications directly rather than with a human in the middle to plug the LLM outputs into other systems manually. This is the first and crucial step towards giving LLMs some sense of "agency", where they can make requests to applications on behalf of the user, and can fetch data or submit generated data.

How does it work? In a nutshell, the LLM is asked very nicely to generate output in a very specific structured format whenever it wants certain things to happen, so that a parser that looks for that very specific structured format can pick that up. It honestly sounds very hacky, and for a long time models were very unreliable at actually following these specific structured formats. It's only been in the last couple or so months that almost every major model is good at tool calling by incorporating it in the training regime. An unfortunate consequence is that each model would be trained with different structures, so you have to rely on the model provider's syntax for tool definitions for the most reliable results. That said, there are abstractions like the AI SDK that smoothen out these differences for us.

The more important part about tools is where they fit architecturally.

Tool calls look very much like API endpoints. They are named functions that can be referenced from outside, their inputs and outputs are serialized over a network, and they facilitate communication between independent systems. Tool calls are basically endpoints that are called by an LLM on behalf of the user, instead of by an interface like UI or CLI. So instead of having to specify the exact parameters of the endpoint through forms and buttons, the user expressed their intention in natural language, then the LLM decided to call the endpoint and generated the exact parameters from the user's prompt.

Once again, this unlocks a new realm of user experience that is infinitely more accessible than what we have today, provided that the LLM's interpretation of the user's request is sound and reliable. Therefore, the major challenge with tool calls is to, surprise surprise, increase the probability of getting the right tool call and the right time with the right inputs.

At the same time, most of the challenges we already face when building APIs carry over to the realm of tool calling:

* **Authentication & Authorization:** Ensuring the LLM (and the user it represents) has permission to execute the tool.
* **Input Validation:** Verifying the structured JSON generated by the LLM is safe and formatted correctly before executing the underlying function.
* **Observability:** Tracing tool executions, failures, and latency just like standard API endpoints.

Most of the time, the same practices and patterns that we already use today are exactly what we need here. We don't need new solutions to the same problems. We need to figure out what the _new_ problems are and how we might be able to solve them.

## Injecting State via Context Engineering

**Context Engineering** is simply the industry accepted term for describing the process of optimizing for a certain likelihood out of the LLM by modifying the input. "Context" describes everything that is fed into the LLM when it's given a task. This used to be "prompt" but every AI app injects a reasonably large amount of information as "context" to the LLM with the user's prompt.

It's a very wide umbrella of a concept and manifests in many different ways, and we keep discovering new ways every day. So the concept is useful as a high level idea like "software engineering" which encompasses everything from data structures to system design to relational databases to centering a div.

For example, an LLM doesn't inherently know today's date, who the user is, or what the user's database schema looks like. Context Engineering is the architectural practice of gathering that state—fetching the user's profile, querying the database for relevant records, grabbing the current timestamp—and injecting it into the prompt payload before the LLM ever sees it. If prompts are the functions, Context Engineering is how we pass the arguments.

Crucially, this context is bounded by the model's **context window** (measured in tokens). You cannot simply dump an entire database into the prompt. The art of context engineering is retrieving and injecting _only_ the most relevant state needed for the immediate task without overflowing the token limit or diluting the model's reasoning capabilities.

## Key Takeaways for Part 1

* **LLMs are Probabilistic Functions:** Do not use them for logic that can be handled deterministically.
* **Prompting is Programming:** Natural language instructions are core application logic and should be version-controlled, tested, and treated as IP.
* **Tools Act as APIs:** Tool Calling translates natural language intent into structured JSON, bridging the gap between LLM reasoning and existing software endpoints.
* **Context is State:** You must engineer systems to inject the necessary user and application state into the prompt payload before the LLM can act on it.

---

These primitives—prompts, tools, and context—are powerful on their own. But the real magic happens when we wire them together into multi-step systems. What happens when an LLM is allowed to call a tool, evaluate the result, and decide what to do next entirely on its own?

In Part 2, we'll move from individual components to system architecture. We'll demystify the heavily-hyped world of **Agents**, contrast them with traditional deterministic **Workflows**, and explore how to combine the best of both worlds.

---

# Why Is Every AI App Single Player?

> Learn why most AI apps and agents can and should go beyond single player interactions and allow multiplayer collaboration for the best user experience.

- Published: 2026-04-21
- Author: Dev Agrawal
- Category: Engineering
- Source: https://powersync.com/blog/why-is-every-ai-app-single-player

---

Maggie Appleton's recent post, ["One Developer, Two Dozen Agents, Zero Alignment"](https://maggieappleton.com/zero-alignment), makes a strong case for collaborative AI engineering. Her example, Ace from GitHub Next, shows why single-player AI tools break down on teams. Software development depends on shared context, planning, and coordination. Most coding agents still hide that work inside one person's session.

I think that argument applies more broadly.

This is not only a problem for coding tools. It is becoming a problem for most AI apps.

## AI already makes solo work feel collaborative

AI changes how one person works. You can ask for options, assign subtasks to multiple agents, compare outputs, and iterate in tight loops. Writing, research, analysis, coding, and planning start to feel less like using a tool and more like coordinating a team.

But most AI apps still package that experience as a private session.

You get one user, one thread, and one hidden context window. If you want to involve someone else, you usually share the result after the fact. That means the actual work stays trapped inside a private conversation.

The model supports collaboration. The product does not.

## Shared workspaces are step one

Ace is interesting because it moves beyond private copilots. It treats agents, humans, plans, and implementation as part of one shared environment. That is much closer to how teams actually work.

If AI is going to participate in real workflows, its outputs cannot live only as text inside private sessions. They need to become first-class data in the application itself:

- messages
- tasks
- plans
- drafts
- decisions
- annotations
- approvals
- run history
- provenance

Once AI output becomes shared state, collaboration stops being something you do after the model responds. It becomes part of the product's core execution model.

## Good AI apps already need the right infrastructure

This is also why multiplayer AI is less of a leap than it first appears.

If you are building a good AI app, you already need server-side infrastructure to make the single-player experience reliable. Long-running model calls need durable state. Streamed responses need to survive reconnects. Agent runs need to resume after disconnects, page refreshes, or mobile network drops. Background work needs a system of record outside the browser.

In practice, that usually means adding stateful infrastructure anyway. Maybe that is Redis. Maybe it is a database-backed job system. Maybe it is a sync engine.

Once you have that layer, you already have many of the pieces needed for multiplayer:

- durable run state
- resumable streams
- shared message history
- server-side coordination
- live updates across clients
- a consistent view of work in progress

At that point, making the app multiplayer is no longer about inventing a completely new architecture. It is about deciding that this state should be shared across participants instead of scoped to one user session.

That is why I think many AI apps will move in this direction. Reliability pushes you toward shared infrastructure first. Multiplayer becomes the natural next step.

## This is bigger than coding

Coding is the clearest example, which is why Ace is useful. But the same pattern shows up in every category.

- Research tools help one analyst, but the team still reviews findings elsewhere.
- Writing tools help one author draft, but review and approval still happen in docs and chat.
- Support and operations tools help one person act faster, but handoffs still happen outside the system.

AI makes solo work feel multiplayer. Human collaboration still happens around the product instead of inside it. That separation creates friction.

## What collaborative AI apps actually need

Good prompt UX is not enough. If humans and agents are going to work in the same system, the app needs live, durable, shared state that every participant can inspect and update safely.

That means handling:

- presence
- shared memory
- provenance
- permissions
- handoffs
- conflict resolution
- sync across users, agents, and devices

These are product requirements, but they are also infrastructure requirements. A collaborative AI app is not just a model wrapped in chat UI. It is a system where humans and agents coordinate around shared state.

## Small example: PowerChat

I have been experimenting with this in a demo app called [PowerChat](https://github.com/powersync-community/powerchat).

In PowerChat, you do not message an agent in a private sidebar. You @mention an agent in a shared channel. That message is written locally first, synced immediately, and then turned into agent runs on the server. Placeholder responses appear quickly, streamed output lands back in the shared thread, and everyone in the channel sees the same state update live.

That is a small UI change, but a bigger architectural change.

The agent output is not a response returned to one user. It is a state change synced to the workspace.

That is the direction I think more AI apps need to move toward.

## Shared-state AI is where this goes

Maggie's post is right to focus on alignment. Faster agents make poor coordination more expensive.

The next step is to apply the same thinking to AI apps more broadly.

If we want AI apps that are truly multiplayer, we need to build them like collaborative software from the start. Not as single-user chat products with sharing added later, but as shared systems where humans and agents work on the same underlying state.

The future of AI apps is where collaboration with AI and collaboration with other people happen in the same loop.

---

# Most AI Chat Apps Are Broken. Sync Engines are the Fix.

> When a tab refresh or spotty Wi-Fi kills the stream, most AI chat apps throw away the whole in-flight response. Treating LLM output as synced state — not a disposable HTTP stream — fixes resumability, multiplayer, and offline by default.

- Published: 2026-04-10
- Author: Dev Agrawal
- Category: Engineering
- Source: https://powersync.com/blog/most-ai-chat-apps-are-broken-sync-engines-are-the-fix

---

This is the experience of most AI chat apps today: you start a generation, get halfway through, and if anything interrupts the connection, such as a refresh, a tab switch, or a network hiccup, you lose the response.

Gone. The entire response. The app had no memory of the generation that was literally happening seconds ago.

That's the moment I realized most AI apps are built like demos. They work perfectly in controlled conditions and fall apart the instant real users do real user things.

The problem lies not with the user, but with how we've learnt to build AI apps.

## How we usually build AI apps (and why it breaks)

The standard pattern looks like this:

1. User clicks "Generate" in your UI
2. Client sends a request to your server
3. Server calls the LLM API
4. LLM streams tokens back
5. Server forwards those tokens to the client
6. Client renders them in real-time
7. Server saves the final result to your database

This works great for screenshots. I've built apps this way myself.

But that stream in step 4-5? It's tied to a single HTTP connection. If that connection hiccups (user refreshes, switches tabs, loses WiFi for three seconds), the stream dies. Some apps try to reconnect, but they're reconstructing state from scratch, hoping the LLM will resume from the right spot (it won't, unless you're paying for expensive persistent connections).

The deeper problem: only the client that started the request sees the live output. If you open the same document on your phone while the AI is generating on your laptop, you see nothing until it's done. Your backend has the stream. Your database gets the final result. But everything in between is invisible to anyone else.

Teams solve this by adding more infrastructure. WebSockets for cross-device sync. Redis for caching partial results. Background queues for retry logic. It works, but now you're maintaining a real-time system just to show AI output that will eventually just be text in a database anyway.

There's a simpler way. But it requires thinking about AI output differently.

## State, not streams

PowerChat is a multiplayer chat app I built where AI agents can be @mentioned in channels. In this app, I tried a different approach. Instead of treating the LLM response as a stream to be forwarded, I treat it as state to be synced.

Here's what happens when a user mentions an AI agent:

```typescript
// Client writes the message locally
await clientDb.insert(messages).values({
  id: crypto.randomUUID(),
  channelId: props.channelId,
  authorType: "user",
  authorId: username,
  content: text,
});
```

That's it. The client doesn't wait for a response. It doesn't handle streaming logic. It writes to the local SQLite database and PowerSync syncs it to Postgres.

The backend picks it up from there:

```typescript
// Server creates placeholder agent message
await db.insert(messages).values({
  id: agentMessageId,
  channelId: message.channel_id,
  authorType: "agent",
  authorId: agentId,
  content: "Thinking...",
});
```

Notice what's happening: the AI response is just another message in the channel. From the client's perspective, there's no difference between a human typing and an AI generating.

Then the streaming happens server-side:

```typescript
// Stream from LLM, persist as it arrives
for await (const event of stream.fullStream) {
  if (event.type === "text-delta") {
    finalText += event.text;
    await db
      .update(messages)
      .set({ content: finalText })
      .where(eq(messages.id, agentMessageId));
  }
}
```

Every connected client sees the response evolve in real-time because PowerSync syncs those writes down to everyone's local database.

The UI is dumb in the best way possible:

```typescript
const messages = useQuery(() =>
  clientDb
    .select({ id: messages.id, content: messages.content })
    .from(messages)
    .where(eq(messages.channelId, props.channelId))
);
```

It doesn't know or care whether content came from a human or an AI. It just renders what's in the local database.

## What changes

This architecture moves complexity into a place that's easier to reason about: the data model. Instead of building separate paths for streaming, persistence, retry, reconnection, and multiplayer updates, you model the AI interaction as synced state from the start.

That gives you properties that are hard to get cleanly any other way:

* **Multiplayer by default.** Three people in the same channel all see the AI response appear simultaneously. No extra WebSocket code required.
* **Resumable everything.** Close your laptop mid-generation, reopen it on your phone, and you haven't lost anything. The response was never tied to your connection, it was in the database the whole time.
* **Offline queueing.** Write a message offline, and the AI will process it once you're back online. The "request" is just data waiting to sync.
* **Simpler client code.** No stream handlers. No connection state management. Just queries against local state.

Latency and write volume are real concerns, but they're implementation details, not reasons to fall back to a more fragile architecture. The initiating user action is still instant because it starts as a local write. For generated output, you can tune how often partial results are persisted, keep workers close to your database, and still preserve the core model: the response lives in synced state, not in a disposable connection.

In practice, that usually means flushing periodically instead of writing every token:

```typescript
let chunksSinceFlush = 0;
for await (const event of stream.fullStream) {
  if (event.type === "text-delta") {
    finalText += event.text;
    chunksSinceFlush++;

    if (chunksSinceFlush > 20 || finalText.endsWith("\n")) {
      await db
        .update(messages)
        .set({ content: finalText })
        .where(eq(messages.id, agentMessageId));

      chunksSinceFlush = 0;
    }
  }
}
```

This is a conceptual shift: the LLM stream is an implementation detail. The database is the source of truth. The client simply renders the database.

## Try this instead

Next time you build an AI feature, start by asking: what happens when the user refreshes?

If your answer involves reconnecting to a stream, checking sequence numbers, or hoping the LLM can resume, you are focusing on transport infrastructure instead of the product.

Instead, write the request as data. Let the server generate. Persist incrementally. Sync to clients. Let your UI be a simple view of the state that happens to be changing.

The refresh, multiplayer, and even the offline problems vanish.

Ultimately, these issues vanish when you stop treating AI output as a stream and start seeing it as application state.

---

If you want to see this in action, the [PowerChat source is available](https://github.com/powersync-community/powerchat). It's built with SolidStart, PowerSync, Neon, and Mastra, mostly as an experiment in how simple collaborative AI apps can be when you stop fighting the network.

---

# PowerSync Changelog: March 2026

> Over the last few weeks we had a lot of fun running our first hackathon. We had several very solid submissions and many of you came up with great use cases for sync-powered AI. It's also been another big month of shipping things.

- Published: 2026-04-02
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-changelog-march-2026

---

Over the last few weeks we had a lot of fun running our first hackathon. We had several very solid submissions and many of you came up with great use cases for sync-powered AI. More on that in the feature story below.

It's also been another big month of shipping things. Our .NET SDK and SQL Server backend DB adapter both reached beta, meaning you can now build and ship production-ready PowerSync apps on the Microsoft stack. We also shipped query-driven sync for PowerSync's TanStack DB collection, a native Tauri SDK, and first-class Nuxt support.

## Product updates shipped in March:

**PowerSync Service:**

  * **SQL Server Beta**: SQL Server backend support is now production-ready. To get here, we needed to add automatic schema change handling. Now replication keeps working as your schema evolves, with minimal manual intervention. [Release notes](https://releases.powersync.com/announcements/sql-server-backend-database-support-beta-release).
  * **v1.20.3**: MongoDB now tracks the same replication metrics as Postgres (bytes, transactions, and chunks replicated), bringing the same observability to both. [Changelog](https://releases.powersync.com/announcements/powersync-service).
  * **v1.20.2**: You can now define global CTEs so you don't have to repeat them across Sync Streams (thanks `@Yahya` for [the nudge](https://discord.com/channels/1138230179878154300/1422138173907144724/1483050209889222656)). Added `instr()` support in Sync Stream query expressions. SQL Server schema changes are now detected and handled automatically. [Changelog](https://releases.powersync.com/announcements/powersync-service).
  * **v1.20.1**: Fixed a Sync Streams auth filter bug where certain auth subqueries could be silently ignored, potentially syncing data to users who shouldn't have access. It only applied in narrow circumstances, very few Cloud instances were affected and were patched automatically. Self-hosted users should upgrade to be safe. [Security advisory](https://github.com/powersync-ja/powersync-service/security/advisories/GHSA-q6wc-xx4m-92fj).

**Client SDKs:**

  * **TanStack DB Query-Driven Sync**: `@tanstack/powersync-db-collection` now supports on-demand sync mode — the collection loads only the rows your active live queries need, not the full SQLite table. No need to load 50,000 rows into memory if your list only shows 20. [Release notes](https://releases.powersync.com/announcements/query-driven-sync-for-the-powersync-tanstack-db-collection) and [Docs](https://tanstack.com/db/latest/docs/collections/powersync-collection#on-demand-sync-mode-query-driven-sync).
  * **.NET SDK Beta**: The .NET SDK is production-ready. New since the alpha: full feature parity (Sync Streams, sync priorities, Rust-based sync client); concurrent reads so parallel queries no longer queue behind each other; faster query execution with significantly lower memory usage; and more idiomatic .NET APIs. [Release notes](https://releases.powersync.com/announcements/powersync-net-sdk-beta-release) and [SDK Reference](https://docs.powersync.com/client-sdks/reference/dotnet).
  * **Native Tauri SDK**: Tauri apps can now use native Rust-backed SQLite instead of IndexedDB/OPFS (which reset on every app update). Sync state and watched queries are shared across all windows automatically. [Release notes](https://releases.powersync.com/announcements/introducing-the-powersync-tauri-sdk-alpha) and [SDK Reference](https://docs.powersync.com/client-sdks/reference/tauri).
  * **First-class Nuxt support**: We shipped `@powersync/nuxt`. It includes auto-imported composables, built-in diagnostics and a SQLite inspector, and optional Kysely for type-safe queries. [Release notes](https://releases.powersync.com/announcements/nuxt-integration-for-powersync-alpha) and [Docs](https://docs.powersync.com/client-sdks/frameworks/nuxt).

**New demos & guides:**

  * **Time-Based Sync Demo**: Shows how to use Sync Streams to sync data by date ranges. Good reference for patterns like "sync the last N days" without redeploying sync config. [Demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-time-based-sync).
  * **SQL Grammar Reference**: Railroad syntax diagrams showing the supported SQL when constructing queries in Sync Streams and Sync Rules. [Sync Streams grammar](https://docs.powersync.com/sync/grammar/sync-streams) and [Sync Rules grammar](https://docs.powersync.com/sync/grammar/sync-rules).
  * **Sync Streams Bucket Troubleshooting**: Run into `PSYNC_S2305` and not sure what to do? Sync Streams give you a lot of flexibility, but how your queries translate to sync bucket count isn't always obvious. We now explain how different patterns (subqueries, JOINs, hierarchies, subscription parameters) affect bucket count, and ways to reduce it. [Docs](https://docs.powersync.com/debugging/troubleshooting#too-many-buckets-psync_s2305).

## Community spotlight

  * Watch Dev build PowerSync apps from scratch in Codex: [zero-shotting Supabase + PowerSync into a TanStack Start app using just the CLIs](https://www.youtube.com/watch?v=R3DBUKa7AWY), then [turning it into a full quest log from a single handwritten spec](https://www.youtube.com/watch?v=9O-RUC9Rkl0). Coding agents have come a long way, and so have we ([AI accessible docs](https://docs.powersync.com/tools/ai-tools#ai-accessible-documentation), [overhauled CLI](https://docs.powersync.com/tools/cli), [official agent skills](https://github.com/powersync-ja/agent-skills)). A year ago these tools would hallucinate just trying to install our web SDK.
  * Shoutout to `@MrLightful` who built a Tauri + PowerSync [community example](https://github.com/MrLightful/powersync-tauri) which helped motivate our native SDK.
  * Thanks `@qtpi-bonding` for fixing the SQLCipher extension crash on iOS and macOS in the Flutter SDK. [PR #381](https://github.com/powersync-ja/powersync.dart/pull/381).
  * Thanks `@arcashka` for catching the Android `powersync-sqlite-core` version mismatch that caused runtime crashes. [PR #376](https://github.com/powersync-ja/powersync.dart/pull/376).
  * Built with PowerSync:
    * _Samay_ by [@rouuuge](https://x.com/rouuuge): Timetracking for small businesses. [Website](https://samay.ch).
    * _Mealift_ by Stefan Dukic. AI recipe tracking and meal prep. [App Store](https://apps.apple.com/ch/app/mealift-meal-prep-macros/id6758587250?l=en-GB).

## Feature story: AI Hackathon

The PowerSync [AI Hackathon](https://powersync.com/blog/powersync-ai-hackathon-8k-in-prizes) attracted a strong group of builders, and we received **53 submissions** spanning a wide range of AI use cases. Across the final 8 winning projects, PowerSync and our partners awarded **more than $9,000** in cash, credits, and prizes. Keep an eye on our socials - we'll be showcasing the winning projects there.

![](https://powersync.com/images/blog/powersync-changelog-march-2026-inline-856c9cb38d.png)

Huge shoutout to **Christiaan** , **Manrich** , **Dev** and **Conrad** for judging the submissions. It was a close competition, and many projects could easily have been placed.

Reviewing the submissions also gave us a clearer picture of how developers are building AI apps today. One recurring pattern was the heavy use of HTTP streaming for token output, even in cases where syncing outputs through PowerSync can be simpler and more reliable. We also saw that AI coding tools often struggled to use PowerSync correctly, with some of the same assumptions and API mistakes showing up across multiple submissions.

Those are useful lessons for us. They point to clear opportunities to improve our documentation, examples, and guidance so both developers and AI coding agents can build with PowerSync more effectively.

That’s it for this issue.

---

# PowerSync AI Hackathon: $8k+ in Prizes

> Join the PowerSync AI Hackathon to build innovative, AI-powered software using PowerSync as a sync engine. Compete for over $8,000 in prizes, including core cash prizes and bonus awards from partners like Supabase, Neon, Mastra, TanStack, and Cactus. The virtual hackathon starts on Friday, March 6, 2026, with a submission deadline of Sunday, March 22, 2026. Register today to bring your favorite AI use case to life!

- Published: 2026-03-06
- Author: Dev Agrawal
- Category: Announcement
- Source: https://powersync.com/blog/powersync-ai-hackathon-8k-in-prizes

---

We are hosting a **virtual hackathon** where the challenge is **to build innovative AI-powered software** using PowerSync as a sync engine.

Bring your favorite AI use case to life and compete for **$8,000+ in prizes** , including bonus partner prizes and awards!

Join the [#ai-hackathon](https://discord.com/channels/1138230179878154300/1479216133075767322) channel in the [PowerSync Discord server](https://discord.gg/powersync) for live updates and discussions, and feel free to use the [#hackathon-lounge](https://discord.com/channels/1138230179878154300/1479229403702755420) voice channel.

See Ideas for What You Could Build below for inspiration of where PowerSync can be useful for building AI software.

## Partners

PowerSync has partnered with [Supabase](https://supabase.com/), [Neon](https://neon.com/), [Mastra](https://mastra.ai/), [TanStack](https://tanstack.com/), and [Cactus](https://www.cactuscompute.com/) to bring more bonus prizes to this hackathon.

![](https://powersync.com/images/blog/powersync-ai-hackathon-8k-in-prizes-inline-33236568.png)

## Timeline (All times in Pacific Time, PT)

  * Hackathon starts: **Friday, March 6, 2026 at 12:00 AM PT**
  * Submission deadline: **Sunday, March 22, 2026 at 10:59 PM PT**(updated)
  * Winners announced: **Wednesday, March 25, 2026**

## Prize Pool

### Core prizes

  * 1st: **$3,000 cash.**[Winner](https://x.com/powersync_/status/2036900098035376474): Sonde by Yahya Jirari
  * 2nd: **$1,000 cash.**[Winner](https://x.com/powersync_/status/2036900098035376474): Urdr by Jakob Andreas Malmo
  * 3rd: **$500 cash.**[Winner](https://x.com/powersync_/status/2036900098035376474): INAPOS by Abi Noval Fauzi

[Video: PowerSync AI Hackathon - Winning Projects](https://www.youtube.com/watch?v=kgrxSBCdD9s)

### Bonus Prizes

  * **Best Local-First Submission**  
**Prize:** $500 cash. [Winner](https://x.com/powersync_/status/2036900098035376474): DevTrace AI by Jexan Joel & Lakshmi Sree  
Build an app aligned with the [local-first principles](https://www.inkandswitch.com/essay/local-first/). Local models are encouraged but not required.

  * **Best Rust SDK Submission**  
**Prize:** $500 cash. [Winner](https://x.com/powersync_/status/2036900098035376474): Fieldmid by Saif Ali Khan  
Build something using the PowerSync [Rust Client SDK](https://docs.powersync.com/client-sdks/reference/rust) (pre-alpha).

  * **Best Submission Using TanStack Start/DB/AI**  
**Prize:** Office hour with Tanner Linsley + TanStack swag bag. [Winner](https://x.com/powersync_/status/2036900098035376474): Urdr by Jakob Andreas Malmo  
Use one or more of [TanStack Start](https://tanstack.com/start/latest), [TanStack DB](https://tanstack.com/db/latest), or [TanStack AI](https://tanstack.com/ai/latest) in a meaningful way.

  * **Best Submission Using Supabase**  
**Prize:** $1,000 Supabase credits. [Winner](https://x.com/powersync_/status/2036900098035376474): DevMemAI by Senai Ghirmai  
Use [Supabase](https://supabase.com/) as a meaningful part of your backend architecture.  
Bonus: Free $25 Supabase credits are available for all participants. Email [hackathons@powersync.com](mailto:hackathons@powersync.com) to request your credit!

  * **Best Submission Using Mastra**  
**Prize:** $500 Amazon gift card. [Winner](https://x.com/powersync_/status/2037288572555030638): Svitlo by Nazar Palamarchuk  
Use [Mastra](https://mastra.ai/) for AI agents/workflows in a meaningful way.  
Bonus: Free copy of _Principles of Building AI Agents_ for all participants using Mastra.

  * **Best Submission Using Neon**  
**Prize:** $2,000 in Neon credits per team member of the winning team. [Winner](https://x.com/powersync_/status/2037274212747141599): INAPOS by Abi Noval Fauzi  
Use [Neon](https://neon.com/) as a meaningful part of your backend architecture.  
Bonus: Free $100 Neon credits are available for all participants. Email [hackathons@powersync.com](mailto:hackathons@powersync.com) to request your credit!

  * **Best Submission Using Cactus**  
**Prize:** 1 month of [Cactus](https://www.cactuscompute.com/) hybrid inference (up to 1,000 hours of audio). [Winner](https://x.com/powersync_/status/2036900098035376474): Askari AI by Clement Lumumba  
Use Cactus hybrid inference in a meaningful way (on-device + cloud routing). 

## Ideas for What You Could Build

[PowerSync](https://powersync.com/) is a sync engine that removes the complexity of synchronizing state across backend, frontend, and agents. It syncs data between your backend database (PostgreSQL, MySQL, MongoDB, or SQL Server) and a local SQLite database for instant client/agent access. This makes real-time experiences and distributed AI workflows significantly easier to build.

**The best would be to “scratch your own itch”:** If you’re using an AI tool today, and are frustrated with any aspect of the state management, latency, offline capabilities, etc. then that could be a great opportunity to build your own version of that tool using PowerSync.

**Food for thought:** If one of the below ideas excite you, take it as extra validation, but you are not required to build one of these to participate. Any AI use case that meaningfully incorporates PowerSync is valid. Let your imagination run wild!

  * **Agentic Collaborative Apps:** Build apps where humans and agents work in the same shared live environment. PowerSync can serve as the state synchronization layer for humans, agents, and services. Learn more in our blog post, [Unleashing the Power of Sync](https://powersync.com/blog/unleashing-the-power-of-sync). Some specific ideas: (but don’t let this limit you!)   

    * Productivity tools such as task management, document collaboration, AI-assisted meeting notes, etc.
    * Developer tools and IDE copilots, for use cases such as pair programming, evals, tracing, debugging, QA, test harnesses, simulation, and workflow automation. 
    * Business operations tools such as support, incident response, onboarding, scheduling, invoicing, customer communication, reporting and compliance.
  * **Local-First & Offline-Capable AI Products:** PowerSync can be useful when paired with local/open-weight models on devices, and for combining offline and cloud execution. PowerSync allows AI systems to operate on a fully queryable local SQLite database, while synchronizing with backend systems when connectivity is available. This could enable use cases like:   

    * Fully offline AI assistants/copilots. Especially relevant for regulated or disconnected environments, e.g. field technicians (oil & gas, mining, utilities), defense / government, hospitals, manufacturing plants, warehouses, ships, aircraft and other remote sites. PowerSync can serve as the data plane for local AI where structured data is queryable in SQLite and sync happens opportunistically when connectivity exists. 
    * Connectivity-resilient agents: Agents and AI systems that continue operating without connectivity, queue actions locally and reconcile with a backend later. Specific ideas include field data collection & summarization, incident reporting, research agents, compliance audits, recommendations, anomaly detection, etc. Think environments like retail point-of-sale, robots, kiosks, vehicles, etc.
    * Real-time operational systems: There are use cases such as logistics, robots and manufacturing where instant local intelligence is needed. Edge nodes can run local AI models, operate on local data, and sync results upstream when connectivity allows. 
    * Hybrid RAG: Structured SQL + vector search. Query PowerSync-provided SQLite for structured data and exact answers, and combine it with embeddings for fuzzy / semantic lookup. 
    * Hybrid cloud/local inference. Alternating between cloud frontier models and local models for different inference tasks can be useful for saving costs, minimizing data transfer, and improving response latency. Inference results can be synced from cloud to device or device to cloud. See our Cactus category prize below.
    * AI-driven event processing and data pipelines: Database changes can trigger local AI processing, generate structured results, and sync results back via SQLite and PowerSync.
    * The above use cases may also manifest in _embedded_ _systems_ : think connected vehicles, IoT, robotics, drones, etc. The PowerSync Rust SDK can be useful here, and we have a special category prize for that (see below).
  * **Agentic Workflows:** Build agentic workflows using PowerSync + your backend database as the workflow engine (Postgres, MongoDB, MySQL, SQL Server). Get distributed durable workflow state that is resilient to intermittent connectivity. Specific ideas include customer support triage, sales lead qualification, field service inspections, incident response workflows, document processing pipelines, marketing content pipelines, product development workflows, etc.
  * **Personal AI Assistants & Machine-Control Agents:** For OpenClaw and similar tools, PowerSync may be useful to enable things like multi-device collaborative control, cloud oversight and audit logs. The agent loop can be recorded in the database (SQLite synced to a backend database).
  * **Multi-Agent Coordination Systems:** Build orchestration layers where multiple agents can route work, share memory, recover from failure, and escalate to humans when needed. This can scale to large agent swarms that collaborate through shared state.
  * **AI Observability, Governance & Safety:** Tools to track and audit AI behavior. Example projects: Prompt and response logging systems, AI decision audit trails, human-in-the-loop approval workflows, AI confidence scoring dashboards, monitoring hallucinations and failures.
  * **AI Memory Systems:** AI agents need multiple forms of memory: episodic, semantic, procedural, and shared memory. PowerSync + SQLite may be useful as a substrate for this, and can sync shared memory across agents and devices. 

## Judges

From the [PowerSync team](https://powersync.com/team): Dev Agrawal | Conrad Hofmeyr | Kobie Botha

From the TanStack team: Tanner Linsley

From the Supabase team: Prashant Sridharan

From the Cactus team: Roman Shemet

From the Mastra team: Alex Booker

From the Neon team: Atila Fassina

## Helpful Resources

  * [PowerSync Setup Guide](https://docs.powersync.com/intro/setup-guide)
  * [Sync Streams Overview](https://docs.powersync.com/sync/streams/overview)
  * [Supabase + PowerSync Guide](https://docs.powersync.com/integrations/supabase/guide)
  * [Neon + PowerSync Guide](https://docs.powersync.com/integrations/neon)
  * [PowerSync AI Coding Guide](https://docs.powersync.com/tools/ai-tools)
  * [Mastra Getting Started](https://mastra.ai/docs)
  * [Cactus Quickstart](https://www.cactuscompute.com/docs/v1.7/quickstart)
  * [SolidStart + PowerSync + Mastra AI Chat Sample](https://github.com/powersync-community/powerchat)
  * [React Native + PowerSync + Cactus Starter Project](https://github.com/powersync-community/cactus-powersync-react-native)

## Rules and Guidelines

### 1) Eligibility

  * Open worldwide where legally permitted.
  * Participants must be **18+** (or age of majority in their jurisdiction where applicable).
  * Employees and active contractors of PowerSync and partner companies, official judges, and immediate family members are not eligible for prizes.
  * Participants must comply with applicable local laws, export controls, and sanctions restrictions.

### 2) Team Requirements

  * Minimum team size: **1**
  * Maximum team size: **4**
  * A participant may only be on **one** team.
  * Each team must designate one primary contact for submission and prize fulfillment.

### 3) Build + Stack Requirements

  * Projects must be AI-powered applications/features/workflows.
  * Projects must use **PowerSync** as a meaningful part of the implementation, and must use [Sync Streams](https://docs.powersync.com/sync/streams/overview).
  * Any language, framework, and deployment stack is allowed. See [PowerSync Client SDKs](https://docs.powersync.com/client-sdks/overview).
  * Open-source libraries, SDKs, and starter templates are allowed.
  * The project’s core implementation must be built during the hackathon window.

### 4) Submission Requirements & Form

Each submission must include:

  1. Project name and short description
  2. Team member names and contact email
  3. Public source repository link (or private access instructions for judges)
  4. Demo video and/or live demo URL (both are optional, but highly recommended)
  5. Prize categories selected in the submission form

Submission form: [**Submit here**](https://form.typeform.com/to/YR9U17Sn)

### 5) Prize Category Requirements

  * A project can be considered for core prizes automatically if it meets all baseline requirements.
  * For each bonus category, teams must:   

    1. Select that category in the submission form.
    2. Meaningfully use the tech required for that category in the project.
    3. Describe that usage clearly in the architecture summary.

A single project may be eligible for multiple bonus categories, and entering multiple categories is encouraged.

### 6) Judging Criteria

Projects are evaluated on:

  * **Originality (30%)**
  * **Impact and usefulness (20%)**
  * **Technical implementation quality (25%)**
  * **PowerSync usage (15%)**
  * **Product and UX quality (10%)**

Tie-breaker order:

  1. Higher PowerSync usage score
  2. Higher impact score
  3. Final judge panel vote

### 7) Disqualification Criteria

Submissions may be disqualified for:

  * Not using PowerSync meaningfully
  * Missing required submission artifacts
  * Plagiarism or misrepresentation of authorship
  * Fake/non-functional demos presented as working products
  * Harassment, abuse, hate speech, doxxing, or other [code-of-conduct](https://powersync.com/legal/community-code-of-conduct) violations
  * Violating applicable law, partner terms, or platform terms

### 8) IP, Publicity, and Prize Fulfillment

  * Teams retain ownership of their projects.
  * By submitting, teams grant PowerSync and partners permission to showcase project name, summary, screenshots, and demo clips for hackathon-related promotion.
  * Winners may be required to provide valid identification details and payment verification information before prize fulfillment.
  * Winners are responsible for applicable taxes and reporting obligations unless required otherwise by law.

### 9) Organizer Rights

PowerSync may update rules, timelines, category details, or prize operations when required for legal, operational, or security reasons. Material changes will be posted on this page.

---

# PowerSync Changelog: February 2026

> We are running a hackathon starting on 6 March, and the theme is sync-powered AI. We have loads of prizes planned, including over $5,000 in core cash prizes plus prizes from our partners - Supabase, TanStack, Neon, Mastra and Cactus.

- Published: 2026-03-05
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-changelog-february-2026

---

Important announcement! We are running a hackathon starting on Friday, and the theme is sync-powered AI. We have loads of prizes planned, including bonus prizes from our partners -  Supabase, TanStack, Neon, Mastra and Cactus. Sign up using the link [here](https://x.com/powersync_/status/2026734435295764725?s=20), and read more in our featured story down below.

## **Product updates shipped in February:**

  * **Sync Streams in Beta** : This is a big one. We now consider Sync Streams production-ready and recommended over Sync Rules. There’s a lot that we shipped since the Alpha: JOINs, CTEs, multiple queries per stream, nested subqueries, table-valued functions, and clearer validation errors. We've also added TanStack React Query support (`useQuery`/`useQueries` with a streams option) and Vue/Nuxt support via `useSyncStream`. Check out the [release notes](https://releases.powersync.com/announcements/sync-streams-are-now-in-beta).   

    * Note: we’re still ironing out some kinks when auto-migrating more complex Sync Rules to Sync Streams.
  * **New PowerSync CLI and Agent Skills** : We overhauled the CLI for better DX, support for self-hosted instances, and it's now open source 🎉 The main win: you edit instance and sync config in YAML files in your project instead of long command-line flags. As an extra bonus, we published Agent Skills that help coding agents build with PowerSync (thanks to everyone who _prompted_ us to get these out). [New CLI](https://releases.powersync.com/announcements/introducing-the-new-powersync-cli) and [Agent Skills](https://releases.powersync.com/announcements/introducing-powersync-agent-skills).

  * **Sync Diagnostics Client** : We refreshed the UI (shadcn/ui, TanStack Router), added state tracking, and a new SQLite File Inspector (drag-and-drop, no login). It’s now easier to inspect data, debug sync, and view the JWT. [Try it out](https://github.com/powersync-ja/powersync-js/tree/main/tools/diagnostics-app).
  * **PowerSync Service**   

    * **v1.20.0** : You can now pass connection params (e.g. `connect_timeout`, `maxPoolSize`) via the database URL. Sync config errors now report source offsets so you can fix Sync Streams/Rules errors quickly. [Full changelog](https://releases.powersync.com/announcements/powersync-service).
    * **v1.19.1** : Adds SQL Server 2019 support. [Changelog](https://releases.powersync.com/announcements/powersync-service).
    * **v1.19.0** : Adds support for configuring logging level & format for self-hosted, and MongoDB compression support via `snappy` and `zstd`. [Changelog](https://releases.powersync.com/announcements/powersync-service).
  * **Client SDKs**   

    * **Attachment APIs** for our JavaScript SDKs are now in `@powersync/common`, resulting in fewer dependencies to manage and improved consistency with APIs from our other SDKs. [Docs](https://docs.powersync.com/client-sdks/advanced/attachments)
    * We enabled **trusted publishing** for npm in our JavaScript SDKs for more secure package publishing. [PR #841](https://github.com/powersync-ja/powersync-js/pull/841).
    * **Swift v1.11.0** : Adds tvOS support. [Changelog](https://releases.powersync.com/announcements/powersync-swift-sdk)
    * **.NET** : We shipped several DX updates ahead of the imminent beta release: more .NET-idiomatic schema definition and `Watch` APIs. [Changelog](https://github.com/powersync-ja/powersync-dotnet/blob/main/PowerSync/PowerSync.Common/CHANGELOG.md) and [SDK Reference](https://docs.powersync.com/client-sdks/reference/dotnet).
    * **Rust SDK** : We released an experimental Rust SDK for standalone native environments. It’s an early entry point for Rust/C++, automotive, robotics, or embedded use cases where HTTP and SQLite are available. Your feedback will shape if and how this SDK evolves. [Release notes](https://releases.powersync.com/announcements/introducing-the-powersync-rust-client-sdk-experimental) and [SDK reference](https://docs.powersync.com/client-sdks/reference/rust).
  * **New demos & guides**   

    * **AWS ECS** : Step-by-step guide for self-hosting PowerSync on AWS ECS. [Guide](https://docs.powersync.com/maintenance-ops/self-hosting/aws-ecs).
    * **Offline-First Apps with TanStack DB and PowerSync** : Conflict resolution strategies and a ticket-tracking demo. [Blog post](https://powersync.com/blog/offline-first-apps-with-tanstack-db-and-powersync) and [demo](https://github.com/powersync-community/poweroff).

## **Behind the scenes** :

  * In **Unleashing the Power of Sync** , our founding DevRel Engineer Dev Agrawal argued why sync engines beat manual or keyed state, and how to build agentic chat with PowerSync. [Read](https://powersync.com/blog/unleashing-the-power-of-sync).
  * Thanks **raffidahmad** for a MySQL contribution that changes replication so we no longer store full row copies, which reduces storage use. [PR #530](https://github.com/powersync-ja/powersync-service/pull/530).
  * Congrats to **LucaL1fe** on launching [Raccoon](https://www.raccoon.kids/) with PowerSync - gamified family task management that makes chores fun!
  * **Proposal: Tauri SDK** : We’re exploring a Tauri (v2) SDK - Rust-backed SQLite and sync with a JavaScript API, starting with desktop. We’re particularly interested to know if your app’s business logic lives in Rust or JS. [Discussion #873](https://github.com/powersync-ja/powersync-js/discussions/873).
  * **Proposal: Incremental Compacting** : We're proposing an incremental compact implementation so you can run compact more often (e.g. hourly) with less overhead. Especially relevant at high data volumes. [Discussion #537](https://github.com/orgs/powersync-ja/discussions/537).

## **Feature story: PowerSync AI hackathon**

We're running a virtual hackathon and the theme is AI apps that use PowerSync as the sync engine. 

There's over **$5,000** in core cash prizes plus bonus partner and category prizes. Our partners include Supabase, Neon, Mastra, TanStack, and Cactus. There’s a category prize for best local-first submission, best use of our Rust SDK, and prizes for best use of each of the partner technologies.

The hackathon **starts tomorrow,** **Friday March 6** ; submissions close March 20; and we’ll announce winners March 25.

Keep your eyes peeled for a blog post on Friday March 6 with detailed guidelines and rules!

Sign up [here](https://form.typeform.com/to/zzswESaj).

I'm excited to see what you build!

That’s it for this issue.

---

# Offline-First Apps with TanStack DB and PowerSync

> Build offline-first apps with TanStack DB and PowerSync, and learn a practical framework for handling sync conflicts, from sensible last-write-wins defaults to domain-specific and manual resolution strategies for complex real-world collaboration.

- Published: 2026-02-26
- Author: Dev Agrawal
- Category: Tutorial
- Source: https://powersync.com/blog/offline-first-apps-with-tanstack-db-and-powersync

---

Offline-first apps are web/native applications that can be used while the user's device is offline.

In my [previous post](https://powersync.com/blog/unleashing-the-power-of-sync), I presented some parameters of an ideal sync engine:

  * simple to integrate
  * stable and mature
  * pluggable into existing setups
  * low lock-in
  * runs everywhere
  * enterprise compliance-ready
  * offline-first

In this blog post, I want to focus on what building offline-first applications looks like with PowerSync and TanStack DB.

Note: Offline-first and local-first apps are different, learn more about their differences [here](https://powersync.com/blog/local-first-key-concepts-offline-first-vs-local-first).

## The Hassle of Offline

Building applications that can work offline is a difficult problem for many reasons:

  1. Traditional approaches (REST, GraphQL, etc) only provide a way to access data over the network
  2. Browser storage APIs are very low-level and difficult to use for non-trivial tasks
  3. Keeping a consistent local cache in sync with the server is a difficult distributed systems problem
  4. The state management logic starts duplicating backend logic and gets complicated and inefficient
  5. Changes made offline can result in conflicts with server data, requiring manual resolution

Most sync engines today solve the first 4 problems relatively well:

  1. Data access against a local database (in-memory + persisted)
  2. Automatic durable storage (file system / IndexedDB / SQLite)
  3. Consistent bidirectional synchronization (server → client streaming, client → server queue)
  4. Reactive queries for expressive state management (SQL or similar, type-safe builders)

This is an **architectural guarantee** offered by sync engines: _Users can read their data instantly and consistently at any point in time, even if they are offline_.

Even though the client cannot receive updates while offline, they can read a consistent snapshot of the data as it was right before the client went offline.

But when it comes to making changes offline in a real-time and multi-user environment, there is the possibility of conflicts. A conflict arises when two users change the same piece of data in different ways. Ways that cannot be reconciled with each other, where only one can be kept and the other has to be discarded. How does the system decide which change should be kept?

## Theoretical vs Practical

The theory that comes from distributed systems research rightly claims that when two stateful nodes are disconnected from each other, changes/transactions can never be put on a single timeline since computers have unreliable clocks.

This means that allowing users to change data while offline is, theoretically speaking, a recipe for disaster.

Let’s walk through some scenarios where an offline user makes changes to the data:

  1. A user that goes offline works on a subset of the data that has no overlap with the data that other users are changing at the same time. This is fine.
  2. A user that goes offline collaborates with another user on the data but changes different parts/fields than the other user. This is also fine.
  3. A user goes offline and changes something another user is changing at the same time. Oops, conflict!

We can imagine scenario #3 more concretely:

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-6c9a16e5c6.png)

Some data starts with the value of A. Someone goes offline and changes it to C, while another online user changes it to B. Once the offline user comes back online, the value might get changed to C, losing the change made by the online user.

The simplest solution to this problem of conflicts is to disable writing to the database offline completely. As the famous saying goes, “in a distributed system, anything that **can** go wrong **will** go wrong”.

No offline writes === #3 can’t happen === no conflicts!

While this approach is completely sound, based on our practical experience helping build offline-first apps across hundreds of use cases and dozens of industries since 2009, **most** offline use cases actually look like #1 and #2.

So a more practical solution to the problem of conflicts would allow for these use cases by default, and provide a way to opt into [custom conflict resolution](https://docs.powersync.com/handling-writes/custom-conflict-resolution) or opt out of offline writes.

A similar tradeoff is discussed in [this Supabase CRDT post](https://supabase.com/blog/postgres-crdt#offline-philosophy).

Let's walk through a demo to understand this well.

## Demo

This is a simple ticket tracking app with certain offline capabilities:

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-39feb3af65.png)

Users have access to a shared list of tickets that they work on. For the most part, it's just basic CRUD operations.

There are certain operations that can be performed offline that have no way of running into conflicts.

  * Creating new tickets
  * Adding/removing user assignments from tickets
  * Adding/removing comments
  * Adding/removing attachments (URLs)

A more detailed walkthrough for implementing offline-first file attachments is available [in this post](https://powersync.com/blog/building-offline-first-file-uploads-with-powersync-attachments-helper).

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-1141abd4a1.gif)

Other operations like changes to title, description, and status are _usually_ safe to do.

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-4827fbf190.gif)

## Setup

This demo is built using PowerSync and TanStack DB on the client side.

The schema for the client side SQLite database looks like this:

```typescript
export const ticketSchema = new Schema({
  app_user: new Table({
    id: column.text,
    name: column.text,
  }),
  ticket: new Table(
    {
      id: column.text,
      title: column.text,
      description: column.text,
      status: column.text,
      deleted_at: column.text,
      created_at: column.text,
      updated_at: column.text,
      version: column.integer,
    },
    {
      indexes: {
        idx_ticket_status: ["status"],
      },
    },
  ),
  ticket_assignment: new Table(
    {
      id: column.text,
      ticket_id: column.text,
      user_id: column.text,
      deleted_at: column.text,
      created_at: column.text,
    },
    {
      indexes: {
        idx_ticket_assignment_ticket: ["ticket_id", "created_at"],
      },
    },
  ),
  ...
});
```
Once the PowerSync schema is created, we can create TanStack DB collections for each table in the schema like this:

```typescript
export const appUsersCollection = createCollection(
  powerSyncCollectionOptions({
    id: "app-users",
    database: powerSyncDb,
    table: ticketSchema.props.app_user
  }),
);

export const ticketsCollection = createCollection(
  powerSyncCollectionOptions({
    id: "tickets",
    database: powerSyncDb,
    table: ticketSchema.props.ticket
  }),
);

export const ticketAssignmentsCollection = createCollection(
  powerSyncCollectionOptions({
    id: "ticket-assignments",
    database: powerSyncDb,
    table: ticketSchema.props.ticket_assignment
  }),
);
```
These collections can now be queried in our UI components and hooks like this:

```typescript
const ticketsQuery = useLiveQuery((q) =>
  q
    .from({ ticket: ticketsCollection })
    .orderBy(({ ticket }) => ticket.updated_at, "desc")
    .select(({ ticket }) => ({
      id: ticket.id,
      title: ticket.title,
      description: ticket.description,
      status: ticket.status,
      deleted_at: ticket.deleted_at,
      updated_at: ticket.updated_at,
      version: ticket.version,
    })),
);

const assignmentsQuery = useLiveQuery((q) =>
  q
    .from({ assignment: ticketAssignmentsCollection })
    .where(({ assignment }) => eq(assignment.ticket_id, ticketId()))
    .orderBy(({ assignment }) => assignment.created_at, "desc")
    .select(({ assignment }) => ({
      id: assignment.id,
      ticket_id: assignment.ticket_id,
      user_id: assignment.user_id,
      deleted_at: assignment.deleted_at,
    })),
);
```
And updated in events like this:

```typescript
const createTicket = () => {
  const title = draft.newTicketTitle.trim();
  const id = crypto.randomUUID();
  const now = new Date().toISOString();

  ticketsCollection.insert({
    id,
    title,
    description: draft.newTicketDescription,
    status: "pending",
    deleted_at: null,
    created_at: now,
    updated_at: now,
    version: 0,
  });
};
```
Changes made to the TanStack DB collections are automatically synced into the local SQLite database by the PowerSync SDK, as well as put in an upload queue to be synced with the server.

If the client is online, the PowerSync SDK calls this `uploadData` method on the connector class:

```typescript
async function uploadData(operations: SerializableCrudEntry[]) {
  "use server";

  const session = getServerSession();
  await processWriteBatch(operations, session);
}

class TicketConnector implements PowerSyncBackendConnector {
  async fetchCredentials() {...}

  async uploadData(database: AbstractPowerSyncDatabase): Promise<void> {
    while (true) {
      const transaction = await database.getNextCrudTransaction();
      if (!transaction) break;

      await uploadData(toSerializableCrud(transaction.crud));
      await transaction.complete();
    }
  }
}
```
Inside this `uploadData` method, we are free to handle these changes however we want. In this example, the changes are sent to a [server function](https://docs.solidjs.com/solid-start/reference/server/use-server) that processes these writes on the backend. This backend function is free to process these writes by simply writing them to the database (the simplest pattern) or by applying custom logic to detect and handle conflicts.

PowerSync's consistency model ensures that the server data is treated as the source of truth, and all clients converge to the source of truth once their local changes are accepted by the server.

While you can build offline-first apps with PowerSync alone, using TanStack DB comes with some additional benefits:

  * Type-safe API for local queries and mutations
  * Incrementally recomputing live queries
  * Joins across collections from other non-PowerSync sources

These capabilities make [PowerSync + TanStack DB](https://tanstack.com/db/latest/docs/collections/powersync-collection) an ideal choice for offline-first applications.

## Designing for Conflicts

While last-write-wins is a sensible default for most use cases, it's not possible to get rid of conflict resolution issues entirely if we are to allow users to make offline changes. Therefore it's important to know when and how to design for conflicts.

There are many strategies for avoiding conflicts in offline-first apps that range from simple to complicated.

### Disable Destructive Actions

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-e935eba925.png)

The simplest way to avoid conflicts is to disallow certain destructive operations while offline. This is not the same thing as making the entire app read-only when offline. As discussed earlier, there are always certain operations that don't run into conflicts and are fine to do offline.

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-e3e7e13f41.gif)

This approach trades off a user-facing capability (making changes while offline) for operational simplicity (no conflicts possible).

### Audit/Activity Log

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-db583b8da1.png)

Quite often a last-write-wins strategy is a perfectly acceptable solution as long as the history of changes is visible to the users.

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-3de3572b8d.gif)

This activity log is as simple as an additional database table that is written to in the same transaction as the actual change to the ticket.

### Domain-Specific Resolution

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-2e1a44ab64.png)

Let's imagine while I am offline, someone changes this ticket from pending to done. But since I was offline, I didn't see that change. I separately change the status from pending to in progress.

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-687cbab61a.gif)

While the default last-write-wins strategy would say that the final status once I come back online should be in progress, it might make sense in this scenario to keep the ticket status as done rather than overriding.

This is not necessarily a technical decision — it should be up to the product/business to decide how conflicts like these resolve.

Here we can detect the case when an offline user syncs with a pending change to the status field.

This approach can provide automatic and predictable conflict resolution, but it's not a general solution and the actual logic of making a decision is going to vary a lot for different use cases.

### Manual Resolution

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-a2a5fe67dd.png)

A more general solution is to simply notify a user and let them decide how to proceed.

This usually involves tracking conflicts separately and prompting the user to provide a resolution by comparing the changes made.

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-a56dd5f303.png)

Manual resolution is a good choice for the most sensitive parts of the apps. There is some initial overhead in building the UI for manual resolution, but once the UI is there it can be used for any conflict scenario throughout the app. It is also the safest way to deal with conflicts, even though it might have a negative impact on the user experience by forcing users through an extra conflict resolution step. On the downside, this is one of the more complicated strategies on this list.

### CRDT/OT

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-795814bab1.png)

To handle conflicts on collaborative data like a document or canvas editor, it's best to use either an Operational Transform (OT) approach or a Conflict-free Replicated Data Type (CRDT).

Both of these approaches allow people to make changes to a document offline and have them automatically be merged into concurrent changes. OT requires a server to coordinate and transform changes, while CRDTs can be used fully locally.

![](https://powersync.com/images/blog/offline-first-apps-with-tanstack-db-and-powersync-inline-2e36796d63.gif)

Automerge and Yjs are some of the popular CRDT libraries with a simple interface. This example uses Yjs to construct the CRDT on the client side by reading deltas from a database table.

While CRDT/OT can automatically handle any complexity of conflicts, it doesn't mean its final output will be what the users actually want, especially if there have been massive conflicting changes. These are algorithms that guarantee a resolution, not that you will like the resolution. In those cases, it's best to combine a CRDT/OT approach with manual resolution — show not just the conflicting changes, but the CRDT merge as a possible solution, and let the user make final edits before resolving the conflict.

## Optionality

As we walk through the various possible approaches to conflict resolution, it's important to keep in mind that very few applications will genuinely need to handle all these cases. However, almost every application has some features that can be used offline, and it is important for the tools we use to scale and support these needs as they come along. This is the pragmatic reality of building offline-first applications that PowerSync addresses. It provides a sensible default that satisfies the majority of use cases, while making it simple to opt-in to more advanced strategies as needed.

The source code of this demo is available [here](https://github.com/powersync-community/poweroff).

Learn more about [handling update conflicts in PowerSync](https://docs.powersync.com/handling-writes/handling-update-conflicts), or get started with PowerSync by following [this setup guide](https://docs.powersync.com/intro/setup-guide).

---

# PowerSync Changelog: January 2026

> AI tools are moving at tremendous speed (whatever happened to “prompt engineering”?) and while we might not always be shipping bleeding-edge integrations with Ralph loops or Moltbots, we are closely monitoring the space and want to support developers using these tools. We’re starting by revamping the PowerSync CLI which will form the foundation for our plans in this space.

- Published: 2026-02-09
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-changelog-january-2026

---

“Hey Claude, follow the self-hosted setup instructions in this guide[ https://docs.powersync.com/intro/setup-guide.md](https://docs.powersync.com/intro/setup-guide.md)”

This actually works now! 

We’ve been working hard on making our docs easier to follow by humans and agents alike, and the results are paying off. 

AI tools are moving at tremendous speed (whatever happened to “prompt engineering”?) and while we might not always be shipping bleeding-edge integrations with Ralph loops or Moltbots, we are closely monitoring the space and want to support developers using these tools. We’re starting by revamping the PowerSync CLI which will form the foundation for our plans in this space, and our proposal for that is [available here](https://github.com/orgs/powersync-ja/discussions/476).   
  

## Product updates shipped:

  * **PowerSync Service**   

    * **SQL Server support has landed!** SQL Server / Azure SQL databases can now be plugged into PowerSync. This has been one of our most requested features and we’re very excited to have this out for you to try. Learn more about how we built this integration in our feature story below.
    * **Capture custom metadata in sync logs** – You can now attach custom metadata to client connections and have it show up in the Service/API logs, so you get richer context when inspecting and debugging syncs. For example, you can tag your logs with the user’s app version or a feature flag. [See the docs](https://docs.powersync.com/maintenance-ops/monitoring-and-alerting#custom-metadata-in-sync-logs) to get started. 
  * **Client SDKs**   

    * **GRDB integration for Swift** (v1.9.0) – The Swift SDK now optionally integrates with GRDB so you can use its Swift-friendly, type-safe query APIs instead of writing raw SQL. [Learn more](https://releases.powersync.com/announcements/grdb-integration-alpha-for-powersync-swift).
    * **SQLite encryption support in Swift** (v1.10.0) – If your Swift app stores sensitive data, you can now opt in to built-in SQLite database encryption, powered by `SQLite3MultipleCiphers`. [Get started](https://docs.powersync.com/client-sdks/advanced/data-encryption#swift).
  * **PowerSync Cloud**   

    * **HIPAA** – PowerSync Cloud is now HIPAA compliant. [Our docs](https://docs.powersync.com/resources/hipaa) lay out the shared compliance model, what PowerSync covers, and what you control.
  * **Simplified navigation for PowerSync docs** – We heard repeatedly that our docs were hard to navigate in certain scenarios, so we restructured them from the ground up: there’s now a single _Setup Guide_ you can follow start-to-finish, plus a unified sidebar organized around what you’re trying to do and the order you’re likely to do it in. [Check them out](https://docs.powersync.com/) and [learn more](https://releases.powersync.com/announcements/navigation-update-for-powersync-docs) about what changed.  
  * **Under-the-hood:** Our [Rust-based Sync Client](https://powersync.com/blog/speeding-up-powersync-with-a-sqlite-extension-written-in-rust) has become the default in recent versions of our client SDKs. It’s been out for around half a year in an experimental state, and was used and refined extensively. You can currently still opt in to the native sync client implementations, but we have plans to completely remove these over time. If you are using the native sync client because of issues you found in the Rust-based version, please let us know.
  * **New demos & guides:**   

    * [Querying JSON data in SQLite with SQLite JSON functions](https://docs.powersync.com/client-sdks/advanced/query-json-in-sqlite)
    * [How to pre-seed SQLite files](https://docs.powersync.com/client-sdks/advanced/pre-seeded-sqlite) for applications that download large volumes of data on initial sync
    * [Conflict resolution strategies beyond last-write-wins](https://docs.powersync.com/handling-writes/custom-conflict-resolution)
    * [How to sync data by time ranges using Sync Rules](https://docs.powersync.com/sync/advanced/sync-data-by-time)
    * [Step-by-step guide for connecting Neon databases to PowerSync](https://docs.powersync.com/integrations/neon)

## Community feed:

  * Conrad from our team [retrospected](https://powersync.com/blog/2025-powersync-roadmap-update) on how our 2025 product roadmap turned out! 
  * We’ve started sharing our plans for projects we’re actively working on (or have lined up) – to make our thinking more transparent, and have these discussions in public. Here’s what we’re busy with:   

    * [Our CLI is getting a major upgrade](https://docs.google.com/document/d/1iqpJF2gog2jB-ZWeN8TBEjcad8aBKNKbue2yJ21q_-s/edit?tab=t.0). Notable improvements are: adding support for self-hosted instances, helping with first-time setup, exposing diagnostics, making the CLI open source, and more.
    * [Roadmap for raw SQLite tables](https://docs.google.com/document/d/1h2sayKHsQ2hwSAaBlR8z7ReEVDeJ2t1Zzs8N0um5SJc/edit) (which allow you to bypass our JSON-based view system). Our goal is to make them easier to use.
    * We shared [this proposal](https://github.com/powersync-ja/powersync-dotnet/discussions/34) on making the .NET SDK’s schema definition syntax more .NET idiomatic, as well as some investigations into ORM support. 
  * It’s always fun to see PowerSync out in the wild: `qwerty2k.` shared PolyPod, a tool for tracking your podcast listening time. Check it out on the [App Store](https://apps.apple.com/us/app/polypod/id6747622986). And `varetalindinha` launched Smart Expiry Tracker. Check it out on the [App Store](https://apps.apple.com/us/app/controle-de-validade/id1549418617) and [Google Play](https://play.google.com/store/apps/details?id=com.controledevalidade).
  * And as always, thanks for the many contributions in GitHub. It’s starting to get difficult to list them all! [najamansari](https://github.com/powersync-ja/powersync-service/pull/418), [flochaz](https://github.com/powersync-ja/powersync-js/pull/794), [bfour](https://github.com/powersync-ja/powersync-docs/pull/313), [longfellowone](https://github.com/powersync-ja/powersync-js/pull/806), [tristanwagner](https://github.com/powersync-ja/powersync-docs/pull/323), [hamzzy](https://github.com/powersync-ja/powersync-service/pull/449), [stevenctl](https://github.com/powersync-ja/sqlite_async.dart/pull/123), and [giovannibonetti-jota](https://github.com/powersync-ja/powersync-docs/pull/341) all contributed PRs recently 🙏  
  

## Feature story: SQL Server support

As mentioned above, PowerSync finally supports Microsoft SQL Server and Azure SQL as source databases, so you can sync from existing SQL Server backends into local SQLite clients. This was one of our most requested features.

Rather than rehash the background and design decisions here, we’re pointing you straight to [Roland’s blog post](https://powersync.com/blog/change-data-capture-vs-change-tracking-how-we-built-our-sql-server-replication) – it dives into how the replication from SQL Server works, why we chose the mechanisms we did (CDC vs Change Tracking), and what that looks like under the hood.

That’s it for this issue.

---

# Unleashing the Power of Sync

> Discover the power of sync engines like PowerSync to build fast, real-time, and agentic applications. Simplify complex client-server state management, improve developer ergonomics, and learn how to integrate LLM agents easily.

- Published: 2026-02-06
- Author: Dev Agrawal
- Category: Engineering
- Source: https://powersync.com/blog/unleashing-the-power-of-sync

---

Sync engines and sync-based apps have recently exploded in popularity and mindshare. And for good reason.

They claim to offer snappier user experiences and simpler developer ergonomics, all by automating the process of moving data back and forth over the network. They make data fetching and mutation as easy as interacting with a local, reactive database, which is kept in sync with the backend database automatically.

A sync engine keeps a local database and a server database in continuous, bidirectional sync, so apps can read and write locally while replication happens in the background.

For people who have built native applications, the idea of working with a local database might sound familiar and obvious. I remember talking to one of my uncles who is an old school .NET developer building desktop apps. Most of his career he has written code that ships to users’ devices, and it bundles a SQL Server instance that runs locally and stores all the data. And I was trying to explain to him how after 2 decades of complicated web frameworks, people are realizing that the same local database architecture is not only simpler, but much superior.

So what are the benefits that sync engines promise exactly?

  * Application loads immediately with local data
  * Navigation between screens is instant
  * Changes are immediately reflected everywhere, including to other clients in real time
  * Network connection is not required to access the data
  * Complex and brittle cache management logic disappears
  * Reactivity across the stack
  * Radically simpler mental model
  * Efficient data flow from the server to the client

To understand the benefits better, let’s step back into history for a bit and see how client-server state management has been handled traditionally.

## Approaches to Async State Management

### Manual

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-59b3311ec2.png "Data flow in manual state management with actions that manage state and refetching||portrait")

  * Data was usually fetched from the server once the client application loads, and stored in local state.
  * When the user interacts with the UI, actions are invoked, which update the local state to reflect the interaction, as well as send mutation requests to the server. They might update the state again with the server response, or trigger a refetch of the data.
  * This is usually handled with procedural logic that tends to get complicated very easily as multiple locations of state need to be updated in co-ordination, or the user might see broken inconsistent states.
  * Data models often need to be duplicated between the server and the client

### Keyed Queries

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-a9b684e1b1.png "Data flow in key-based queries with mutations that invalidate queries||portrait")

  * Data is fetched through keyed queries that can be invalidated
  * Mutations can simply invalidate queries with no knowledge of the data structures
  * Invalidated queries automatically refetch and update everywhere in the UI
  * Optimistic updates get complex for the same reasons as manual mutations

### Sync Engine

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-e0ef2c9c82.png "Data flow in a sync-based system where client DB automatically updates queries and syncs data with the server||portrait")

  * Mutations go directly to a local database
  * Any affected queries automatically rerun, no invalidation logic required
  * Optimistic updates for free
  * Syncs automatically with server database
  * Real-time for free

### Comparison

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-dd379aa11a.png "Comparison table between Manual, Keyed Queries, and Sync Engine across Primary Reads, Offline Access, Realtime Updates, Cache/State Glue, and Optimistic UX.")

## Can Sync Engines Deliver?

UX expectations are at an all-time high in the industry and don’t show signs of stopping

  * The demand for software is only going up
  * Users need fast, real-time interfaces to be productive in their work
  * LLMs are putting even more stress on our infrastructure by forcing us to handle long-running and failure-prone streams of tokens
  * Managing complicated client and server state becomes difficult and slows down development

Sync engines equip developers to better tackle the complexities of client-server application development while ensuring a fast, snappy, and real-time user experience by default.

At the same time, a simpler mental model helps coding agents work better in the codebase, since there are less opportunities for the agents to make mistakes.

This is the power of sync.

And do sync engines today deliver on this?

Well…. yes, mostly, but there are tradeoffs.

  * Sync engines can be notoriously difficult to integrate with existing backends
  * Not every sync engine is stable, mature, or production-ready  

  * Many require rewriting code to fit their assumptions  

  * Might lock you in to a specific database and query layer  

  * Might not support your target client runtime  

  * Might lack enterprise-grade compliance features  

  * Might not support offline-first workflows

You probably want a sync engine that is

  * simple to integrate
  * stable and mature
  * pluggable into existing setups
  * low lock-in
  * runs everywhere
  * enterprise compliance-ready
  * offline-first

PowerSync is one such sync engine.

Most sync engines still assume a narrow stack: a specific backend, a specific client runtime, or both. That forces teams to re-platform or settle for a web-only experience. PowerSync is designed to be backend-agnostic and multi-client from day one, so you can adopt it without rewriting core infrastructure and keep one sync layer across web, mobile, and desktop.

## Building with PowerSync - Collaborative Agentic Chat

I have been building a shared workspace where users and agents can chat and collaborate with each other on work.

It’s like Discord or Slack but if Agents were a first-class citizen, like Users.

Let's see how PowerSync makes it simple to build these kind of apps.

> **Note**
>
> **NOTE:** The code snippets shown below are simplified to highlight the interaction with PowerSync. Many parts of the code that deal with UI specific logic have been hidden.

### Channel Creation

Let’s start with a simple feature - the ability to create channels and invite users and agents to it.

![Screen Recording 2026-02-05 at 2.41.17 PM.mov \[video-to-gif output image\]](/images/blog/unleashing-the-power-of-sync-inline-c83646f683.gif)

Implementing this is as straightforward as a couple of SQL queries in the form submit handler

```tsx
const handleChannelCreate = async (name) => {
  await writeTransaction(async (tx) => {
    // Insert channel
    await tx.execute(
      `INSERT INTO channels (name, created_by) VALUES (?, ?)`,
      [name, username]
    );

    // Add user as member
    await tx.execute(
      `INSERT INTO channel_members (channel_id, member_type, member_id) VALUES (?, 'user', ?)`,
      [channelId, username]
    );

    // Auto-add default assistant agent
    await tx.execute(
      `INSERT INTO channel_members (channel_id, member_type, member_id) VALUES (?, 'agent', ?)`,
      [channelId, defaultAgent]
    );
  });

  navigate(`/channel/${channelId}`);
};
```
The Channel list on the left simply queries the database for channels and shows them. Query reruns and updates the UI automatically when the new channel is added.

```tsx
function ChannelList() {
  const channels = useWatchedQuery(
    () =>
      `SELECT c.* FROM channels c
      JOIN channel_members cm ON cm.channel_id = c.id
      WHERE cm.member_type = 'user' AND cm.member_id = ?`,
    () => [username() || ""]
  );

  return <For each={channels.data}>
    {(channel) => (
      <A href={`/channel/${channel.id}`}>
        # {channel.name}
      </A>
    )}
  </For>
}
```
Without a sync engine, this would be a little complicated to implement.

  * Any queries showing a list of channels on the screen need to be invalidated
  * Cannot navigate to the new channel until the server responds with okay

### User Invites and Real-Time Updates

Let’s say adding a user to a channel should make the channel available in their UI like this:

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-e801e7ef53.gif "GIF showing inviting users to channels in real time")

Shouldn't be a surprise that adding this functionality is as simple as writing a SQL query:

```tsx
const handleInviteUser = async (invitedUsername) => {
  await writeTransaction(async (tx) => {
    await tx.execute(
      `INSERT INTO channel_members (channel_id, member_type, member_id)
         VALUES (?, 'user', ?)`,
      [props.channelId, invitedUsername],
    );
  });
};
```
Reactivity makes it simpler to extend the business logic and add features.

Without a sync engine, this might require a separate real-time notifications setup, which subscribes clients to topics and requires writing glue logic between the notification service, state management, and query invalidation. PowerSync reduces everything to SQL queries running against a local DB.

### Send and Receive Messages

Frequent bi-directional communication is where most applications and infrastructure configurations tend to break down. However, sync engines make it feel like a piece of cake, and PowerSync reduces everything down to SQL queries like normal business.

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-6949198e73.gif "GIF showing real time chat between users in a channel")

Listing out the messages in a channel is as simple as a query with some `JOIN`s for the author names.

```tsx
export function ChatMessages(props: ChatMessagesProps) {
  const messages = useWatchedQuery(
    () =>
      `SELECT m.*, a.name AS author_name
       FROM messages m
       LEFT JOIN users u ON m.author_type = 'user' AND u.id = m.author_id
       LEFT JOIN agents a ON m.author_type = 'agent' AND a.id = m.author_id
       WHERE m.channel_id = ?
       ORDER BY m.created_at ASC, m.id ASC`,
    () => [props.channelId],
  );

  return <For each={messages.data}>
    {(message) => {
      return (
        <div>
          <span>{message.author_name}</span>
          <span>{message.created_at}</span>
          <RenderMarkdown>{message.content}</RenderMarkdown>
        </div>
      );
    }}
  </For>
}
```
Sending a message just adds it to the table. No extra fuss.

```tsx
const handleMessageSend = async (text) => {
  await writeTransaction(async (tx) => {
    return tx.execute(
      `INSERT INTO messages (channel_id, author_type, author_id, content) VALUES (?, 'user', ?, ?)`,
      [props.channelId, username, text],
    );
  });
};
```
And as usual, real-time updates come out of the box.

Without a sync engine, this setup would require developers to define WebSocket messages and session-based state management both on the server and client, which often leads to messy logic requiring conversions from event formats to state updates, along with the infrastructure challenges of high-volume scalable realtime services.

### Agentic Integrations

This is a more recent and more interesting challenge being faced by app developers.

To understand the challenge of integrating LLM agents, let’s go back to the manual/keyed state management approach and understand what integrating with agents look like in code.

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-41543f950d.png "Convoluted dataflow resulted by integrating an agent into an app with manual state management||portrait")

Certain actions, alongside requesting mutations that update the server database, might also trigger agents on the server. Then they update local state to reflect the in-progress agent work. Agents usually respond with a stream of tokens, that then need to be pushed to the client through HTTP/SSE/WebSocket streams. Once the stream completes, the action might trigger refetching to ensure the latest query data is fetched for the client.

This way of building agentic integrations into apps has all the same issues of manual state management, along with a new one - streaming infrastructure. Agents could be running for long periods of time, and they stream tokens all throughout their lifetime. This stream not only needs to be continually pushed to the client, but also persisted on the server, and the client needs to ensure it doesn’t go out of sync with the server and show broken responses.

A sync-based architecture could simplify this integration by removing the need to stream token responses separately.

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-84edb3fe0f.png "Simplified dataflow by integrating an agent in a sync-based app with response streaming through the sync engine||portrait")

Instead, the agent response is simply persisted to the database, which gets synced automatically to the client database, immediately reflecting in the UI. This also works flawlessly with multiple users looking at the same channel.

However one issue still remains: the agent relies on a brittle request-response cycle between the client and the server. If either side disconnects for any reason, the agent execution can be interrupted in-flight with no recovery.

This can be addressed by abstracting the agent behind the sync entirely.

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-7cfcfaa684.png "Even simpler agent integration entirely through the sync engine on the server")

The agent can respond directly to changes made in the database, and stream responses back to the database. The client never needs to make a separate request to trigger an agent and stream tokens - it simply mutates the local database and the sync engine ensures the rest.

This not only simplifies agentic integrations, but also makes it easier to build multi-agent collaboration, i.e. agents that work with each other to accomplish larger and more complex tasks by delegating work where appropriate.

This pattern also makes the agents durable - i.e. they are resilient to crashes, failures, timeouts, and restarts.

```tsx
for await (const userMessages of db.watch("SELECT * FROM messages WHERE author_type = 'user'")) {
  for (const message of userMessages) {
    const mentionedNames = findAgentMentions(message.content)

    const mentionedAgents = await query(
      `SELECT a.id, a.name
       FROM agents a
       JOIN channel_members cm
         ON cm.member_id = a.id::text
        AND cm.member_type = 'agent'
       WHERE cm.channel_id = $1
         AND a.name = ANY($2)`,
      [message.channel_id, mentionedNames],
    );

    await Promise.all(
      Array.from(mentionedAgents).map(async (agent) => {
        const agentMessageId = crypto.randomUUID();

        await query(
          `INSERT INTO messages (id, channel_id, author_type, author_id, content) VALUES ($1, $2, 'agent', $3, $5)`,
          [agentMessageId, message.channel_id, agentId, "Thinking..."],
        );

        const response = await agent.generate(message.content);

        await query(`UPDATE messages SET content = $1 WHERE id = $2`, [
          response.text,
          agentMessageId,
        ]);
      }),
    );
  }
}
```
On a high level, this is all the code needed on the server side to integrate with agents.

  1. The server listens to changes on the messages table
  2. When a new message arrives, it looks for a @mentioned name in the message
  3. It looks for agents in the channel with the mentioned name
  4. The agent is called with the user’s message
  5. Agent’s response is saved into the database

![](https://powersync.com/images/blog/unleashing-the-power-of-sync-inline-2a455e1d9c.gif "GIF showing agent response streaming across multiple users in a channel")

The sync engine not only ensures that messages sent by clients are received by agents, but also that the agents’ responses are synced automatically to the clients. All the processing happens asynchronously and survives network failures, crashes, and reloads. Any messages sent to the agent offline are held on client devices until they come back online, and once online, the agents immediately start responding to the pending messages, and it’s visible for everyone in the channel in real time.

> **Note**
>
> **NOTE:** This code snippet shows a simplistic view of persisting and syncing the entire agent response once it completes. However, LLMs responses usually stream tokens granularly, and streaming each token through a sync engine is a more complicated and nuanced topic that requires an entirely separate blog post. For the purposes of this demonstration, showing the response of the agent being persisted in the database directly is simpler.

## The Power of Sync

Ultimately, this is what a sync engine is about - remove the accidental complexities of application development with distributed state, and reduce it down to boring SQL queries in the UI, while all the data synchronizes automatically with whatever database I might be using.

To learn more about PowerSync, check out the [documentation](https://docs.powersync.com/intro/powersync-overview).

---

# Building Offline-First File Uploads with PowerSync Attachments Helper

> PowerSync is an amazing tool to create completely offline-first applications with amazing user experience. There is one thing that has always held me back - attachments (photos/videos). This was missing part in my apps, it was the only thing that kept me apart from practically calling my app 100% offline. I’ve finally solved it once and for all, and I’m here to tell you the story.

- Published: 2026-01-28
- Author: Emil Zulufov (Guest author)
- Category: Engineering
- Source: https://powersync.com/blog/building-offline-first-file-uploads-with-powersync-attachments-helper

---

PowerSync is an amazing tool to create completely offline-first applications with amazing user experience. There is one thing that has always held me back - attachments (photos/videos). This was missing part in my apps, it was the only thing that kept me apart from practically calling my app 100% offline. I’ve finally solved it once and for all, and I’m here to tell you the story.

It is very common to see some sort of attachments uploading in a vast majority of mobile/web applications. For example, Instagram posts photos/videos uploading is a fundamental feature, and it is crucial to keep the uploading flow smooth, uninterrupted and continuous. This is where PowerSync takes advantage, providing a very convenient, easy-to-use [attachments helper](https://docs.powersync.com/usage/use-case-examples/attachments-files) to get this job done with straightforward API and integration.

## What is PowerSync?

PowerSync is a powerful synchronisation layer that makes apps feel fast, reliable, and always connected. It’s built to help developers turn basic cloud-connected apps into truly _offline-first_ experiences, where everything keeps working smoothly.

At its core, PowerSync keeps your local app data and backend server data perfectly in sync. When you make changes offline, they’re stored locally first and automatically sync up once your internet connection returns.

### What to note:

PowerSync feels instant because all actions happen locally, so users never wait on a network call. It’s always reliable since data safely syncs later, ensuring nothing gets lost. The system requires low maintenance as you focus on your app logic while PowerSync handles the complexity of sync and conflict resolution. Finally, it’s built for scale and works just as well for small apps as for large systems handling thousands of updates.

PowerSync guarantees [Causal+ Consistency](https://docs.powersync.com/architecture/consistency) while allowing partial replication and offline work, handling the tricky parts of network retries, browser storage, and cross-tab sync. This makes it a great tool for offline-capable apps where you want to remain in control of your backend.

The PowerSync Service specifically syncs rows, filtered by [sync rules](https://docs.powersync.com/usage/sync-rules) that you define.

That foundation makes advanced features like attachments uploading much easier and more resilient to build.

PowerSync’s attachments helper gives you a “Telegram‑style” send‑and‑forget layer for files: you enqueue uploads locally, and the helper takes care of syncing, retrying, and cleaning up between device storage and your backend.

## The Challenge

If you’re in a hurry, you can skip to the [demo repo](https://github.com/itsezlife/powersync_attachments_demo_app).

Before diving into the implementation, let me share what I was trying to achieve. I wanted to replicate that Telegram/WhatsApp-style experience where you send a message with photos or videos and don’t have to worry about your internet connection, it just uploads eventually.

On top of that, I needed the ability to safely close the app mid-upload without losing progress. Users should be able to start uploading a post with multiple photos, close the app, and come back later to find everything still uploading or already completed.

Breaking this down, there are four core challenges to solve:

  1. **Remote adapter** \- Upload attachment bytes to your storage backend (Supabase, S3, etc.)
  2. **Continuous background sync** \- Automatically retry failed uploads, handle network interruptions
  3. **Persistent queue** \- Store upload state so nothing is lost if the app closes
  4. **Local preview** \- Show posts and attachments with upload progress before they’re synced to the server

PowerSync’s attachments helper handles challenges 1, 2, and 3 out of the box. You just need to implement a `RemoteStorage` interface for your backend, and PowerSync takes care of the queue management, retries, and persistence. `Local Preview` is application-specific but follows a common pattern I’ll show you.

## When to Use the Attachments Helper

The attachments helper shines when persistence and reliability truly matter. Here’s a quick guide:

**Use it when:**

  * Uploading multiple attachments per post/message
  * Offline-first behaviour is critical
  * Users need to see upload progress
  * You want “send and forget” behaviour

**You can skip it when:**

  * Uploads are not frequent and quick (like profile avatars)
  * Persistence isn’t a concern
  * You’re okay with blocking UI during uploads

For this demo, I’m building a social media-style app where posts can have multiple photos. Users need to see their posts immediately with upload progress, and everything must persist across app restarts.

## How the Attachments Helper Works

Relevant code:

  * [_attachment_queue_service.dart_](https://github.com/powersync-ja/powersync.dart/blob/main/packages/powersync/lib/src/attachments/attachment_queue_service.dart)
  * [ _remote_storage.dart_](https://github.com/powersync-ja/powersync.dart/blob/main/packages/powersync/lib/src/attachments/remote_storage.dart)
  * [ _sync_error_handler.dart_](https://github.com/powersync-ja/powersync.dart/blob/main/packages/powersync/lib/src/attachments/sync_error_handler.dart)

At its core, PowerSync’s attachments helper provides an `AttachmentQueue` that manages file uploads. You enqueue files with metadata, and the queue handles the rest: uploading to your backend, tracking progress, retrying on failure, and persisting state.

The queue stores attachments in a special `attachments_queue` table (automatically created by PowerSync) that tracks each file’s state: preparing, uploading, completed, or failed. This table is local-only, meaning it never syncs to your backend.

To use it, you implement the `RemoteStorage` interface with three methods:

  * `uploadFile` \- Stream file data to your storage
  * `downloadFile` \- Retrieve files (if needed)
  * `deleteFile` \- Remove files from storage

The helper calls these methods as needed, and you control retry behavior through an `AttachmentErrorHandler` that returns `true` to retry or `false` to give up on specific errors.

## Building the Demo

This demo app ([source code](https://github.com/itsezlife/powersync_attachments_demo_app)) implements a complete post creation flow with photo attachments.

### Setting Up the Schema

 _Relevant code:_[_AttachmentsQueueTable_](https://github.com/powersync-ja/powersync.dart/blob/main/packages/powersync/lib/src/attachments/attachment.dart)

First, we define our database schema. The key pieces are the `AttachmentsQueueTable` and local-only tables for posts and attachments:

```dart
AttachmentsQueueTable(
  additionalColumns: const [
    Column.text('post_id'),
    Column.integer('sent'), // bytes uploaded so far
  ],
),
Table.localOnly('posts_local', [...]),
Table.localOnly('post_attachments_local', [
  // ... attachment fields plus 'sent' for progress
]),
```
The local-only tables `posts_local` and `post_attachments_local` are crucial, they let us show posts immediately while attachments upload, without syncing incomplete posts to other users. Once all attachments finish uploading, we move the post to the regular `posts` table, which PowerSync syncs to the backend.

I should note that this approach of using separate local tables is my personal preference. You could also use a simpler pattern with just reference columns in synced tables. For me, it felt more natural to treat the `attachments_queue` table as an internal implementation detail that the attachments helper manages internally, handling uploads, deletions, and downloads. For display and business logic purposes, having dedicated tables felt like a cleaner separation of concerns. The attachments helper manages the core business logic with all background workers and internal sync loops, while the display layer can be adjusted based on your own preferences and needs.

You can see the full schema [here](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/schema/schema.dart).

### Initialising the Queue

When the app starts, we initialise the attachment queue with our `RemoteStorage` implementation:

```dart
final remoteStorage = SupabasePostStorageAdapter(
  db: _db,
  uploadedAttachmentsStorage: uploadedAttachmentsStorage,
);

final attachmentQueue = await initializePostAttachmentQueue(
  _db,
  remoteStorage,
);

await attachmentQueue.startSync();
```
_Relevant code:_[_SyncingService.startSync_](https://github.com/powersync-ja/powersync.dart/blob/main/packages/powersync/lib/src/attachments/sync/syncing_service.dart)

The initialisation code is in [`powersync_client.dart`](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/powersync_client.dart#L437-L456). The `startSync()` call begins processing the queue in the background, automatically retrying failed uploads and handling new ones as they’re added.

You might notice that `watchAttachments` returns `Stream.value([])` in the initialisation. This is because in this demo, all images are loaded on-demand in the image widget itself when posts and images are displayed, so there's no need to watch remote tables and automatically download attachments. This approach bypasses the library's automatic orphan cleanup feature, which would normally delete local files that aren't referenced in the stream. If you ever need to handle stale file cleanup manually, you'd need to implement that yourself, but for this use case where files are managed explicitly through the upload queue, it hasn't been necessary.

### Creating Posts with Attachments

When a user creates a post, the flow depends on whether there are attachments:

```dart
final postTable = attachments.isEmpty ? 'posts' : 'posts_local';
```
If there are no attachments, we write directly to `posts` and PowerSync syncs it immediately. If there are attachments, we write to `posts_local` and start uploading each attachment to the queue.

For each attachment, we call `saveAttachment`, which adds it to the queue:

```dart
await _powerSyncClient.saveAttachment(
  data: File(file.path!).openRead(),
  file: file,
  postId: id,
  attachmentId: attachment.imageUrl?.removeExtension,
  isUploaded: attachment.uploadState.isSuccess,
  minithumbnail: minithumbnail,
);
```
This code is in [`powersync_database_client.dart`](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/database_client/powersync_database_client/lib/src/powersync_database_client.dart#L181-L188). The `saveAttachment` method wraps PowerSync’s `attachmentQueue().saveFile()`, which stores the file locally and adds it to the queue for upload.

### The Upload Pipeline

Once an attachment is in the queue, PowerSync calls our `RemoteStorage.uploadFile` method. This is where all the business login lies in [`supabase_storage_adapter.dart`](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/attachments/post/supabase_storage_adapter.dart).

The upload process begins by validating that the attachment exists, checking that the local attachment row still exists since it might have been deleted. Next, we upload to Supabase Storage by streaming the file bytes to Supabase and reporting progress via `onSendProgress`. As the upload progresses, we track progress by updating the `post_attachments_local.sent` column with bytes uploaded so far. After each successful upload, we check completion by counting remaining attachments. Finally, when all attachments are uploaded, we publish the post by moving it from `posts_local` to `posts`.

The progress tracking happens here:

```dart
onSendProgress: (count, total) async {
  await _db.execute(
    '''
      UPDATE post_attachments_local
      SET sent = ?, file_size = ? WHERE image_url = ? AND post_id = ?
    ''',
    [count, total, storageFileName, postId],
  );
},
```
This updates the local table, which the UI watches to display progress. The [`PostAttachment` widget](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/lib/src/posts/post/widgets/post_attachment.dart) reads the `sent` and `file_size` columns to show a percentage indicator.

In the implementation you might notice I explicitly use `Dio` to upload bytes to the Supabase, rather than Supabase API directly. This is because Supabase doesn't provide `onSendProgress` callback, so you can't dispatch bytes uploaded so far for granular progress indicator. There is a `supabase_progress_uploads` library, I've been playing a lot with, and while it provides progress callback and has a bunch of cool features out of the box, it has a significant drawback - it slows down the uploading process by about 3-5 times. Internally it uses `tus_client_dart`, which is a network client that uses TUS protocol for resumable uploading, that causes this “lag”. While pausing/resuming might be beneficial, the trade-off with the speed is not acceptable.

### Ensuring Atomic Post Publishing

One of the trickiest parts is ensuring a post only appears to other users after all its attachments are uploaded. We solve this with a completion check after each upload:

```dart
var leftAttachments =
    (existingLocalAttachmentsCount) - uploadedAttachments.length;

// Account for deleted attachments
leftAttachments -= deletedAttachments.length;

if (leftAttachments == 0) {
  await _uploadPost(
    tx: tx,
    postId: postId,
    localPostRow: localPostRow,
    uploadedAttachments: uploadedAttachments,
  );
}
```
The `_uploadPost` method ([implementation](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/attachments/post/supabase_storage_adapter.dart#L109-L209)) atomically deletes from `posts_local`, inserts into `posts` (which PowerSync syncs to backend), inserts attachments into `post_attachments` (synced to backend), and cleans up `post_attachments_local`.

### Handling Errors and Retries

The attachments helper includes an error handler that decides whether to retry failed uploads:

```dart
errorHandler: AttachmentErrorHandler(
  onUploadError: (attachment, exception, stackTrace) async {
    if (exception is UploadFileNotFoundFailure ||
        exception is UploadPostNotFoundFailure) {
      return false; // Don't retry - file/post was deleted
    }
    return true; // Retry on other errors
  },
),
```
This is configured in [`attachments_queue.dart`](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/attachments/post/attachments_queue.dart#L21-L37). Returning `false` tells PowerSync to stop retrying (useful when a post is deleted mid-upload). Returning `true` triggers automatic retries.

### Persistence Across App Restarts

Here’s where PowerSync really shines, everything persists automatically. The `attachments_queue` table is stored in SQLite, so if the app closes mid-upload, the queue state is preserved. When the app reopens and calls `attachmentQueue.startSync()`, PowerSync resumes uploading from where it left off.

The local-only tables (`posts_local`, `post_attachments_local`) also persist, so users see their in-progress posts immediately when reopening the app. The business logic in [`user_profile_bloc.dart`](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/lib/src/user_profile/bloc/user_profile_bloc.dart) queries and watches both local and synced posts, creating a seamless experience where users see their own posts immediately.

## The Result

With this implementation, users get a truly offline-first experience. Posts appear immediately with upload progress, providing instant feedback to users. The system survives app restarts seamlessly, with everything continuing to upload after reopening the application. Posts are published atomically, meaning they only appear to other users when fully uploaded. The implementation includes graceful error handling where failed uploads retry automatically. Users can track progress in real-time with percentage indicators shown for each attachment.

The attachments helper handles all the hard parts: queue management, retries, persistence, and background sync. You just implement the storage adapter and define your local-only tables for preview.

## Try It Yourself

You can explore the complete implementation in the [demo repository](https://github.com/itsezlife/powersync_attachments_demo_app). The key files to check out:

  * [Schema definition](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/schema/schema.dart) \- Local-only tables and queue setup
  * [Storage adapter](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/attachments/post/supabase_storage_adapter.dart) \- Complete upload pipeline
  * [Queue initialization](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/powersync_client/lib/src/attachments/post/attachments_queue.dart) \- Error handling configuration
  * [Post creation](https://github.com/itsezlife/powersync_attachments_demo_app/blob/master/packages/database_client/powersync_database_client/lib/src/powersync_database_client.dart#L54-L196) \- Adding attachments to the queue

The attachments helper transformed what would have been weeks of work (background uploads, retry logic, persistence, progress tracking) into a straightforward integration. If you’re building an app with file uploads, especially multiple files per entity, I highly recommend giving it a try. But, it's worth a note that attachments API is experimental and can be changed significantly at any time, consider using it at your own risk. From my side, I'll do my best to keep up with the most up-to-date solution in this demo app. Happy coding!

---

# 2025 PowerSync Roadmap Update

> Early in 2025, I wrote about the 2025 roadmap for PowerSync. The main theme was improving PowerSync for the web. In this post, I want to provide an update on how 2025 turned out. We refined our plans during the course of 2025 and ended up in what I think is a pretty good place, albeit slightly different than originally envisioned.

- Published: 2026-01-05
- Author: Conrad Hofmeyr
- Category: Product Update
- Source: https://powersync.com/blog/2025-powersync-roadmap-update

---

Early in 2025, I wrote about the [2025 roadmap](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility) for PowerSync. The main theme was improving PowerSync for the web:

> PowerSync began as a sync engine for apps that need to work offline. But more and more developers are using sync engines for always-online web apps. Why? Because they make web apps super-fast, and significantly simplify state management. PowerSync has some strong qualities, like how it exposes standard SQLite, and its robust offline capabilities. Yet it has areas where it needs to evolve to work better for online web apps. Today we are announcing our roadmap for 2025 that will level-up PowerSync for the new era of web apps powered by sync engines, while preserving our offline & mobile DNA.

I shared some of the major projects on the roadmap in pursuit of that objective, including better allowing for on-demand syncing of data in addition to “pre-syncing” data, and some web-focused performance optimizations. I also mentioned supplementary goals in the roadmap: improved querying flexibility by allowing syncing from incrementally materialized views, a simplified Sync Rules mental model, and an improved developer onboarding experience — including specifically an improved PowerSync Dashboard.

In this post, I want to provide an update on how 2025 turned out. We refined our plans during the course of 2025 and ended up in what I think is a pretty good place, albeit slightly different than originally envisioned.

### Exploring the problem more deeply

During this past year, we thought more deeply about the specifics of how to improve the design of the [Sync Rules](https://docs.powersync.com/usage/sync-rules) system at the heart of PowerSync. Back when we started PowerSync, Sync Rules were designed for syncing all data upfront when the user connects, which is what you typically want for offline-first architecture.

For web use cases where users are mostly online however, it makes more sense to sync only the relevant contextual data “just-in-time” based on the specific pages or UI sections that the user is browsing, and to keep that data around for a while after they close the tab or UI component. 

A sync engine like PowerSync is still useful for these kinds of online apps for various reasons: resiliency against losing the network connection, instantly loading data when refreshing or navigating to pages (when the data is already synced), optimistic local state when making updates, real-time updates when changes are made remotely, and ease of working with local state — avoiding complexities of caching and cache invalidation.

It is technically possible to accomplish “sync only the relevant data on-demand” with [client parameters](https://docs.powersync.com/usage/sync-rules/advanced-topics/client-parameters) in our existing Sync Rules system, but it gets ugly quickly. The user may have multiple tabs open, each needing to sync a different set of data. Implementing the logic to combine client parameters across different tabs and/or UI components, and deciding when to remove parameters quickly becomes complex and painful.

### Enter Sync Streams

Our goals were clear: We wanted to allow clients to sync relevant data on-demand in an elegant way that works well across multiple UI components and multiple browser tabs, while not compromising on how well PowerSync works for offline-first “sync data upfront” use cases. And while making these improvements, we wanted to simplify the mental model and developer experience. 

After iterating through a few ideas, we came up with a design we are calling [_Sync Streams_](https://docs.powersync.com/sync/streams/overview). Here’s a quick rundown of the core ideas. 

Sync Streams are defined upfront:

```yaml
streams:
  issue: # Define a stream to a specific issue
    query: select * from issues where id = subscription.parameters() ->> 'id'
  issue_comments: # Define a stream to a specific issue's comments
    query: select * from comments where issue_id = subscription.parameters() ->> 'id'
```
Clients can then subscribe to the Sync Streams one or more times with different parameters — each time creating a _subscription_. If a client unsubscribes a certain subscription, the associated data continues to sync within a TTL window, which means that if the client resubscribes a Sync Stream with the same parameters as before, there will be a warm client-side cache of the relevant data. This solves the problem of manual wrangling of client parameters:

```typescript
const sub = await powerSync
  .syncStream('issues', { id: issue_id })
  .subscribe({ ttl: 3600 });
```
One way to use Sync Streams is with React hooks, where a component can automatically subscribe to a Sync Stream with the relevant parameter(s) when it mounts, and then automatically unsubscribe when it unmounts. The TTL behavior means that when unmounting and remounting, the relevant data is already synced on the client:

```typescript
const stream = useSyncStream({ name: 'todo_list', parameters: { list: 'foo' } });
```
If you want “sync everything upfront” behavior (like the current Sync Rules system), that’s easy too: you can configure any of your Sync Streams to be auto-subscribed when the client connects:

```yaml
streams:
  issues_for_org:
    query: select * from issues where org_id = auth.parameters() ->> 'org_id'
    auto_subscribe: true
```
We also simplified the mental model in Sync Streams: We eliminated the concepts of having separate Parameter Queries and Data Queries like we do in Sync Rules. Sync Streams just have _queries with embedded subqueries_. As you can see in the example above, you can use parameters directly in the query. And you can do things like this with subqueries:

```sql
-- "in (subquery)" replaces parameter queries:
select * from comments where issue_id in (select id from issues where owner_id = auth.user_id())
```

> **Note**
>
> When this blog post was originally published, Sync Streams were in alpha. They landed in [beta in March 2026](https://releases.powersync.com/announcements/sync-streams-are-now-in-beta) and [GA in June 2026](https://releases.powersync.com/announcements/sync-streams-are-now-generally-available). See all the details in the [docs](https://docs.powersync.com/sync/streams/overview).

### How Sync Streams stack up

Our original 2025 roadmap ideas involved adding several new concepts to the _Sync Rules_ system: Simple vs Advanced Sync Rules. Pre-Synced vs. On-Demand Buckets. Caching Helpers. In the end, we ended up throwing all that out the window, and rather designed a streamlined set of concepts and syntax from the ground up: _Sync Streams._ Sync Streams initially exists alongside Sync Rules, but is a long-term complete replacement for Sync Rules.

We feel that Sync Streams delivers on the vision in our 2025 roadmap by providing an elegant unified solution catering for both offline apps that sync data upfront, and online apps that sync data on-demand — while simplifying the mental model and developer experience.

### Other major 2025 projects shipped

We also shipped a bunch of other things we said we would:

**Web performance optimizations:** We shipped all the [optimizations](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility#2-web-performance-optimizations) we planned on: [prioritized syncing](https://releases.powersync.com/announcements/prioritized-sync-ensure-critical-data-syncs-first) to ensure critical data syncs first, allowing you to improve load times especially for web apps; [compression](https://github.com/powersync-ja/powersync-service/pull/329) of data in transit; an [OPFS](https://github.com/powersync-ja/powersync-js/pull/418)-based VFS for our web SDK, and [incremental & differential watch queries](https://releases.powersync.com/announcements/introducing-incremental-and-differential-watch-queries-for-javascript) to avoid re-running entire queries continuously whenever any row in an affected table is updated. We also went further in expanding the reactivity options available to developers, with experimental [high-performance diffs](https://releases.powersync.com/announcements/get-high-performance-diffs) in our JavaScript SDKs, and an initial [TanStack DB integration](https://powersync.com/blog/powersync-tanstack-db-collection), which allows leveraging the differential dataflow implementation in TanStack DB. 

As we [talked about](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility#the-principles-guiding-us-sqlite-front-and-center), we are huge proponents of SQLite, and SQLite performance on the browser is a topic we care a lot about. If you are interested in learning more about what’s under the hood, you may enjoy [my talk](https://www.youtube.com/watch?v=7yNG1aj7-Aw) from Sync Conf 2025 about the state of the art of SQLite persistence in web browsers, which is based on Ralf’s [blog post](https://powersync.com/blog/sqlite-persistence-on-the-web).

**New PowerSync Dashboard**

When it comes to developer onboarding experience, we said we would improve the PowerSync Cloud experience by improving the PowerSync Dashboard. We ended up going a step further than that: we [completely rebuilt](https://releases.powersync.com/announcements/introducing-the-new-powersync-dashboard) the PowerSync Dashboard from the ground up, and it uses the PowerSync web SDK under the hood! We will share more about the behind-the-scenes story in the near future. We think it’s a great use case of sync engines on the web and for PowerSync in particular.

### Lots of other features shipped

We were quite busy in 2025. We shipped a bunch of other stuff, including: 

  * Moving various parts of the stack from alpha to beta and from beta to V1
  * [Sync progress tracking](https://releases.powersync.com/announcements/sync-progress-tracking-now-available-in-powersync-sdks)
  * [Postgres bucket storage](https://releases.powersync.com/announcements/introducing-postgres-for-sync-bucket-storage), providing an alternative to MongoDB storage when self-hosting the PowerSync Service.
  * [SQL Server](https://releases.powersync.com/announcements/announcing-sql-server-backend-support-alpha) backend database support
  * New client SDKs for [Node.js](https://releases.powersync.com/announcements/introducing-our-node-js-client-sdk-alpha-release), [.NET](https://releases.powersync.com/announcements/introducing-our-net-client-sdk-alpha-release) and [Capacitor](https://releases.powersync.com/announcements/introducing-our-native-capacitor-sdk)
  * A new [Rust-based client](https://releases.powersync.com/announcements/improved-sync-performance-in-our-client-sdks) architecture that improves performance 
  * [Raw SQLite tables](https://releases.powersync.com/announcements/introducing-raw-sqlite-tables-support-experimental) experimental support, as an alternative to the JSON-based SQLite views system
  * [Fine-grained update tracking](https://releases.powersync.com/announcements/powersync-sdks-fine-grained-update-tracking-with-previous-values-metadata) in client SDKs with previous values & metadata
  * [Custom metadata in sync logs](https://releases.powersync.com/announcements/capture-custom-metadata-in-sync-logs-for-improved-observability) for improved observability
  * [OP-SQLite support](https://releases.powersync.com/announcements/op-sqlite-for-powersync-react-native) for PowerSync on React Native
  * [Expo Go support](https://releases.powersync.com/announcements/expo-go-support-via-powersync-adapter-sql-js-alpha) for React Native
  * [Room and SQLDelight integrations](https://releases.powersync.com/announcements/more-robust-sql-queries-for-kotlin-apps-room-and-sqldelight-integrations) for our Kotlin SDK

### Still pending: Syncing from incrementally materialized views

One big thing that we didn’t manage to ship in 2025 is the ability to create materialized views that you can sync from, which are automatically incrementally updated using an Incremental View Maintenance (IVM) or a similar algorithm. Therefore, Sync Streams currently have similar limited querying flexibility to Sync Rules, e.g. when it comes to multi-level joins and many-to-many relationships. 

> **Note**
>
> Since this blog post was originally published, we added [limited support for joins](https://docs.powersync.com/sync/streams/queries#using-joins) to Sync Streams.

### We want your feedback

We feel that with Sync Streams and other web focused optimizations, PowerSync is now much more usable for a much larger percentage of web app use cases.

If you are using PowerSync on the web, we would love to [chat](https://docs.powersync.com/resources/contact-us) to get your feedback on what you see as the remaining gaps.

---

# PowerSync Cloud Is Now HIPAA Compliant

> Previously we recommended that customers who build apps dealing with HIPAA patient data need to self-host PowerSync. But starting now, PowerSync Cloud is also a compliant option.

- Published: 2025-12-26
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/powersync-cloud-is-now-hipaa-compliant

---

The Health Insurance Portability and Accountability Act (HIPAA) is a U.S. federal law that protects the privacy and security of individuals’ health information. Companies building applications that handle healthcare data must comply with HIPAA.

## Background

Since we launched PowerSync, we’ve received a bunch of requests to support HIPAA on PowerSync Cloud. Up till now, we’ve recommended to these customers that they should self-host PowerSync. But starting now, PowerSync Cloud is also a compliant option.

We have been SOC 2 Type 2 audited for several years now, so adding additional controls required for HIPAA compliance was luckily not a heavy lift. We were also able to work with our existing SOC 2 auditing firm to expand the scope of our annual compliance audit to cover HIPAA. 

## Build Healthcare Apps with PowerSync

We have a shared responsibility model when it comes to HIPAA compliance. The detailed breakdown of customer responsibilities vs. PowerSync responsibilities can be found in our documentation [here](https://docs.powersync.com/resources/hipaa).

If you want to start developing healthcare apps using PowerSync, the first step is to get in touch with us to sign a Business Associate Agreement (BAA). To request a BAA, email us at [hello@powersync.com](mailto:hello@powersync.com)

---

# Change Data Capture vs. Change Tracking: How We Built Our SQL Server Replication

> Ever since launching PowerSync, we’ve had a steady stream of users asking us to support SQL Server. We're excited to announce that the wait is over and PowerSync now officially supports Microsoft SQL Server and Azure SQL Database as source databases!

- Published: 2025-12-10
- Author: Roland Teichert
- Category: Engineering
- Source: https://powersync.com/blog/change-data-capture-vs-change-tracking-how-we-built-our-sql-server-replication

---

Ever since launching PowerSync, we’ve had a steady stream of users asking us to support SQL Server. We're excited to announce that the wait is over and PowerSync now officially supports Microsoft SQL Server and Azure SQL Database as source databases! This means you can now sync data from your SQL Server databases to local SQLite databases on clients, enabling offline-first experiences for applications backed by Microsoft's flagship relational database.

Let's take a closer look at how we built this integration, the technical decisions we made, and how you can get started syncing your SQL Server data today.

## How PowerSync Works with SQL Server

When you first connect PowerSync to your SQL Server database, we perform a full snapshot of your configured tables. This involves querying the tables to capture the current state of your data and storing it in PowerSync.

Once that is done the PowerSync Service switches to streaming replication mode, where it leverages Change Data Capture (CDC) to track and replicate changes from your source tables. Unlike Postgres’ logical replication, or MySQL's binary log streaming where we listen for change events, PowerSync has to continuously poll the CDC change tables for updates.

### What is SQL Server Change Data Capture?

[Change Data Capture (CDC)](https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-ver17) is a feature built into SQL Server that records `INSERT`, `UPDATE`, and `DELETE` activity on tables. When enabled, CDC captures row-level changes and stores them in special change tables that mirror the structure of your source tables, plus metadata columns that track the type of operation and transaction details.

CDC also provides system functions that allow one to query changes within a specific Log Sequence Number (LSN) range. This is exactly what PowerSync uses to efficiently poll for changes.

### Why CDC Instead of Change Tracking?

SQL Server offers another more lightweight update tracking mechanism called [Change Tracking](https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-tracking-sql-server?view=sql-server-ver17), so why did we choose CDC? There are a few reasons:

1\. Change Tracking only tells you _that_ a row changed, not _what_ changed: It is up to you to query the current state of a row after learning it was modified. This requires additional queries to the database for each row that was modified. This can potentially introduce inconsistencies, because the data may have changed between the time the change was detected and the time the row was queried.

CDC, on the other hand, captures the actual before and after values of each change. Functionally this more closely matches the behavior of our other database adapters.

2\. Change Tracking requires that a table has a primary key or unique constraint:  While this is not a problem for most applications (having a primary key is good practice after all), our other database adapters support syncing tables without a primary key or unique constraint.

3\. Delete operations: When a row is deleted, Change Tracking only tells you the primary key of the deleted row. For proper downstream processing, PowerSync needs to know the actual values of the deleted row.

### A Note on Change Event Streaming (Preview)

Microsoft recently introduced [Change Event Streaming](https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/change-event-streaming/overview?view=sql-server-ver17), a new preview feature that provides a more modern, event-driven approach to change capture. Basically updates are streamed into [Azure Event Hubs](https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-about) from where they can be synced to other configurable destinations. This could potentially be an interesting option for integration, offering a more real time stream of updates, but the current hard coupling to Azure Event Hubs adds an extra layer of complexity. We'll definitely keep an eye on this feature as it matures!

## Database Requirements

This section presents a high level outline of requirements. See the [documentation](https://docs.powersync.com/configuration/source-db/setup#sql-server-alpha) for detailed setup instructions. 

Before PowerSync can sync from your SQL Server database, we require the following:

  1. CDC must be enabled on the database level.  

     1. Note that CDC is only available on specific SQL Server editions. We support:  

        1. Standard Edition 2022 (v16) or newer
        2. Enterprise Edition 2022 (v16) or newer (includes Developer and Evaluation) 
        3. Azure SQL Database
        4. Azure SQL Managed Instance
  2. Each table you want to sync must have CDC enabled.  

  3. A database user for PowerSync to connect with, with the necessary permissions: 
     1. `SELECT` access to the source and the CDC change tables
     2. `SELECT` access to the CDC schema.
     3. `VIEW SERVER PERFORMANCE STATE`, `VIEW DATABASE PERFORMANCE STATE` access to server and database level performance state views.
  4. A PowerSync Checkpoints Table has been created. The PowerSync database user requires `SELECT`, `INSERT` and `UPDATE` access to this table. This table is used to generate regular CDC entries that help us track replication progress accurately.

## Implementation Deep Dive

Let's get into the technical details of how PowerSync syncs data from SQL Server. Our SQL Server integration consists of two main phases: **_Initial snapshot_** and **_Streaming replication_**.

### Initial Snapshot

When PowerSync first connects to your database, we need to capture the current state of all the tables configured in the sync rules/sync streams. Here's how it works:

  1. We resolve the schemas for all tables from your sync rules/sync streams.
  2. Then we confirm that CDC is enabled for each table and that the database user has the necessary permissions to read the source and the change tables.
  3. Finally we stream the table data in batches, using primary key ordering for resumable snapshots

**Note:** The snapshot uses SQL Server's `READ COMMITTED` isolation level. While this means data can change during the snapshot process, we compensate for this during the streaming replication phase. We record the current LSN when starting the snapshot and when completing the snapshot. We then start streaming replication from the snapshot start LSN. Once replication has caught up with all the changes between the snapshot start and end LSN, we know that the snapshot is complete and consistent.

### Streaming Replication

After the initial snapshot, we enter streaming replication mode using CDC polling. The polling mechanism:

  1. Calculates the LSN bounds for the polling cycle, limiting the number of transactions based on the polling batch size.
  2. Uses the built-in CDC functions to retrieve changes within the LSN range.
  3. Processes any applicable updates.
  4. Records a new [checkpoint](https://docs.powersync.com/architecture/consistency#how-it-works:-checkpoints) once all tables have been processed for this polling cycle.

**Note:** The polling interval and polling batch size are configurable. The default polling interval is 1 second and the default polling batch size is 10 transactions. Reducing the polling interval helps reduce the latency at the cost of higher CPU usage. Increasing the polling batch size helps to increase the throughput per polling cycle at the cost of increased memory usage.

## Challenges and Solutions

Building a robust CDC-based replication system came with several interesting challenges:

### Challenge 1: CDC retention and data expiry

CDC doesn't keep change data forever — it has a configurable retention period (default is 3 days). If PowerSync is stopped for longer than this retention period, the changes since the last checkpoint will no longer be available.

**Solution** : Before resuming replication, we check if the last checkpoint LSN is still within the retention window for all the CDC change tables. If data has expired, we automatically trigger a fresh snapshot.

### Challenge 2: Transaction affecting multiple tables

CDC change data can include transactions that may span multiple tables. We need to ensure we process complete transactions so that when we record a checkpoint, it includes all the changed tables for that transaction.

**Solution** : Even though we retrieve the updates for all the change tables sequentially, we only create a new checkpoint once tables have been processed for a polling cycle.

### Challenge 3: Potentially large backlog of changes

If PowerSync is offline for a long time, a large backlog can build up in the CDC change tables. If we simply processed all the updates in a single polling cycle, we are likely to run into memory issues. We might also be starved for checkpoints for a long time.

**Solution** : We limit the number of transactions that can be processed in a single polling cycle to a configurable number. Smaller values mean more frequent checkpoints, and a lower memory footprint.

### Challenge 4: LSN mismatches between the transaction log and CDC

The LSNs in the transaction log and the change tables are not always in sync. This is commonly the case when a bunch of transactions are recorded in the transaction log, which do not apply to any of the replicated tables. It can also happen if the CDC capture job is not able to read updates in the transaction log fast enough, causing a backlog.

**Solution** : Since we can't guarantee that an LSN we record even ends up in the CDC change tables, we need to be able generate a transaction on demand that we _know_ will be replicated. This is where the PowerSync Checkpoints Table comes in. Basically if we record the current LSN, then update the checkpoint table, we can reliably wait for a transaction with an LSN greater than the recorded LSN to appear in the CDC. Using this mechanism we can track the CDC progress accurately.

## Limitations

While our SQL Server integration is fully functional, there are some limitations to be aware of:

  1. **No true real-time streaming** : The CDC replication mechanism involves polling. This adds some inherent latency to the replication process. See _Latency and Performance Tuning_ below for more details.
  2. **Schema changes** : Currently, schema changes (adding/removing columns, renaming tables) require manual intervention. We plan to support automatic schema change handling in the near future.
  3. **Temporal data types** : Temporal data types are replicated with a maximum precision level of milliseconds.
  4. **Spatial data types** : Spatial data types like geometry and geography are replicated as non standard spatial JSON objects as supplied by the Tedious node-mssql [client](https://github.com/tediousjs/node-mssql?tab=readme-ov-file#geography-and-geometry).
  5. **CDC retention period** : If PowerSync is offline longer than the CDC retention period (default 3 days), a fresh snapshot will be required.

**Note:** Azure SQL Database comes with its own set of limitations and considerations. See the _Azure SQL Database Specifics_ section below for more details.

## Latency and Performance Tuning

Due to the fundamental differences in how CDC works compared to logical replication (Postgres) or binlog streaming (MySQL), there is an inherent latency in replicating data from SQL Server to PowerSync. The latency is determined by two factors:

  1. **Transaction Log Scan Interval** : The frequency at which the CDC capture job scans the transaction log for changes. The default value of 5 seconds can be changed by modifying the capture job settings on SQL Server. The recommended value is 1 second or lower, but this can add additional load on the database. 
  2. **Polling Interval** : The frequency at which PowerSync polls the CDC change tables for changes. The default value is once every 1000ms. This can be changed by setting the `**_pollingIntervalMs`_** parameter in the PowerSync configuration.

The combination of the log scan interval and the polling interval determines the overall latency from when a transaction is committed to when it is available in PowerSync. In practice the actual latency is lower than the sum of the two intervals, due to the fact that the CDC capture job and the PowerSync polling are running asynchronously.

## Azure SQL Database Specifics

Azure SQL Database fully supports CDC, but there are some [additional limitations](https://learn.microsoft.com/en-us/azure/azure-sql/database/change-data-capture-overview?view=azuresql#known-issues-and-limitations) to be aware of:

  1. **Transaction Log Scan Interval is not configurable** : Azure SQL Database doesn't have SQL Server Agent. Instead, CDC capture and cleanup are handled by a scheduler automatically. This means you can't customize the capture job polling interval the same way you would for an on-premise SQL Server. This means that even with aggressive polling settings on the PowerSync side, your actual sync latency is bounded by Azure's internal CDC capture frequency. For most applications, this is measured in seconds, but it's something to be aware of for latency-sensitive scenarios.

  2. **Service Tier Requirements** : CDC requires S3 tier or higher for DTU-based pricing, or any tier for vCore-based pricing. Basic, S0, S1, and S2 tiers are not supported.

## Getting started

Ready to try PowerSync with SQL Server? 

### PowerSync Cloud

Our SQL Server adapter is available in PowerSync Cloud. To get started see our official [docs](https://docs.powersync.com/installation/database-connection#sql-server-alpha-specifics).

### Open Edition

We've prepared a complete self host [demo app](https://github.com/powersync-ja/self-host-demo/tree/main/demos/nodejs-mssql) to help you get started quickly. This demo includes:

  * Docker Compose setup with a CDC enabled SQL Server
  * Sample database schema for a todos app and corresponding client application
  * Pre Configured PowerSync service with sync rules

## What's Next?

This release marks an important milestone in our mission to bring offline-first capabilities to every application, regardless of the backend database. With SQL Server and Azure SQL Database support, PowerSync now covers the major enterprise database platforms.

We'll be continuing to improve the SQL Server integration with:

  * Automatic schema change handling
  * Better handling of spatial data types
  * More authentication options for Azure SQL

Join our [Discord server](http://discord.gg/powersync) if you have any feedback for us.

---

# PowerSync Changelog: November 2025

> You might’ve noticed we skipped the October update – we were heads-down shipping a lot of stuff and a bunch of us attended Sync Conf in San Francisco. Feels like a good problem to have, but we also want to keep you in the loop, so here’s a stacked October+November edition to make up for it!

- Published: 2025-12-04
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-changelog-november-2025

---

You might’ve noticed we skipped the October update – we were heads-down shipping a lot of stuff and a bunch of us attended Sync Conf in San Francisco. Feels like a good problem to have, but we also want to keep you in the loop, so here’s a stacked October+November edition to make up for it!

## Product updates shipped in October and November:

  * **TanStack DB Integration** – [You can now use](https://powersync.com/blog/powersync-tanstack-db-collection) TanStack DB collections on top of a PowerSync-backed SQLite store. This combines TanStack DB’s reactive, super fast in-memory queries and optimistic updates with PowerSync’s offline-first persistence, multi-tab sync, and real-time backend sync with solid conflict resolution. See our feature story below for more.
  * **PowerSync Capacitor SDK (alpha)** – Capacitor projects (iOS, Android, or web) can now use PowerSync. The SDK uses native SQLite on mobile and WA-SQLite on web. That means one codebase for web + mobile for reliable persistence and sync in Capacitor apps. [See the release notes](https://releases.powersync.com/announcements/introducing-our-native-capacitor-sdk).
  * **PowerSync Dashboard revamp** – The new dashboard is live at [dashboard.powersync.com](http://dashboard.powersync.com)! This release is a big step toward improved UI/UX and it now dogfoods the PowerSync Web SDK. This lays the groundwork for self-hosting the dashboard too. Note that we still need to port the current Alerts & Notifications functionality to it. If you need it, please use the legacy dashboard for now. It should be available in the new dashboard soon.
  * **SDK & under-the-hood improvements:**   

    * **For Dart/Flutter** : we shipped improved attachment utilities under `package:powersync_core/attachments/attachments.dart` making file handling more robust, easier to maintain and more consistent with our other SDKs. [Release notes](https://releases.powersync.com/announcements/improved-attachments-utilities-in-the-dart-flutter-sdk).
    * **Support for custom better-sqlite3 forks in the Node.js SDK** , which enables functionality such as database encryption. Note: initialization now requires loading the custom fork via a worker.[ See the docs](https://github.com/powersync-ja/powersync-js/tree/main/packages/node#encryption).
  * **We published several new demos & guides:**   

    * [Using pg_ivm for JOINs in Sync Rules](https://powersync.com/blog/using-pg-ivm-to-enable-joins-in-powersync) – showing how to use the `pg_ivm` Postgres extension to create materialized views with JOINs, then reference them in Sync Rules.
    * [E2EE chat app with PowerSync + Supabase](https://powersync.com/blog/building-an-e2ee-chat-app-with-powersync-supabase) – a full end-to-end encrypted chat example with real-time sync.
    * [Expo Background Tasks + PowerSync](https://powersync.com/blog/keep-background-apps-fresh-with-expo-background-tasks-and-powersync) – a tutorial walking through how to wire up Expo’s BackgroundTask API to keep sync alive when apps are backgrounded.
    * [Server-side Dart backend (Serverpod) + PowerSync integratio](https://docs.powersync.com/integration-guides/serverpod)n – a guide for full-stack Dart/Flutter projects with a Serverpod backend.
    * [Understanding the SQLite Database](https://docs.powersync.com/usage/lifecycle-maintenance/client-database-diagnostics) – a guide for accessing, inspecting, and optimizing PowerSync database files.

## Community feed

  * Conrad from our team [spoke at Sync Conf](https://x.com/sync_conf/status/1988746023838392493) about the landscape of SQLite in the browser – a video of the talk should be available soon!
  * Loper [shared](https://powersync.com/blog/how-we-built-personalized-college-matching-using-sync-ai-and-rag) how they built a personalized college-matching app using PowerSync + AI + RAG for real-time sync and background recommendation updates.
  * Cinapse [explained](https://powersync.com/blog/why-cinapse-moved-away-from-crdts-for-sync) why they moved away from CRDTs for sync and adopted PowerSync.
  * Facilitron [walked us through](https://powersync.com/blog/how-facilitron-migrated-from-atlas-device-sync-to-powersync) their migration from MongoDB Atlas Device Sync to PowerSync – a useful reference for switching sync stacks.
  * Alex Dumouchelle [wrote about](https://powersync.com/blog/speeding-up-electron-apps-with-powersync) speeding up Electron apps by switching to local SQLite with PowerSync.
  * I made the case that combining Supabase + PowerSync is the strongest stack for offline-first apps – [check it out](https://powersync.com/blog/offline-first-apps-made-simple-supabase-powersync).
  * Brandon Boswell launched [Playlist](https://playlist.day/) – a calendar that helps you focus and actually get meaningful things done. Built with PowerSync!
  * We published a new proposal: [Bucket data on object storage](https://github.com/powersync-ja/powersync-service/discussions/376) for higher sync throughput. Please comment on it!
  * `js2702` improved connection‑pool support in [sqlite_async.dart](https://github.com/powersync-ja/sqlite_async.dart/pull/101), `jonkan` and `CrownedPhoenix` contributed to our Swift SDK and `whygee-dev` added TanStack's [useQueries hook](https://github.com/powersync-ja/powersync-js/pull/642) – huge thanks to everyone (several of you being repeat-contributors 🙏)!

## Feature story: TanStack DB PowerSync Collection

TanStack DB is a very cool project – it’s a reactive in-memory store designed for super-fast queries and reactivity in web apps, and it is a good enabler for incremental adoption of sync. When it launched, we noticed people in the community asking for persistence support. Persistence is [difficult](https://github.com/TanStack/db/issues/865) with TanStack DB, and the team have said they won’t be focusing on it for now, so we decided to build a PowerSync integration that _does_ provide persistence. 

The PowerSync TanStack DB Collection brings first-class offline-first persistence and multi-tab sync to TanStack DB, and we compiled some handy bullets to help you understand the benefits:

### What TanStack DB gives you:

  * Fast in-memory queries (client-side IVM)
  * Optimistic and synchronous query operations (synchronous operations are possible even if the underlying data source is async)
  * Powerful query syntax which can be used to query multiple collections (from different sources) easily — think mixing data from SQLite and REST
  * Reactivity and reactivity integrations with (many) popular app frameworks (React, Vue, Svelte, Solid, Angular)

### What PowerSync adds:

  * Offline-first persistence on top of battle-hardened SQLite. The PowerSync collection is currently the only TanStack DB collection that is backed by SQLite.
  * Multi-tab sync: changes made in one tab instantly appear in all other tabs
  * Real-time backend database sync (Postgres/MySQL/MongoDB)
  * Automatic de/serialization between rich JS types and primitive SQLite types

We’re super excited to be partnering with the TanStack DB team, and look forward to future collaborations with them. Up next we want to investigate support for [query driven sync](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync) – this would enable paging for massive synced tables without sacrificing on performance. We’re also working on an [experimental, more lightweight variant](https://github.com/powersync-ja/powersync-js/pull/758) – which we’re calling _PowerSync Lite_ at this stage – which strips out SQLite from the stack. This means that you get these benefits of PowerSync and TanStack DB, but with a much smaller client bundle size and simpler setup (pure JS, no large WASM files, no WASM plugin configuration). We’re obviously [big fans of SQLite](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility#the-principles-guiding-us-sqlite-front-and-center), but we think this could be useful for customers who don’t need persistence.

That’s it for this issue. 

\- Kobie

---

# Re-evaluating our FlutterFlow Integration

> After careful consideration, we are putting further development of our FlutterFlow Library on hold.

- Published: 2025-11-20
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/re-evaluating-our-flutterflow-integration

---

After careful consideration, we are putting further development of our FlutterFlow Library on hold.

### Background

To address the demand for an offline-first solution within the FlutterFlow developer community, we integrated PowerSync via our Flutter SDK. The initial version was developed in close collaboration with users ([example](https://powersync.com/blog/insights-from-production-use-trashblitz)), leveraging FlutterFlow’s Custom Actions for PowerSync data handling.

Following the launch of FlutterFlow Libraries, we quickly released the [PowerSync FlutterFlow Library](https://marketplace.flutterflow.io/item/dm1cuOwYzDv6yQL2QOFb), which drastically simplified the configuration required for PowerSync. We published this library free of charge to maximize adoption.

### Further development put on hold

Unfortunately the integration has a relatively high maintenance burden on our team and we are not seeing sufficient adoption to justify the required time investment. We have therefore decided to pause further development on the FlutterFlow integration and re-evaluate our future plans for FlutterFlow users.

**What’s changing?**

  * We’ve published our last update to the Library, which contains a notice saying that the Library is no longer actively maintained.
  * We’ve delisted our FlutterFlow integration guides from our docs.

**What’s not changing?**

  * We won’t unpublish the Library until we have more clarity on our future plans. This means that you can continue using the Library in your project.
  * We are keeping the #flutterflow channel on our Discord open for the community to use.
  * The integration guide is still accessible using a [direct URL](https://docs.powersync.com/integration-guides/flutterflow-+-powersync).

**Your existing projects continue to work:** You can continue to use the Library in your projects, access the documentation, and receive support from our team via Discord, while we figure out a path forward.

### We remain committed to the Flutter ecosystem

Please note that this decision applies _only_ to the FlutterFlow integration. Our [Flutter SDK](https://docs.powersync.com/client-sdk-references/flutter) remains one of our flagship SDKs, and we are continuing to actively develop and support it.

Feel free to get in touch with us on [Discord](https://discord.gg/powersync) if you have any questions or feedback about this decision.

---

# How Facilitron Migrated from Atlas Device Sync to PowerSync

> Facilitron successfully migrated from Atlas Device Sync to PowerSync in only a few months. Their engineering team, led by Dima Bronin, was kind enough to share their experience so that others who find themselves in the same position could benefit.

- Published: 2025-11-18
- Author: Phillip van der Merwe
- Category: Showcase
- Source: https://powersync.com/blog/how-facilitron-migrated-from-atlas-device-sync-to-powersync

---

When MongoDB announced the [deprecation of Atlas Device Sync and Realm](https://www.mongodb.com/docs/atlas/app-services/sync/device-sync-deprecation/) in September 2024, many teams were affected — some were still just evaluating Atlas Device Sync, some were busy integrating it, and some were already running it in production. If you were in the latter category, you naturally faced the biggest challenge.

Facilitron found themselves in this category. They considered a few options. One was to migrate to an alternative solution recommended by MongoDB: Ditto and PowerSync stood out. Another was to build their own home-brewed sync solution. They even considered whether they really needed sync in the first place. Ultimately, **they successfully migrated to PowerSync in only a few months**. Their engineering team, led by Dima Bronin, was kind enough to share their experience so that others who find themselves in the same position could benefit.

> **Note**
>
> [Facilitron](https://www.facilitron.com/) operates a national marketplace for community use of public spaces—helping school districts and municipalities manage access, scheduling, and policy compliance.

## Facilitron and their Build app

**“Facilitron is the Airbnb for public facilities,”** says Steve Gaylord, a senior engineer who oversaw the migration to PowerSync. He explains that federal law requires that many public facilities be made available for rent, but that it’s often a schlep for both renters and administrators. Facilitron provides a platform for solving that problem, but as Steve continues: “one of the differentiators is we are not just a software company.” 

A key in-person service Facilitron provides is scheduling a team to go on-site and collect data, validate amenities, and capture professional photos for the facility listings. The app that they migrated to PowerSync manages this on-site data collection workflow—part of Facilitron’s operational process for documenting and publishing facilities within its marketplace.

![](https://powersync.com/images/blog/how-facilitron-migrated-from-atlas-device-sync-to-powersync-inline-a0514f8776.png)

The **Facilitron __ app provides a structured way for remote teams to capture facility data, while automatically uploading data to a central database**. “Keep in mind that all of this has to work offline, seamlessly between network states, with teams of 4-5 capturing hundreds of data points each.” says Steve.

Pre-migration app stack for the Build app:

| Stack component | Pre-migration technology |
| --- | --- |
| Backend database (source) | MongoDB Atlas |
| Backend database (sync replica) | MongoDB Atlas |
| Backend sync service | MongoDB Atlas Device Sync |
| Client-side framework | React Native + Expo |
| Client-side database | Realm (Atlas Device Sync SDK) |
  
## Migration Process

### Deciding between alternatives

It was clear that **sync and offline-first functionality were non-negotiables for the Build app**. They considered three options for the migration:

  1. Ditto
  2. PowerSync
  3. A home-brewed solution

“On paper Ditto looked more promising,” says Steve, “but then we started talking to you all and you guys were so great and proactive that it really gave us a sense that you knew what you were doing.”

Dima adds two other important considerations:

  1. “**You guys are open source**.” After their experience with Atlas Device Sync, it was critical for Facilitron to know they could self-host the sync part of the stack.
  2. “**We couldn’t justify the ROI for building something in-house**. There is so much that comes into play with conflict management and conflict resolution that we don’t have the bandwidth to be the experts on.”

### Migration approach and experience

Islajd Meco and Kyr Korota were the two engineers responsible for the migration. Islajd's focus was on the backend side of things and Kyr looked at the frontend.

On the frontend, the plan was to migrate bit-by-bit and validate functionality as they went: “We did it screen by screen to not break the whole system,” says Kyr. Realm is a NoSQL client-side database, whereas PowerSync uses SQLite on the client-side. This required some data types to be migrated. For example, a facility object contained JSON arrays that had to be transformed to their component parts to work well in the relational database setup. “We would migrate data types and audit the data side-by-side,” says Kyr. “We had two versions of the app for this… This was the right approach.”

On the backend, the existing setup made use of two MongoDB databases: a source database and a “sync database” — a replica wired up to the sync engine. They did this for two reasons. The first is that not all data in the source database was relevant to the mobile application and so creating a partial replica simplified the sync implementation. The second is that isolating the sync database provides another layer that can be used for data validation and transformation. 

This turned out to be useful for the migration to PowerSync, which for example requires some data to be denormalized (this is true as of late 2025: support for syncing from incrementally materialized views which would reduce the need for denormalization is currently [in development](https://roadmap.powersync.com/c/112-support-multiple-table-joins-in-sync-rules?&utm_medium=social&utm_source=share)). “Every time we have a new operation in the sync database, we have triggers that normalize the objects and update the source database.” says Islajd. In fact, there were no unexpected backend changes necessary to implement PowerSync: “Everything was the same as with Realm.”

Post-migration app stack for the Build app:

| Stack component | Post-migration technology |
| --- | --- |
| Backend database (source) | MongoDB Atlas |
| Backend database (sync replica) | MongoDB Atlas |
| Backend sync service | PowerSync Service + custom backend API |
| Client-side framework | React Native + Expo |
| Client-side database | SQLite (managed via PowerSync React Native SDK) |
  
### Architecture and data flow with PowerSync

  * PowerSync connects directly to the MongoDB “sync database”, where it reads the change stream to replicate relevant data to the PowerSync Service. This is based on [Sync Rules](https://docs.powersync.com/usage/sync-rules) (and soon, Sync Streams) which declaratively define what data should be replicated and synced to users. 
  * The PowerSync client SDK in the React Native app maintains a WebSocket connection with the PowerSync Service, and streams data in real-time to the client-side where it is persisted in SQLite. 
  * Any client-side mutations are immediately written to the SQLite database and also placed in an upload queue. 
  * Developers define an `uploadData()` function that specifies how client-side mutations should be uploaded to a backend API that applies changes to the MongoDB “sync database”. The PowerSync client SDK automatically invokes the `uploadData()` as needed.
  * The sync database syncs with the source database through database triggers.

![](https://powersync.com/images/blog/how-facilitron-migrated-from-atlas-device-sync-to-powersync-inline-3aecb7ef0c.png)

## Advice for others migrating from Atlas Device Sync

“I would give the typical migration advice for any project,” says Dima. “Start small, do an MVP, make sure you get your foundation set and you understand how the system works.” **Having a PowerSync team available for their engineers to work with has been crucial to their success** : “Sometimes you go into a migration thinking that you can figure it out. It makes a difference to have a contact — don’t discount that.”

---

# Speeding Up Electron Apps With PowerSync

> Electron is one of the most popular cross-platform tools, allowing you to build desktop apps with HTML, CSS, and JavaScript. PowerSync is a sync engine which syncs your backend database with in-app SQLite, allowing for quick and offline-capable apps.

- Published: 2025-11-17
- Author: Alex Dumouchelle (guest author)
- Category: Engineering
- Source: https://powersync.com/blog/speeding-up-electron-apps-with-powersync

---

## Speeding up Electron apps

[Electron](https://www.electronjs.org/) is one of the most popular cross-platform tools, allowing you to build desktop apps with HTML, CSS, and JavaScript. PowerSync is a sync engine which syncs your backend database with in-app SQLite, allowing for quick and offline-capable apps.

If you’re familiar with Electron, you’re likely aware that it has quite an infamous reputation for its performance, package size, and less-than-native feeling depending on your tastes. Apps like Slack, Discord, Spotify, 1Password, and VSCode [among others](https://github.com/electron/apps/tree/main/apps) are all built with the tool. Hundreds of people have written extensive opinion pieces in personal blogs about their Electron horror story or redemption arc. Some claim it’s the worst thing to happen to desktop app development, while others praise the path it created for an easier and cheaper desktop-to-web developer experience.

Take the downsides out of the equation for a second (we’ll get back to them) and we immediately see why so many companies have reached for it to deliver their main app. It _is_ really nice to have a desktop app just work on every operating system, and even a website, all with the same core codebase. No, they will not be as performant as desktop apps made with Swift, Kotlin, or cross-platform toolkits like Qt. But, the benefits of having access to the world of web development for your desktop app are indisputable. The Electron official docs [give their own reasons](https://www.electronjs.org/docs/latest/why-electron) as to why Electron is great for many projects and many bloggers have posted their tips for trying to [keep Electron apps snappy](https://www.johnnyle.io/read/electron-performance).

In performance, PowerSync can help significantly. There’s obviously nothing magic about PowerSync that will remove the Chromium overhead, but using local SQLite can greatly speed up the app and its perceived performance by users, possibly eliminating the “Electron bloat” people often experience. This follows one of the core philosophies of PowerSync — [performance](https://docs.powersync.com/intro/powersync-philosophy#performance). As far as package size, PowerSync of course isn’t going to do anything to help that. If you find this unavoidable trait about Electron particularly annoying, check out newer tools like [Tauri](https://tauri.app/) which greatly reduce the bundle size of desktop apps by using the OS’s native web view (meaning no Chromium bundle included!) 

Let’s see the ins and outs of how PowerSync can power up an Electron app.

## Main process vs renderer process

If you’ve only lived in the typical world of web development, Electron’s Process Model can feel a bit jarring at first glance. However, if you already think in "frontend vs backend", the split maps quite well:

  * **Main process** : the app's _orchestrator_ (Node.js)  

    * Creates browser windows
    * Owns native OS integrations (like file system IO, tray notifications, and the auto-updater)

  * **Renderer process** : the _UI runtime_ (Chromium)  

    * Where you write your UI code (React, Svelte, etc.)
    * Creates a separate one per each window/webview (think tabs)

These two processes, much like a frontend and server, cannot ([or should not](https://www.electronjs.org/docs/latest/tutorial/security#security-is-everyones-responsibility)) _directly_ talk to each other. Rather, you must make an API for them to talk to each other with serializable data. This is called an **IPC Bridge** (Inter-process communication). 

![Diagram: Electron main process and renderer process connected by IPC](https://powersync.com/images/blog/speeding-up-electron-apps-with-powersync-inline-77358aaff5.png "The Electron documentation on their Process Model goes into greater depth on the subject.||landscape")

So, where does PowerSync go, renderer or main? This comes to the heart of this post — it's up to you!

Currently, PowerSync offers SDKs for both [Node.js](https://docs.powersync.com/client-sdk-references/node) and [web clients](https://docs.powersync.com/client-sdk-references/javascript-web), meaning you have _two choices_ for how you can build a local-first Electron app with PowerSync. Notably, the experience between these two implementations is quite different. The SDK you choose will shape how your app handles data sync and offline behavior. Plus, the developer experience between the two will be quite different.

## Comparing the two implementations

### PowerSync in the main process - best for performance-heavy apps

When running a SQLite driver, Node.js will naturally outperform WebAssembly (WASM) in the browser. PowerSync builds on those same drivers, so it inherits the same real-world performance differences. As mentioned in [_Speeding Up PowerSync with Rust_](https://powersync.com/blog/speeding-up-powersync-with-a-sqlite-extension-written-in-rust), SQLite (being a C library) expects a synchronous filesystem in order to run. While browsers do not have this — relying on clever hacks to get SQLite drivers like wa-sqlite to work — the main process gives us access to everything that a Node.js process has, which indeed includes a synchronous filesystem.

Because of this, PowerSync in the main process can take advantage of the high-performance native SQLite driver [better-sqlite3](https://github.com/WiseLibs/better-sqlite3) which uses Node’s native addons to call the C API, leading to a sky-high performance ceiling. 

You might be saying “Better performance means it’s the best choice for me. Why would I not want the absolute fastest performance?” Well, you’re giving up a lot of developer-experience benefits. If you’re using a reactive UI library like React or Vue, you will _not_ be able to use PowerSync’s provided UI hooks. This is because the sync engine is not running in a place where the UI can react to it. Rather, you have to treat the main process as a sort of middle-end that you need to pass your data through to the UI. You are responsible for making your own hooks.

> **Note**
>
> This may not be too hard though, as tools like TanStack Query allowing you to make queries and mutations from any async functions make it very easy to handle asynchronous state in a predictable way. With this, also note that the renderer and main process should only ever talk to each other with asynchronous IPC calls, lest you block the main process ([a cardinal sin of Electron](https://www.electronjs.org/docs/latest/tutorial/performance#3-blocking-the-main-process))

Lastly, if you rely heavily on logic in the main process of your Electron app, you make the road to having a web-only version a bit harder, since you won’t be able to access the main process logic.

### PowerSync in the renderer process - best for a simpler developer experience

While performance may be slower when running PowerSync in the renderer process, doing so can lead to a simpler overall architecture and an easier development experience. Firstly, you can use those handy hooks for Vue, React, and TanStack Query that build right on top of the sync engine. This means you don’t have to think too hard about updating your UI state. Treat these like you would any sort of UI hook.

The second major benefit is code portability. If there’s no app-critical code in the main process (rather than simple window management and startup scripts), then there’s nothing stopping you from deploying your Electron app right on the web. Meaning, you can have one codebase that services both your desktop and online platforms without the need to change significant logic or IO operations from one app to another. This can save thousands of hours of development time, which is why so many companies have apps that look exactly the same on desktop and on the web.

But of course, the performance losses can be quite a large thorn. We mentioned that SQLite requires a synchronous filesystem and that wa-sqlite (the WebAssembly SQLite driver used by the PowerSync web SDK) relies on browser APIs in order to implement a virtual filesystem. Well, this means SQLite isn’t running at native speed. WebAssembly has matured a lot and it is continually getting better, but it still takes quite a hit compared to its native Node.js counterpart.

### The TLDR

**PowerSync in the Main Process -**[**Node.JS SDK**](https://docs.powersync.com/client-sdk-references/node)

  *  _Trickier, but more performant_
  * ✅ Faster query performance due to system-native SQLite driver (via [better-sqlite3](https://github.com/WiseLibs/better-sqlite3))
  * ❌ Requires manual setup of IPC communication to the renderer
  * ❌ No built-in UI for tools like React. You will have to implement this yourself

**PowerSync in the Renderer Process -**[**Web Client SDKs**](https://docs.powersync.com/client-sdk-references/javascript-web)

  *  _Simpler setup - no IPC communication needed_
  * ✅ Use of PowerSync's custom hooks for UI reactivity (React/Vue)
  * ✅ Easy portability of your code from an Electron desktop app to a hosted web app
  * ❌ Uses the slower WASM build of SQLite with the virtual filesystem

## Benchmarking the two implementations

If you’re saying “Well I still don’t really know what I should use.” Or  “Will the performance hit of the web-based engine hurt my app enough that it doesn’t justify the simplicity gains?” We have some hard numbers and best-practices!

For the exact numbers comparing the two strategies, here are some benchmarks I whipped up, inspired by [React Native Performance Comparison](https://powersync.com/blog/react-native-database-performance-comparison).

**Note -** these benchmarks do not yet take into account sync latency, IPC overhead, and other small details that may be noticeable to the user experience. Take note of what your app will be most often (reading, writing, updating, etc)

| Benchmark | Node.js (seconds) | Web- React (seconds) | Node.js Speedup |
| --- | --- | --- | --- |
| 1000 INSERTs | 0.457 | 2.497 | 5.47x |
| 25000 INSERTs in a transaction | 4.799 | 6.796 | 1.42x |
| 100 SELECTs without an index | 4.671 | 7.465 | 1.60x |
| 100 SELECTs on a string comparison | 5.764 | 8.170 | 1.42x |
| 5000 SELECTs using primary key | 5.676 | 7.526 | 1.33x |
| 1000 UPDATEs without an index | 11.589 | 21.390 | 1.85x |
| 25000 UPDATEs using primary key | 11.320 | 13.470 | 1.19x |
| 25000 text UPDATEs using primary key | 10.346 | 13.570 | 1.31x |
| INSERTs from a SELECT | 4.490 | 7.122 | 1.59x |
| DELETE without an index | 4.841 | 6.430 | 1.33x |
| DELETE using primary key | 4.522 | 7.465 | 1.65x |
| A big INSERT after a big DELETE | 13.583 | 13.309 | 0.98x |
| A big DELETE followed by many small INSERTs | 9.862 | 33.232 | 3.37x |
| Clear table | 4.924 | 5.366 | 1.09x |
  
  
If your app is quite simple and you don't have very large query loads, the web-version very well may be good enough. If you’re certain that you need the tippity top of the performance chain, go ahead and use the Node.js SDK, but just be aware of the trickier upfront setup. The easiest path from nothing to Hello World is the web SDK. If you’re on the fence about your options, web is the simplest starting point. 

When you think of your app, keep in mind these factors:

  * The more components, the lower the performance floor
  * Does your app need to be portable from desktop to web?
  * You would typically set up PowerSync to sync more data than what’s needed on the current page to support offline-capability   

    * If Page A needs data 123, and Page B needs data 456, you would typically keep all data “123456” in sync regardless of if the user is on Page A or B
    * Note that for apps that don’t specifically need to work offline,  [Sync Streams](https://docs.powersync.com/usage/sync-streams) (currently in early alpha) will make it easier to dynamically choose what data is synced 
  * You can control what data is synced to the client with [Sync Streams](https://docs.powersync.com/sync/streams/overview)

There is currently an open roadmap item for a [Native Electron SDK](https://roadmap.powersync.com/c/95-native-electron-client-sdk) which may combine the performance benefits of the main process with the ease of the renderer. Start with whatever option you think best suits your app. If you’re not sure, I’d recommend the web SDK to start. If you have any questions, please ask on the PowerSync Discord!

## Video

[Video: Building an offline-first desktop app with Electron and PowerSync](https://www.youtube.com/watch?v=zFlvwbiTWsk)

---

# PowerSync TanStack DB Collection

> Combine PowerSync with TanStack DB for powerful multi-tab and offline-first capabilities.

- Published: 2025-11-12
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/powersync-tanstack-db-collection

---

We're excited to announce the release of `@tanstack/powersync-db-collection`, bringing PowerSync's powerful offline-first and multi-tab capable sync engine to the TanStack DB ecosystem.

## Overview

The PowerSync TanStack DB integration seamlessly bridges PowerSync's SQLite-based sync engine with TanStack DB's reactive query system. This combination enables you to build super fast, offline-capable applications with real-time synchronization across devices and browser tabs.

## What is TanStack DB?

[TanStack DB](https://tanstack.com/db/latest) is a reactive client store that provides:

  * **Blazing Fast In-Memory Queries**: Built on top of [differential dataflow](https://timelydataflow.github.io/differential-dataflow/), TanStack DB's live queries update incrementally (rather than re-running entire queries). This makes queries incredibly fast—usually sub-millisecond—even for complex queries across multiple collections.
  * **Optimistic Updates**: Mutations apply instantly to the local in-memory state, providing immediate user feedback. TanStack DB maintains separate optimistic state that overlays on top of synced data, and automatically rolls back if the server request fails.
  * **Cross-Collection Queries**: Live queries support joins across collections, allowing you to load normalized data and then denormalize it through queries. TanStack DB collections can have their data sourced from multiple sources—REST endpoints, sync engines (like PowerSync or ElectricSQL), local storage, or in-memory state—and developers can seamlessly join and query data from these different sources. This simplifies your backend by avoiding the need for bespoke API endpoints and enables powerful data combinations regardless of where the data originates.
  * **Reactive Data Flow**: Live queries automatically update when underlying data changes, triggering component re-renders only when necessary. This creates a smooth, responsive user experience.

## What This Package Adds

This integration brings PowerSync's battle-tested offline and multi-tab capable sync engine to TanStack DB, combining the best of both worlds:

### Offline-First Persistence

All data is stored locally in PowerSync's SQLite database, allowing your application to work completely offline. Changes are queued and automatically synchronized when connectivity is restored.

### Multi-Tab Synchronization

PowerSync collections automatically synchronize data across browser tabs in real-time, ensuring all tabs stay in sync without manual intervention.

### Real-Time Backend Sync

When connected to a PowerSync backend, changes are automatically synchronized in real-time across all connected clients. The sync process handles:

  * Bi-directional sync with Postgres, MongoDB, and MySQL backends
  * Automatic conflict resolution
  * Queue management for offline changes
  * Automatic retries on connection loss

### Type-Safe Rich Types

PowerSync collections support rich JavaScript types like Date, Boolean, and custom objects while maintaining SQLite compatibility. The collection handles serialization and deserialization automatically, so you can work with native JavaScript types in your application code while PowerSync handles the SQLite storage.

### Optimistic Updates with Rollback

Updates to the collection are applied optimistically to the local in-memory state first, then synchronized with PowerSync and the backend. If an error occurs during sync, the changes are automatically rolled back, maintaining data consistency.

## Key Features

### Automatic Data Mirroring

Collections automatically mirror the state of an underlying PowerSync SQLite table. When data changes in SQLite, the collection updates reactively. When you mutate the collection, changes are persisted to SQLite.

### Schema Validation

Collections support schema validation using Standard Schema-compatible schemas (like Zod or Effect). This provides client-side validation of mutations and rich type transformations.

### Flexible Type System

You can work with SQLite types directly, add validation constraints, transform SQLite types to rich JavaScript types, or completely decouple input/output types from SQLite types. The collection handles all the serialization complexity for you.

### Advanced Transaction Support

For complex scenarios, you can use PowerSync's transaction system directly with TanStack DB transactions, allowing you to batch multiple operations and control transaction lifecycle.

## Example Usage

```typescript
import { createCollection, eq, useLiveQuery } from "@tanstack/react-db"
import { powerSyncCollectionOptions } from "@tanstack/powersync-db-collection"
import { PowerSyncDatabase, Schema, Table, column } from "@powersync/web"

// Define PowerSync schema
const APP_SCHEMA = new Schema({
  documents: new Table({
    name: column.text,
    author: column.text,
    created_at: column.text,
    archived: column.integer,
  }),
})

// Initialize PowerSync database
const db = new PowerSyncDatabase({
  database: { dbFilename: "app.sqlite" },
  schema: APP_SCHEMA,
})

// Create TanStack DB collection
const documentsCollection = createCollection(
  powerSyncCollectionOptions({
    database: db,
    table: APP_SCHEMA.props.documents,
  })
)

// Use in your components with live queries
const { data: documents } = useLiveQuery((q) =>
  q.from({ doc: documentsCollection }).where(({ doc }) => eq(doc.archived, 0))
)

// Mutations apply optimistically and sync automatically (mutations require an implementation of `PowerSyncBackendConnector` for the write path)

documentsCollection.insert({
  id: crypto.randomUUID(),
  name: "New Document",
  author: "John Doe",
  created_at: new Date().toISOString(),
  archived: 0,
})
```
## Installation

```bash
npm install @tanstack/powersync-db-collection @powersync/web @journeyapps/wa-sqlite
```
## Framework Support

The PowerSync collection works with all TanStack DB framework adapters:

  * React (`@tanstack/react-db`)
  * Vue (`@tanstack/vue-db`)
  * Solid (`@tanstack/solid-db`)
  * Svelte (`@tanstack/svelte-db`)
  * Angular (`@tanstack/angular-db`)

## Learn More

For detailed documentation, examples, and API reference, see:

  * [PowerSync Collection Documentation](https://tanstack.com/db/latest/docs/collections/powersync-collection)
  * [TanStack DB Overview](https://tanstack.com/db/)
  * [PowerSync Documentation](https://docs.powersync.com)

## What's Next?

This is just the beginning. We're excited to see what you build with this powerful combination of offline-first sync and reactive queries. Join us on Discord or GitHub to share your experiences and feedback!

---

# The Current State Of SQLite Persistence On The Web: May 2026 Update

> SQLite is the most widely deployed database in the world. Recently, it has also become a viable option for data persistence in browser-based applications.

- Published: 2025-11-11
- Updated: 2026-05-15
- Author: Ralf Kistner
- Category: Engineering
- Source: https://powersync.com/blog/sqlite-persistence-on-the-web

---

This post is intended to be a comprehensive view of the SQLite persistence in web browsers landscape. See the changelog at the end of this post for updates made since the original publication, and please [contact us](https://powersync.com/contact) if you notice something wrong.

This post has been summarized in a talk at Sync Conf 2025 - watch the video [here](https://www.youtube.com/watch?v=7yNG1aj7-Aw).

## Background

SQLite is the [most widely deployed](https://www.sqlite.org/mostdeployed.html) database globally. Recently, it is also becoming an option for data persistence in browser-based applications.

There are a couple of projects bringing SQLite to web browsers:

  1. [**SQL.js**](https://sql.js.org/) has been around since 2014 — initially cross-compiling SQLite to JavaScript, then [Wasm](https://webassembly.org/) (WebAssembly) when browsers started supporting it. By itself, SQL.js only supports in-memory databases, and does not support persistence other than importing or exporting the entire database file at a time.
  2. In 2021, the [**wa-sqlite**](https://github.com/rhashimoto/wa-sqlite) project was created, implementing experimental support for persisting SQLite data in IndexedDB. The performance was quite slow at this point.
  3. Later in 2021, the [**absurd-sql**](https://github.com/jlongster/absurd-sql) project did the same, but using a couple of new techniques to achieve much faster performance — even surpassing direct IndexedDB performance for some query patterns. The [accompanying blog post](https://jlongster.com/future-sql-web) has a lot of details on the complexities of the implementation. While it was a great showcase of what can be done, it was never maintained as a project to be used in production. The wa-sqlite project built further on some of these ideas.
  4. Towards the end of 2022, the **official SQLite** project released their own [beta Wasm build](https://sqlite.org/releaselog/3_40_0.html).

> **Note**
>
> Side note: there was also the [Web SQL](https://nolanlawson.com/2014/04/26/web-sql-database-in-memoriam/) project which used to be built-in to Chrome and older versions of Safari (it never made it into Firefox). It had too many limitations and difficulties to be a cross-browser standard, and is now deprecated. For that reason, we’re not exploring it any further in this post.

While none of these projects currently claim “production level stability” for persistence, we have found that the current support is already sufficient for certain use cases. That being said, there are many options to choose from, and it may not be immediately clear what the pros and cons are.

This post gives an overview on the different considerations that go into persisting SQLite data in a web browser, with details on what the current implementations do. If you only want to know what to use right now, skip to the recommendations at the end of the post.

### Concurrency in SQLite

SQLite supports concurrent access to a single database file, by utilizing multiple “connections” to a file. Concurrency should not be confused with thread-safety: A single connection can be “safe” to use from different native threads (depending on compile options used), but it serializes statements and can never execute more than one transaction at a time.

To execute multiple transactions concurrently, multiple connections can be used. Each connection operates independently and uses locking via the file system, so the effect is the same whether connections are used from different threads or different processes on the same machine.

By default, SQLite uses a rollback journal ([DELETE, TRUNCATE or PERSIST modes](https://www.sqlite.org/pragma.html#pragma_journal_mode)) to protect against corruption, and supports rolling back transactions. Only a single transaction can modify the rollback journal at a time, which means that only a single write transaction can execute at a time. Any other transactions that attempt to write at the same time will fail with `SQLITE_BUSY`. Additionally, no read transactions can be performed while a write transaction is active. The[ official documentation](https://www.sqlite.org/lockingv3.html) has more details. 

When using the [WAL](https://www.sqlite.org/wal.html) journal mode instead, the concurrency restrictions are relaxed somewhat: read transactions can be executed concurrently with a single write transaction.
This works by appending changes to a log file, readers can consult that log (up to the offset active when the read transaction was started) without conflicts.
To avoid unbounded growth of that file, SQLite runs a checkpoint operation moving log entries back to the main database file. Writes block checkpoints, and slow readers may interrupt them.
An experimental WAL2 mode uses two WAL files to avoid that problem, but since this is on a separate SQLite branch, we won’t cover that here.

Finally, there's a prototype experimenting with concurrent writes as part of the [HC-tree project](https://sqlite.org/hctree/doc/hctree/doc/hctree/index.html),
which we also won't cover here.

### Persistence on web

SQLite has a [VFS interface](https://www.sqlite.org/vfs.html) which can be used to implement a file system on any system. Generally, the implementation must provide methods to write a block of data, read a block of data, flush data to the file system, and lock files, in addition to other more advanced methods.

For the underlying storage, there are two primary options in web browsers:

  1. [OPFS](https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system) (origin private file system). This API gives random access to files, private to the origin of the page. In principle, this API is ideal for databases like SQLite, but the APIs currently available do still have some limitations, covered in this post.
  2. [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API). This is a more general-purpose database for browsers. It can be used as a storage layer for SQLite by storing individual blocks of data as IndexedDB objects.

Other options such as `localStorage` are too restrictive, so we won’t cover that here.

### Asynchronous calls

SQLite, being a C-based library, makes use of synchronous operations. This is still the case when compiling to Wasm, which means that VFS implementations in JavaScript must also be synchronous. This is a problem in the JavaScript world, where file system operations are typically asynchronous.

There are various workarounds involved in dealing with this:

#### Emscripten Asyncify

[Asyncify](https://emscripten.org/docs/porting/asyncify.html) translates the synchronous calls into asynchronous calls, allowing the VFS implementation to be asynchronous. There are several downsides:

  1. The built Wasm file size increases by around 2x.
  2. Performance can be reduced by 2-5x.
  3. The behavior of SQLite may be affected by the transforms in Asyncify, and this build is not as well tested. Any bugs in Asyncify could cause subtle issues in the SQLite build. The SQLite team [does not use it](https://news.ycombinator.com/item?id=38827760) for this reason.

#### SharedArrayBuffer + Atomics API

The basic idea is described [here](https://jlongster.com/future-sql-web#the-big-problem-sync-apis). This approach requires running a separate Worker process for the file system operations. It also places additional restrictions on the web origin to allow [safe usage](https://web.dev/articles/why-coop-coep) of `SharedArrayBuffer`. The COOP and COEP headers required are explained [here](https://sqlite.org/wasm/doc/trunk/persistence.md#coop-coep).

Additionally, significant overhead is added wherever this mechanism is used.

#### JavaScript Promise Integration (JSPI)

The new WebAssembly [JavaScript Promise Integration](https://v8.dev/blog/jspi) (JSPI) gives functionality similar to Asyncify, but as a core browser feature and with better performance. JSPI has been [available](https://webassembly.org/features/) in Chrome without a feature flag since version 137 (May 2025), and is available in Firefox _with a feature flag_ since version 131 (October 2024). In recent Safari Technology Preview builds, JSPI is available as well.
Maturing JSPI support is a [focus area](https://web.dev/blog/interop-2026#jspi_for_wasm) for major browser makers in 2026.

#### `SQLITE_BUSY` hacks

The wa-sqlite project invented a clever approach exploiting SQLite's ability to recover from file system errors automatically. In a synchronous SQLite build,
the VFS implementation can return a `SQLITE_BUSY` error code. SQLite recognizes this error code and forwards it to the calling application without
terminating active statements.

In wa-sqlite, a VFS saves a JavaScript promise before returning `SQLITE_BUSY`, then catches the error at the outer statement layer, awaits the
promise, and finally retries the operation.
This is substantially faster than Asyncify builds, but can cause issues with native SQLite extensions unaware of this retry logic.

#### OPFS FileSystemSyncAccessHandle

The File System API allows [obtaining](https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle/createSyncAccessHandle) a `FileSystemSyncAccessHandle` using `createSyncAccessHandle()` within dedicated Workers that provides synchronous read and write access to files within the OPFS. The latest versions of Chrome, Safari and Firefox all support this.

There are some caveats:

  1. While operations on an open file are synchronous [^1], opening a file is still an asynchronous operation. This requires either pre-opening all files that could be used, combining with the `SharedArrayBuffer` + Atomics API workaround above, or using a retry mechanism ([see above](#sqlite_busy-hacks)).
  2. By default, opening a file takes out an exclusive lock, meaning no other connection can read or write the same file at the same time. If files are pre-opened and kept open for the duration of the connection, it means only a single connection can be used.

Based on a WHATWG [proposal](https://github.com/whatwg/fs/blob/main/proposals/MultipleReadersWriters.md) in 2023, a `mode` argument for `createSyncAccessHandle()` is being introduced, with `readwrite-unsafe` mode allowing for multiple concurrent readers and writers. The `readwrite-unsafe` mode is available in Chrome 121+, but is [not yet supported](https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle/createSyncAccessHandle#browser_compatibility) by Firefox or Safari.

#### Obtaining file access handles in JavaScript

Obtaining file access handles remains asynchronous, even with OPFS `createSyncAccessHandle()`. One class of workarounds involve opening the file handles and/or locks in a JavaScript layer, outside Wasm. `OPFSCoopSyncVFS` in the wa-sqlite project is one example of this.

### Concurrency on the web

Concurrency for SQLite on the web generally has the same restrictions as on other platforms: Each connection can run one transaction at a time. Browsers do not provide direct support for multi-threading, including in Wasm, but multiple web workers can be used to get a similar effect.

Concurrent transactions may be supported over multiple tabs or within a tab, by utilizing multiple SQLite connections. However, some VFS implementations require an exclusive lock on the database and only support having a single connection open at a time, in which case concurrent transactions are not supported at all. The single connection has to be shared between any active tabs. Other VFS implementations allow multiple concurrent connections, but only a single concurrent transaction. And others do allow multiple concurrent read transactions, as long as no write transaction is active.
As of April 2026, there's also a VFS that supports read transactions concurrently with write transactions.

### Performance tweaks

Performance in SQLite is tightly related to how the file system operations are implemented.

There are a couple of ways to get better performance — either in the file system layer, or in higher-level configuration.

#### Batch-atomic write transactions

By default, SQLite assumes that a sequence of writes to a file may be interrupted at any point in time, due to e.g. operating system crash or power loss. The rollback journal is used to allow recovery after a crash.

However, some file systems can guarantee that a batch of write operations will all either succeed or all fail — typically by implementing a journal mode as part of the file system itself. SQLite can exploit this behavior when available, avoiding the need for a rollback journal in many (but not all) cases. It still keeps a rollback journal in memory, and may need to persist it to a file if it grows too large. On the web, IndexedDB can be used to provide the same guarantees, which then gives some nice performance improvements.

Unfortunately, even though this could in theory also provide similar concurrency to WAL mode, SQLite does not support that at the moment. Some discussion around this can be seen [here](https://github.com/rhashimoto/wa-sqlite/discussions/78).

#### Exclusive locking

The database can be locked in[ exclusive mode](https://www.sqlite.org/pragma.html#pragma_locking_mode), only allowing a single connection to access the database as long as it is open. This reduces the number of locks needed for transactions, and can significantly speed up writes. This is configured using `PRAGMA locking_mode = EXCLUSIVE`.

The caveat is that concurrent read transactions are not possible in this mode. But when the file system implementation only allows a single connection at a time anyway (like a couple of the options below), this is not an issue.

#### Relaxed durability

By default, SQLite only acknowledges a transaction when it is safely persisted to the underlying storage. In other words, even an operating system crash or power failure should not lose the transaction.

It also offers relaxed durability, where acknowledged transactions may not be persisted if the operating system crashes, but is safe if the application crashes. This is configured using `PRAGMA synchronous = NORMAL`. There is a further mode of `PRAGMA synchronous = OFF`, which does not wait for the file system at all, but may cause database corruption if the operating system crashes.

Some VFS implementations may provide additional relaxed durability options specific to the storage layer.

When combining exclusive locking with `synchronous = OFF` (or an equivalent durability option in the VFS), write transactions may occur without waiting for the file system at all, which can result in a[ much higher](https://github.com/rhashimoto/wa-sqlite/discussions/81#discussioncomment-5675533) number of transactions per second. Throughput within a large transaction is not expected to change much with this.

### File system transparency

When using OPFS, files can be stored “transparently”, meaning the persistence format is exactly the same as what SQLite traditionally uses, with no workarounds or additional metadata required. This has the advantage of interoperability between different implementations — it may be possible to switch out libraries completely, without losing data already persisted.

### Higher-level libraries

The implementations mentioned here are generally low-level — SQLite APIs are exposed directly. A typical application would ideally use a library that manages transactions, locking, connection pooling (optional), web workers (if applicable), and provides higher-level APIs for querying and persisting data.

At PowerSync we provide wrapper libraries to support both Kysely (a type-safe query builder) and Drizzle (a more full-featured ORM) on top of wa-sqlite. Currently this requires using the full PowerSync SDK. There are also some community-maintained libraries:

  * [SQLocal](https://sqlocal.dev/) \- supports Drizzle and Kysely on top of sqlite-wasm.
  * [kysely-sqlite-tools](https://github.com/subframe7536/kysely-sqlite-tools) \- supports Kysely on top of wa-sqlite.

### Encryption support

SQLite supports at-rest encryption using optional extensions.

The commercial [SQLite Encryption Extension](https://sqlite.org/com/see.html) (SSE) supports building for sqlite-wasm.

Alternatively, the community-based [SQLite3 Multiple Ciphers](https://github.com/utelle/SQLite3MultipleCiphers) has instructions for WebAssembly builds, working on both sqlite-wasm and wa-sqlite. Both options may require manually building the Wasm builds, and for wa-sqlite some changes to the build scripts may be required. PowerSync includes a build with SQLite3 Multiple Ciphers in its Web SDK, but this is not designed for standalone use outside PowerSync at the moment.

[SQLCipher](https://github.com/sqlcipher/sqlcipher) does not appear to officially support Wasm builds at this point.

## Implementations

### wa-sqlite

wa-sqlite provides a Wasm build of SQLite — both synchronous and Asyncify versions. It also provides a couple of examples and various VFS [implementations](https://github.com/rhashimoto/wa-sqlite/blob/master/src/examples/README.md). Only the higher-performing persistent VFS implementations are compared here.

These VFS implementations are intended as examples rather than production-ready code, but we have found they perform well in practice. 

#### IDBBatchAtomicVFS

Persists versioned blocks of file data to IndexedDB. Can execute either in a worker process or the main page.

It uses batch-atomic write transactions to get very good write performance, despite the additional IndexedDB layer sitting between SQLite and the underlying file system.

Needs the Asyncify or JSPI build. Restricted to a single transaction at a time by default, but[ can be configured](https://github.com/rhashimoto/wa-sqlite/issues/5) to support concurrent read transactions.

This VFS can be configured with `PRAGMA synchronous=NORMAL` to reduce overhead per write transaction.

#### OPFSAdaptiveVFS (similar to the previous OriginPrivateFileSystemVFS)

Persists files directly as files in OPFS. Uses asynchronous open and read operations, and synchronous access handles for write operations.

Needs the Asyncify or JSPI build. Restricted to a single transaction at a time by default, but[ can be configured](https://github.com/rhashimoto/wa-sqlite/issues/5) to support concurrent read transactions. However, there are[ potential issues](https://github.com/rhashimoto/wa-sqlite/issues/68) when writing from different connections. On Chrome, the `readwrite-unsafe` mode can be used for real concurrent reads.

This VFS has[ file system transparency](https://github.com/rhashimoto/wa-sqlite/discussions/99), making it compatible with sqlite-wasm.

### OPFSCoopSyncVFS

`OPFSCoopSyncVFS` is similar to `AccessHandlePoolVFS` in that it uses synchronous access handles, but it supports multiple concurrent connections, and has file system transparency.

`OPFSCoopSyncVFS` uses a workaround in that when a new access handle is needed, the VFS [raises a `SQLITE_BUSY` error](#sqlite_busy-hacks) while queuing the operation. On the JavaScript side, when the `SQLITE_BUSY` error is observed, it waits for the asynchronous operations to open the file, then retries the SQLite operation.

Note that this approach is only required for opening access handles and locks — the actual reads and writes are synchronous, giving good performance overall.

One caveat here is that transactions spanning multiple databases are not supported.

`OPFSCoopSyncVFS` currently supports multiple concurrent connections, but not concurrent transactions — each transaction uses an exclusive lock. Improved concurrency may be supported in the future.

#### AccessHandlePoolVFS

This implementation pre-opens a number of files, so that they can be accessed synchronously in the VFS, thereby not requiring Asyncify. This means there is a pre-configured limit on the number of databases that can be opened without re-instantiating the connection, but that should not be an issue for most applications.

The persisted files use auto-generated names, each with a header containing the original filename. This makes the storage format incompatible with other implementations. There are [some ideas](https://github.com/rhashimoto/wa-sqlite/discussions/99) for getting file system transparency in the future.

Since a sync access handle locks a file exclusively, concurrent transactions are not possible. And more than that — only a single connection can be opened to a file at a time. This means that accessing the same database from multiple tabs needs additional coordination, by opening `MessageChannel`s to a single worker process. Since the worker is associated with a single tab, some care is required to spawn a new worker when that tab closes. Issues may also arise if a page and associated worker is closed in the middle of a transaction — the application will need to be able to handle transactions failing.

> Note: Unfortunately SharedWorker cannot be used for accessing the same database from multiple tabs, since OPFS sync access handles are [not available](https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system) in SharedWorker or ServiceWorker.

#### OPFSWriteAheadVFS

Added to wa-sqlite in April 2026, OPFSWriteAheadVFS is a new VFS with support for reads running concurrently. It relies on the `readwrite-unsafe` access mode currently
only available in Chrome.
This VFS implements something similar to [WAL mode](https://sqlite.org/wal.html) on a filesystem level. SQLite uses its regular journaling mechanism, but the VFS will:

1. Append writes to an internal write-ahead log instead of writing to OPFS directly.
2. When a read transaction starts, treat the write-ahead log until the current position as an overlay to the main database.

This allows multiple concurrent reads, both across tabs and within a single tab (by spawning multiple workers managing database connections).
This VFS comes with some usage restrictions though:

1. Write transactions must use `BEGIN IMMEDIATE`, allowing the VFS to acquire locks and to prepare writing to the WAL.
2. Running `VACUUM` statements requires `PRAGMA locking_mode = EXCLUSIVE`.
3. By default, the VFS offers weak durability guarantees for faster performance (recent transactions could be lost on crashes). Using `PRAGMA synchronous` restores full durability at the cost of reduced write performance.

The VFS offers configuration options to fine-tune database performance, see [its announcement](https://github.com/rhashimoto/wa-sqlite/discussions/315) for details.

PowerSync collaborated with Roy Hashimoto of wa-sqlite to develop this VFS.

### sqlite-wasm

As of late 2022, SQLite has an official Wasm build. Only a synchronous build is supported. The following VFS options are available:

#### opfs

The[ OPFS-based VFS](https://sqlite.org/wasm/doc/trunk/persistence.md#vfs-opfs) uses sync access handles for read and write operations. Multiple connections can be open concurrently, but only a single read or write transaction can be open at a time.

Additionally, since opening a file handle is an asynchronous operation, the `SharedArrayBuffer` + Atomics workaround is used to make the operation synchronous. This means COOP and COEP headers are [required](https://sqlite.org/wasm/doc/trunk/persistence.md#coop-coep) (to use `SharedArrayBuffer`).

It may be possible to support concurrent access in the future by using sync access handle modes.

This VFS does have file system transparency, making it interoperable with wa-sqlite’s OPFS VFS.

There is also another option using[ Emscripten’s WasmFS](https://sqlite.org/wasm/doc/trunk/persistence.md#opfs-wasmfs). It uses similar mechanisms, but has additional restrictions, so I would not recommend it over the OPFS VFS.

#### opfs-sahpool

The [OPFS SyncAccessHandle Pool VFS](https://sqlite.org/wasm/doc/trunk/persistence.md#vfs-opfs-sahpool) (`opfs-sahpool`) has been released in SQLite 3.43.0. It uses the same ideas as wa-sqlite’s `AccessHandlePoolVFS`, avoiding the need for the `SharedArrayBuffer` + Atomics workaround, and getting much better performance. This VFS requires an exclusive database lock, and only a single connection can be open at a time [^3].

#### absurd-sql

The [absurd-sql](https://github.com/jlongster/absurd-sql) project uses a synchronous SQLite build, with the `SharedArrayBuffer` + Atomics workaround to expose the IndexedDB operations as a synchronous VFS.

This project is not actively maintained, and only included as a reference.

## VFS Summary Table

In the table below, “concurrent connections” means multiple connections can be open at the same time, but only a single transaction can be active at a time. “Concurrent reads” means that multiple read transactions can be open at the same time, as long as no write transaction is open. May require[ additional configuration and application-level locking](https://github.com/rhashimoto/wa-sqlite/issues/5). Supported versions of browsers haven’t been tested as part of this post. It may be inaccurate, especially for the older version ranges.

| Implementation | Storage | Asyncify or JSPI required? | In main page? | In web worker? | Concurrency | File system transparency? | Needs COOP and COEP headers? | Chrome | Safari | Firefox |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| sqlite-wasm - `opfs` | OPFS | No | No | Yes | Concurrent connections | Yes | Yes | 102+ | 17+ | 111+ |
| sqlite-wasm - `opfs-sahpool` | OPFS | No | No | Yes | No | No | No | 108+ | 16.4+ | 111+ |
| wa-sqlite - `IDBBatchAtomicVFS` | IndexedDB | Yes | Yes | Yes | Concurrent reads | No | No | 69+ | 15.4+ | 96+ |
| wa-sqlite - `OPFSAdaptiveVFS` | OPFS | Yes | No | Yes | Concurrent reads | Yes | No | 102+ | 15.4+ | 111+ |
| wa-sqlite - `AccessHandlePoolVFS` | OPFS | No | No | Yes | No | No | No | 108+ | 16.4+ | 111+ |
| wa-sqlite - `OPFSCoopSyncVFS` | OPFS | No | No | Yes | Concurrent connections | Yes | No | 108+ | 16.4+ | 111+ |
| wa-sqlite - `OPFSWriteAheadVFS` | OPFS  | No | No | Yes | Concurrent write + reads | No | No | 121+ | - | - |
| sql.js - `absurd-sql` | IndexedDB | No | No | Yes | Not confirmed | No | Yes | 91+ | 15.2+ | 79+ |
  
### Recommendations

As of 2025, wa-sqlite’s `OPFSCoopSyncVFS` is a good general-purpose VFS that has excellent performance, even with large databases, and works on recent versions of all major browsers. The increased performance makes up for the lack of concurrency support.

For read-heavy workloads that benefit from parallel reads, the design of `OPFSWriteAheadVFS` is an excellent fit. Since it is a new VFS, we don't have as much experience we could share with it though.

If support for older browser versions is required, wa-sqlite’s `IDBBatchAtomicVFS` is a good fallback option.

The SQLite Wasm OPFS build is also an option with good performance and with file system transparency. I would not recommend it over the wa-sqlite builds yet due to the restrictions around COOP and COEP headers.

### Real-world experience

We’ve supported both wa-sqlite’s `OPFSCoopSyncVFS` and `IDBBatchAtomicVFS` in the PowerSync client SDKs since early 2025. We’ve found both work really well for most use cases, with some things standing out:

  1. `IDBBatchAtomicVFS` works well for small databases, but performance degrades with larger databases (100MB+). `OPFSCoopSyncVFS` keeps performing well even for databases over 1GB in size.
  2. We’ve observed some `RangeError: Maximum call stack size exceeded` errors on Safari on `IDBBatchAtomicVFS` with large queries. `OPFSCoopSyncVFS` does not have the same issue.
  3. Incognito mode on Safari does not support OPFS. `IDBBatchAtomicVFS` is a good fallback for that.
  4. Incognito mode on Chrome introduces a 100MB database size limit, with unexpected errors when this limit is reached.
  5. The behavior of `OPFSCoopSyncVFS` throwing `SQLITE_BUSY` errors in the middle of transactions can introduce some additional complexity in certain cases. In PowerSync, we implement complex operations in a [SQLite extension](https://github.com/powersync-ja/powersync-sqlite-core), so we had to ensure that the extension can handle these errors. However, most applications using standard SQLite operations should not run into these issues.
  6. `OPFSCoopSyncVFS` requires using dedicated workers. Shared web workers unfortunately do not support OPFS at this point. At PowerSync we use one dedicated database worker at a time, with cross-tab messaging to the worker. This introduces some complexity and edge cases. Firefox supports spawning dedicated workers from shared workers, but Chrome and Safari do not support that at this point.   

     1. On Chrome and Edge, tabs can be “suspended” after a period of inactivity. If a tab’s database worker is shared with other tabs, it will become inaccessible, causing queries to stop responding. We worked around this by keeping a Web Lock open on the worker, which prevents the tab from being suspended.
  7. On Ionic Capacitor, access handles in `OPFSCoopSyncVFS` can be closed when the app is in the background, causing errors when resuming the application. A workaround is to use native SQLite or `IDBBatchAtomicVFS`.

## Acknowledgements

A special thanks to [Roy Hashimoto](https://github.com/rhashimoto), the author of wa-sqlite, for providing many corrections and additional details for this post. Thanks also to [Stephan Beal](https://github.com/sgbeal) for reaching out about clarifications and updates.

## Changelog

### 2026-05-15

Updated the post to mention [`OPFSWriteAheadVFS`](https://github.com/rhashimoto/wa-sqlite/discussions/315), the first VFS to support reads in parallel to a writer.

### 2025-11-11

Updated the post with new wa-sqlite VFS implementations, improved browser JSPI support, and some real-world experience at PowerSync. Added a section on at-rest encryption support.

On the browser side:

  1. JSPI does not require a feature flag anymore as of Chrome 137, and now has similar performance to Asyncify.   

     1. On Firefox it is still behind a feature flag, and slower than Asyncify.
     2. No support on Safari yet, although there is [indication](https://github.com/WebKit/standards-positions/issues/422) that Safari may support JSPI in the future.
  2. wa-sqlite reached 1.0 in July 2024, with new VFS implementations.   

     1. It now supports some concurrency using the `readwrite-unsafe` mode with `OPFSPermutedVFS` or `OPFSAdaptiveVFS` (replaces `OriginPrivateFileSystemVFS`)
     2. In version 1.0.0, `IDBBatchAtomicVFS` has been rewritten, although it still uses the same principles. It no longer has a `durability` option, instead using the standard `PRAGMA synchronous` option to configure durability.

### 2024-02-14

Updated the post to better cover the difference between support for concurrent connections, concurrent transactions, or no concurrency.

### 2024-02-08

Since this post was first published on 2023-07-19, there have been some updates in the landscape.

On the browser side:

  1. The OPFS `readwrite-unsafe` mode has [landed](https://chromestatus.com/feature/5172892632875008) in Chrome 121. This allows concurrent access to the same file.
  2. WebAssembly JavaScript Promise Integration (JSPI) is a proposal to remove the need for Asyncify. This is currently available as a [flag](https://v8.dev/blog/jspi#how-can-i-use-it-today%3F) in Chrome, and Firefox support is [planned](https://bugzilla.mozilla.org/show_bug.cgi?id=1850627). Unfortunately the current version is [much slower](https://bugs.chromium.org/p/chromium/issues/detail?id=1518374&q=&can=4) in Chrome than Asyncify, and tab crashes are still common.

In the official sqlite3 Wasm build, the `opfs-sahpool` VFS has been released in SQLite 3.43.0.

In wa-sqlite, a rewrite of the current VFS implementations is in progress, which can use the above browser functionality when available:

  1. `IDBBatchAtomicVFS` can now use JSPI instead of Asyncify.
  2. `OriginPrivateVFS` replaces `OriginPrivateFileSystemVFS`, and can support concurrent reads via the `readwrite-unsafe` mode. This still uses the asynchronous OPFS APIs, so performance is not expected to be great.
  3. `AccessHandlePoolVFS` is rewritten to have file system transparency, and support concurrent reads via readwrite-unsafe. This requires pre-creating the database files from the database — it is not possible to just `ATTACH` to new databases at runtime, but that is not a feature that many web applications would require. This VFS does not require Asyncify or JSPI.

Details on the new VFS implementations are [here](https://github.com/rhashimoto/wa-sqlite/discussions/153).

With file system transparency and concurrent read support, the new `AccessHandlePoolVFS` should be a great default choice for most web apps.

There is still no web VFS that supports WAL mode. There is one [experimental VFS](https://github.com/rhashimoto/wa-sqlite/discussions/116) in wa-sqlite that implements similar ideas on the JavaScript side, supporting concurrent reads while writing. This is a space to watch.

In the ORM space, there are now some options for using higher-level APIs:

  1. [SQLocal](https://sqlocal.dallashoffman.com/) provides [Kysely](https://kysely.dev/) and [Drizzle](https://orm.drizzle.team/) wrappers for the official sqlite3 Wasm build.
  2. [Another project](https://github.com/subframe7536/kysely-sqlite-tools) provides Kysely dialects for both sqlite3 Wasm and wa-sqlite.

The summary table has been updated to reflect these new options.

### 2023-07-19

Initial publication date.

[^1]: There was a stage when the `close`, `flush` and `truncate` methods were asynchronous. In the current version of the spec, these methods are all synchronous.
[^2]: It is technically possible to use WAL mode on the web by using an [exclusive locking mode](https://sqlite.org/wal.html#use_of_wal_without_shared_memory). Since it negates any concurrency benefits, this has limited use cases.
[^3]: The opfs-sahpool VFS may be [“paused”](https://sqlite.org/wasm/doc/trunk/persistence.md#vfs-opfs-sahpool-concurrency) to release the lock for other connections, but this requires manual management.

---

# Introducing the PowerSync Capacitor SDK

> The release of the PowerSync Capacitor SDK brings native SQLite performance to Capacitor applications on iOS and Android while maintaining seamless compatibility with web platforms.

- Published: 2025-11-03
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/introducing-the-powersync-capacitor-sdk

---

We're excited to announce the release of the PowerSync Capacitor SDK, bringing native SQLite performance to Capacitor applications on iOS and Android while maintaining seamless compatibility with web platforms.

The PowerSync Capacitor SDK extends our Web SDK to automatically use native SQLite implementations when your app runs on mobile platforms. This means you can write your code once and get:

  * Native SQLite on iOS and Android via the Capacitor Community SQLite plugin
  * WA-SQLite on web platforms using IndexedDB or OPFS storage
  * Automatic platform detection of the above (handled by the SDK)
  * All the benefits of synced SQLite: bulletproof persistence, instant reactivity, and automatically synced state

## Why We Built This

As more developers adopted PowerSync for Capacitor apps, we heard consistent feedback about the need for better mobile performance and persistence:

**Roadmap User 1 quote:**

> I would like to add sync to my Android and iOS apps built with Capacitor. I need full local-first offline support. As I understand it, native SQLite storage is the only real reliable permanent storage option on Capacitor mobile apps, since other options such as IndexedDB may be cleared by the OS at any point

**Roadmap User 2 quote:**

> local-first for web & mobile apps without switching the codebase! would allow us to not have to use react native and rewrite all our frontend

**Roadmap User 3 quote:**

>  webview storage seems unreliable. If powersync doesn’t support native sqlite for persistence, I might have to use rxdb instead of powersync. Thank you for working on this!

These insights drove us: Developers want the simplicity of web code with the reliability of native mobile databases. Our Capacitor SDK delivers that.

## The Inside Story: How We Built It

The challenge was interesting: Capacitor runs web applications in native web views, but those environments don’t provide access to native SQLite. We needed to bridge between PowerSync’s JavaScript layer and platform-specific SQLite implementations.

### Platform detection and driver swapping

The SDK uses Capacitor's platform detection APIs to determine the runtime environment. When running on iOS or Android, it automatically swaps WA-SQLite for the [Capacitor Community SQLite](https://github.com/capacitor-community/sqlite) driver, which provides JavaScript bindings to native SQLite implementations on each platform.

### Basic usage

```typescript
import { PowerSyncDatabase } from '@powersync/capacitor';
import { Schema } from '@powersync/web';

const db = new PowerSyncDatabase({
  schema: new Schema({...}),
  database: {
    dbFilename: "mydatabase.sqlite"
  }
});

// Automatically uses:
// - Native SQLite on iOS/Android 
// - WA-SQLite on web platforms
```

### Solving SQLite Extension Loading

PowerSync requires two critical capabilities from any SQLite implementation:

  1. **SQLite extension loading** : our PowerSync Core extension handles the sync protocol's complexity
  2. **Table update notifications** : for reactive queries

The Capacitor Community SQLite plugin presented some challenges here. While they added APIs for enabling and loading SQLite extensions, these APIs weren't fully implemented on native platforms ‒ they would throw errors on Android and iOS.

Rather than fork and maintain an entire SQLite library, we initially took a more surgical approach. The Capacitor Community SQLite plugin uses SQLCipher as its underlying SQLite library on mobile platforms, exposing it through Java (Android) and Swift (iOS) bindings. We created our own minimal Capacitor plugin that exposes a `registerCore` native method, allowing us to interface directly with SQLCipher to load our Core extension automatically for any opened connection.

This approach got even cleaner recently. SQLCipher Android [added support](https://github.com/sqlcipher/sqlcipher-android/commit/55ed7afd15a6e2b606cc0d93344e9241ceb50751) for enabling dynamic extension loading by default for all connections. Once the Capacitor Community SQLite library [updated their Android SQLCipher dependency](https://github.com/capacitor-community/sqlite/pull/664), we no longer needed direct SQLCipher integration on Android. We still use this approach for iOS, but the architecture is cleaner and more maintainable.

### Reactive Queries and Update Hooks

The second requirement ‒ table update notifications – is essential for PowerSync's reactivity model. When data changes (whether from local mutations or changes from background sync), watched queries need to re-execute and update your UI.

The Capacitor Community SQLite library doesn't provide update hooks, however as part of a different project, we recently [implemented our own version](https://github.com/powersync-ja/powersync-sqlite-core/pull/120) of update hooks directly in the PowerSync Core extension. This gives us access to table change notifications at the SQLite level, enabling reactive queries to work seamlessly.

This architecture means that features like `useQuery()` in React work identically across platforms. Your components automatically re-render when data changes, regardless of whether the app is running on web, iOS, or Android.

## Performance and Reliability Benefits

By using native SQLite on mobile platforms, Capacitor users get:

  * **Improved Database Persistence** : Native SQLite provides more reliable data storage than browser-based solutions, with proper filesystem integration and crash recovery
  * **Enhanced Query Performance** : Direct access to native SQLite implementations delivers better performance, especially for complex queries and large datasets
  * **Lower Latency** : Native execution eliminates the JavaScript-to-WASM boundary that browser-based SQLite implementations require. We ran some [initial benchmarks](https://github.com/powersync-ja/powersync-js/pull/708#issuecomment-3319055112) and saw a significant speedup versus IndexedDB.

## Resources for Builders

See our official [Capacitor SDK documentation](https://docs.powersync.com/client-sdk-references/capacitor) for installation instructions and API reference.

Have an enjoyable cup of coffee with our [example app](https://github.com/powersync-ja/powersync-js/tree/main/demos/example-capacitor): it showcases the SDK in action on Web, iOS and Android. 

If you get stuck or want to share what you’re building, join our [Discord server](https://discord.gg/powersync) to connect with other PowerSync developers and our engineering team.

## Known Limitations and Roadmap

This release is just the beginning. First and foremost we’re looking for your feedback! This will have a big impact on our roadmap. Additionally, if we see uptake from the community, we’ll be working on the [known limitations](https://github.com/powersync-ja/powersync-js/tree/main/packages/capacitor#limitations). Lastly, we're also exploring opportunities to contribute upstream to the Capacitor Community SQLite plugin, potentially upstreaming some of our extension loading improvements to benefit the broader community.

---

# How We Built Personalized College Matching Using Sync, AI + RAG

> Thanks to the instant sync now available in-app, we now provide our users with a seamless and hyper-personalized recommendation experience without our users having long wait times. Our users continue using every feature in Loper all while receiving tailored college recommendations in real-time from long-running AI + RAG processes.

- Published: 2025-10-22
- Author: Jared Tracy (Guest Author)
- Category: Engineering
- Source: https://powersync.com/blog/how-we-built-personalized-college-matching-using-sync-ai-and-rag

---

A little more than a year ago, Sam Eigen ([Loper](https://www.getloper.com/)’s CTO) was in a meeting with our designer going through a new feature that was going to be the most dynamic and information dense screen Loper had ever built for our app. This wasn’t simply a screen with some graphs and counters. We certainly had stats to display, but the screen was also packed with college and personality quiz recommendation lists, saved school previews, gamification badges, and a variety of information (including embedded YouTube videos) to help users find what’s most relevant to them as quickly as possible. On top of that, this was going to be the first screen our users would see when they enter Loper.

![](https://powersync.com/images/blog/how-we-built-personalized-college-matching-using-sync-ai-and-rag-inline-cfb85b09f2.png)

That week, we were asking ourselves: how do we query this much information that’s unique to a specific user in an efficient manner to feed the UI we need to render for the user? We kicked around the usual suspects: massively paralleled REST calls with caching, GraphQL, UI tricks to fake performance, etc. At that time, we were using a classic AWS Lambda + RDS implementation; TanStack to handle our query states with overall good performance that was heavily reliant on caching. We had a standard React Native implementation on top of the AWS ecosystem. There were a number of shortcomings we identified with our current stack when looking at what it would take to build out this new screen with so many features. We needed to think outside the stack… outside our existing paradigm.

The solution was a complete shift in the way we related to data: instead of imperative data fetching, declarative sync via PowerSync. I admit, before we discovered PowerSync, we (very briefly) toyed with the idea of attempting to build a sync engine on top of our existing AWS paradigm. Thankfully, we discovered PowerSync early in our planning stage, and the learning for implementing PowerSync in React Native was minor.

This was a radical shift in the way we thought about mobile app development. Suddenly, all of the data we wanted to make available to the client was directly and immediately available within our app. We also learned that PowerSync’s SQLite implementation supported JSON functions, which opened the door to extending our data far beyond our existing data structures. Within a few weeks, we had a fully functioning feature ready to start internal testing… Yes, it really is that quick to get PowerSync set up and going in a React Native project!

## How sync opened the door to AI + RAG

After we completed our first PowerSync integration, we had another realization: we could level up our existing college matching algorithm using AI + RAG processes that take much longer than the performance you need with REST API calls and UI performance tricks! Our existing matching algorithm was already comprehensive, but we knew we could do better now that we had the ability to sync data to the client instantly. PowerSync has a `watchWithCallback` function (and recently added [differential watch queries](https://docs.powersync.com/usage/use-case-examples/watch-queries#differential-watch-queries)) as part of their SDK that would allow us to drive truly real-time interactions with our users!

PowerSync allowed us to increase the amount of server resources driving our recommendations by a long shot! We no longer had to cherry pick a score of matching attributes to keep query performance as optimized as possible. We have upwards of 22 user onboarding data points augmented by 200-300 interests the user interacts with in our app that need to be matched and scored across more than 500 data points we have on each college. We could now build an AI + RAG process that would run for as long as is needed to make the best matches between so many data points. If a match took more than 30 seconds (our average is roughly 28 seconds of runtime), it wouldn’t impact the user’s experience.

Thanks to the instant sync now available in-app, we now provide our users with a seamless and hyper-personalized recommendation experience without our users having long wait times. Our users continue using every feature in Loper all while receiving tailored college recommendations in real-time from long-running AI + RAG processes. Additionally, each college recommendation is coupled with specific details about exactly why the user matched with that specific college. This way, the user knows exactly why a given college is a fit just for his/her needs and preferences. Two users with the same onboarding profile won’t always match to the same colleges because there are 200-300 other data points distinguishing each user’s interests from another. It’s hyperpersonalization at scale. To date, we’ve delivered over 1.3MM recommendations to nearly a quarter million users based upon nearly 7.5MM user preference data points, and we’re working on further deepening the level of hyperpersonalization to include more relationships and data.

## Loper Demo Video

In the video below you can see the background AI + RAG in action. A user uses a “Super Like” on computer science programs as an area of study, and gives physics programs a like as well. They continue to use other areas of the app while these new preferences are sent to the server. There, they’re combined with 200+ other user preference data points in a server-side AI + RAG process that has time to make the best college matches. When the process completes, the result is immediately synced to the user in the form of a new recommendation (in this case for the _Illinois Institute of Technology_). This flow is designed to keep the user engaged (and logging preferences) while college matching processes run in the background.

## About Loper 

Loper is a free college search and planning app built to help students explore their post–high school options in a more personalized, engaging way. Students can explore their interests and college life through a social media style feed, get personalized college recommendations, easily build and manage their lists, and access free resources that make it easier to stay on top of applications and apply confidently. For counselors and college partners, Loper creates more meaningful touchpoints with students by turning a traditionally overwhelming process into something simple, visual, and actionable.

[Video: Loper college matching screen recording](https://www.youtube.com/watch?v=AulA1efJAkk)

---

# Using pg_ivm To Enable Joins In PowerSync

> The pg_ivm extension for Postgres can be used to

- Published: 2025-10-21
- Author: Joshua Brink
- Category: Engineering
- Source: https://powersync.com/blog/using-pg-ivm-to-enable-joins-in-powersync

---

> **Warning**
>
> Since this post was published, PowerSync has released [Sync Streams](https://docs.powersync.com/sync/streams/overview), which support [INNER JOINs](https://docs.powersync.com/sync/streams/queries#using-joins) with simple equality conditions. The use case described in this post can now be handled using Sync Streams. However, for more complex joins (e.g. many-to-many), `pg_ivm` remains a valid approach, and this post may still serve as a useful reference. 

PowerSync keeps in-app SQLite databases in sync by replicating data changes from backend source databases. When using Postgres as the source database, this happens via Postgres [logical replication](https://www.postgresql.org/docs/current/logical-replication.html), which is derived from the [Write-Ahead Log (WAL)](https://www.postgresql.org/docs/current/wal-intro.html). Using this approach, PowerSync gets a stream of changes that occur in Postgres, allowing for high-performance, scalable and efficient syncing.

The specific data that should be replicated is defined using [Sync Streams](https://docs.powersync.com/sync/streams/overview) (or legacy [Sync Rules](https://docs.powersync.com/sync/rules/overview)) on the PowerSync Service, which make use of SQL-like query statements.

![](https://powersync.com/images/blog/using-pg-ivm-to-enable-joins-in-powersync-inline-811e718bb3.png)

### 3+ table JOINs not yet supported

 _Since this post was originally published, PowerSync has introduced_** _Sync Streams_** _, which support 3+ table INNER JOINs. For many common use cases, this means the approach described below is no longer required.  
_

_However, this post remains a useful reference. The example below explains how normalized relational data can be synced by restructuring queries and relationships. While Sync Streams now handle simple JOINs directly, the same principles described here can still be applied when working with more complex joins (for example, many-to-many relationships)._

Consider the following example: Let’s say we have Orders that belong to Customers, and we want to sync certain customers with their associated orders:

![](https://powersync.com/images/blog/using-pg-ivm-to-enable-joins-in-powersync-inline-ed02a68747.png "||portrait")

Since we only need a 2-table join in this scenario, we can make use of the Orders table’s `customer_id` foreign key in the Sync Rules:

```yaml
parameters: SELECT request.jwt() ->> 'customer_id' as customer_id 
data:
      - SELECT * FROM customers WHERE id = bucket.customer_id
      - SELECT * FROM orders WHERE customer_id = bucket.customer_id
```
The problem comes in when we have a **tertiary** relationship. Let's say we expand the above example to include a Line Items table linked to an order:

![](https://powersync.com/images/blog/using-pg-ivm-to-enable-joins-in-powersync-inline-06b35368ad.png "||portrait")

How do we create the Sync Rules to represent this?

```yaml
parameters: SELECT request.jwt() ->> 'customer_id' as customer_id 
data:
      - SELECT * FROM customers WHERE id = bucket.customer_id
      - SELECT * FROM orders WHERE customer_id = bucket.customer_id
      - SELECT * FROM line_items WHERE line_items.order_id = ?
```
PowerSync doesn’t have a built-in solution yet to sync based on the relationships across these 3 tables without changing your schema.

### Denormalization workaround

The generally recommended workaround is to [denormalize](https://docs.powersync.com/usage/sync-rules/guide-many-to-many-and-join-tables) the relationships in your schema: By adding a `customer_id` column to the Line Items table, we can use the following to sync all the Orders and Line Items that belong to the relevant Customers:

```yaml
parameters: SELECT request.jwt() ->> 'customer_id' as customer_id
data:
      - SELECT * FROM customers WHERE id = bucket.customer_id
      - SELECT * FROM orders WHERE customer_id = bucket.customer_id
      - SELECT * FROM line_items WHERE customer_id = bucket.customer_id
```
![](https://powersync.com/images/blog/using-pg-ivm-to-enable-joins-in-powersync-inline-a362dcefce.png "||portrait")

Note that while arbitrary JOINs are not yet supported in Sync Rules, JOINs _are_ supported in the client-side SQLite database that the data is synced to. So in the client-side application, we can write queries with JOINs as needed. 

Unfortunately, denormalizing relationships has drawbacks such as:

  * The effort to refactor the database schema
  * Redundant data (duplication)
  * Increased vulnerability to data inconsistencies

Fortunately, there is another alternative solution: The `pg_ivm` extension for Postgres. 

### What is IVM and what does pg_ivm do? 

A materialized view is a stored, precomputed result of a query that behaves like a table and can be refreshed to stay up to date. Incremental View Maintenance (IVM) is a technique used to efficiently update materialized views: instead of refreshing the entire view when the underlying data changes (by re-running the whole query), the view is incrementally updated. The `pg_ivm` extension for Postgres implements this technique, allowing developers to create materialized views that are efficiently automatically updated as the base tables are modified.

Postgres includes built-in [materialized views](https://www.postgresql.org/docs/current/rules-materializedviews.html), but they don’t provide IVM: They need to be refreshed manually (`REFRESH MATERIALIZED VIEW my_view`) which can be an expensive operation, and the changes to the view are not published to the logical replication stream.

By contrast, the “materialized views” created by `pg_ivm` are just regular Postgres tables that are kept up to date using an IVM algorithm — and therefore changes to these tables are published in logical replication. 

### Using pg_ivm for JOINs in PowerSync

To use `pg_ivm` with PowerSync, create a materialized view using `pg_ivm` that includes JOINs, and reference it in PowerSync’s Sync Streams like any other table. 

![](https://powersync.com/images/blog/using-pg-ivm-to-enable-joins-in-powersync-inline-ccc2992cbc.png)

**Note:** There are some limitations to the types of queries that can be used with `pg_ivm`. For details on what type of clauses and aggregations are supported, see [this section](https://github.com/sraoss/pg_ivm#supported-queries) from the README.

### pg_ivm demo

A working demo of the above example can be found at [powersync-pg_ivm-example](https://github.com/powersync-community/pg-ivm) repository. 

The schema includes `customers`, `orders` and `line_items` tables, and then implements an incrementally materialized view of `line_items_ivm` using `pg_ivm`: (see [setup.sql](https://github.com/powersync-community/powersync-pg_ivm-example/blob/main/backend/pg-init/setup.sql))

```sql
CREATE EXTENSION pg_ivm;
SELECT
  pgivm.create_immv('line_items_ivm', 
    'SELECT li.id, 
            c.id AS customer_id, 
            c.name AS customer_name, 
            o.id AS order_id, 
            o.reference AS order_reference, 
            li.product_name
     FROM customers AS c 
     JOIN orders AS o ON c.id = o.customer_id 
     JOIN line_items AS li ON o.id = li.order_id');

ALTER TABLE line_items_ivm REPLICA IDENTITY FULL;
```

**Note on that last SQL statement:** By default, when you create a logical replication publication for a table in Postgres, it uses the table’s primary key to allow subscribers to identify existing rows on which `UPDATE` and `DELETE` operations happened. If a table does not have a primary key, like our materialized view in the above example, Postgres will throw an error unless you enable `REPLICA IDENTITY FULL`, which publishes the entire row as an identifier in the logical replication stream.

### Caveat: Offline updates to SQLite database

There is an important drawback to this approach to take note of: Because these materialized views are updated server-side in Postgres, changes made locally in the client-side SQLite database (while offline) won’t immediately reflect in the materialized view until the next sync cycle.

This means that the normal pattern of using PowerSync breaks a bit. For example, you might be using PowerSync’s watched queries like this:

```typescript
powerSync.watchWithCallback(
  `SELECT * 
   FROM orders 
   JOIN line_items ON orders.id = line_items.order_id
   WHERE orders.id = 1`,
  [],
  {
    onResult: (rows) => {
      const orders = rows.rows?._array;
      console.log("Watch orders result:", orders);
    },
  }
);

console.log("Updating a line item...");
await powerSync.execute(`UPDATE line_items SET product_name = ? WHERE order_id = 1`, ["test"]);
```
With `pg_ivm` we lose this live SQLite feedback in the client. Mutations on the underlying tables (like `line_items`) require a full roundtrip synchronization (`updateData` → source Postgres database → PowerSync Service →  local SQLite database) to be reflected in the materialized view table (`line_items_ivm`).

### Supported cloud providers

The only managed cloud Postgres providers we know of that currently support extensions and therefore `pg_ivm` are:

  * [Neon](https://neon.com/docs/extensions/extensions-intro) — see also [Google Cloud SQL’s extension list](https://cloud.google.com/sql/docs/postgres/extensions#miscellaneous-extensions)
  * [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/extensions#miscellaneous-extensions) (take note of the warnings)
  * [CrunchyBridge](https://docs.crunchybridge.com/extensions-and-languages)

---

# Product Update: September 2025

> September is a shoulder season in many parts of the world, and that aligns with a big upgrade coming to the heart of PowerSync — Sync Streams, an evolution of our current Sync Rules system.

- Published: 2025-10-09
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/product-update-september-2025

---

Hey all!

September is a shoulder season in many parts of the world, and that aligns with a big upgrade coming to the heart of PowerSync — Sync Streams, an evolution of our current Sync Rules system. In this edition I’ve compiled some juicy Sync Stream updates for you. 

## Product updates shipped in September:

  * **PowerSync Service**   

    * Sync Streams are in early alpha! This is a step change in the flexibility of the overall PowerSync system. See this edition’s _Feature Story_ below.
    * Since Sync Streams is a re-design of a core part of PowerSync, we took the opportunity to [fix](https://docs.powersync.com/usage/sync-rules/compatibility#supported-fixes) some long-standing issues with sync behavior. You can opt-out of individual fixes using the new config flags. 
  * **Client SDKs**   

    * Our Kotlin SDK now has support for Room and SQLDelight! Can’t decide which one to use? Use Room if you already have a Room database, else use SQLDelight.
    * We shipped a [demo](https://docs.powersync.com/usage/use-case-examples/full-text-search#example-implementations) showing how to use SQLite FTS5 with our Swift SDK.
  * **PowerSync Cloud**   

    * We [simplified and streamlined](https://powersync.com/blog/simplified-cloud-pricing-based-on-data-synced) the pricing for PowerSync Cloud. Almost all customers can expect to pay _less_ going forward.

## Community feed

  * Amine (**@gimyboya** on Discord) who is based in Malaysia joined our Product Success Engineering team! Our PSE team’s goal is to help developers build on PowerSync, with Amine bolstering support for our customers in the Asia-Pacific region.
  * Community PRs:   

    * Thanks [jonkan](https://github.com/powersync-ja/powersync-swift/pull/74), [davidmartos96](https://github.com/powersync-ja/sqlite_async.dart/pull/109) and [js2702](https://github.com/powersync-ja/sqlite_async.dart/pull/102) for your contributions to our client SDKs during September. 
  * Simon Binder [recounts](https://powersync.com/blog/speeding-up-powersync-with-a-sqlite-extension-written-in-rust) his Rust-powered odyssey to turbocharge our SQLite extension, yielding 5x React Native speedups and streamlined SDK logic.
  * Matthew Weidner [summarizes](https://powersync.com/blog/collaborative-text-editing-over-powersync) his work to use PowerSync for collaborative text editing and presence. No CRDTs were harmed during this project.
  * Since announcing our public proposals in August, we have two new ones: [incremental reprocessing](https://github.com/powersync-ja/powersync-service/discussions/349) and [syncing binary data](https://github.com/powersync-ja/powersync-service/discussions/360).

## Feature story: Sync Streams in early alpha

One of our biggest releases ever — Sync Streams — is now available as an [early alpha](https://docs.powersync.com/usage/sync-streams). I wrote about Sync Streams last month, and in this edition, I want to give a status update and add more color on their usage:

Sync Streams allow for more dynamic syncing, while not compromising on existing offline-first capabilities (i.e. “sync everything upfront” when the client connects). It vastly improves the usability of PowerSync for many use cases, especially on the web. It’s awesome to see this validated already – one of our early adopters told us: “We are actually very bullish on Sync Streams … we’re expecting [them] to give us more control”.

One of my favorite use cases for Sync Streams is component-level subscriptions. With the current Sync Rules system, updating client parameters requires reconnecting the client at the top level of the application. Since this would typically be triggered by user actions happening at the bottom of the component hierarchy, it’s a bit hacky. Sync Streams enable fine-grained and just-in-time sync subscriptions at the component level.

Client parameters in Sync Rules are also super tricky to manage across multiple tabs, while Sync Streams automatically handle multiple subscriptions across tabs. Icing feature: configurable TTLs create a warm cache for data from recently-unsubscribed streams, reducing latency when re-subscribing.

Sync Streams are available today in our JavaScript (Web + React Native), Flutter/Dart and Kotlin SDKs. We’re slow rolling the announcements while we iterate on early feedback. See [this](https://discord.com/channels/1138230179878154300/1422138173907144724) channel on our Discord server for instructions.

Heads up: There’s currently one glaring known issue which is that the config fix for ISO 8601 timestamps breaks the JS SDK, i.e. new `Date(syncedValue)` will throw an exception, so either cast or set `timestamps_iso8601` to `false` in your config.

If you’ve made it this far, I’ll mention that we’re currently deep into a rebuild of the PowerSync Dashboard, and it uses Sync Streams. Availability will be announced on our Discord server first, soon™️

---

# Building an E2EE Chat App with PowerSync + Supabase

> This is a candid write‑up of the developer experience of building a PowerSync + Supabase React app with end‑to‑end encryption (E2EE): smooth parts, clunky parts, performance questions I still want to answer, and where a little documentation and tooling could remove friction for the next person.

- Published: 2025-10-08
- Author: Marcus Pousette (Guest Author)
- Category: Engineering
- Source: https://powersync.com/blog/building-an-e2ee-chat-app-with-powersync-supabase

---

I built a PowerSync + Supabase React [app](https://github.com/powersync-community/react-supabase-chat-e2ee) with end‑to‑end encryption (E2EE), leaning on [differential watch](https://docs.powersync.com/usage/use-case-examples/watch-queries#differential-watch-queries) hooks for a reactive UI. This is a candid write‑up of the developer experience: smooth parts, clunky parts, performance questions I still want to answer, and where a little documentation and tooling could remove friction for the next person.

![Screenshot of E2EE Chat](https://powersync.com/images/blog/building-an-e2ee-chat-app-with-powersync-supabase-inline-4e93264bfe.png "_End-to-end encrypted group chat with guest access, room invites, and local vault unlock flows._")

## Setup & DX

The initial setup was quick: wiring Supabase Auth, pointing the PowerSync client at my service, and getting a watch query on screen. From there, layering E2EE (vault key, per‑room keys, and mirror tables) felt natural. The rough edge was operational rather than conceptual: I had to bounce between the Supabase and PowerSync dashboards to configure URLs, roles and SQL, copying values back and forth. Coming from an AWS CDK background, I missed an infrastructure‑as‑code path to stamp environments consistently. A stable CLI or IaC starter (for roles, publications, and Sync Rules) would turn that friction into muscle memory.

## Architecture at a glance

Messages and rooms are stored as encrypted rows; mirrors expose the plaintext needed for UI. I used PowerSync’s differential watch to feed the chat, because it tells you exactly what changed (added/updated/removed) rather than re‑emitting whole result sets. It plays well with list UIs — especially when you want a snappy scrollbar without fetching the entire history up front. See: [Live / Watch Queries](https://docs.powersync.com/usage/use-case-examples/watch-queries) and the note on trade‑offs in [High‑Performance Diffs](https://docs.powersync.com/usage/use-case-examples/high-performance-diffs).

## What felt smooth

Once the plumbing was in place, local‑first flow really shines: writes are instant, the UI stays responsive offline, and sync‑back is transparent. The encryption pieces slot in cleanly because the app owns the mirror schema, so I can keep ciphertext opaque while shaping the plaintext columns I actually render.

## Where I stumbled

I spent time in trial‑and‑error on [Sync Rules](https://docs.powersync.com/usage/sync-rules) and [Sync Streams](https://docs.powersync.com/usage/sync-streams) syntax (the new system that PowerSync is working on that will eventually replace Sync Rules; it’s currently in early alpha) — figuring out which SQL operators are supported in parameter/data queries and how to structure them for buckets. The “Ask AI” assistant didn’t unlock much there. What did help was building a small catalog of working examples and learning the constraints called out in the docs: [Data Queries](https://docs.powersync.com/usage/sync-rules/data-queries) and [Parameter Queries](https://docs.powersync.com/usage/sync-rules/parameter-queries), plus the detailed limits in [Operators & Functions](https://docs.powersync.com/usage/sync-rules/operators-and-functions).

## Raw tables or default views?

Default (JSON-based) SQLite views are zero-migration on the client: the PowerSync SDK applies your client schema over schemaless JSON, so you aren’t writing client migrations when fields change. Raw tables are the “you own it” path: you create tables, define the sync mappings (`put`/`delete`), add triggers to forward local writes, and handle schema changes yourself. In return, you get native indexes/constraints and faster queries on hot paths. The docs spell this out here: [Raw SQLite Tables](https://docs.powersync.com/usage/use-case-examples/raw-tables) (“How Raw Tables Work”, “Define sync mapping…”, “Capture local writes with triggers”).

_Why raw tables in this project:_ The app encrypts at the application layer. What we sync is an opaque cipher envelope (`alg`, `aad`, `nonce`, ciphertext, KDF params), not a JSON business object. The JSON view model can’t decrypt on the client’s behalf or project fields out of ciphertext; it’s designed for schemaless JSON that’s already usable. With raw tables, I can store the envelope as columns, decrypt locally, and maintain mirror tables that expose just the plaintext fields the UI needs, with proper indexes. That’s why JSON views weren’t a fit here.

Migrations — precisely. No client migrations for JSON views; with raw tables, migrations are your responsibility. If you **add columns** to a raw table, there’s currently no “re-sync with new columns” mechanism. The guidance is to **delete local data** for that table and let the client perform a **full re-sync** so the new columns populate. This is a **client-side reset only** — server data stays intact — but note that `disconnectAndClear()` **does not** clear raw tables; you must wipe them explicitly. See [Migrations](https://docs.powersync.com/usage/use-case-examples/raw-tables#migrations), [Migrations on raw tables](https://docs.powersync.com/usage/use-case-examples/raw-tables#migrations-on-raw-tables), and [Deleting data and raw tables](https://docs.powersync.com/usage/use-case-examples/raw-tables#deleting-data-and-raw-tables).

Recommendation: Start with defaults to get momentum; move targeted tables to raw when you need schema guarantees, client-side indexes, or app-layer encryption. A tiny migration playbook (version check → pause watchers → wipe affected raw tables → reconnect) makes this path safe from day one.

## Performance questions (and how I plan to answer them)

I haven’t pushed this to “giant room” scale yet, so my unknowns are mostly about behavior under load. How quickly does a cold client converge when a room has millions of messages? What’s the steady‑state input‑to‑paint latency with high message rates? How big does the local DB get, and what does P95/P99 look like on typical devices? What’s the cost profile of a differential watch when result sets are large? The high‑level note in the docs is that differential watches are the most flexible but can be slower on large result sets — hence the need to measure in context. See: [High‑Performance Diffs](https://docs.powersync.com/usage/use-case-examples/high-performance-diffs).

My plan is to build a small harness that varies fan‑out (members/room), message rate, and payload size, and record: time to “recent messages visible” on cold start; steady‑state input→paint latency; memory/CPU of the watch path; local DB footprint and query latency; convergence after offline flaps; and network/backpressure behavior under bursts. Until those numbers exist, I’d ship conservative defaults: small initial windows per room, attach Sync Streams only for visible rooms (or if using Sync Rules, use client parameters to limit data similarly), cap local cache with tail eviction, and back off when queues deepen. The built‑in diagnostics are handy here: see the [troubleshooting page and Sync Diagnostics Client](https://docs.powersync.com/resources/troubleshooting).

## Data‑shaping & Sync Streams

Two practical tips helped the “scrollbar‑happy” prefetch problem. First, shape what you sync: be explicit about output columns and avoid accidental broadening ([Data Queries](https://docs.powersync.com/usage/sync-rules/data-queries)). Second, let the UI drive attachment: open a Sync Stream for the room you’re actually looking at (or if using Sync Rules, use client parameters); keep a tiny warm cache for neighbors; and page backwards as the user scrolls. Differential watch makes this cheap to reason about, because you get diffs instead of whole lists. When you do need parameters from the client, read the caveats in [Parameter Queries](https://docs.powersync.com/usage/sync-rules/parameter-queries) and the limits in [Operators & Functions](https://docs.powersync.com/usage/sync-rules/operators-and-functions).

## Documentation notes

The docs got me there, but the edges around Sync Rules and Sync Streams SQL were where I burned time. A “decision tree” for raw vs. default views, a migration playbook for raw tables, and a handful of end‑to‑end examples for common patterns (chat, feed, infinite scroll) would pay for themselves. A small “what SQL is supported in Sync Rules & Sync Streams” table with yes/no examples would reduce trial‑and‑error.

## JS client ergonomics

I wanted a bit more hand‑holding in the JS client: clearer raw‑query guidance, and sharper examples around watch queries for list UIs. The watch‑query pages are good starting points: [Live Queries / Watch Queries](https://docs.powersync.com/usage/use-case-examples/watch-queries) overview and [High‑Performance Diffs](https://docs.powersync.com/usage/use-case-examples/high-performance-diffs). If you’re using a [typed SQL builder](https://docs.powersync.com/client-sdk-references/javascript-web/javascript-orm/overview) (Drizzle/Kysely), first‑class adapters/wrappers for watch queries would be great.

## Raw tables + Sync Streams as a default path?

Raw tables feel powerful — and paired with Sync Streams they seem like a strong mental model for new apps. I’d love official guidance on when that should be the **default** versus when the higher‑level helpers are a better fit. Until then, I’m comfortable recommending: start simple, then graduate to raw tables + Sync Streams where you need precision or speed.

## What I’d love to see next

  * A CLI or IaC starter that provisions Supabase + PowerSync and stamps roles, publications, and Sync Rules/Streams without manual copy‑paste.
  * A “new‑dev guide” that says plainly when to stick to default views and when to reach for raw tables, including the migration playbook and callouts to the raw‑table sections: [How Raw Tables Work](https://docs.powersync.com/usage/use-case-examples/raw-tables#how-raw-tables-work), [Migrations](https://docs.powersync.com/usage/use-case-examples/raw-tables#migrations), [Migrations on raw tables](https://docs.powersync.com/usage/use-case-examples/raw-tables#migrations-on-raw-tables), and [Deleting data and raw tables](https://docs.powersync.com/usage/use-case-examples/raw-tables#deleting-data-and-raw-tables).
  * More examples covering bucket design and supported SQL in Sync Rules/Streams: start at [Data Queries](https://docs.powersync.com/usage/sync-rules/data-queries), [Parameter Queries](https://docs.powersync.com/usage/sync-rules/parameter-queries), and [Operators & Functions](https://docs.powersync.com/usage/sync-rules/operators-and-functions).

## Closing

Overall, the experience was good. The local‑first model feels great in a chat app, and PowerSync’s watch hooks pair naturally with E2EE mirrors. The rough edges I hit — manual provisioning, raw‑table migrations, and figuring out the limits of Sync Rules/Streams — are solvable with a little guidance and tooling. I would happily ship this to production after we answer the benchmarking questions and lock in a small migration helper for raw tables.

---

# Keep Background Apps Fresh with Expo Background Tasks and PowerSync

> Use Expo background tasks and PowerSync to keep app databases fresh while apps are minimized.

- Published: 2025-10-07
- Author: Dean Braun
- Category: Tutorial
- Source: https://powersync.com/blog/keep-background-apps-fresh-with-expo-background-tasks-and-powersync

---

PowerSync ensures that your app’s local database is always kept fresh. However, users frequently move in and out of apps. By default, apps only sync when they’re in the foreground. What happens when your app is running in the background? 

Apps that have been backgrounded might get stale as new server-side data stops syncing down to the user’s app. Users could then face a loading state while the local database catches up. Depending how much data has changed, the impact could range from imperceptible to highly frustrating. Thankfully, Expo’s [BackgroundTask API](https://docs.expo.dev/versions/latest/sdk/background-task/) provides a solution.

This article walks through how to implement background sync in an Expo app using PowerSync and Supabase. We'll cover the problem, the solution, and a step-by-step implementation, complete with code and a demo to show it in action. 

[Video: Keep Background Apps Fresh with Expo Background Tasks and PowerSync](https://www.youtube.com/watch?v=gvEIn31NsN4)

_A React Native app running on Android, being minimized, and loading data in the background through Expo background tasks._

## The Problem: Stale Data and Slow Catch-Up

PowerSync ensures fast, responsive apps by storing data in a local SQLite database that syncs with a remote backend (like Supabase). When the app is in the foreground, sync works like a charm and users get instant updates. But when the app is backgrounded, sync stops. This leads to two issues:

  * **Stale Data Offline** : Users opening the app offline have data that could be hours or days old.
  * **Waiting For Fresh Data** : When users return online, PowerSync must process all pending upload transactions and download new operations, which could lead to unnecessary delays in your app.

These issues can make your app feel sluggish, especially for users who frequently switch apps or leave them idle for long periods. 

## The Solution: Background Sync with Expo

[Expo’s BackgroundTask API](https://docs.expo.dev/versions/latest/sdk/background-task/) offers a way to keep PowerSync’s local SQLite database in sync even when the app is in the background. By scheduling a background task to periodically connect to PowerSync and sync with your source database, you can reduce stale data by keeping the local SQLite database up-to-date with the latest remote changes without your users even knowing about it.

This approach uses [expo-background-task](https://www.npmjs.com/package/expo-background-task/v/0.2.8) to register a background task that connects to PowerSync. The task is carefully managed to run only when the app is backgrounded, avoiding conflicts with foreground sync.

While background tasks aren’t perfect — iOS and Android impose restrictions based on battery life and user behavior — they’re a best-effort enhancement that makes your app feel snappy and professional. When the stars align; users open your app to find fresh data with no waiting, creating those delightful moments where everything just works.

## Implementation Steps

Let’s break down how to implement background sync with PowerSync and Expo. The full code is available in [this](https://github.com/powersync-community/powersync-react-native-expo-background-sync) demo app repo.

### Step 1: Set Up Supabase with expo-fetch

Since I’m using a `SupabaseConnector`, we need to override the default fetch function with expo-fetch in the Supabase client. This is critical because background tasks normally run in headless mode, which lacks a full JavaScript environment, causing React Native's default `fetch` function not to work.  
  
This demo is also configured to use anonymous sign-ins with Supabase. Read more about that [here](https://supabase.com/docs/guides/auth/auth-anonymous?queryGroups=language&language=python).

```typescript
import { fetch } from "expo/fetch";
import { createClient } from "@supabase/supabase-js";

this.client = createClient(AppConfig.supabaseUrl, AppConfig.supabaseAnonKey, {
  auth: {
    persistSession: true
  },
  global: {
    // Override the default fetch to use expo-fetch
    fetch: fetch as any
  }
});
```
### Step 2: Define the Background Sync Task

The background task located in `lib/utils.ts` reuses the system object from `SystemContext.ts` to avoid creating a new PowerSync instance, which could lead to inconsistent sync behavior. We simulate a pending transaction by inserting a mock entry into the `lists` table, then trigger PowerSync’s sync process. A custom promise ensures all uploads and downloads are complete before the task finishes.

```typescript
import * as TaskManager from "expo-task-manager";

const BACKGROUND_SYNC_TASK = "background-powersync-task";

TaskManager.defineTask(BACKGROUND_SYNC_TASK, async () => {
  try {
    console.log(`[Background Task] Starting background task at ${new Date(Date.now()).toISOString()}`);

    // Ensure we don't create another connection to PowerSync if it's already connected
    if (system?.powersync?.connected) return;

    // Insert a mock list to simulate a pending transaction in `ps_crud`
    await system.powersync.execute(
      `INSERT INTO ${LIST_TABLE} (id, name, owner_id) VALUES (uuid(), 'From Inside BG', ?)`,
      [await system.connector.userId()]
    );

    console.log("[Background Task] Initializing PowerSync");

    // Capture the previous lastSyncedAt BEFORE init so we can detect a sync that
    // completes during this background task run. `lastSyncedAt` is process-scoped
    // (not listener-scoped) and persists across `system.init()` calls within the
    // same JS runtime, so on a warm start it will already be set from a prior
    // foreground session - gating on `Boolean(status.lastSyncedAt)` alone would
    // resolve immediately without waiting for this run's sync.
    const previousSyncAt = system.powersync.currentStatus.lastSyncedAt;

    await system.init();

    // Wait for a sync to complete during THIS background task run
    await new Promise<void>((resolve) => {
      console.log("[Background Task] Waiting for sync to complete");
      const unregister = system.powersync.registerListener({
        statusChanged: (status) => {
          const syncedThisRun =
            Boolean(status.lastSyncedAt) &&
            previousSyncAt?.getTime() !== status.lastSyncedAt?.getTime();
          const downloading = status.dataFlowStatus?.downloading || false;
          const uploading = status.dataFlowStatus?.uploading || false;

          // Resolve when a fresh sync has completed and no transfers are in flight
          if (syncedThisRun && !downloading && !uploading) {
            console.log(
              "[Background Task] Download complete"
            );
            resolve();
            unregister();
          }
        },
      });
    });
  } catch (error) {
    console.error("[Background Task] Failed to execute the background task:", error);
    return BackgroundTask.BackgroundTaskResult.Failed;
  }
  return BackgroundTask.BackgroundTaskResult.Success;
});
```
This task first uploads pending transactions to Supabase and downloads new operations from the PowerSync Service, ensuring the local database stays fresh. We use a custom promise instead of `system.powersync.waitForFirstSync()` because `waitForFirstSync()` relies on the `hasSynced` property under the hood, which may already be true due the system object being shared.

### Step 3: Register the Background Task

Register the background task when the app is backgrounded and unregister it when the app is active to avoid conflicts with foreground sync. The `innerAppMountedPromise` promise ensures the task is only registered after the app’s home screen mounts, and we check the app’s state to handle cases like deep links.

```typescript
import * as TaskManager from "expo-task-manager";
import * as BackgroundTask from "expo-background-fetch";
import { AppState } from "react-native";

const BACKGROUND_SYNC_TASK = "background-powersync-task";
const MINIMUM_INTERVAL = 15; // Run every 15 minutes

/**
 * Initializes and manages the background task based on app state changes.
 */
export const initializeBackgroundTask = async (innerAppMountedPromise: Promise<void>) => {
  // Wait for the app to mount
  await innerAppMountedPromise;

  // Listen for app state changes
  AppState.addEventListener("change", async (nextAppState) => {
    console.log("App state changed:", nextAppState);

    if (nextAppState === "active") {
      // Unregister task when app is in foreground
      const isTaskRegistered = await TaskManager.isTaskRegisteredAsync(BACKGROUND_SYNC_TASK);
      if (isTaskRegistered) {
        console.log("App is active. Unregistering background task.");
        await BackgroundTask.unregisterTaskAsync(BACKGROUND_SYNC_TASK);
      }
    } else if (nextAppState === "background") {
      // Register task when app is in background
      const isTaskRegistered = await TaskManager.isTaskRegisteredAsync(BACKGROUND_SYNC_TASK);
      if (!isTaskRegistered) {
        console.log("App is in background. Registering background task.");
        await BackgroundTask.registerTaskAsync(BACKGROUND_SYNC_TASK, {
          minimumInterval: MINIMUM_INTERVAL,
        });
      }
    }
  });

  // Handle initial app state (e.g., app starts in background via deep link)
  const initialAppState = AppState.currentState;
  if (initialAppState === "background") {
    const isTaskRegistered = await TaskManager.isTaskRegisteredAsync(BACKGROUND_SYNC_TASK);
    if (!isTaskRegistered) {
      await BackgroundTask.registerTaskAsync(BACKGROUND_SYNC_TASK, {
        minimumInterval: MINIMUM_INTERVAL,
      });
    }
  }
};
```
This code reduces the risk of multiple simultaneous PowerSync connections, which could cause race conditions or SQLite conflicts.

### Step 4: Test and Debug

Background tasks can be tricky to test due to OS restrictions and scheduling variability. On iOS, Expo’s `BackgroundTask API` uses the iOS `BGTaskScheduler`, which determines the best time to launch your task based on battery level, network availability, and user usage patterns. You can specify a `minimumInterval` (e.g., 15 minutes), but the system may delay execution, especially on iOS.

Below are detailed testing instructions from the demo app repo. The app must be in the background for the task to run, and the OS ultimately decides when to execute it (typically within 20 minutes, though iOS may delay longer). Testing on physical devices is more reliable than simulators.

#### Android Testing

  1. **Run the App** : Start the app with `npm run android`
  2. **Change the** `AppState`**to** `background`
  3. **Check Job Scheduler** : Use the following command to view the job scheduler for the app (`com.anonymous.powersyncreactnativebackgroundsync` is the package name):

```bash
adb shell dumpsys jobscheduler | grep -A 40 -m 1 -E "JOB #.* com.anonymous.powersyncreactnativebackgroundsync"
```
Look for output like:

```text
JOB #u0a212/0: 74a550e com.anonymous.powersyncreactnativebackgroundsync/androidx.work.impl.background.systemjob.SystemJobService
```
The number after the `/` (e.g., 0) is the job ID.

  4. **Force the Task** : Run the task manually with:

```bash
adb shell cmd jobscheduler run -f com.anonymous.powersyncreactnativebackgroundsync 0
```
Note: Forcing may not work immediately due to OS scheduling.

  5. **Monitor Logs** : Watch all device logs using `adb logcat` to catch task activity. Look for these logs to confirm the task is running:

```text
[Background Task] Starting background task at [timestamp]
[Background Task] Initializing PowerSync
[Background Task] Waiting for first sync to complete
[Background Task] Download complete
Validated and applied checkpoint
```
#### iOS Testing

  * **Physical Device Required** : Background tasks are not supported on iOS simulators. Test on a physical iOS device with Background App Refresh enabled (Settings > General > Background App Refresh).
  * To enable background tasks on iOS, you need to add both `processing ` and `fetch` to the `UIBackgroundModes` array in your app’s `Info.plist` (`ios/powersyncreactnativebackgroundsync/Info.plist`). The `fetch` mode is required so your app can periodically run background fetches, allowing PowerSync to upload and download data even when the app is not in the foreground:

```xml
<key>UIBackgroundModes</key>
<array>
    <string>processing</string>
    <string>fetch</string>
</array>
```
  * **Monitor Logs** : Use Xcode’s console to view logs. Look for the same log messages as above to confirm task execution.

#### Debugging Tips

  * **Permissions** : Ensure Background App Refresh is enabled on iOS and battery optimizations are disabled on Android (Settings > Battery > Battery Optimization > Select your app > Don’t Optimize).
  * **Offline Behavior** : If the device is offline, the task will fail gracefully and retry when the network is available. Check for network-related errors in logs.
  * **Verify Sync** : After forcing the task or waiting for it to run, check Supabase to confirm the mock transaction (e.g., a list item named “From Inside BG”) was uploaded.
  * **Log Monitoring** : If logs don’t appear in your project's terminal, use `adb logcat` (Android) or Xcode’s console (iOS) to watch all device logs, as task logs may be filtered out in some environments.

For more debugging tips, check the demo app’s [README](https://github.com/powersync-community/powersync-react-native-expo-background-sync/blob/main/README.md).

## FAQ

  * **What if the device is offline during the task?** The task will fail gracefully and is scheduled to retry every 15 minutes. Log errors to diagnose persistent issues.
  * **Why reuse the system object?** Creating a new PowerSync instance risks race conditions or duplicate connections. Reusing the global system object ensures consistent sync behavior.
  * **What’s the minimum interval?** The `minimumInterval` (15 minutes) is essentially a suggestion to the operating system. iOS may run tasks every 20 minutes to hours, while Android is more flexible, but depends on many factors.

## Conclusion

Combining background tasks with PowerSync and Expo delivers a much more complete user experience that other mobile apps typically lack. It’s not perfect: iOS and Android can be stingy with background execution. But when it works, users get instant access to fresh data, online or offline, with no frustrating loading spinners. By following the steps above, you can implement this in your own React Native Expo app.

A very special thank you to [AbdelHameed](https://abdelhameed.deno.dev/) for his valuable insights and lessons learned from implementing background sync with PowerSync and Expo himself.

---

# Offline-First Apps Made Simple: Supabase + PowerSync

> In this post, I’ll be making my case that Supabase + PowerSync is one of the best stacks on the market for building offline-first web and mobile apps.

- Published: 2025-10-07
- Author: Kobie Botha
- Category: Engineering
- Source: https://powersync.com/blog/offline-first-apps-made-simple-supabase-powersync

---

## In the age of AI, offline-first still matters

The year is 2025. We are all more connected than ever, constantly chatting with LLMs. Yet this recently happened: 

![A tweet by Notion founder, Ivan Zhao, about offline functionality](https://powersync.com/images/blog/offline-first-apps-made-simple-supabase-powersync-inline-680f8c98cc.png)

This was Notion’s top requested feature for 5 years, and it took a lot of effort to ship it. Use cases that need offline support are plentiful: navigation, productivity, chat, workout tracking and more. Supabase is a fantastic fit for all of these use cases, but how do we make our apps work really well when our users are offline?

In this post, I’ll be making my case that Supabase + PowerSync is one of the best stacks on the market for building offline-first web and mobile apps. First, some background.

## The rise of sync engines

Sync engines have gained popularity in recent years. They generally come in two flavors. On the one hand, you have modern Firebase alternatives such as Convex and InstantDB. On the other, you have pluggable sync engines that integrate with an existing database. We are, of course, more interested in the second flavor because… well… maybe we just like Postgres 😀

There are three pluggable sync engines available today: ElectricSQL, Zero and PowerSync. This post is not a direct comparison of them; all integrate well with Supabase. The focus in this post is on building offline-first apps, and of the three, PowerSync is the only one with first-class offline support.

At the 2025 Local-First Conference in Berlin, Aaron Boodman from Zero (a sync engine with some nice features) was asked about offline support. He noted that offline presents significant UX challenges, and stated that offline is out of scope for Zero for the time being. Similarly, offline is out of scope for ElectricSQL by definition since it does not concern itself with client-side persistence; developers must implement their own persistence.

## When is offline-first really hard?

When syncing a single user’s data, you typically don’t need a sync engine. Most of the time it’s quite straightforward, and there are plenty of [writeups](https://medium.com/%40mabuex/local-first-with-swiftdata-and-supabase-434b0a473dd6) that can guide you through implementation. 

The complexity arises when building collaborative apps, where multiple users need to see the same state. This quickly becomes a hard problem:

  * **Partial sync:** The system should only sync a subset of data to each user, not the entire backend database. Additionally, these subsets are often defined dynamically based on the data, such as team membership or shared folders.
  * **Consistency:** If user 1 performs an action after user 2, then all clients must observe the same sequence of events.
  * **Conflicts:** When a client has been offline for a long time and reconnects, its local changes must be reconciled with any changes made to the same data by other clients during that time.
  * **Reliability:** Any solution must scale well, and handle production issues, such as storage corruption

As of writing, LLMs can’t solve these problems for you.

## Enter PowerSync

PowerSync is a sync engine that synchronizes an in-app SQLite database with your backend database like Supabase. It provides solutions to the challenges outlined above faced when building offline-first apps at scale.

PowerSync’s bucket system is what solves partial dynamic sync at scale, a particularly thorny problem. Think of buckets as subsets of your Postgres data that can be synced as a whole to one or more users. PowerSync also guarantees causal consistency across all synced buckets, avoiding weird scenarios such as your takeout order arriving before you ordered it 😆 

PowerSync scales horizontally: 

  * The overall system can keep millions of rows in a client SQLite database synced
  * The bucket system scales to thousands of buckets per user (millions of buckets overall)
  * User scaling:   

    * Millions of users/clients in total
    * Hundreds of thousands of concurrently connected users, with scaling above that possible with extra configuration

Combined with Supabase, deployment becomes really straightforward. Supabase uniquely provides a set of technologies that solve common headaches:

  * **Cross-platform client libraries:** Both PowerSync and Supabase have libraries for Flutter/Dart, JS/Web, React Native, Swift, Kotlin and more.
  * **Auth:** Simple config to enable Supabase Auth with either PowerSync Cloud or self-hosted PowerSync Open Edition. PowerSync already supports Supabase asymmetric JWTs.
  * **PostgREST:** Used by PowerSync for uploading client writes. Supabase Edge Functions are a great option for more advanced persistence logic.
  * **RLS:** For controlling write permissions. Especially powerful when combined with PostgREST.
  * **Replication tools:** PowerSync uses logical replication, which Supabase supports well. Custom roles can be granted replication privileges.
  * Scales to millions 😉

# Conflicts

As always, conflicts deserve their own section. Conflicts happen when multiple clients modify the same piece of data — often while offline — and those changes require reconciliation upon reconnection. This is a core challenge in collaborative apps. Mishandling the reconciliation can lead to data loss or inconsistency, and that in turn leads to grumpy users.

In my experience of building dozens of enterprise grade offline-first apps over a decade, I can confidently say that a last-write-wins (LWW) resolution strategy is sufficient for ~95% of apps where users are working with shared state. In LWW, the most recent write — as timestamped by the server — is persisted. A common practice when choosing LWW is to implement audit logging on your backend to track which user changed which columns in a row, at what time, and what the new values are. PGAudit could be useful here, depending on your requirements. 

PowerSync gives developers the tools to decide how they want to handle conflicts, instead of avoiding offline entirely. Developers get LWW conflict resolution by default when using the provided `SupabaseConnector`, with the option to customize the behavior.  You can implement your own custom merge algorithm/logic — see Matthew Weidner’s [shining example](https://powersync.com/blog/collaborative-text-editing-over-powersync) of this, or you can use CRDTs. See our Yjs [demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/yjs-react-supabase-text-collab) and CRDT [docs](https://docs.powersync.com/usage/use-case-examples/crdts) for more details on that.

## Conclusion: Supabase + PowerSync = the ultimate stack for offline-first web and mobile apps 

Offline support is as relevant as ever. Among the family of pluggable sync engines, PowerSync includes offline capabilities, partial sync, consistency, customizable conflict resolution, and scaling to large user bases.

The combination of Supabase + PowerSync provides cross-platform client libraries, easy authentication setup, PostgREST for handling writes, RLS for access control, logical replication support and more. Using last-write-wins (LWW) as a conflict strategy works for most shared-state scenarios, with many options for custom resolution. 

The Supabase + PowerSync combo is a great choice for building sophisticated multi-user offline-first web and mobile apps.

## Start building

To get started with PowerSync Cloud, see our Supabase [integration guide](https://docs.powersync.com/integration-guides/supabase-+-powersync). Alternatively for self-hosters or if you prefer local development, see our [Supabase + PowerSync starter template](https://github.com/powersync-community/powersync-supabase-backend-template).

---

# Using ORMs With PowerSync

> As much as some developers love to drop into raw SQL for advanced queries, it can be annoying to have to write SQL for simple queries, often because there’s no type-safety. Using an ORM helps address this challenge.

- Published: 2025-10-02
- Updated: 2026-01-15
- Author: Benita Volkmann
- Category: Engineering
- Source: https://powersync.com/blog/using-orms-with-powersync

---

As much as some developers love to drop into raw SQL for advanced queries, it can be annoying to have to write SQL for simple queries, often because there’s no type-safety. Using an ORM helps address this challenge.

## What’s available today?

> Note: We use “ORM” as a shorthand description of the libraries we’re integrating with. The libraries themselves can provide more than ORM functionality or describe themselves differently: Drift is a "relational persistence library", Kysely calls itself a "query builder” and TinyBase is a “reactive data store”. Similarly, Kotlin libraries like Room and SQLDelight don’t introduce their own query language on top of SQLite — instead, they make working with SQLite databases easier by providing compile-time validation and type safety.

Our plan is to add ORM support for each of our client SDKs. Currently, we integrate with ORMs in our Flutter, JavaScript, Kotlin and Swift SDKs.

### Flutter

#### Flutter ORM Support with Drift

We’ve recently [released a package](https://releases.powersync.com/announcements/drift-orm-integration-for-flutter-clients-alpha) that enables using the popular [Drift](https://pub.dev/packages/drift) persistence library (ORM) with the [PowerSync SDK for Flutter](https://pub.dev/packages/powersync). Our thanks to the author of Drift, [Simon Binder](https://www.simonbinder.eu/), for his help to enable this integration. The Drift integration gives Flutter developers the flexibility to write queries in either Dart or SQL, in the same app and against the same client-side database.

Importantly, the Drift ORM integration supports propagating change notifications from the PowerSync side to Drift, which is necessary for streaming queries.

The use of this package is recommended for Flutter developers who already know Drift, or specifically want the benefits of an ORM for their PowerSync projects. An example of using the drift_sqlite_async package with PowerSync is available [here](https://github.com/powersync-ja/powersync.dart/pull/60).

#### Support for Other Flutter ORMs

Other ORMs for Flutter, like Floor, are not currently supported. It is technically possible to open a separate connection to the same database file using Floor but there are two big caveats to that:

**Write locks**

Every write transaction (or write statement) will lock the database for other writes for the duration of the transaction. While transactions are typically short, if multiple happen to run at the same time they may fail with a SQLITE_BUSY or similar error.

**External modifications**

Often, ORMs only detect notifications made using the same library. In order to support streaming queries, PowerSync requires the ORM to allow external modifications to trigger the same change notifications, meaning streaming queries are unlikely to work out-of-the-box.

### JavaScript

#### Kysely

Following a wide evaluation of JavaScript ORMs we chose [Kysely](https://kysely.dev/) as the first ORM to integrate with PowerSync. This choice was driven by Kysely’s unique combination of declarative query building and type-safe imperative APIs.

Kysely integrates with our JavaScript-based SDKs through the [kysely-driver](https://www.npmjs.com/package/@powersync/kysely-driver) package. Visit our [docs](https://docs.powersync.com/client-sdk-references/javascript-web/javascript-orm/kysely) to learn how to get started.

#### Drizzle

PowerSync also integrates with [Drizzle](https://orm.drizzle.team/), which is quickly gaining popularity. Drizzle stands out for offering both [relational](https://orm.drizzle.team/docs/rqb) and [SQL-style](https://orm.drizzle.team/docs/select) queries, giving developers the best of both worlds.

Drizzle queries can be used in our JavaScript-based SDKs through the [drizzle-driver](https://www.npmjs.com/package/@powersync/drizzle-driver) package. See our [docs](https://docs.powersync.com/client-sdk-references/javascript-web/javascript-orm/drizzle) to get started and for common usage examples.

#### TanStack DB

[TanStack DB](https://tanstack.com/db/latest/docs/overview) is a client-side database for JavaScript that provides a structured way to work with local data using collections, queries, and reactive updates. It’s designed to integrate tightly with the TanStack ecosystem, making it a natural fit for applications that already rely on TanStack Query and related tools.  

Our TanStack DB integration lets you define TanStack DB collections that are backed directly by PowerSync tables. PowerSync handles persistence and sync, while TanStack DB provides the query and mutation layer on top. When PowerSync applies synced changes to the local database, those changes are reflected in the corresponding TanStack DB collections, so reactive queries update automatically.  

This integration is a good fit if you want a **collection-based, reactive API** on top of PowerSync without writing SQL in your application code. It works especially well if you’re already using TanStack libraries and want local-first behavior without managing SQLite or sync logic directly.

See these [docs](https://tanstack.com/db/latest/docs/collections/powersync-collection) for usage details.

#### TinyBase

[TinyBase](https://tinybase.org/) is a reactive local data store with a query builder, [TinyQL](https://tinybase.org/guides/making-queries/tinyql/), that provides type-safe APIs. TinyBase added support for PowerSync in their [version 4.8 release](https://tinybase.org/guides/releases/#v4-8) and now ships with a PowerSync persister built-in. Community member **Benedikt Müller** is the driving force behind this integration and wrote an [article on the benefits of this approach](https://bndkt.com/blog/2024/the-easiest-way-to-build-reactive-local-first-apps-with-tinybase-and-powersync).

### Kotlin

#### Room

[Room](https://developer.android.com/training/data-storage/room) is the official Android persistence library providing an abstraction layer over SQLite that makes it easier to manage and query a local database in Android apps.

Our Room integration lets you keep using your existing Room database while adding sync. Room detects schema and query issues at compile-time and generates code to map raw SQLite rows into typed classes, so you don’t need to write this yourself.

The integration also makes sure PowerSync’s synced changes are visible to Room, so reactive queries continue to update correctly. Room is best if you already have a Room database and want to add sync without changing your existing setup.

See these [docs](https://docs.powersync.com/client-sdk-references/kotlin-multiplatform/libraries/room) for usage details.

#### SQLDelight

[SQLDelight](https://sqldelight.github.io/sqldelight) lets you write raw SQL statements, and the compiler generates type-safe Kotlin APIs for those queries. Without a library like SQLDelight you’d have to manually read values from a Cursor and map each column to the correct fields in your data classes.

All Flows from SQLDelight automatically update for PowerSync’s synced changes, so your reactive queries stay up-to-date without extra work.

SQLDelight is the easiest option if you’re starting fresh with a PowerSync database.

See these [docs](https://docs.powersync.com/client-sdk-references/kotlin-multiplatform/libraries/sqldelight) for usage details.

### Swift

#### GRDB

[GRDB](https://github.com/groue/GRDB.swift) is a popular SQLite toolkit for Swift that provides a structured, type-safe way to work with SQLite databases. It includes features like query builders, database observation (reactive queries), robust concurrency handling, and comes with its own ecosystem of tools and libraries.

Our GRDB integration lets you keep using your existing GRDB database while adding sync. PowerSync shares a `DatabasePool` with GRDB, so synced changes are made visible to GRDB and its observation mechanisms, ensuring reactive queries continue to update correctly. This integration is a good fit if you already use GRDB in a Swift or SwiftUI app and want to add sync without rewriting your database layer. It also brings access to GRDB’s broader ecosystem, including tools like GRDBQuery for SwiftUI bindings.

See these [docs](https://docs.powersync.com/client-sdk-references/swift/grdb) for usage details.

## Why doesn’t PowerSync have a built-in ORM?

Developers often have strong opinions on using ORMs — they either love it or hate it. With PowerSync our goal is to not force that decision on developers. Instead, we want to allow any approach from raw SQL queries to arbitrary ORM libraries.

We specifically avoid implementing our own ORM since we feel it's better to support popular existing ORMs, which likely do a much better job than we can. It also makes it easier to switch to/from PowerSync if you can keep most of your database code the same.

That said, integrating PowerSync with any ORM unfortunately requires some custom work. However, we do try to do the integration work on a generic level. For example in the case of the Drift ORM for Flutter, the integration is between sqlite_async (which PowerSync uses) and Drift, so you're not locked into PowerSync at all.

## I want to use a specific ORM with PowerSync

We’re open to discussing any requirements or ideas around ORMs. Feel free to ask us any questions on our [Discord server](https://discord.gg/powersync).

---

# Why Cinapse Moved Away From CRDTs For Sync

> Cinapse’s scheduling app was the first one I built from scratch using CRDTs. CRDTs are an impressive and exciting technology, but they turned out to be a bad fit for our use case.

- Published: 2025-10-02
- Author: Francois van der Merwe (Guest Author)
- Category: Engineering
- Source: https://powersync.com/blog/why-cinapse-moved-away-from-crdts-for-sync

---

[Cinapse](https://www.cinapse.io/) is scheduling software for film and TV production. Our users are production teams with two important needs: (1) **offline availability** and (2) **easy collaboration**. 

I’ve built offline-first, collaborative apps before, but Cinapse’s scheduling app was the first one I built from scratch using CRDTs. I learnt a lot through this process: ultimately migrating away from CRDTs and preferring PowerSync’s server-authoritative architecture. CRDTs are an impressive and exciting technology, but they turned out to be a bad fit for our use case. Hopefully sharing our experience helps others who are considering building apps with real-time sync.

## Our introduction to CRDTs

Before we built our scheduling app, Cinapse had a more limited app used for managing cast and crew on set. We targeted mobile for this app and built it with React Native. We came across CRDTs when we initially faced the challenge of syncing changes made by one user to other users in real-time.

This was around 2020, and CRDTs looked like the perfect fit for this use case. [Automerge](https://automerge.org/) stood out as a CRDT sync engine since it is JSON-based, which meant that we were able to incorporate it into our existing data structures with minimal work. The Automerge project is led by some big names in the CRDT space which only reinforced that this was the solution for us. We also considered [Yjs](https://yjs.dev/) but ultimately decided on Automerge because of its JSON-based nature: to put it simply, manipulating a JSON object using traditional JSON methods is a far less steep learning curve than learning Yjs-specific functions, which for our team was paramount due to the turnaround time allowed for this integration. As an example: when using Yjs, you are required to instantiate an array using the [Yjs.Array constructor](https://docs.yjs.dev/api/shared-types/y.array), whereas Automerge would simply be a [JavaScript array (or [])](https://automerge.org/docs/reference/documents/lists/).

We implemented Automerge and it worked very well for the cast & crew management use case. So when we pivoted to tackle the bigger industry challenge of scheduling, we considered designing that app around Automerge and CRDTs from day one.

![](https://powersync.com/images/blog/why-cinapse-moved-away-from-crdts-for-sync-inline-fa0bba6de6.png "The Cinapse home page.||landscape")

## Building a collaborative app from scratch using Automerge

### Table stakes and differentiators

While offline availability was expected, we knew from the start that well-designed collaboration would be critical to differentiating our scheduling app from legacy competitors. At the time, the consensus was that CRDT systems were _the_ way to build offline-first apps. 

Our team was already familiar with the Automerge approach, so it felt natural to start there. Since collaboration and conflict resolution (sometimes at a fairly fine-grained level, like sortable lists) were core requirements, and Automerge was purpose-built for offline-first systems, it seemed like the perfect starting point to ensure the app could function as we envisioned.

We decided to choose our tech stack around Automerge and CRDTs rather than trying to build that in after the fact. Since scheduling is mostly done on large screen devices like laptops and iPads, a web app built with React was a good fit. Automerge is not difficult to set up, especially with the automerge-repo packages, and I still view it as an easy recommendation if you don’t have a project that will require large CRDT files with complex data structures.

### Automerge in a nutshell

Automerge is a CRDT library. V1 of Automerge was originally a JavaScript library, and was slow. This prompted the Automerge team to migrate to a Rust implementation which compiles to WebAssembly for use in JavaScript environments. This shipped with Automerge V2. 

Automerge V3 is a recent release, which optimizes the internals of the Rust library, making huge gains in the memory footprint of Automerge, e.g. bringing memory usage down by [more than 10x](https://automerge.org/blog/automerge-3/). We never had the opportunity to evaluate Automerge V3 because we needed a solution before it was ready.  

`automerge-repo` is a JavaScript wrapper for the Automerge CRDT library. It [provides](https://github.com/automerge/automerge-repo) all the plumbing for working with multiple documents as well as pluggable networking and storage. Automerge [recommends](https://automerge.org/docs/reference/the_js_packages/#relationship-between-automergeautomerge-and-automergeautomerge-repo) using `automerge-repo` as their batteries-included implementation.

### Constraints discovered

Because Automerge compiles to WebAssembly for use in JavaScript environments, and WebAssembly has a 32-bit memory model, there is a hard memory limit of 4GB.

For our scheduling use case, users typically work on the same file for an extended period of time: producing a film or TV series can take months or even years. This creates a really large history, which in Automerge V2 was contained in the CRDT itself. These large CRDT files require a lot of memory — frequently at the upper limit of the 4GB available.

Since `automerge-repo` is the recommended way to implement Automerge, our Automerge sync servers needed to run in a JavaScript environment (Node.js for us) and came with the same memory constraints mentioned above. This was the choke point of the system for us: to support a large number of files or even very large files, we needed to spin up additional servers purely because of this limitation.

As file sizes of our customers increased, we were forced to throw money at the problem just as a band-aid. We were burning around $1,000/month on Automerge sync servers for some customers with really large files. We needed to find a solution.

## Reasoning about alternatives

A core realization was that **the per-character tracking done by CRDTs was not necessary for our use case** , since the data structure that needed to be synced was not a giant chunk of text but rather individual properties or fields. At worst, we might need CRDTs within certain fields, but this was also unlikely since even though our system includes data used by multiple users, each user typically has a distinct role and mostly edits only their subset of data which is rolled up into the schedule view.

In general, for a scheduling use case like ours, the outline of the project is already understood by the time the scheduling happens. It would be more accurate to describe putting that outline into a schedule as an act of “translation” rather than the type of collaboration (e.g. text editing) that CRDTs are a good fit for.

With this insight, we became open to considering sync engine alternatives that were not based on CRDTs.

![](https://powersync.com/images/blog/why-cinapse-moved-away-from-crdts-for-sync-inline-dd7abae611.png "_A user input view showing individual properties and fields that need to be updated._")

## Alternatives considered

**Timeline was important for us** : we couldn’t continue burning money on infrastructure. For this reason we couldn’t wait for Automerge’s V3 release. Even though it seemed like a good option at the time, in hindsight it’s clear that V3 would still not have solved the problem of ever-growing CRDT file sizes. We looked into Electric-SQL but they were going through a rewrite.

So in addition to the hope that Automerge might release V3 soon enough to stop our bleeding, the alternatives we seriously considered were PowerSync, Yjs, and OrbitDB + IPFS.

For each of these alternatives, we tried to get an understanding of general pros and cons as well as migration complexity. Here are my notes from this evaluation:

### PowerSync

  * PowerSync provides a database replication-based solution that supports offline-first and real-time collaboration requirements without CRDT complexity.
  * Pros:   

    * Efficient Large File Handling: Instead of relying on a single JSON structure, it leverages a database-backed approach, which can better handle large datasets.
    * Offline-First: PowerSync’s model is offline-first by design, supporting local data storage and syncing with the server once back online.
    * Real-Time Collaboration: Enables real-time collaboration similar to CRDTs, but without the same overhead.
    * Security: Built with encryption capabilities for data at rest and in transit, aligning with your security requirements.
  * Cons:   

    * Migration Complexity: Migrating from automerge-repo could be complex, as it would involve restructuring your data from a single JSON model to a database-oriented model.
    * Custom Conflict Resolution: PowerSync does not inherently provide a CRDT-like conflict resolution model, so you may need to handle conflicts, especially in a last-change-wins scenario.
  * Migration Complexity:   

    * Data Model Transformation: Your current single JSON structure would need to be broken down and reorganized into a relational or NoSQL database format.
    * Sync Strategy: While PowerSync handles sync, you may need custom code to adapt Automerge’s sync semantics (e.g., merging timestamps) to PowerSync’s replication methods.
    * Offline State Management: automerge-repo’s built-in sync model would be replaced by PowerSync’s replication approach. This means that reading and displaying local data would require some additional overhaul, primarily due to the fact that the data is now in a database as opposed to an in-memory object.

### Yjs

  * Yjs is a high-performance CRDT library that supports real-time collaboration with a memory-efficient, binary-based approach. It is designed for scalability and can handle large documents better than Automerge due to its garbage collection mechanism and binary encoding.
  * Pros:   

    * Efficient Memory Usage: The binary encoding and garbage collection mechanisms help Yjs scale better than JSON-based CRDTs, making it suitable for complex and frequently updated data.
    * Real-Time and Flexible Sync: Yjs supports multiple network providers (WebSocket, WebRTC) and sync strategies, making it adaptable to various real-time needs.
    * Security: Yjs doesn’t inherently handle encryption, so encryption would need to be layered on top.
    * Conflict Resolution: CRDT-based, which inherently handles conflicts and merges changes without needing explicit logic.
  * Cons:   

    * Migration Complexity: Migrating from automerge-repo to Yjs may be more complex than transitioning to PowerSync due to different data structures and CRDT models.
    * Offline-First Limitations: Yjs is designed with real-time in mind, so implementing offline-first functionality requires additional layers or custom logic.
  * Migration Complexity:   

    * Data Structure Transformation: You’ll need to translate your JSON structure into Yjs’s more modular approach (e.g., Y.Text, Y.Map), which might require significant re-engineering.
    * Sync Layer: Adapting automerge-repo’s sync engine to Yjs’s multi-provider sync model could add complexity.
    * State and Conflict Resolution: Though Yjs handles conflicts well, implementing offline support would require additional code to manage state and conflict resolution after going offline.

### Automerge

  * Automerge is a JSON-based CRDT library that excels in offline-first applications by automatically syncing changes and resolving conflicts with a “last-write-wins” model. Its WebAssembly-based memory limit, however, makes it challenging to scale for large files.
  * Pros:   

    * Offline-First: Automerge is offline-first by design, making it ideal for applications that need local-first data handling with sync capabilities.
    * Automatic Conflict Resolution: Automerge’s CRDT model resolves conflicts automatically, which simplifies collaborative application logic.
    * Built-in Sync: automerge-repo’s built-in sync engine provides an end-to-end sync model out of the box.
  * Cons:   

    * Memory Consumption: Automerge’s JSON-based approach is memory-intensive and struggles with large files, constrained by WebAssembly’s 4GB memory limit.
    * Scaling Issues: For large files or datasets, Automerge’s performance deteriorates, impacting business performance, as we’ve experienced.
  * Migration Complexity:   

    * No migration needed

### OrbitDB + IPFS

  * OrbitDB, a peer-to-peer database, runs on top of IPFS (InterPlanetary File System) and allows offline and distributed data storage with eventual consistency. It’s designed for offline-first, decentralized applications and handles large data by distributing it across nodes.
  * Pros:   

    * Offline-First and Decentralized: Designed to work offline and sync over a decentralized network, which is ideal for distributed and offline-first use cases.
    * Efficient with Large Files: Leveraging IPFS’s DHT allows OrbitDB to store large files in a decentralized, memory-efficient manner.
    * Security: OrbitDB provides built-in data encryption and can operate securely over a distributed network.
  * Cons:   

    * Peer-to-peer database: peer-to-peer data synchronization is not ideal given our authoritative approach to data integrity.
    * More Complex Setup: IPFS and OrbitDB require more setup and a distributed infrastructure, which may be more complex to integrate than PowerSync.
  * Migration Complexity:   

    * Data Structure and Distribution: OrbitDB uses a document-store model, so migrating from a single JSON file may involve restructuring and distributing data.
    * Sync Complexity: OrbitDB’s sync model, which relies on IPFS, differs significantly from automerge-repo’s built-in sync engine. This would require re-architecting your sync layer and handling the switch from real-time to eventual consistency.
    * Security Layer: While OrbitDB provides encryption, ensuring consistency and data security during migration may need a custom setup.

A big reason for choosing PowerSync was that it theoretically allowed for a rework to the way that data is loaded in the UI that didn’t require a complete rewrite. In contrast, If we moved to Yjs, for example, the UI would need to be reworked to use Yjs structures (as mentioned above). The way that this is avoided with PowerSync is that data is loaded from the database into the exact same shape as the Automerge objects that had been used previously.

## Implementing PowerSync

Migrating to PowerSync did not come without challenges. For starters, the mental model was completely different and required converting our JSON structure into a database schema that allowed us to minimize rewriting code. Figuring out how to get existing code to work with both Automerge and PowerSync was a hard but important task, since it allowed us to migrate to PowerSync incrementally.

Here’s a snippet showing how we would load an element using our paradigm for loading “elements” via Automerge and PowerSync in a consolidated manner:

```tsx
export function useElement(id: string): { element: Element | undefined } {
  const sync = useQueryParam('sync')
  const powersync = useMemo(() => sync === 'v2', [sync])

  //both hooks run due to React restriction
  const automergeData = useElementAutomerge(id)
  const powersyncData = useElementPowersync(id)

  return useMemo(
    () => (powersync ? powersyncData : automergeData),
    [automergeData, powersync, powersyncData],
  )
}

function useElementAutomerge(id: string): { element: Element | undefined } {
  const [document] = useDocument() //automerge-repo/react provided hook

  const { element } = useMemo(() => {
    const allElements = document?.elements ?? {}
    const element = allElements[id]
    return { element }
  }, [document?.elements, id])

  return { element }
}

function useElementPowersync(id: string): { element: Element | undefined } {
  const fileId = useQueryParam('id')
  const db = useKysely() //custom kysely wrapper around powersync db
  const query = useMemo(
    () =>
      db
        .selectFrom('element')
        .selectAll()
        .where('id', '=', id)
        .where('file_id', '=', fileId)
        .limit(1),
    [db],
  )

  const { data: rows, ..._rest } = useQuery(query)

  const element = useMemo(() => {
    if (rows?.length !== 1) return undefined
    const row = rows[0]
    if (!row) return undefined
    const element: Element = {
      id: row.id,
      isHold: Boolean(row.is_hold),
      ... //rest of assignments
    }

    return element
  }, [rows])

  return { element }
}
```
In addition, denormalizing data and making sure we were using the correct references was tedious at times, and because PowerSync doesn’t support relations and constraints out of the box, queries that work client-side sometimes fail when it needs to be synced. 

## Post migration experience

Since migrating to PowerSync’s server-authoritative model, the impact has been significant:

  * **Support Load**   

    * We saw an **89% reduction in support requests** , largely because the infrastructure now handles large datasets far more reliably.
  * **Costs**   

    * **Hosting expenses dropped by 66%** , and even with the user base doubling, costs have only climbed back to about 50% of what they were originally.
  * **Throughput**   

    * Raw throughput was technically faster with Automerge, since changes were consolidated per client. PowerSync’s approach processes changes on the server instead, which trades some throughput for consistency and reliability at scale.
  * **Data Integrity**   

    * Data reliability improved substantially. Automerge struggled with memory constraints and in-memory document limits, whereas PowerSync saves and reads directly from the database, avoiding those pitfalls.

PowerSync fundamentally solved our scaling and reliability challenges. The server-authoritative architecture delivers deterministic synchronization that performs consistently whether users are working on small Indie projects or enterprise-scale productions. Offline functionality now works reliably: users can disconnect for hours or days, make extensive changes, and trust that everything will reconcile correctly when they reconnect. 

More importantly, PowerSync eliminated an entire class of infrastructure problems that previously consumed engineering resources and generated support tickets. Where we once spent significant time firefighting data integrity issues and memory constraints, we now have a system that scales predictably and requires minimal intervention. The combination of reduced operational burden, lower costs, and rock-solid reliability has allowed us to focus on building features instead of maintaining infrastructure.

---

# Collaborative Text Editing Over PowerSync

> This blog post describes the resulting demo of collaborative text editing over PowerSync. The demo uses Tiptap as the editor, has basic support for shared cursors and anonymous share links, and includes a "Sync Active" toggle that you can use to try out concurrent edits.

- Published: 2025-09-30
- Author: Matthew Weidner (Guest Author)
- Category: Engineering
- Source: https://powersync.com/blog/collaborative-text-editing-over-powersync

---

PowerSync is an open-source devtool that syncs between your own backend database and in-app SQLite databases on your users' devices. It guarantees [Causal+ Consistency](https://docs.powersync.com/architecture/consistency) while allowing partial replication and offline work, handling the tricky parts of network retries, browser storage, and cross-tab sync. This makes it a great tool for offline-capable collaborative apps where you want to remain in control of your backend.

The PowerSync Service specifically syncs rows, filtered by [sync rules](https://docs.powersync.com/usage/sync-rules) that you define. This works well for CRUD operations, but what about a Google Docs-style collaborative text document, which allows fine-grained edits that don't translate well to row-level changes?

After meeting at [Local-First Conf](https://powersync.com/blog/local-first-conf-2025-reflections), Kobie and Conrad from the PowerSync team reached out to me about tackling this problem. In particular, they asked if I could implement my talk [Collaborative Text Editing without CRDTs or OT](https://mattweidner.com/2025/05/21/text-without-crdts.html) on top of PowerSync - a great opportunity to turn that idea into a working prototype!

This blog post describes the resulting demo of collaborative text editing over PowerSync. The demo uses [Tiptap](https://tiptap.dev/) as the editor, has basic support for shared cursors and anonymous share links, and includes a "Sync Active" toggle that you can use to try out concurrent edits.

If you're in a hurry, you can skip to the [demo repo](https://github.com/mweidner037/powersync-text-editing), or check out the [live version](https://powersync-text-editing-74afa9931793.herokuapp.com/).

## Approach

The basic idea of the demo is that, instead of trying to "fit" collaborative text into a database table, we merely record the log of all updates to the text. So, when a user inserts some characters, formats a range of text, etc., their client inserts a row containing that update (as arbitrary JSON) into their local PowerSync table.

Eventually, those rows reach the backend database - Supabase in the demo - which assigns them an auto-incrementing `server_version`. That establishes a canonical total order on updates. All clients compute the current text state by processing the updates in `server_version` order.

![image](https://powersync.com/images/blog/collaborative-text-editing-over-powersync-inline-a6f9367ee8.png)

What about local updates that haven't yet reached the backend, including updates that you performed offline or in another tab? Those are still in the local PowerSync table but have NULL `server_version`. We apply those _after_ all of the backend updates, in the order that they were inserted into the local PowerSync table. That gives us the expected "optimistic" state: the state that the text document will be in once the backend receives our updates, assuming no collaborators make edits before then.

### Text Updates

The hard part is knowing what to put in the updates' JSON. Naively, we could  use literal text updates such as `{ type: "insert", index: 17, char: "X" }`. However, this update breaks if, before it reaches the backend, someone else performs the update `{ type: "delete", index: 10 }`: that _changes the index_ of our desired insertion point (17 -> 17 - 1 = 16).

To solve this, we describe insertion points (and character positions generally) using unique per-character IDs instead of indexes. For example, if the user types "X" following a character "W" with ID "abc123", we send an update like `{ type: "insert", afterId: "abc123", char: "X", newId: "def456" }`.

Our actual updates are [ProseMirror steps](https://prosemirror.net/docs/ref/#transform.Steps) but with the ProseMirror positions (indexes) replaced by per-character IDs like above. These IDs are generated and stored by the [Articulated](https://github.com/mweidner037/articulated) library that I made for my Local-First Conf talk.

### Vs A CRDT?

Instead of ProseMirror steps + character IDs, we could have gotten our updates from a [Conflict-free Replicated Data Type (CRDT)](https://crdt.tech/) for rich text, storing each CRDT operation as a row. In fact, PowerSync already has a [Yjs demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/yjs-react-supabase-text-collab) that works this way. The CRDT axioms then guarantee that we can apply operations in any order or even multiple times and still get a consistent result across users.

Why does this prototype take a different, non-CRDT approach? In brief: PowerSync's architecture makes it possible to obtain a consistent total order on updates, with no duplicates. Thus the CRDT rules are not necessary: you're allowed to choose arbitrary (deterministic) updates and you'll still get a consistent result across users.

Bring-your-own updates have some nice properties:

  * Transparency: You can "see" what the updates are doing, since they are defined by your own application logic instead of an external library's CRDT internals.
  * Flexibility: You control how updates are generated and applied, so you can tweak how they interact with conflicting updates, or generalize them to add new functionality - without first becoming a CRDT expert. (E.g., ignore letters inserted inside words that were just deleted.)
  * Authority: Your updates can enforce invariants on the output state, and [your backend can rewrite or reject updates](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer#server-authority-instead-of-distributedcrdt-architecture) if desired for e.g. fine-grained authorization rules.

## Implementation Notes

### Querying the Update Log

 _Relevant code:_[_server_reconciliation.ts_](https://github.com/mweidner037/powersync-text-editing/blob/8f7a9fb03a82cd72cca591cbc7bd43b09f0c68b0/src/library/powersync/server_reconciliation.ts)

Recall that to compute the current text state, each client applies all updates in the order: updates from the backend ordered by `server_version`, followed by (optimistic) local updates in the order that they were inserted into the local PowerSync table.

We can query the local insertion order using SQLite's [rowid](https://www.sqlite.org/lang_createtable.html#rowid) column. Thus we can obtain the complete update log using a PowerSync query like:

```sql
SELECT "update" FROM text_updates
WHERE doc_id=?
ORDER BY server_version NULLS LAST, rowid;
```
Because of how PowerSync works, `text_updates` is actually a view instead of a table in the local SQLite database (though it's a literal table in the backend database). To get at the `rowid`, we need to query the underlying table

```sql
SELECT
  CAST(json_extract(data, '$.doc_id') as TEXT) AS doc_id,
  CAST(json_extract(data, '$.update') as TEXT) AS "update",
  CAST(json_extract(data, '$.server_version') as INTEGER) AS server_version,
  rowid
FROM ps_data__text_updates
WHERE doc_id=?
ORDER BY server_version NULLS LAST, rowid;
```

Luckily, PowerSync's watched queries allow this; we just need to do some extra work (normally handled by the view) to extract columns from the table's `data` JSON blob:

### Incremental Updates

It would be inefficient to re-run the above query every time the update log changes. Instead, we want to update the current state incrementally, applying new updates as they arrive.

A recent PowerSync feature, [High Performance Diffs](https://releases.powersync.com/announcements/get-high-performance-diffs), makes this possible. After running the above query once to get the initial state of the log, we use `powerSync.triggers.trackTableDiff` to watch for newly inserted rows and rows that change `server_version` (when they are acknowleged by the backend). That lets us update the text state without doing `O(# total updates)` effort.

One wrinkle: due to concurrency, the new/changed rows are not necessarily last in the log. In particular, because the demo uses [Priority 0 sync](https://docs.powersync.com/usage/use-case-examples/prioritized-sync#special-case%3A-priority-0), new updates from the backend might appear "underneath" optimistic local updates. We handle this using [Server Reconcliation](https://mattweidner.com/2024/06/04/server-architectures.html#1-server-reconciliation), a generic strategy for collaboration over a central server.

### Batched Uploads

 _Relevant code:_[_SupabaseConnector.ts_](https://github.com/mweidner037/powersync-text-editing/blob/8f7a9fb03a82cd72cca591cbc7bd43b09f0c68b0/src/library/powersync/SupabaseConnector.ts)

Another important optimization is batched uploads. Each keystroke generates a new update, hence a new database row, which PowerSync asks us to upload to our backend (here Supabase). If we upload these rows one at a time - calling `await` on each call to the Supabase API - then they'll upload pretty slowly, potentially more slowly than you can type.

Instead, the demo uses the [pre-sorted batch strategy](https://docs.powersync.com/tutorials/client/performance/supabase-connector-performance#pre-sorted-batch-strategy) described in PowerSync's docs. This uploads new rows to Supabase in batches, avoiding a separate network round-trip per keystroke.

## Conclusion

The demo is a prototype, so expect some rough edges. For example, PowerSync tolerates inserting a new database row per keystroke, but it would be wise to optimize this:

  * Throttle writing to PowerSync so that each row describes a few characters, if the user is typing rapidly.
  * Periodically "compact" the updates, replacing them with the resulting document state.

We're also interested in polishing (& thoroughly testing) the reusable pieces of the demo - [shared presence over PowerSync](https://github.com/mweidner037/powersync-text-editing/blob/8f7a9fb03a82cd72cca591cbc7bd43b09f0c68b0/src/library/powersync/usePresence.ts), a [generalized server reconciliation hook](https://github.com/mweidner037/powersync-text-editing/blob/8f7a9fb03a82cd72cca591cbc7bd43b09f0c68b0/src/library/powersync/server_reconciliation.ts), and [rebaseable ProseMirror steps](https://github.com/mweidner037/powersync-text-editing/blob/8f7a9fb03a82cd72cca591cbc7bd43b09f0c68b0/src/library/tiptap/step_converter.ts) \- before making them available as separate tools.

I personally have learned a lot about PowerSync (& ProseMirror steps) from working on this project, and I'm grateful for the opportunity to make a collaborative text demo that has proper reconnection & offline support - all handled by PowerSync - instead of my usual basic WebSocket servers :)

You can find the demo code at https://github.com/mweidner037/powersync-text-editing.

---

# Speeding Up PowerSync With A SQLite Extension Written In Rust

> How we increased engineering velocity and sync performance in PowerSync’s cross-platform SDKs using Rust.

- Published: 2025-09-16
- Author: Simon Binder
- Category: Engineering
- Source: https://powersync.com/blog/speeding-up-powersync-with-a-sqlite-extension-written-in-rust

---

PowerSync is an automatic sync engine for syncing data between different kinds of backend databases and SQLite. This is enabled by a custom protocol designed to correctly capture source database state, with checks at critical steps of the sync process enabling our [consistency model](https://docs.powersync.com/architecture/consistency).

PowerSync offers SDKs for popular programming languages and historically, each of our SDKs implemented most of this protocol themselves. That initially worked quite well for us,  and it’s nice that we’re able to integrate with networking libraries available on the target stack (allowing e.g. the PowerSync Kotlin SDK to reuse a ktor client configured by the app developer).

However, the SDK implementations were not without issues:

  1. We have features on our roadmap requiring protocol additions, and we’d like to avoid updating four different client implementations each time.
  2. While we support both a text (JSON) and a binary (BSON) protocol, we prefer BSON for efficiency. Not all of our SDK targets have a good BSON library available though.
  3. In particular for React Native, the JavaScript implementation wasn’t as performant as we’d like. Profiling React Native is also quite challenging, with the official suggestions not yielding anything more helpful than a “yup, your JavaScript app is indeed busy running JavaScript”.

It was clear that we’d have to do something about this. While a shared client is the obvious solution, the exact details are less clear:

  * We want to continue being good citizens of the platforms we build on, instead of e.g. linking a full HTTP client as part of our SDK and ignoring the underlying ecosystem.
  * A key part of PowerSync is that it’s “just SQLite”, and it needs to work with a wide range of SQLite libraries. If we write a native client, we’d have to write bindings for each target SDK using e.g. JNI, `dart:ffi` or JSI.

While the first point prevents us from sharing anything that requires IO, it doesn’t mean that we can’t share any logic between our SDKs. We’re already using a custom SQLite extension written in Rust to define a few virtual tables and SQL helper functions, so our idea was to expand that extension to include a client state machine for the PowerSync protocol. The extension would be responsible for reacting to data received from the network and writing changes to the database, while SDKs open the HTTP stream and forward data into the client.

## Architecture

Our SQLite extension is a Rust crate. To make it as easy as possible to load it on different platforms (we need to, for instance, support WebAssembly without Emscripten or any other JS glue code), we are quite strict about reducing external dependencies as much as possible. The crate is `no_std`, and we rely on SQLite’s allocator, mutex, and randomness implementations where necessary.

We keep the client’s state in-memory in Rust, while relying on our SDKs to forward external events (like a new chunk of sync data received from the network). To avoid new custom binding code, the state machine is driven by a SQLite function we call `powersync_control`:

  1. It is invoked with parameters encoding an event, e.g `powersync_control('binary_line', <blob>)` indicating new binary data from the network.
  2. The function returns a JSON array of _instructions_ for the client SDK, such as:
     1. Persisting changes and updating user tables based on received data.
     2. Updating user-visible progress counters or other sync state information.
     3. Validating checksums received from the protocol.
     4. Emitting errors and reconnecting after a delay.

Most of the Rust client was a fairly straightforward port of the other clients. Decoding BSON was a fun issue: Since the `bson` crate does not support `no_std` environments, we wrote our own parser as a `serde` deserializer.

We have adopted the Rust client as an option in our public SDKs, with relatively few changes required for that. After all, we had a client in there already and just had to rewire things to forward lines to the extension instead of parsing it in the SDK. Importantly, we didn’t have to change any part of the build logic or configure new FFI/interop bridges.

Since the public API of our Rust client is a SQL function, we get to keep using our existing SQLite libraries.

## Results

One of the most immediate benefits we noticed with the Rust client was a modest performance increase on React Native: Depending on the exact scenario, the new client is around 5 times faster than the JavaScript-based implementation! While that may not sound like much to developers used to JavaScript generally being slow, a more convincing metric may be that, in isolated benchmarks, we now spend almost all of the time actually inserting data. So the performance increase is a reduction of parsing overhead, and we’re about as fast as SQLite can write to disk now.

After a deeper profiling analysis on the original JS client, we learned that we spend almost all of the time decoding UTF-8 (using a polyfill, because Hermes doesn’t implement `TextDecoder`). This is terrible of course, but it also validates the idea of moving that logic to Rust - there simply isn’t a way to fix that in JS without introducing native dependencies.

There is still a considerable performance increase outside of React Native and our other SDKs though.

Another benefit of the core extension being written in IO-free Rust is that it’s much easier to test. Testing the sync process on our SDK requires mocking the HTTP client delivering data. Also, since the SDKs react to new data asynchronously, tests require an “add line“, “wait for next observable event from SDK”, “assert state” pattern that is more complex to write assertions for than the synchronous `powersync_control` function. So while we still have SDK tests to ensure that they’re using the Rust client correctly, this style of testing allows us to be more thorough and gives us more confidence in our sync client.

## Some regressions

The Rust client has been available as an experimental option on all our SDKs for a while now, and we’re working towards making it stable and the default option (which will also make our SDKs a bit smaller, which is especially relevant on the web). During testing, we encountered one interesting issue on the web: Sometimes, sync sessions would crash for seemingly no reason. While everything works up to a certain point, our SQLite extension suddenly thinks there’s no active session to use. A silent and platform-specific error in deterministic Rust code that only appears in some cases. What’s up with that?

Eventually, we realized this is a consequence of how we bind to SQLite on the web. We use the amazing WA-sqlite package to be able to ship different storage implementations depending on what the current browser supports. One problem solved by that library is that, while most storage APIs in the web are asynchronous, SQLite, being a C library, expects a synchronous file system. While there are tools to “asyncify” existing C code, those generally cause painful slowdowns.

Instead, WA-sqlite uses a clever hack that relies on the fact that prepared statements are, in a way, asynchronous state machines already: Every time that you call sqlite3_step(), the statement’s internal cursors are updated to find a new row. So when WA-sqlite finds that it needs to do asynchronous filesystem work in the middle of a statement, it returns a retryable error code from the low-level filesystem shim that SQLite bubbles up without permanently disrupting the statement. At the higher levels in JavaScript, that error is recognized, the internal promise is awaited and the step call is transparently retried.

While this works really well with regular SQL, our trick to expose stateful Rust code as SQLite functions has messed the whole thing up! There are plenty of places in the client where we’re stepping through statements in Rust. When those encounter an error, we’d reset our session and forward the error to the client. While this error handling strategy works great in normal circumstances, it breaks for non-fatal errors where we should be retrying instead. But of course, we can’t retry in Rust because we’re writing synchronous code completely unaware about the outer JavaScript promise. Instead, we will have to behave just like SQLite: Allowing our operations to get interrupted in the middle and then having the outer WA-sqlite library retry. Luckily, most of the sync client has the natural form of a state machine already. So what we ended up doing is:

  1. When we receive new data, we first persist it to the database.
  2. Only when that has worked do we update the in-memory state.

In most languages, it would be tricky to be vigilant about this. In Rust, it’s almost trivial! The first step receives an immutable reference to the in-memory state, so it literally can’t get this wrong. It then returns a description of the state machine transition, which the second step applies if everything looks good. This ensures that, even if we hit errors internally, we don’t lose track of the overall state and can retry the exact operation again. With that refactored, our web client was working just as well as the other platforms.

---

# Simplified Cloud Pricing Based On Data Synced

> Pro and Team plans now use one billing metric for data throughput: data synced. This replaces the existing sync operations and data processing metrics. We’re also increasing the overage rate for peak concurrent clients from $15 to $30 per 1,000. Overall, these changes should lower usage costs for everyone.

- Published: 2025-09-12
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/simplified-cloud-pricing-based-on-data-synced

---

## TL;DR

Pro and Team plans now use one billing metric for data throughput: _data synced_. This replaces the existing _sync operations_ and _data processing_ metrics. We’re also increasing the overage rate for _peak concurrent clients_ from $15 to $30 per 1,000. Overall, these changes should lower usage costs for everyone.

## Pricing challenges

Since launching PowerSync Cloud pricing back in 2023, we've gathered enough data to analyze our customers’ actual usage patterns, associated invoices, and our related infrastructure costs. Three things stood out:

  1. **_Sync operation_ billing spikes weren’t proportional to costs:** Customers often had big spikes in billing for sync operations, but our infrastructure costs didn’t spike in the same way. When there were excessive (and unexpected) spikes, we worked with customers directly to offset costs, but this was time-consuming for everyone involved.
  2. **Not all sync operations carry the same amount of data** : `MOVE` and `CLEAR` operations typically contain very little data, but they were being billed the same as other operations. If developers didn’t defragment regularly, the number of billed sync operations could be an order-of-magnitude higher than the number of rows actually synced. [Defragmenting](https://docs.powersync.com/usage/lifecycle-maintenance/compacting-buckets#defragmenting) is still a good idea, but the pricing impact was not sufficiently warranted.
  3. **_Data processing_ and _peak concurrent clients_ were undervalued:** The overage rates  for these metrics didn’t fully cover our infrastructure costs 

## What is changing

Here’s a refresher of how the billing metrics (mentioned above) are defined:

  * A _sync operation_ is when a single row is synced from the PowerSync Service to a client.
  * _Data processing_ is calculated as the sum of:   

    * _Data replicated_ from your source database(s) to PowerSync Service instances
    *  _Data synced_ from PowerSync Service instances to clients.
  * _Peak concurrent clients_ is the peak number of client connections active at the same time across all apps in your organization.

_Data synced_ is now the only metric we use to measure data throughput for billing. _Sync operations_ and _data processing_ metrics have been removed.

Additionally, the overage rate for peak concurrent clients will increase from $15 to $30 per 1,000 concurrent clients.

Pro and Team plans are still usage-based: the base fee includes a certain baseline usage allowance, and usage overages beyond that have an additional cost.

Here’s a summary of what’s changing:

### Pricing model comparison

| Infrastructure component | Previous model | New model |
| --- | --- | --- |
| Replication operations (count) | _not billed_ | _not billed_ |
| Data replicated (per GB) | Billed as data processing @ $0.15 per GB after the first 30 GB. | _not billed_ |
| Sync operations (count) | $2.00 per 1,000,000 after the first 10,000,000. | _not billed_ |
| Data synced (per GB) | Billed as data processing @ $0.15 per GB after the first 30 GB. | $1.00 per GB after the first 30 GB. |
| Peak concurrent clients (count) | $15 per 1,000 after the first 1,000. | $30 per 1,000 after the first 1,000. |
| Data hosted (per GB) | $1 per GB after the first 10 GB. | _no change_ |
  

### Previous model

![](https://powersync.com/images/blog/simplified-cloud-pricing-based-on-data-synced-inline-62f2253a5b.png)

### New model

![](https://powersync.com/images/blog/simplified-cloud-pricing-based-on-data-synced-inline-e31a16ef47.png)

Our [pricing page](https://powersync.com/pricing) has been updated, and new customers are already on the new model.

## How we reasoned about it

Our goal was to reduce the impact of sync operation spikes on customers, while making sure that our relevant infrastructure costs are covered.

In practice, every sync operation already contributes to data processing, which can be calculated as: the number of operations synced × the average size of a row. So when you sync a row, it contributes to both the number of sync operations and to data processing. 

By removing sync operations as a separate billing metric, your usage is now mainly measured in data terms (GB). This is more intuitive for developers to reason about, keeps billing simpler, and ties in better with our actual cost driver — the infrastructure needed to move data. 

To make this sustainable, we had to look into increasing the $ rate for _data synced_ (in our current model this forms part of the _data processing_ line item). Historically, our infrastructure costs for replicating data have been lower than for syncing data. Increasing the rate for _data processing_ as a whole meant our customers would pay disproportionately more for replicating data. We therefore decided to drop _data replicated_ as a billing line item, and only bill _data synced_. We set the data synced rate to $1.00/GB, which is closer to our real infrastructure costs.

Our infrastructure costs for handling concurrent clients are currently over $50 per 1,000 clients. The previous $15 rate was far below that. We’re raising it to $30 — still well under our actual costs — to strike a balance between covering more of the cost and avoiding too steep a jump for existing customers. Over time we hope we can lower costs for this metric by optimizing our infrastructure further.

## Impact on existing customers

We looked at each of our existing Pro and Team plan customers’ historic usage and invoices, and simulated their future billing using the new model. The outcome: 99% of customers will be paying less under the new pricing model, assuming similar usage.

We are working with existing customers to migrate them to the new pricing model and are aiming to have everyone migrated by 31 October 2025.

If you have any questions, feedback or concerns about this update, please [get in touch](https://powersync.com/contact).

Overall, we hope this will simplify billing and reduce billing surprises around sync operations.

---

# PowerSync Update: August 2025

> This update covers what we shipped in August and upcoming Sync Streams: a major update to our dynamic partial replication system.

- Published: 2025-09-11
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-august-2025

---

As builders we're often focused on what comes next, but it's also important to reflect on what we've shipped. This edition's feature story is about the upcoming Sync Streams — a major update to our dynamic partial replication system. Skip to "Feature story" for that.

## Product updates shipped in August:

  * **Database adapters**   

    * Our MySQL support has been promoted to Beta. This means it’s now considered stable for production use, and is fully covered under our support SLAs (although resources like docs and demo apps may still be somewhat on the thin side — that’s for V1).
  * **Client SDKs**   

    * Our Node.js client SDK has also been promoted to Beta.
    * It’s currently possible to batch client mutations for uploads using `getCrudBatch()`, but this does not respect transaction boundaries. So we added `getCrudTransactions()` to batch transactions when uploading mutations. See [Dart](https://github.com/powersync-ja/powersync.dart/pull/320), [Kotlin](https://github.com/powersync-ja/powersync-kotlin/pull/245) and [JS](https://github.com/powersync-ja/powersync-js/pull/693) PRs.
    * In our [July update](https://powersync.com/blog/powersync-update-july-2025), I wrote about incremental watched queries for JS that can avoid re-renders when dealing with large datasets. This was essentially patching the underlying behavior — SQLite queries would still re-run on any table change with the diff being calculated in memory on top of that. Some use cases need the same end result, but more efficient SQLite performance, so we [shipped](https://docs.powersync.com/usage/use-case-examples/high-performance-diffs) high-performance diffs in our JavaScript SDKs that use SQLite triggers.
    * We added a bunch of stuff to our Swift support: enabled [SwiftUI Previews](https://github.com/powersync-ja/powersync-swift/pull/71), strict [concurrency checking](https://github.com/powersync-ja/powersync-swift/pull/70) for Swift 6, and a new full-text search [demo app](https://github.com/powersync-ja/powersync-swift/pull/76).
  * **PowerSync Cloud**   

    * You will now get an email when your usage reaches (or exceeds) what’s included in your PowerSync Cloud plan. We announced this [on Discord](https://discord.com/channels/1138230179878154300/1138230180813479968/1412084866509438979). In the future we’ll be adding budgeting tools to cap spending, but that’s a tricky problem since we don’t just want to turn off actively syncing instances.
  * **PowerSync Service**   

    * We released [v1.15](https://releases.powersync.com/announcements/powersync-service) of the service, which has a solid number of improvements and additions:
    * We added automatic configuration for Supabase asymmetric JWT signing keys (JWKS) when using Supabase Auth and a Supabase-hosted database ([PR #311](https://github.com/powersync-ja/powersync-service/pull/311))
    * We enabled transport compression for both HTTP Streams and WebSockets, reducing initial sync download size by a whopping 80%. Next up: client-side storage compression.
    * Support for Sync Streams. See below.

## Behind the scenes

  * We have a strong culture of writing internal proposals for new features at PowerSync, and we started publishing those publicly now. See Conrad’s [announcement](https://discord.com/channels/1138230179878154300/1145797047128170537/1412421799341461575) on Discord for our first batch of proposals. 
  * Community contributions:   

    * `omnicpie` [fixed](https://github.com/mongodb/node-mongodb-native/pull/4587) a nasty bug in the official MongoDB Node.js driver used by the PowerSync Service (OK OK, technically not a community contribution _to_ PowerSync, but this was amazing to see and we can undo our workaround fixes now).
    * `whygee-dev` [got the ball rolling](https://github.com/powersync-ja/powersync-kotlin/pull/222) for the batched transaction uploads I mentioned above.
    * `Radiokot` [fixed](https://github.com/powersync-ja/powersync-kotlin/pull/242) some logging issues in our Kotlin SDK.
    * `ecstatic-morse` [added a note](https://github.com/powersync-ja/powersync-docs/pull/219) to our docs explaining the consequences of ID aliases when uploading.  
  * A few creative apps using PowerSync were shared on our #showcase channel. Check out [Frontiers Market](https://frontiersmarket.com/), [PuffinPilot](https://puffinpilot.app/) and [Whelper](https://www.whelper.com/).
  * Christiaan wrote a [post on what synced SQLite brings to Expo Apps](https://expo.dev/blog/what-synced-in-app-sqlite-brings-to-expo-apps) that was featured on Expo’s blog.
  * We [worked with](https://github.com/mweidner037/powersync-text-editing) Matthew Weidner on using PowerSync as an experimental testbed for his work on [Collaborative Text Editing without CRDTs or OT](https://mattweidner.com/2025/05/21/text-without-crdts.html).

## Feature story: Sync Streams

I usually keep the content in these emails to things we’ve shipped, but Sync Streams will be such a fundamental change to the product that I wanted to take some time to tell you about what’s coming.

Sync Streams is an evolution of our Sync Rules system, and it's significant enough to warrant a name change. Our Sync Rules system was initially designed for offline-first use cases where you want to “sync everything upfront” when the client connects. By contrast, Sync Streams is a configurable system that’s optimized for the best of both worlds: it caters for dynamic on-demand syncing, as well as “sync everything upfront” that’s needed for offline-first.

A Sync Stream is a parameterized subset of data that clients are able to subscribe to just-in-time. You define your streams upfront, and a client can subscribe to them one or more times with different parameters. Imagine a web app use case where users open up multiple projects in different tabs. Sync Streams are perfect for this kind of use case where your users are mostly online, and they only need to sync contextual data for the specific things they’re looking at — each tab subscribes just-in-time to just the specific project the user is viewing. It naturally works great for multiple tabs, since multiple subscriptions across tabs are automatically handled. Each subscription includes a configurable `TTL` that keeps data active after the client unsubscribes, acting as a warm cache for recently-accessed data. 

If you want “sync everything upfront” behavior, that’s easy too: you can configure Sync Streams to be auto-subscribed by the client on connecting.

As a side-effect of all this work, we’ve also simplified the syntax and mental model compared to Sync Rules, delivering significant DX improvements across the entire stack.

It should go without saying, but we will offer a smooth migration path as well as a proper LTS plan for customers using Sync Rules, and we’ll never compromise on our offline-first support.

That’s it for this issue!

---

# React Native Local Database Options: A Comprehensive Summary

> A comprehensive summary of local database options for React Native. Includes various SQLite packages, WatermelonDB, RxDB, Realm.

- Published: 2025-08-27
- Updated: 2025-08-27
- Author: Kobie Botha
- Category: Engineering
- Source: https://powersync.com/blog/react-native-local-database-options

---

## Local-First for React Native

A few years ago, the only reason to consider a local-first app architecture was if advanced offline functionality was a hard requirement for your app[^1]. More recently though, giving users a real-time collaborative UX (like [Figma](https://www.figma.com)) has been [enticing enough](https://powersync.com/blog/offline-first-local-first-is-a-big-deal-especially-for-the-web) for more developers to venture down the path of local-first.   

In particular, the interest in building React Native apps with local-first architecture is on the rise. New tools and tutorials[^2] make it easier than ever to get started with a local-first React Native app. More and more developers are realizing that local-first is not simply a way to provide certain features (e.g. real-time reactive UI, offline mode, real-time collaboration), but rather an architecture that avoids a lot of the complexities that come with modern cloud-first apps (e.g. caching, optimistic updates, etc.)  

Part of what makes local-first appealing for React Native is that it inherently provides a simple approach to state management. There are many good state management frameworks available like [Zustand](https://zustand-demo.pmnd.rs/), [Redux](https://redux.js.org/) and [MobX](https://mobx.js.org/README.html), but local-first provides a different paradigm: using a local database (e.g. SQLite) to manage state[^3]. Coupled with tools like [Kysely](https://kysely.dev/) (a SQL query builder) and [TinyBase](https://tinybase.org/) (a reactive in-memory data store), using a local database for state management becomes even more accessible.

## React Native Local Database Options

The growing interest in local-first architectures for React Native led us to further explore the various local database options in the React Native ecosystem. Evaluating each requires diving a bit deeper into their code, and also having an idea of what you’re looking for.  

We created the table below to show the main options available with key features that should help you decide which local database will work best for you. Good luck!  

### Preface

This breakdown only consists of local database options that provide full database functionality (persistent, consistent and queryable data stores). We ignored less-featured databases and caches. For example, we haven’t included [react-native-mmkv](https://github.com/mrousavy/react-native-mmkv) or [async-storage](https://github.com/react-native-async-storage/async-storage).  

All of the below databases are open-source.

### Comparison Table

| Database / Package | Description | Type | Asynchronous by Default? | Concurrency | Encryption Support | Web Support | Query Method | Plug-in Cloud Sync Support | Backend Database Type |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [react-native-nitro-sqlite](https://github.com/margelo/react-native-nitro-sqlite) | Nitro SQLite embeds the latest version of SQLite and provides a low-level JSI-backed API to execute SQL queries. A fork of the original [react-native-quick-sqlite](https://github.com/ospfranco/react-native-quick-sqlite) (by [ospfranco](https://github.com/ospfranco)), which was deprecated in favour of OP-SQLite. | SQLite | Yes (has equivalent synchronous and asynchronous APIs for most operations) | No (single read or write transaction at a time) | No | No | SQL | No | - |
| [powersync-react-native-quick-sqlite](https://github.com/powersync-ja/react-native-quick-sqlite) | Fork of react-native-quick-sqlite with some optimisations and enhancements. **Note:** This is not meant to be used directly, without [PowerSync](https://powersync.com/). [^4] | SQLite | Yes | Yes (built-in support for one write transaction and multiple read transactions concurrently) | No (use OP-SQLite instead) | No | SQL | Yes (via [PowerSync](https://powersync.com/)) | Postgres, MySQL, MongoDB |
| [op-sqlite](https://github.com/OP-Engineering/op-sqlite) | Embeds the latest version of SQLite and provides a low-level API to execute SQL queries. | SQLite | Yes (has equivalent synchronous and asynchronous APIs for most operations) | Yes (multiple connections supported) | Yes (via [SQLCipher](https://docs.expo.dev/versions/latest/sdk/sqlite/#sqlcipher)) | No | SQL | Yes (via [PowerSync](https://powersync.com/)) | - |
| [expo-sqlite](https://docs.expo.dev/versions/latest/sdk/sqlite/) | Provides access to a SQLite database that can be queried through a WebSQL-like API. | SQLite | Yes (has equivalent synchronous and asynchronous APIs for most operations) | Likely yes (via WAL and manual connections) | Yes (via [SQLCipher](https://docs.expo.dev/versions/latest/sdk/sqlite/#sqlcipher)) | Yes (via WA-SQLite) | SQL | Yes (via [PowerSync](https://powersync.com/)) | - |
| [WatermelonDB](https://github.com/Nozbe/WatermelonDB) | Database framework that provides high-level abstractions for SQLite. | SQLite | Yes | No (single [Reader](https://watermelondb.dev/docs/Writers#advanced-readers) or [Writer](https://watermelondb.dev/docs/Writers) at a time) | No | Yes | ORM [^5] | Yes (bring your own backend implementation) | Backend-specific |
| [RxDB](https://rxdb.info/) | NoSQL database made for JavaScript applications supporting various underlying storage layers. | NoSQL | Yes | Unknown | Yes via encryption-crypto-js | Yes | Domain-specific | Yes (e.g. with [CouchDB](https://rxdb.info/replication-couchdb.html) server or any custom [GraphQL](https://rxdb.info/replication-graphql.html) endpoint) | NoSQL |
| [LiveStore](https://livestore.dev/) | LiveStore is a next-generation state management framework based on reactive SQLite and git-inspired syncing (via event-sourcing). | SQLite | No. Queries are performed against a synchronous in-memory DB. This DB is persisted asynchronously. [Docs](https://docs.livestore.dev/evaluation/design-decisions/#major-design-decisions) | No. Queries are executed synchronously on the main thread. | No ([docs](https://docs.livestore.dev/patterns/encryption/)) | Yes | ORM with the [ability](https://docs.livestore.dev/reference/state/sql-queries/) to perform custom SQL queries. | Yes ([docs](https://www.mongodb.com/docs/atlas/device-sdks/deprecation/)) • CloudFlare Workers • ElectricSQL • S2 (planned) • Custom sync integration | • CloudFlare syncing uses D1 (SQLite compatible) to persist LiveStore events. • Postgres DB used to store mutation event history when using ElectricSQL |
| [Realm](https://www.mongodb.com/docs/atlas/device-sdks/sdk/react-native/) ([deprecated](https://github.com/realm/realm-js)) | Object database originally maintained by Realm, then MonogoDB. | NoSQL | Yes | Unknown | Yes | Yes | Domain-specific | No (MongoDB Atlas Device Sync support [deprecated](https://www.mongodb.com/docs/atlas/device-sdks/deprecation/)) | NoSQL |

## Notes On Table Columns

### Type

Indicates whether the database is SQLite-based or NoSQL.  

### Asynchronous by Default

Indicates whether the database supports asynchronous operations; in other words, whether there is support that prevents the main thread from being blocked.

### Concurrency

This refers to the database’s ability to support multiple concurrent transactions.

### Encryption Support

Whether the database supports encryption, and if so, how.  

### Web Support

This refers to the library being compatible with plain JavaScript web or frameworks.   

### Query Method

Here the query methods are "SQL" or "ORM" for SQLite-based databases and "domain-specific" for NoSQL databases since they each have their own query syntax flavor.  

### Plug-In Cloud Sync Support

This refers to the database’s ability to plug into an existing sync system that keeps data in sync with a primary cloud database and across multiple devices.  

### Backend Database Type

This indicates the database type that the database sync solution supports.  

## Feedback

If you have feedback on this summary or have a suggestion for a feature or database to include, please let us know on [our Discord server](https://discord.gg/powersync).

[^1]: The concept of “offline-first” is a predecessor to “local-first” and there’s overlap between the two concepts.
[^2]: See an [example here](https://bndkt.com/blog/2023/building-an-offline-first-chat-app-using-powersync-and-supabase).
[^3]: See a previous post on [local-first state management with SQLite](https://powersync.com/blog/local-first-state-management-with-sqlite) for more on that.
[^4]: This will be available as a general-purpose SQL library in the near future.
[^5]: SQL is possible but [discouraged](https://watermelondb.dev/docs/CRUD#advanced-unsafe-raw-execute).

---

# PowerSync Update: July 2025

> What the PowerSync team was up to in July '25

- Published: 2025-08-12
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-july-2025

---

Sync engines keep becoming more popular in the app dev space, and we're thrilled to be part of the journey with you all. 

Here’s what we’ve been up to during July:

## Product updates

  * **Incremental watched queries:** see our feature story below :)
  * **Expo Go support via `@powersync/adapter-sql-js`:** Expo is a powerful framework for building React Native applications, but until now we weren’t able to support Expo Go because it doesn't support loading our native SQLite extension. To address this, we added support for SQL.js — a pure JavaScript implementation of SQLite. By loading both SQLite and the PowerSync extension in JS, developers can now bypass native builds entirely, enabling a faster and simpler setup when using Expo Go. There are some performance trade-offs when using a JavaScript-based SQLite engine, so this approach is not intended for production use. However, it significantly lowers the barrier to entry for developers getting started with Expo and PowerSync.
  * **(Experimental) Raw SQLite tables:** One of the benefits of PowerSync being based on a schemaless protocol is that developers don't have to care about migrations: the schema you pass to the SDK is used to create views over JSON data — so things like adding new columns will just work, with data being available immediately. The tradeoff of this convenience is that, since the clients don't use "real" SQLite tables, you can't use column constraints like foreign keys. For some complex queries, the performance of reading data from JSON instead of a structured table can also be limiting. This is why we've recently started experimenting with a feature called raw tables, where developers have full control (and responsibility!) of the SQLite tables to use. If you have use cases where raw tables could help, we'd appreciate your feedback. Specifically, we've heard that defining and migrating raw tables can be hard, and we'd like to look into integrations with packages to help with that. So if you've used raw tables, please reach out to us in our Discord!
  * **Email notifications for alerts:** Monitoring and alerting was previously something that had to be [built](https://gist.github.com/kobiebotha/7ab814ac48845c9c70a3d447b39e9864) using the PowerSync CLI or APIs, and many developers simply weren’t doing this. So we built an alerting and notification system! PowerSync can now email you when an alert on your instance fires or clears — like a database connection error or a replication problem — so that you can catch issues early. If you’re on a paid plan, webhooks are still available to notify external systems too. Learn how to set up alerts and email rules in the [Monitoring and Alerting docs](https://docs.powersync.com/usage/tools/monitoring-and-alerting).

## Inside Syncball

  * We’re trialing an approach of writing our proposals in public [on GitHub](https://github.com/powersync-ja/powersync-service/discussions/categories/proposals), instead of using internal documents. The first proposal to go public is about [write checkpoint protocol changes](https://github.com/powersync-ja/powersync-service/discussions/317). 
  * Thanks to [Doug](https://github.com/douglascayers), [Luc](https://github.com/LucDeCaf), [Felix](https://github.com/felixgourdeau) and [Sven](https://github.com/svenpaulsen) for their community contributions in July!
  * Simon penned his [reflections on Fluttercon USA](https://powersync.com/blog/my-reflections-on-fluttercon-usa-2025). He’ll also be presenting a talk on [Simpler state management with Dart on the server and synced databases](https://www.fluttercon.dev/speakers/simon-binder) at Fluttercon Europe in September.
  * Shoutout to the team at [Dumai](https://apps.apple.com/us/app/dumai-ai-voice-notes/id6746932965), who use PowerSync in their AI voice notes app (_dumai_ means _think_ in Ukrainian).

## Feature story: Incremental Watched Queries for powersync-js

PowerSync has always provided reactive watched query functionality — perfect for building real-time, reactive UIs with no need for polling or manual update hooks. However, React developers regularly wanted support for React memoization in `useQuery`-based components. 

Unfortunately, this wasn’t feasible due to limitations in our original implementation. This led to:

  * Watched queries emitting "updated" results even when the actual data hadn’t changed.
  * Unnecessary component re-renders, even when no UI update was required.

This meant the PowerSync JS SDKs weren't usable out of the box for advanced React apps, and we regularly saw developers building things like in-memory representations of SQLite data on top of PowerSync.

We’ve now addressed these concerns with the release of **Incremental Watched Queries**.

This is a fundamental upgrade that replaces our original `PowerSync.watch` methods, and introduces two new APIs:

  * `PowerSync.query().watch()`
  * `PowerSync.query().differentialWatch()`

These new APIs enable features like in-memory caching and shared query results. 

To avoid unnecessary emissions and re-renders, developers now provide:

  * A `comparator` function for `query().watch()`
  * A `rowComparator` function for `query().differentialWatch()`

These comparators detect meaningful changes between underlying SQLite updates. 

With `query().watch()`, false-positive updates are completely eliminated. And with `query().differentialWatch()`, we go even further — reporting exactly what rows were added, removed, or updated.

Differential queries also preserve JavaScript array object references for unchanged rows, which makes React memoization effortless to implement.

That’s it for this issue.

Thanks,

The PowerSync Team

---

# My Reflections On Fluttercon USA 2025

> Reflections on Fluttercon USA 2025 in New York, featuring insights on Dart’s upcoming code assets feature, highlights from standout talks, and thoughts on how the conference can improve.

- Published: 2025-07-30
- Author: Simon Binder
- Category: Showcase
- Source: https://powersync.com/blog/my-reflections-on-fluttercon-usa-2025

---

Last month, I had the opportunity to attend Fluttercon USA in New York to [present a talk](https://www.youtube.com/watch?v=xUNrykAIhsU) on the upcoming [code assets feature](https://github.com/dart-lang/sdk/issues/50565) in Dart and Flutter. Since I maintain the sqlite3 and drift packages that need to talk to SQLite under the hood, I’m really looking forward to that feature which will make it much easier for Dart packages to interop with native code.

I’ve been looking forward to the conference for a while - not only because it lets me share my excitement about upcoming Dart features in front of an interested audience, but also because this was the first public talk I’ve given! Despite being active in the community for a long time, I’ve never spoken at a conference before and this was an excellent time to change that. Apart from my own talk, the schedule also looked promising and made Fluttercon USA an event I didn’t want to miss.

Since it has also been a while since I’ve attended  a Flutter conference (I was at one in Berlin a few years ago), I want to use this post to share my impressions from this year’s conference in NYC!

![A roundtable discussion at Fluttercon USA](https://powersync.com/images/blog/my-reflections-on-fluttercon-usa-2025-inline-d9b4e877f3.jpeg  "Roundtable discussions also took place. Image: Fluttercon USA")

## Interesting talks and learning

One of the nicest things at Fluttercon was finally meeting all the amazing people I’ve only interacted with online before. I’ve had very pleasant conversations with [drift](https://drift.simonbinder.eu/) users, PowerSync enthusiasts, dart_community Discord members, other speakers and also just random people at the conference. The Flutter community is incredibly friendly, and interesting conversations are everywhere!

Something I really liked is the mix of introductory presentations all the way up to advanced talks and roundtable discussions. At a previous Fluttercon I attended, I had the impression that there were relatively few intermediate and advanced talks, so it was good to see more variance this time. Since I really enjoy the Dart language on its own, it was also good to see that there were many talks that aren’t exclusively relevant to Flutter. In addition to [my talk](https://www.youtube.com/watch?v=xUNrykAIhsU&list=PL9Pfzam3fFdeWOBXQ9JFwa63VMcVy8SWr&index=12) about native assets, there were two more dart:ffi-related talks and others discussing architecture principles in Dart.

As almost all talks were recorded, here are just three of the many good talks I was glad I could listen to. Maybe some of them are interesting to you as well:

  * [Mastering Dart Isolates: Custom Entrypoints for Smarter Background Processing](https://www.youtube.com/watch?v=8Od7C8IOas0&list=PL9Pfzam3fFdeWOBXQ9JFwa63VMcVy8SWr&index=40): This talk starts with an introduction of isolates in Dart, and then quickly goes over to Flutter-specific concerns for apps with non-trivial background tasks. I’m using isolates a lot in drift, but especially the challenges of running multiple Flutter engines for UI and background tasks were fun to learn about!
  * [Binding Native Plugins with Flutter and Dart](https://www.youtube.com/watch?v=FC9BKyueS8s&list=PL9Pfzam3fFdeWOBXQ9JFwa63VMcVy8SWr&index=3): This talk is somewhat adjacent to mine, but covers many more interop options and how they relate to each other. Definitely worth a watch if you’re interested in calling native libraries from Dart.
  * [Bringing a Legend to Life: Reimagining Rogue in Flutter](https://www.youtube.com/watch?v=gxJya_GNDYI&list=PL9Pfzam3fFdeWOBXQ9JFwa63VMcVy8SWr&index=14): This was a super fun talk about porting a game written in eighties-style C to modern Dart. I’ve never played Rogue and understood at most half of the references, but there was good advice about dealing with extremely legacy code bases in there!

Here’s the full [playlist on YouTube](https://www.youtube.com/playlist?list=PL9Pfzam3fFdeWOBXQ9JFwa63VMcVy8SWr).

## How Fluttercon can improve

Despite the amazing people and talks I was able to attend, one thing that stood out a bit was the venue. The weather during the conference was quite hot, and the location was not really suitable for that. I was told that’s a one-off though, so hopefully nothing that affects future Fluttercons.

Another first was that the conference was in a “Silent Disco” format, where, instead of using loudspeakers, we were supposed to listen with our phones over a wifi stream. In theory, that would make it easier to listen to another talk without having to switch rooms. In practice, the routers were quickly overloaded, leading to horrible latency and spotty audio. By the second half of the keynote, no one was using this anymore. Let’s hope we’ve all learned from that and don’t try it again.

## Consider attending Fluttercon if you…

If you’re keen to meet people from the Dart and Flutter community, Fluttercon is a great place to be at! You can always watch the talks online, but I don’t think I could have had all these conversations anywhere else. So if you enjoy Dart, Flutter and the community, this is the conference for you.

I will also be back for [Fluttercon in Berlin](https://www.fluttercon.dev/speakers/simon-binder) this year! So if you see me, come say hi!

![Simon Binder presenting at Fluttercon USA](https://powersync.com/images/blog/my-reflections-on-fluttercon-usa-2025-inline-bbb8b9b932.jpeg "Image: Fluttercon USA")

---

# PowerSync Update: June 2025

> We’re trying something new: inspired by the ink slingers at Fly.io, we’re experimenting with mostly text-based product newsletters. If you can get through this issue before your morning coffee hits the halfway mark, we’re doing it right. Here’s what we’ve been up to.

- Published: 2025-07-07
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-june-2025

---

We’re trying something new: inspired by the ink slingers at [Fly.io](http://fly.io), we’re experimenting with mostly text-based product newsletters. If you can get through this issue before your morning coffee hits the halfway mark, we’re doing it right.

Here’s what we’ve been up to:

## Product updates

  *  _Native Rust sync implementation:_ We recently started moving sync logic from client SDKs to our core SQLite extension, built in Rust: `powersync-sqlite-core`. In this setup (currently opt-in), client SDKs still handle network connections and streaming, but the SQLite extension now manages sync state and processing. The result is significantly improved performance. More about this in the feature story section below, or see the [release announcement](https://releases.powersync.com/announcements/improved-sync-performance-in-our-client-sdks).
  * We shipped multiple improvements to the PowerSync Service, the server-side component of the PowerSync system:  

    * _Resumable initial replication_ : When Sync Rules are updated, we perform initial replication from the source database using the new rules. This starts with a snapshot, followed by incremental changes. If the snapshot replication is interrupted, it previously had to restart from scratch. Now, it resumes from where it left off, resulting in better efficiency and reliability. Sources currently supported: Postgres and MongoDB.
    * _Postgres RLS checks:_ For Postgres, RLS is common and recommended on Supabase. Originally, Supabase only supported logical replication on the built-in `postgres` role. They’ve since added support for custom roles with the `REPLICATION` privilege. The problem was that switching to a custom role would silently break access to tables when RLS is in use: no error is shown, just empty results. PowerSync now checks whether RLS is enabled for every replicated table, and then logs a warning if you’re not using either a superuser or `BYPASSRLS`.
    * _Replication lag monitoring:_ It’s important to know if replicating changes from the source database to PowerSync becomes backlogged. This can happen for example if the rate of changes in the source database is very high. We now record the replication lag as a metric and output it in the logs, and it’s soon coming to the PowerSync Dashboard too.
    * _MySQL binlog backpressure handling:_ For MySQL, large bursts of binlog events could lead to out-of-memory errors due to unbounded size of the processing queue. We now cap queue memory use by pausing the binlog listener once a limit is hit, resuming after the queue drains or a certain amount of time has passed.
  * _.NET MAUI support:_ We’ve [added a PowerSync.MAUI package](https://github.com/powersync-ja/powersync-dotnet/pull/9) (and demo app) to extend our .NET SDK to iOS, Android, and Windows via .NET MAUI. It builds on `PowerSync.Common` and ensures the right platform-specific extension is loaded at runtime.

## Inside Syncball

(apologies to the folks at Fly.io for this one)

  * We’re hiring! In addition to other roles open on our [Join Us page](https://journeyapps.com/join-us/#opportunities), we’ve recently started looking for a [Design Lead](https://journeyapps.com/join-us/design-lead/) that comes with a wide range of responsibilities and impact.
  * We’ve been impressed by this month’s community contributions: shoutout to [David Martos](https://github.com/powersync-ja/powersync.dart/pull/289), [fethij](https://github.com/powersync-ja/powersync-kotlin/pull/205) and [Yahya Jirari](https://github.com/powersync-ja/powersync-js/pull/623)!
  * We’ve been writing developer documentation for over a decade but only just [documented our journey](https://powersync.com/blog/how-we-converged-on-the-optimal-docs-setup-for-our-devtool-product) (Readme.io → custom framework → GitBook → Mintlify).
  * Simon Binder (a.k.a. the [Drift](https://drift.simonbinder.eu/) guy) was on stage at Fluttercon USA, talking about how Dart’s upcoming _code assets_ functionality is a major improvement for [building cross-platform FFI packages](https://www.simonbinder.eu/talks/native_assets/).

## Feature story: Moving sync logic to our core Rust-based SQLite extension

We used to handle a significant amount of sync logic (processing and state management) in our client SDKs. It worked, but the performance was not as good as it could be, and it also meant that every new feature had to be re-implemented N times, once for each SDK platform.

So we started wondering, what if our native SQLite extension just did most of the work? We figured it would probably improve performance and reduce duplication of code. We’d been kicking the idea around for a while, but things got real when a customer syncing 100k+ rows started seeing brutal UI lockups on React Native. No amount of fine-tuning could fix it. That pushed us over the edge.

So we rewrote the sync client inside the core extension. Performance jumped way beyond expectations, and feature parity got a whole lot simpler. 

Here’s what initial data shows:

  * **React Native:** ~35% faster sync, with significantly better UI responsiveness
  * **Kotlin (1M rows)** : ~25% faster sync

We invite all users to try it out. See our [release notes](https://releases.powersync.com/announcements/improved-sync-performance-in-our-client-sdks) for instructions.

That’s it for this issue. Did you like it? Do you still have half a cup of coffee on your mug warmer? [Let us know what you think](https://fomr.io/s/mmwPwTaOhv).

---

# How We Converged On the Optimal Docs Setup For Our DevTool Product

> We've been writing developer documentation for over a decade. During that time, we've cycled through more documentation platforms than we’d like to admit: including various off-the-shelf documentation framework providers and building our own custom docs framework. Plenty of lessons were learned along the way.

- Published: 2025-07-02
- Author: Kobie Botha & Benita Volkmann
- Category: Engineering
- Source: https://powersync.com/blog/how-we-converged-on-the-optimal-docs-setup-for-our-devtool-product

---

We've been writing developer documentation for over a decade. During that time, we've cycled through more documentation platforms than we’d like to admit: including various off-the-shelf documentation framework providers and building our own custom docs framework. Plenty of lessons were learned along the way.

**TL;DR** : If you’re reading this post, you’re most likely not from a huge company like Supabase, so just use [Mintlify](https://mintlify.com/) 😊

# What we all aim for in devtool documentation

Stripe sets the gold standard for developer documentation. Their product is so deeply integrated with their docs that the two feel inseparable, showcasing the product in ways no generic framework could support.

As builders, it’s tempting to chase that level of quality by creating a custom documentation system from scratch. After struggling with the limitations of a SaaS docs provider ([Readme.io](https://readme.com/) at the time), we decided to do just that: develop our own React-based docs framework to deliver the experience we had in mind.

## Table stakes

Even though we aspired to reach Stripe’s standard, the main reason we built our own docs system was that no existing framework offered the baseline features we considered essential for developer documentation. Here’s what we saw as the table stakes:

  * Good versioning support. Whether it’s SDK, API or library versions, your docs will drift across these versions, and you want to make it easy for developers to switch versions.
  * Link management tools:  

    * You will want to write a page once and then reference it in multiple places using backlinks (basically the ability to easily refer to other pages within your docs).
    * When changing a page’s slug, you’ll want an easy way to manage redirects.
    * Nothing kills trust faster than clicking a link in the docs and getting a 404. Makes you wonder what else is broken. Gotta have broken link detection.
  * GitHub/git integration. Most of us are engineers and want to use the same tools we’re already used to.
  * A rich collection of specialized components for embedding code in your docs (e.g. code snippets with tabs / code groups).
  * A way for users to contribute to our docs.

That covers developer experience, but there were operational requirements too:

  * Analytics. We want to know which areas of our product are the most popular, and which users have most questions about. This is just one more thing you’ll need to wire up and maintain if you’re building yourself.
  * Easy to use and maintain: We’re a small team with no dedicated docs roles, so writing and improving docs is something almost everyone in the team needs to be able to jump in on. Fixing a typo in our docs should be something anyone from our leadership to engineering teams can do while waiting for attendees to join a Zoom call.

And so, with a clear idea of what we wanted, confidence that no existing framework could give us that, and the long-term goal of Stripe-level integrated docs, we set out to build our own system.

## Why you shouldn’t build your own documentation framework (in 2025)

In our product, PowerSync, we have the concept of the “network tarpit” — instead of working on core features, app developers are kept busy wrangling state management frameworks and network calls. We felt we had hit an analogous “custom framework tarpit”:

  * Once you build a docs framework, you need to:  

    * maintain it and the deploy pipeline
    * fix bugs
    * add features such as broken link detection
    * all of the above distracts from core product engineering work
  * For users of the framework:  

    * initial setup of toolchain can be tricky
    * no such thing as “make a quick change”
    * previewing changes in a staging environment as a whole other environment that needs to be managed

After too many cycles spent building our docs framework instead of our product, we admitted failure and made the humbling decision to mothball it and move to [GitBook](https://www.gitbook.com/). 

This was an immediate improvement. However, as we built out our docs over many months, we started to get worrying reports from users that our entire docs site was crashing. This would specifically happen on medium length pages with multiple code snippets:

![](https://powersync.com/images/blog/how-we-converged-on-the-optimal-docs-setup-for-our-devtool-product-inline-9958360e8d.png)

After months of back and forth with their team, we couldn’t find a solution. In the end, the best workaround to prevent crashes was to **disable syntax highlighting across our entire site**. We found that, oddly enough, syntax highlighting was being done on the server and not on the client. This was rough for us.

Interestingly, while writing this post we discovered that Supabase has this very same issue (although the page in the video below is 20x longer than our longest page). We’re also not sure whether GitBook has resolved this issue or not.

![](https://powersync.com/images/blog/how-we-converged-on-the-optimal-docs-setup-for-our-devtool-product-inline-c5ed80a78c.gif)

So, after all that, someone in the team suggested we check out Mintlify, which brings us to the next section…

## Why Mintlify is Awesome

After in-depth journeys across all the options (Readme.io → custom → GitBook → Mintlify), we are all Mintlify maximalists at this point (to be clear: Mintlify did not ask or otherwise encourage us to write this post). Their entry-level tier can be quite stiff for early stage startups, but their Hobby plan is so feature rich, we’d actually recommend that over something like [VitePress](https://vitepress.dev/) at this point. It will save you time at every corner.

Some things that really stood out for us about Mintlify:

First off, Mintlify spun up a demo of our existing docs overnight. It made it very easy to evaluate them in a real context, and saved us a lot of time. When that’s your first experience with a service it’s pretty hard to ignore.

We immediately noticed that our pages loaded much faster, including our bulkiest page with lengthy code snippets and syntax highlighting. Again, having the demo from Mintlify which included the majority of our content was important for this, as performance is not something we could have accurately tested had we just built a POC. 

We didn’t really need much more selling after this, but for completeness sake, these are the other main boxes that Mintlify checked for us:

  * They offer a git-based workflow in addition to a web-based WYSIWYG editor. Why this matters: For larger updates the git-based workflow is a must as we already mentioned. But if we quickly want to fix a typo or make a small update, and especially if we want to encourage anyone in the team to help with this, being able to do this easily and quickly in a web editor is super helpful.
  * Excellent customer service: we could easily ask them questions as we onboarded. With their help we had our site converted in a matter of days and they remained pretty responsive once we were live.
  * Extensive component library: We have yet to come across a component we want to use in our docs that Mintlify doesn’t support. We especially liked their various navigation options, e.g. grouping content into tabs, as well as having a sidebar means we can allow our readers to get anywhere in just a single click, without having one long overwhelming list of pages.
  * They’ve released tooling to help LLMs parse our docs so we didn’t have to do anything on that front to let the robots understand our docs. Out of the box we got options like llms.txt and the ability to copy pages in markdown for prompt contexts.
  * Also, our docs just looked really good.

We feel our JavaScript SDK reference page showcases a lot of what we discussed in this post, [see for yourself](https://docs.powersync.com/client-sdk-references/javascript-web).

It’s a big page, with a lot of code, but stays super responsive no matter where in the page you are. It uses a wide range of widgets, including Mintlify’s contextual component for LLMs.

Our users can easily contribute by clicking on Suggest Edits which takes them directly into a PR workflow on our docs [repo](https://github.com/powersync-ja/powersync-docs/tree/main).

---

# PowerSync Update: May 2025

> Some of us just returned from Local-First Conf, energized by the growing excitement among developers who recognize the value of sync. This helps fuel our ambition to be the most capable and developer-friendly sync engine available. Here’s the progress we made in May.

- Published: 2025-06-06
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-may-2025

---

Some of us just returned from Local-First Conf, energized by the growing excitement among developers who recognize the value of sync. This helps fuel our ambition to be the most capable and developer-friendly sync engine available. Here’s the progress we made in May:

## Local-First Conf 2025

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-a8d541d083.png)

We again joined Local-First Conf as a sponsor this year! We had a great time meeting many of you in-person. Thank you to everyone who stopped by our booth 🙌

[Read Conrad’s reflections on Local-First Conf](https://powersync.com/blog/local-first-conf-2025-reflections)

## Fine-Grained Update Tracking

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-1cdc9cae7b.png)

When handling writes in **`uploadData`** that involve complex fields like arrays or nested JSON, it's not always obvious what actually changed. You might need more detail than just the final state of the row. We’ve introduced tools for fine-grained update tracking in all SDKs.

[Read the release notes](https://releases.powersync.com/announcements/powersync-sdks-fine-grained-update-tracking-with-previous-values-metadata)

## React Native: OP-SQLite Driver Now In Beta

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-2cf1b0e749.png)

After multiple improvements since the alpha release, **`@powersync-opsqlite`** can now be used in production with the API considered stable.

[See the NPM package](https://www.npmjs.com/package/@powersync/op-sqlite)

## FlutterFlow Library Improvements

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-2bfc96c877.png)

V0.0.7 of the PowerSync FlutterFlow library added support for customizing how data gets uploaded to Supabase. This is useful for transforming array and JSON fields. V0.0.9 further added support for using backends other than Supabase.

[See the docs](https://docs.powersync.com/integration-guides/flutterflow-+-powersync#arrays%2C-json-and-other-types)

## macOS Support In Our Swift SDK

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-ef8d632a1d.png)

We added macOS support to our Swift SDK and enabled it in our demo app. The demo UX is very rudimentary but it serves as a working reference implementation of a native macOS app.

[Try it through the demo app](https://github.com/powersync-ja/powersync-swift/tree/main/Demo)

## Self-Hosting DX Improvements

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-0d8d6b6c3e.png)

We published a JSON schema for the PowerSync Service configuration. This can be used for validation and autocomplete of YAML configuration files. Also released is configurable health check probes.

[See the JSON schema PR](https://github.com/powersync-ja/powersync-service/pull/257) and [docs on health checks](https://docs.powersync.com/self-hosting/lifecycle-maintenance/healthchecks#health-checks)

## Docs Repo Now Public

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-87335dad5e.png)

Anyone can now make suggestions or improvements to our docs!

[Docs repo](https://github.com/powersync-ja/powersync-docs)

## Blog Post: Building Our Swift SDK With SKIE

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-9014453a74.png)

Steven Ontong covers the journey of building our Swift SDK, explaining some of the design decisions behind it.

[Read the blog post](https://powersync.com/blog/building-a-swift-sdk-with-skie-lessons-in-bridging-kotlin-and-swift)

## Blog Post: Kobie On Local-First Conf

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-5e8d89c5e1.png)

Ready for uncensored opinions and hot takes?

[Read the blog post](https://www.kobiebotha.com/blog/local-first-2025-retro)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-9adfb83386.png)

H/T **Ry Anderson** , **Yahya Jirari** and**fethij** for their contributions in May 🙏

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-79e2bef9a9.png)

**TimeAlign** : Impressive goal-oriented time management app by **Lyan** (**@.361º** on Discord).

[Check it out](https://www.timealignapp.com/)

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-f87b688222.png)

**RANKD** : App to find and book nearby tennis courts, also by **Lyan** (**@.361º** on Discord).

[Check it out](https://apps.apple.com/ca/app/rankd-tennis/id6461214091?platform=iphone)

![](https://powersync.com/images/blog/powersync-update-may-2025-inline-fbd820476e.png)

**Titan Gym App** : Cool workout tracker made by **@george__jose**.

[Check it out](https://www.titangymapp.com/)

That's it for the May update, happy coding!

---

# Local-First Conf 2025 Reflections

> Last week, I attended Local-First Conf in Berlin with 3 other members of the PowerSync team. We all had a blast. Here are some quick thoughts on the conference.

- Published: 2025-06-04
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/local-first-conf-2025-reflections

---

Last week, I attended [Local-First Conf](https://www.localfirstconf.com/) in Berlin with 3 other members of the PowerSync team. We all had a blast. Here are some quick thoughts on the conference:

## A unique gathering of like-minded people

Local-First Conf really stands out amongst the conferences I’ve attended over the years:

  * The density of talent is very high. The conference brings together a ton of very impressive developers and entrepreneurs.
  * At many other conferences, there are plenty of people who don’t seem particularly invested. Yet at Local-First Conf, it felt like everyone was passionate and invested in the common denominators of local-first software. You could almost feel the [excitement](https://x.com/ccssmnn/status/1927785836923236694) in the air, and it felt like everyone I spoke to was brimming with [enthusiasm](https://x.com/ItsAndreKoenig/status/1927772684215042237) and ideas.

## And yet it was a “big tent”

The attendees were like-minded while also being diverse. The idea of “local-first” brings together:

  * Academic researchers and industry
  * Big companies, small companies and individuals 
  * Pre-traction vs post-traction outfits
  * AI skeptics and AI accelerationists
  * Local-first idealists and SaaS-minded utilitarians

This made the event especially interesting, and led to interesting debates. I enjoyed the panel discussion on “The big questions of Local First”. I think [Aaron Boodman](https://x.com/aboodman) is a great spokesperson for the pragmatic view on sync engines as tools to improve user experience in web apps — as opposed to the broader ideals of local-first software around user ownership and longevity. I also applaud Aaron for taking a principled stance on excluding offline writes from [Zero](https://zero.rocicorp.dev/) for now. Aaron argued that Zero should rather not have support for offline writes than offer a half-baked solution — despite this being met with surprise and generating some controversy. I commend their focus.

“What is local-first and what is not local-first?” has been a hotly-debated topic over the last couple of years, and I think the community has made some progress on coming to terms on this. The original local-first [idealists](https://www.inkandswitch.com/essay/local-first/) have created a community of people that is very welcoming to divergent ideas, while the same organizing committee behind Local-First Conf is now also launching [SyncConf](https://syncconf.dev/), which will focus mainly on the idea of using sync engines to build better software. People who feel strongly about the original local-first ideals will find a home in Local-First Conf, whereas people who are interested in building better SaaS & PaaS using sync engines will gravitate towards SyncConf. I suspect many folks (including me) will want to attend both.

## The tools are maturing

It’s exciting to see that the local-first space is heating up. The tools in the local-first landscape are markedly maturing compared to last year. [PowerSync](https://powersync.com/) has expanded its capabilities significantly. Zero has evolved and tuned their ZVM system for incrementally materialized views for high performance. [ElectricSQL](https://electric-sql.com/) has done great work on creating an incremental adoption path for sync with its [TanStack DB](https://tanstack.com/db/latest) initiative and partnership. [Jazz](https://jazz.tools/) is making great progress. 

I was very pleased to speak to lots of people at the conference who are already using PowerSync or have come across it and want to try it out. A few of them were surprised that someone from PowerSync was not speaking at the conference, and they asked us why this is the case. Unfortunately, I don’t know why. We tried to get a chance to speak, to no avail. I can understand why it seemed odd to folks that every significant player in the local-first [landscape](https://localfirst.fm/landscape) was speaking at the conference except for PowerSync. Fortunately though, I had a chance to talk to organizer [James Arthur](https://x.com/thruflo?lang=en), who told me that this will be corrected at SyncConf, and hopefully at future installments of Local-First Conf too.

## Research is progressing

What’s also awesome is that first-principles research on local-first concepts continues to make great progress. There were great talks from Ink & Switch folks, including on [Keyhive](https://www.inkandswitch.com/keyhive/notebook/) and Beelay. I also really enjoyed Matthew Weidner’s talk on collaborative text editing without CRDTs or OT (he also wrote a [post](https://mattweidner.com/2025/05/21/text-without-crdts.html) about it).

## We are all on the same team

I’d like to echo what my colleague [Kobie](https://www.kobiebotha.com/blog/local-first-2025-retro) said: I’d love to see further collaboration amongst the rivals in the local-first tools landscape. Kyle Mathews of ElectricSQL told me that we should work together to grow sync and local-first into a larger movement, since it will benefit all of us. I agree wholeheartedly, and therefore I’m excited to support SyncConf alongside the ElectricSQL folks.

There’s a lot that we can learn from each other. I appreciated some of the wisdom shared at the conference. One of my favorite quotes from the talks is from Anselm Eickoff of Jazz: “With users you’re lucky if you see them fail once. With AI you can watch it fail repeatedly.” That cuts deep!

I would like to give huge kudos to the folks at Ink & Switch for starting this amazing movement, and to the organizers of Local-First Conf. Together, they have created something truly unique and brought together a fantastic group of people. I’m excited to remain a part of this collective and to contribute to growing it.

---

# Building A Swift SDK With SKIE: Lessons In Bridging Kotlin And Swift

> This post covers the journey of building our Swift SDK, explaining some of the design decisions behind it.

- Published: 2025-05-16
- Author: Steven Ontong
- Category: Engineering
- Source: https://powersync.com/blog/building-a-swift-sdk-with-skie-lessons-in-bridging-kotlin-and-swift

---

> **Warning**
>
> Starting from version 1.14.0 of the Swift SDK, we've replaced SKIE with a [pure Swift implementation](https://releases.powersync.com/announcements/swift-sdk-1-14-0-now-pure-swift).
> This article no longer describes the current architecture of the PowerSync Swift SDK, but it's a good overview on using SKIE.

## Synced SQLite For All Platforms

PowerSync is a powerful alternative to traditional approaches of data provisioning and state management which can be complex or boilerplate-heavy. A configured PowerSync service ensures that relevant and authorized data is synced to clients, providing an automatically synced local data store via SQLite.

Our goal is to bring these benefits to as many development environments as possible by offering high-quality SDKs.

This post covers the journey of building our Swift SDK, explaining some of the design decisions behind it.

## Prior Art: JS SDK

When I joined the PowerSync SDK journey, the Flutter/Dart SDK was the only stable SDK available. My goal was to bring the magic of PowerSync to the JavaScript/TypeScript ecosystem. Given the variety of environments and frameworks in the JS world, any viable solution needed to be flexible. Building a flexible system often calls for a well-structured coding methodology and good architectural practices.

I prefer to build systems that are modular, extensible, and reusable. A good system, in my view, is one that anticipates the unknown and makes navigating uncertainty more manageable and even pleasant. With that mindset, I set out to adapt the Dart SDK into a shared JavaScript implementation. Initially, the goal was to target React Native, but the architecture needed to support future extensions for Web and Node.js.

Over time, this modular approach proved invaluable. Our JavaScript ecosystem expanded from a single React Native SDK using Quick SQLite to also support:

  * Web via WA-SQLite
  * Node.js via Better SQLite
  * An additional React Native option via OP-SQLite

Having most of the core logic in a pluggable module made delivering these variants much faster and more consistent.

## Quickly Hacking An Alpha SDK With SKIE

The PowerSync Kotlin and Swift SDKs have a different, but somewhat similar, relationship to the structure used in our JavaScript SDKs.

The first alpha version of the Swift SDK was generated by taking Objective-C code output from the compiled Kotlin SDK and then using SKIE to generate Swift interfaces. We published a detailed blog post on this process [here](https://powersync.com/blog/using-kotlin-multiplatform-with-kmmbridge-and-skie-to-publish-a-native-swift-sdk).

[SKIE](https://skie.touchlab.co/) is an incredible tool by [Touchlab](https://touchlab.co/) that makes it much easier to reuse Kotlin code in Swift. I was impressed the first time I used it. We feed in the Kotlin SDK, add a few SKIE build steps, and out comes a (mostly) usable Swift version of the PowerSync SDK. It was exciting: with relatively little additional effort, we extended and reused our existing codebase and produced two SDKs for nearly the price of one. Swift developers could now access the benefits of PowerSync, but there was still work to be done.

While SKIE does a great job bridging Kotlin and Swift, it's not realistic to expect it to deliver a full-featured SDK out of the box. Our initial alpha SDK was largely the raw SKIE output. We documented it and provided example usage, but there were significant caveats. For example, developers had to deal with:

  * Mangled function names
  * Kotlin type wrappers instead of native Swift types
  * Boilerplate code to bridge between Kotlin interfaces and Swift

The alpha SDK was functional, but the developer experience left much to be desired. Improving this experience became a key focus for our next phase.

## Beta: Going From Project Car To Daily Driver

If the Swift SDK were a project car, the Kotlin SDK would be the crate engine we dropped in to get things moving. With some skill, a developer could take it for a spin, but it wasn’t quite ready for a daily commute. The beta release aimed to install the missing basics: comfort, usability, and a smoother ride.

As with many project cars, we asked ourselves: is all this customization worth it? Wouldn’t it be better to just build the Swift SDK entirely in Swift? After all, many of the alpha shortcomings could be avoided that way. Fortunately, our modular design philosophy offered a better middle ground.

The beta release aimed to resolve the key issues from the alpha. We shifted toward a more Swift-focused API. Even if we kept the Kotlin implementation under the hood, we could still define Swift-native interfaces and provide a clean, idiomatic developer experience.

To that end, we introduced:

  * Swift protocols for the PowerSync APIs
  * A lightweight adapter to bridge the public Swift protocols to the internal Kotlin implementation
  * Use of Swift’s native Foundation APIs
  * Elimination (mostly) of the need for SKIE-generated Kotlin types in public APIs
  * Internal handling of boilerplate that developers previously had to write themselves

This approach let us maintain the shared Kotlin core while offering Swift developers a modern, intuitive SDK.

## Beta to Stable: Leveraging Shared Code and Prioritizing Developer Experience

Stability is a top priority for any SDK. Developers rely on our tools in the critical paths of their apps, from development all the way to production. Our SDK should be rock-solid, especially in production, and never introduce unnecessary bugs into the development process.

The beta release revealed some key improvements which would be required for pushing the Swift SDK past the stable threshold. Diving into these improvements can give some insight into the benefits of using a shared Kotlin implementation wrapped with a dedicated Swift layer.

The mantra when developing the stable release could be summarized to “do the heavy lifting in shared code - polish and make it shiny in the Swift layer”.

### Threading the needle

While the alpha and beta SDKs advertised thread-safe operations, the stable release delivered on this promise with concrete improvements.

The stable release made core SDK functions truly thread-safe:

```swift
// This pattern works reliably across multiple threads
Task {
    try await powerSync.connect() // First task initiates connection
}
Task {
    try await powerSync.connect() // Second task waits for first to complete
}
Task {
    try await powerSync.disconnect() // Properly synchronized with other operations
}
```
In the alpha/beta versions, concurrent calls to some PowerSync SDK methods could lead to race conditions where internal state was corrupted or crashes could occur. The stable release implemented proper synchronization to ensure methods execute sequentially even when called simultaneously from different tasks. The majority of these improvements were directly implemented once in the core Kotlin SDK. 

### Connection Pooling for Concurrent Reads

A major architectural improvement in the stable SDK is our connection pooling system:

```text
┌─────────────────┐       ┌─────────────────┐
│                 │       │ Write Connection│
│                 │       │  (Sequential)   │
│     Your App    │       └─────────────────┘
│                 │       ┌─────────────────┐
│  ┌───────────┐  │       │ Read Connection │
│  │ PowerSync │──┼───────│      Pool       │
│  └───────────┘  │       │  (Concurrent)   │
└─────────────────┘       └─────────────────┘
```
The beta SDK used a single read connection and a single write connection, which limited concurrent read operations. The stable release implements:

  * A dedicated write connection that ensures sequential, atomic modifications
  * A pool of read connections that allows multiple simultaneous read operations

This architecture dramatically improves performance for apps that need to display data from multiple queries simultaneously, a common requirement in modern Swift applications.

The logic for connection pooling and managing SQLite driver connections is shared from the Kotlin SDK. The Swift SDK contains almost no implementation for this logic. “Write once, share always” streamlined this functionality for our Swift SDK.

### Watch Query Concurrency

Our watch query system (which provides real-time updates when data changes) received substantial concurrency and stability improvements:

```swift
// Now truly concurrent and reliable
let tasksStream = try powerSync.watch(
  sql: "SELECT * FROM tasks", 
  parameters: []
) {...}
let projectsStream = try powerSync.watch(sql: "SELECT * FROM projects", ...)
let usersStream = try powerSync.watch(sql: "SELECT * FROM users", ...)

// All three streams update independently and efficiently
// when underlying data changes
```
In the beta SDK, watched queries could miss updates or yield stale data due to internal race conditions. The stable release implements thread-safe notification mechanisms that ensure:

  * All data changes properly trigger relevant watched queries
  * Notifications are coalesced efficiently to prevent redundant updates
  * Read operations for watched queries utilize the connection pool

Our testing methodology focused on real-world usage patterns that developers might encounter. All stability improvements were implemented in the shared Kotlin core SDK, where we developed rigorous unit tests to verify thread safety and concurrency handling. This approach ensures that the improvements benefit both the Kotlin and Swift SDKs without duplicating effort. 

### Truly Native Swift Experience

The beta release aimed to abstract the SKIE interfaces from developers. While the beta release did make the SDK more pleasant to use in a Swift application, the efforts there proved to be incomplete. We identified a few vital improvements which would provide a much cleaner developer experience.

Our stable release delivers a truly native Swift experience by completely removing translated Kotlin types from all public-facing APIs, as detailed in [this PR](https://github.com/powersync-ja/powersync-swift/pull/40). 

This transformation was comprehensive, replacing Kotlin interfaces with Swift Protocols and native types across the entire SDK. The key to success here is that while the public facing API was a little rough, the core implementation was solid. We could still leverage the benefits of a shared core implementation. All the improvements mentioned here were reaped from minor improvements made to Swift Protocols and thin adapters.

#### Improved Types

Developers don’t want to write repeated boiler-plate code which converts SDK results to usable values. We had a few remaining instances where Kotlin wrapper types were returned by the SDK. These wrappers were painful to work with. Using `Date` values in our `SyncStatus` response was one area which was improved. The stable release was updated to provide Swift `Date` types for all time based data.

```swift
// Beta SDK: currentStatus.lastSyncedAt returned a Kotlin datetime wrapper
// which would require boxing to a Swift Date instance
let lastSyncTime = Date(
    timeIntervalSince1970: TimeInterval(
        database.currentStatus.lastSyncedAt!.epochSeconds
    )
)
// Stable SDK (native Swift)
let lastSyncTime: Date = database.currentStatus.lastSyncedAt // Already a Swift Date
```
Improved Transactions

Transactions are a powerful and useful concept in database engineering. Our beta SDK left much to desire when using transactions. The transaction `Context`, which provides means for executing SQLite operations within the active transaction was still tightly coupled to the SKIE output which lacked support for result set generics.

```swift
// Alpha SDK (lost generics, required unsafe casting)
let attachmentIDs = try transaction.getAll(
    sql: "SELECT photo_id FROM todos WHERE list_id = ?",
    parameters: [id]
) { cursor in
    cursor.getString(index: 0)! // Force unwrap needed
} as? [String] // Manual cast required
// Stable SDK (Swift native types)
let attachmentIDs = try transaction.getAll(
    sql: "SELECT photo_id FROM todos WHERE list_id = ?",
    parameters: [id]
) { cursor in
    try cursor.getString(index: 0) // Returns native Swift String
} // Swift properly infers [String] type
```
Bumping transaction support to a stable state was implemented by wrapping the functional (but a little messy) Kotlin implementations with small Swift wrapper implementations. This resulted in fairly large wins with minimal effort.

### Simplified CRUD Operations

Some of our SDK methods required jumping through hoops in order to get the job done. This was mostly a remnant of letting SKIE code leak through to the public API. It should be noted that these inconveniences were not a result of SKIE being bad, but rather the lack of proper presentation of the API on our end. 

```swift
// Alpha SDK (awkward Kotlin invocation)
_ = try await transaction.complete.invoke(p1: nil)
// Stable SDK (natural Swift method call)
try await transaction.complete()
```
Light-weight Swift wrappers were once again the solution to this quagmire.

### Improved SQL Cursor APIs

Our Kotlin and Swift SDKs use cursors to map SQLite result sets to typed result data structures. Once again, the beta SDK bled some Kotlin through to the public Swift SDK. Beta users often found themselves having to skate-by with strange result types. 

```swift
// Alpha SDK (Kotlin primitive wrappers)
let value = (
    cursor.getBoolean(index: 0)?.boolValue, // Kotlin Bool
    cursor.getDouble(index: 1)?.value,      // Kotlin Double
    cursor.getLong(index: 2)?.int64Value    // Kotlin Long
)
// Stable SDK (native Swift types)
let value = (
    try cursor.getBoolean(index: 0),     // Swift Bool
    try cursor.getDouble(index: 1),      // Swift Double
    try cursor.getInt64(index: 2)        // Swift Int64
)
```
How does one fix this? Write a SQLCursor from scratch in Swift? No thank you sir! 

We already had all the core implementation provided by the Kotlin SDK - all we had to do was bundle and wrap it in a nice bow.

The stable SDK also included numerous quality-of-life improvements:

  * `@discardableResult` annotations to silence unnecessary warnings
  * Support for `nil` SQL parameters without compiler warnings
  * Type-safe error handling with dedicated `SqlCursorError` type
  * Consistent behavior between index and name-based `SqlCursor` column value getters

In my opinion, these changes completely transform the developer experience, turning what was a clunky semi SKIE-translated API into a polished, idiomatic Swift SDK that feels natural to Swift developers.

### Why This Architecture Matters

Understanding our approach to the Swift SDK architecture directly impacts your development experience:

  * Faster bug fixes and feature parity - When we implement a new feature or fix a bug in the Kotlin core, Swift developers get these improvements with minimal delay
  * Better testing coverage - With a shared core, our test suite becomes more comprehensive across SDKs
  * Futureproofing - As Apple introduces new Swift features or deprecates old ones, we can adapt our Swift layer without touching the battle-tested core

## The Future

We recently released stable versions of both the Kotlin and Swift SDKs. Swift developers can now confidently use PowerSync in their production apps.

Thanks to the Kotlin-based core, Swift users benefit from timely updates; new features and bug fixes are available shortly after they’re released in the Kotlin SDK. As with all our SDKs, we’ve designed the architecture to remain flexible. We’ve kept the door open for additional Swift-specific features and support for alternative SQLite drivers.

We’re excited about what’s ahead and look forward to continuing to grow the PowerSync ecosystem across platforms.

---

# PowerSync Update: April 2025

> We released a major website update designed to concisely explain what PowerSync is and how it’s built for open database technologies, especially SQLite on the client-side. Here’s the April update.

- Published: 2025-05-13
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-april-2025

---

We [released a major website update](https://x.com/powersync_/status/1917616704445899082) designed to concisely explain what PowerSync is and how it’s built for open database technologies, especially SQLite on the client-side. [Check it out](https://powersync.com/) and [let us know what you think](https://fomr.io/s/PV4kWCXow3)! Here’s the April update:

## Sync Progress Tracking

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-aea2eb91b3.png)

PowerSync Client SDKs now track sync progress, so you can show users when their local database is up to date. This is especially useful for longer-running initial syncs of large datasets.

See the [release notes](https://releases.powersync.com/announcements/sync-progress-tracking-now-available-in-powersync-sdks) for more details.

## Using PowerSync With AI Tools

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-11b399d369.png)

We added a context menu to our docs for copying Markdown or sending pages to ChatGPT/Claude. You can also use `/llms.txt` (page summaries) or `/llms-full.txt` (full docs) to provide LLMs with broader context. We’re expanding that page with more resources.

[Read the docs](https://docs.powersync.com/resources/ai-tools)

## PowerSync Cloud: Service Version Locking

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-1da4bc78f2.png)

Customers on our Team and Enterprise plans on PowerSync Cloud can now lock their instances to specific versions of the PowerSync Service. Downgrades aren’t always supported — contact us if needed.

[Read the docs](https://docs.powersync.com/usage/tools/powersync-dashboard#advanced%3A-service-version-locking)

## Swift Client SDK V1 Release

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-bc9d731977.png)

Version 1.0.0 is the GA release of the PowerSync Swift client SDK, and includes multiple breaking changes to align with Swift best practices, simplify CRUD operations, and improve API stability and consistency. Version 1.1.0 added further improvements.

Shout out to the folks at **Touchlab** who helped us during the early phases of this project!

See the [full changelog](https://releases.powersync.com/announcements/powersync-swift-sdk-v1-0-0) and [SDK reference](https://docs.powersync.com/client-sdk-references/swift) for details, and join the PowerSync community on Discord for support.

## Kotlin Client SDK V1 Release

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-f1a5eeeb10.png)

Version 1.0.0 is the GA release of the PowerSync Kotlin client SDK. We addressed a few remaining items to take our Kotlin client SDK out of Beta. Version 1.1.0 also added further improvements.

See the [release notes](https://releases.powersync.com/announcements/powersync-kotlin-multiplatform-sdk-v1-0-0) for details.

## Improved Logging for JS SDKs

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-0df2d28882.png)

You no longer need to manage your own `js-logger` dependency — logging utilities are now built into the SDKs

[See the docs](https://docs.powersync.com/client-sdk-references/javascript-web/usage-examples#using-logging-to-troubleshoot-issues)

## Blog Post: Escaping The Network Tarpit

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-cb78ba58e3.png)

PowerSync co-founder Conrad Hofmeyr writes about the network tarpit: the seemingly endless complexity developers face with using APIs to move app state over the network. Sync engines like PowerSync provide a better path.

[Read the blog post](https://powersync.com/blog/escaping-the-network-tarpit)

## Blog Post: Building My First .NET SDK

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-9d649c0350.png)

PowerSync engineer Christiaan Landman describes how he built the PowerSync .NET client SDK by combining structured learning, cross-framework support, and idiomatic API design.

[Read the blog post](https://powersync.com/blog/what-i-learnt-building-a-net-sdk)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-1743c19c4c.png)

H/T **MaxMonteil** , **js2702** , **Radiokot** and **fethij** for their contributions in April 🙏

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-2c36b1ad25.png)

**SpacedCards:** An AI-powered flashcard app with spaced repetition and distraction blocking.

Great work **Standa** 👏

[Check it out](https://spacedcards.app/)

![](https://powersync.com/images/blog/powersync-update-april-2025-inline-b27220c88f.png)

**addto.me** lets you interact with multiple apps (like Google Calendar, Notion, Jira, Calendly etc.) directly from your chat apps (Whatsapp and Telegram).

[Check it out](https://addto.me/)

That's it for the April update, happy coding!

---

# Escaping The Network Tarpit

> Modern software involves constantly moving app state over the network. Yet networks are imperfect. Even the best modern networks run into connectivity lapses, latency spikes and temporary throughput bottlenecks. The good news is that sync engines and the local-first movement are changing the paradigm to something better. Read on for more on how PowerSync's architecture and approach help developers free themselves from the network tarpit.

- Published: 2025-05-02
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/escaping-the-network-tarpit

---

Modern software applications are distributed applications. This is a trend that has accelerated over the past decade. Users want their software and data to be accessible from anywhere, and therefore developers build software for the cloud. And because so much data lives in the cloud, modern software involves constantly _moving app state over the network._

Yet networks are imperfect. Even the best modern networks (5G, fiber, Starlink, etc.) run into connectivity lapses, latency spikes and temporary throughput bottlenecks. This is especially unavoidable if you consider that the Internet is a _network of networks_. Nevertheless, users want it all: they want their software to be fast, reliable, collaborative, and feature-rich. 

Developers therefore spend an inordinate amount of time dealing with the complexities of moving state over the network: Data fetching. Loading state. Caching. Client-side indexing. Cache invalidation. State management frameworks. Optimistic updates. The list goes on.

Carl Sverre has done a great job of [describing this](https://sqlsync.dev/posts/stop-building-databases/) as reinventing databases on the front-end:

>  _“In any frontend application of sufficient complexity, engineers will necessarily end up building so many data management features that they are essentially creating a domain specific database. This added complexity is duplicated in each project we work on and takes away from spending time on delighting users and solving business problems.”_

We’ve started [calling it](https://powersync.com/) the _network tarpit:_ It seems simple at first, but quickly becomes endlessly complex. And the more you struggle, the more entangled you get…

![The concept of a "network tarpit" is illustrated by a dinosaur languishing in a tar pit that sits on the network path between the client-side app and server-side backend, surrounded by the network management challenges of network failure handling, state management, retries, cache invalidation, optimistic updates and loading state management.](https://powersync.com/images/blog/escaping-the-network-tarpit-inline-17181fb868.png)

Even the top software companies in the world struggle with the problem. If I use Facebook or Google Maps in the elevator at the office or even in certain sections of the city street where I live, I often just get stuck in a loading state.

## Enter sync engines

The good news is that sync engines and the [local-first](https://localfirstweb.dev/) movement are changing the paradigm to something better: Instead of reinventing a database in the front-end, what if we put an _actual database in the front-end_ and asynchronously keep it in sync with a database in the cloud?

![Using a sync engine results in the "bliss of data availability", illustrated by a dinosaur enjoying a cosmopolitan cocktail next to a block labeled "in-app SQLite" which is automatically synced with the backend in the background.](https://powersync.com/images/blog/escaping-the-network-tarpit-inline-0afe61fdb6.png)

In the year since the first edition of [Local-First Conf](https://www.localfirstconf.com/), we’ve seen an [explosion](https://www.localfirst.fm/landscape) of developer tools aiming to solve this problem. We believe that sync engines are ushering in a new golden era for app development that’s more productive and more fun.

## Different architectural philosophies

With this explosion of tools, there’s also been some patterns emerging in different types of architectures and approaches. 

Some tools merely act as a sync layer between the backend and frontend — like ElectricSQL, Zero and PowerSync. Others replace your entire stack, from backend database to frontend database — like Instant, Triplit, Firebase and arguably Ditto too. Aaron Boodman has [described](https://x.com/aboodman/status/1843049082237170036) this approach and the trade-offs well, contrasting _sync engines_ with _syncing datastores_.

We are skeptical that entire-stack products (“syncing datastores”) will win out. For one, it’s not clear that most developers want this. These products generally expect developers to entrust their system-of-record production data to an unproven new database, rather than a mature system like Postgres or MySQL. Entire-stack products also require a mammoth engineering effort. It will take a lot of time and investment for the new upstarts to reach parity with mature databases. 

Some tools allow you to bring your own backend database, but they provide their own vendor-specific frontend data layer. This approach also didn’t resonate with us, because we don’t think that most developers would prefer a nonstandard API surface over a standards-based one (e.g. SQL). A standards-based interface also allows you to bring your own favorite ORM to work with the data, if that’s what you prefer.

For that reason, we designed PowerSync to act as a sync layer between powerful open database technologies on both the backend (Postgres, MongoDB and MySQL) and the client-side (SQLite). As we’ve [written about](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility) in our 2025 roadmap announcement, using SQLite on the client-side means that developers can benefit from its familiar syntax, powerful functionality, ecosystem (ORMs and extensions), high performance, and maturity. This overall philosophy also led us to make PowerSync [itself](https://powersync.com/open-source) open-source and source-available. 

We have a strong conviction that the philosophy behind PowerSync is the right one for sync engines to achieve wide adoption. We’re doubling down on our architecture and expanding the product with [new major features](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility) this year — to help developers free themselves from the network tarpit.

---

# What I Learnt Building A .NET SDK

> Building a .NET SDK from scratch—with minimal C# experience—by mapping out architecture, learning the language deeply, and solving cross-platform challenges for MAUI, Blazor, and WPF.

- Published: 2025-04-10
- Author: Christiaan Landman
- Category: Engineering
- Source: https://powersync.com/blog/what-i-learnt-building-a-net-sdk

---

## Problem Statement

When I was asked to develop a .NET SDK for PowerSync, I knew I was stepping outside my comfort zone. I’d never built a PowerSync SDK from scratch - and my only C# experience came from some casual Unity side projects. Suddenly, I was navigating one of our most requested [roadmap](https://roadmap.powersync.com/tabs/5-roadmap) items, meant to support MAUI, Blazor, WPF, and others - right as developers were looking for alternatives to [Realm-Dotnet](https://github.com/realm/realm-dotnet) following the [Atlas deprecation announcement](https://www.mongodb.com/docs/atlas/device-sdks/deprecation/).

Despite my time working on our Dart and JS SDKs, this was uncharted territory: unfamiliar tooling, deeper parts of the PowerSync architecture, and a language I barely knew beyond the basics. Here’s how I approached it.

## The Learning Approach

Learning and mastering new programming languages evolves throughout your career:

  * **Learning your first language usually demands significant effort,** as you're simultaneously grasping fundamental programming concepts.
  * **Learning your second language** becomes more intriguing, as you leverage your existing knowledge, often experiencing moments like: "Oh, that's just a different syntax than I'm used to" or, "This feature would've been handy in the previous language!".
  * **When you've stopped counting how many languages you know** , ideally, you've established a structured learning approach, leaving behind the days of blindly stumbling through unfamiliar territory.

These days, my approach is to go directly to a language's official documentation. Microsoft's resources for both [C#](https://learn.microsoft.com/en-us/dotnet/csharp/) and [.NET](https://dotnet.microsoft.com/en-us/learn) are exceptional, catering effectively to developers of all skill levels.

Once I've built some initial comfort with a language, I typically reinforce my knowledge by working through the interactive exercises on [Exercism](https://exercism.org/). Their guided modules cover language specific concepts comprehensively within an online IDE - I highly recommend this platform.

## The Plan

With this learning approach as my foundation, I devised a strategy blending research, targeted learning, and hands-on experimentation to tackle the PowerSync .NET SDK project:

  * Understand how the existing stable SDKs ([powersync.dart](https://github.com/powersync-ja/powersync.dart) and [powersync-js](https://github.com/powersync-ja/powersync-js)) currently operate
  * Determine precisely where surface-level interfaces end and meaningful functionality begins
  * Map out the conceptual areas of the SDK architecture
  * Apply my structured language learning process to C# and .NET
  * Work toward an MVP by identifying and addressing core challenges

This approach would allow me to simultaneously develop my C# skills while building a foundational understanding of what makes PowerSync SDKs work under the hood.

## How SDKs Cross Boundaries

When building an SDK, understanding the interfaces is critical. For PowerSync, these interfaces include:

  * **Queries** : How the SDK interfaces with the local SQLite database
  * **Data synchronization** : How data is fetched and synchronized from the PowerSync Service
  * **Uploading local changes** : How local data modifications are processed and uploaded via a provided connector

I began by reviewing the powersync-js reference SDK. Rather than attempting to memorize JavaScript implementation details, I focused on mapping the core conceptual architecture.

![](https://powersync.com/images/blog/what-i-learnt-building-a-net-sdk-inline-1574d49815.png "This was the general picture I had built up in my head.")

With this understanding in place, I could confidently outline the initial structure for the .NET PowerSync.Common package.

## Working Towards an MVP

When developing SDKs from scratch, you want to identify the core challenges early - particularly those unique to the target language and environment. For PowerSync in the .NET ecosystem, I needed to consider:

### Target Frameworks

  * **WPF and .NET** for desktop applications.
  * **MAUI** for cross-platform desktop and mobile apps.
  * **Blazor** for web-based scenarios.
  * **Special mentions** :
    * **Unity** (yes, the game engine!) for gaming and interactive experiences.
    * **AvaloniaUI** for cross-platform desktop applications.

Initially, the goal is to ensure that our **Common SDK** runs smoothly across as many target frameworks as possible. When dedicated runtime support or reactive bindings become necessary, we can introduce these as supplemental packages. For example in our JS package suite, we have a @powersync/common package but @powersync/react, @powersync/react-native , and @powersync/web  contain platform-specific functionality provided for full compatibility.

### API Ergonomics and Language Conventions

A important lesson in building our .NET SDK was realizing that idiomatic design matters more than just porting functionality from JavaScript or Dart. What feels natural in one language can feel awkward in another.

We’re actively incorporating feedback from developers and reviewing open source libraries to guide these decisions. Even small choices - like preferring builders over inline dictionaries, or using Dispose instead of CancellationTokenSource - can make the API feel more intuitive and familiar.

### Database Adapter Implementation

This should then wrap a SQLite driver/package that works for your target platforms. In some scenarios, you may even need multiple adapters to adequately cover the full spectrum, from desktop and mobile to web. 

To date, [Microsoft.Data.Sqlite](https://learn.microsoft.com/en-us/dotnet/standard/data/sqlite/?tabs=net-cli) has proven robust, providing reliable support and clear examples across .NET, WPF, and MAUI platforms. Most of the work left for support platforms like MAUI would be in ensuring that the PowerSync extension is added correctly (this work is done incrementally as we add official support for more frameworks).

### SQLite Extension Integration

Our [SQLite Core Extension](https://github.com/powersync-ja/powersync-sqlite-core) provides shared SQLite functionality that is used consistently across all our SDKs. Since it does a lot of the heavy lifting, it is important to be able to load this extension within each target environment. During initial development on macOS, loading the SQLite extension turned out to be straightforward - I was able to integrate and validate it quickly within a unit test.

### Schema Definition

With the SQLite extension in place, it was possible to translate schema definitions into a structured format, passing them to the extension. This enabled automatic setup of the tables and views required to power PowerSync’s core functionality.

### Database Hooks and Watched Queries

In our Dart and JS SDKs, we rely on database hooks to enable two features:

  1. **Local Change Detection** – Used to determine when a local CRUD operation (insert/update/delete) has occurred that needs to be uploaded to the backend.
  2. **Watched Queries** – Notifies watched queries when tables involved in their query have changed, prompting automatic re-execution and UI updates.

Fortunately, we also have access to low-level database hooks when using Microsoft.Data.Sqlite via [SQLitePCLRaw](https://github.com/ericsink/SQLitePCL.raw):

```csharp
raw.sqlite3_rollback_hook(Db.Handle, RollbackHook, IntPtr.Zero);
raw.sqlite3_update_hook(Db.Handle, UpdateHook, IntPtr.Zero);
```
Our typical watched query implementation typical involves a few simple steps:

  1. Execute the query for the initial result.
  2. Use [EXPLAIN](https://www.sqlite.org/lang_explain.html) to resolve which tables the query depends on.
  3. Subscribe to the DBAdapter for any updates on tables. 
  4. When notified of a change, check for an intersection between the modified tables and the dependent tables.
  5. If an intersection exists, re-execute the query.

### Implementing Data Synchronization

To be able to connect to a backend and the PowerSync Service, we required a BackendConnector implementation. Initially I started with porting the [Demo Node connector](https://github.com/powersync-ja/self-host-demo/blob/main/demos/nodejs/demo-app/src/library/powersync/DemoConnector.ts), but by the time of writing we also had a port of the [Supabase Connector](https://github.com/powersync-ja/powersync-js/blob/main/demos/react-supabase-todolist/src/library/powersync/SupabaseConnector.ts) using the [Supabase C# SDK](https://supabase.com/docs/reference/csharp/introduction).

With the connector in place, we could now implement an HTTP stream to consume data synchronized down from the PowerSync Service. Additionally, we could process local data changes, passing them through the connector for upload to our self-hosted Node backend.

### Releasing 

When the package is finally ready to be shared with the first batch of alpha testers, it’s important to have a basic release process in place. For .NET libraries, the go-to platform for distribution is [NuGet](https://www.nuget.org/) (pronounced “New-get”, and not “Nugget” 🍗). Publishing on this platform allows developers to easily consume your SDK using familiar tools like `dotnet add` or via Visual Studio’s built-in UI.

### Testing and Demonstration

Throughout development, I defined tests for each component as it was implemented. Where possible, I ported existing tests from our Dart and JS SDKs to validate equivalent behavior.

To demonstrate the SDK's functionality, I created a simple [CLI-based demo](https://github.com/powersync-ja/powersync-dotnet/tree/main/demos/CommandLine) that syncs todo lists in real-time. This served both as a proof of concept and as a reference implementation for developers looking to integrate PowerSync into their own .NET projects.

![](https://powersync.com/images/blog/what-i-learnt-building-a-net-sdk-inline-1b2eac505c.png  "A React web demo syncing data with the newly built .NET CLI demo.")

### The Role of LLMs in My Learning Process

Large Language Models proved invaluable during this project - particularly for translating concepts I understood in other languages into their C# equivalents. They helped bridge the gap between familiarity and fluency, generating quick prototypes and scaffolding test cases when I needed to move quickly.

However, I followed one important rule: 

Use LLMs to write either the code or the tests - but never both. 

This approach ensures I truly understand at least one side of the implementation, maintaining code quality and forcing deeper comprehension of the system.

## TL;DR

  * Start by mapping concepts, not code.
  * Learn the target language idioms deeply - read open source, ask devs.
  * Use LLMs for acceleration, but don’t outsource your understanding.
  * Keep the SDK modular and framework-agnostic where possible.

Thanks for reading - I hope this writeup helps anyone venturing into unfamiliar language ecosystems or building SDKs from the ground up.

---

# PowerSync Update: March 2025

> March was a big month for PowerSync, with major projects like improved concurrent connection scaling and the release of client SDKs for two new frameworks: .NET and Node.js.

- Published: 2025-04-04
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-march-2025

---

March was a big month for PowerSync, with major projects like **improved concurrent connection scaling** and the release of **client SDKs for two new frameworks: .NET and Node.js**. We’re seeing an acceleration in both new users getting started with PowerSync and users deploying PowerSync into production. Let’s go!

## Service Performance Optimizations

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-1be24b5343.png)

We’ve made significant performance improvements that enable even better scalability of _concurrent_ connections. Specifically, we’ve implemented caching of parameter queries and bucket data to reduce redundant computation during incremental sync. We’ve also optimized Postgres transaction replication by batching multiple operations into a single flush to the bucket storage.

See [this PR](https://github.com/powersync-ja/powersync-service/pull/200) as well as [this one](https://github.com/powersync-ja/powersync-service/pull/228)

## Prioritized Sync Available On All Beta+ SDKs

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-a10a95058e.png)

Prioritized sync allows you to make critical data available to users immediately — like showing a dashboard or login state — while non-essential data continues syncing in the background. All SDKs in Beta status or above now support this.

[Read the docs](https://docs.powersync.com/usage/use-case-examples/prioritized-sync)

## .NET Client SDK (Alpha)

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-e0b8b7cc1d.png)

Our .NET client SDK brings real-time sync and offline-first capabilities to .NET desktop and server apps, sharing the same core features as our other client SDKs. Support for mobile applications is up next, including .NET MAUI bindings.We’ve confirmed WPF apps are supported and will be shipping a demo app soon.

[Read the release notes](https://releases.powersync.com/announcements/introducing-our-net-client-sdk-alpha-release)

## Node.js Client SDK (Alpha)

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-5a131b702f.png)

We're excited to announce the alpha release of our Node.js Client SDK, bringing PowerSync’s real-time sync capabilities to Node.js environments, such as server-side apps, CLI tools and Electron apps.

[Read the release notes](https://releases.powersync.com/announcements/introducing-our-node-js-client-sdk-alpha-release)

## Swift and Kotlin Multiplatform SDKs Improved

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-7c4ca68eda.png)

We've updated our Kotlin Multiplatform and Swift SDKs to unify read and write concurrency across iOS, Android, and JVM platforms. All platforms now support concurrent reads (multiple read operations happening at the same time) resulting in faster UI updates. Both of these SDKs will be in V1/GA within the next week or two.

[See release notes for the Swift SDK](https://releases.powersync.com/announcements/powersync-swift-sdk) and [KMP SDK](https://releases.powersync.com/announcements/powersync-kotlin-multiplatform-sdk)

## FlutterFlow Guide Update: Handling Attachments

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-8bebfbbb59.png)

We’ve added a section to our FlutterFlow integration guide on how to sync attachments such as images and PDFs using PowerSync and Supabase Storage. Thanks to **@mad_hatter** for early feedback on this.

[See the guide](https://docs.powersync.com/integration-guides/flutterflow-+-powersync/handling-attachments)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-081231c852.png)

We’ve got a new **_Trusted Engineer_** role on our Discord server, bestowed on those who’ve helped others.

**Guillem** , **Ry** and **Yahya** are our first three trusted engineers. We appreciate you!

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-1f630de147.png)

H/T **Jesse McIntire** for helping us [better handle attachment table naming](https://github.com/powersync-ja/powersync-js/pull/523).

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-e01f6a0008.png)

**Orakemu:** a life management app that makes you view your life as a game 🎮 of which you are the hero ✨

Great work **Yorgo Hoebeke** 👏

[Check it out](https://orakemu.com/)

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-489804be88.png)

**Fomr:** a no code drag-and-drop tool to create forms and surveys that works super fast.

Made by **Bohdan Khodakivskyi 🙌**  

[Check it out](https://fomr.io/)

![](https://powersync.com/images/blog/powersync-update-march-2025-inline-16da84181a.png)

**Kitchen Copilot:** Smart meal planning made simple.

Made by **Scott Forsyth 🍽️**

[Check it out](https://kitchencopilot.com/)

That's it for the March update, happy coding!

---

# WeKan Partners With PowerSync To Deliver Sync Solutions For MongoDB

> WeKan partners with PowerSync to ensure MongoDB customers have access to a proven MongoDB SI partner with expertise in delivering PowerSync-driven solutions.

- Published: 2025-04-03
- Author: Phillip van der Merwe
- Category: Announcement
- Source: https://powersync.com/blog/wekan-partners-with-powersync-to-deliver-sync-solutions-for-mongodb

---

[WeKan Enterprise solutions](https://www.wekanenterprisesolutions.com) is a leading application modernization consultancy and MongoDB’s trusted partner for mobile and IOT. Over the years, their team of MongoDB expert engineers supported complex Realm & Atlas Device Sync implementations for some of Mongo’s largest enterprise customers. More recently, WeKan has been actively guiding organizations through Realm end-of-life transitions. Their expertise spans a broad spectrum of modernization and application development, with a focus on MongoDB.  
  
Following the [deprecation of Atlas Device Sync](https://www.mongodb.com/docs/atlas/app-services/sync/device-sync-deprecation/), WeKan identified [PowerSync](https://powersync.com/) as a strong alternative and has been working closely with the PowerSync team to fast-track evaluations and implementations at MongoDB enterprise customers. The new partnership ensures continued collaboration between the two teams so that MongoDB customers have access to a proven MongoDB SI partner with expertise in delivering PowerSync-driven solutions.

## WeKan Sees PowerSync As A Strong Atlas Device Sync Alternative

When MongoDB deprecated Atlas Device Sync in September 2024, PowerSync emerged as a way for MongoDB users to implement a replacement sync engine while keeping their MongoDB database and overall architecture broadly the same. Below is an overview of how high-level Atlas Device Sync components map to PowerSync’s service and client SDK:

![](https://powersync.com/images/blog/wekan-partners-with-powersync-to-deliver-sync-solutions-for-mongodb-inline-82cd8c26d1.png)

WeKan identified PowerSync’s familiar [server-client architecture](https://docs.powersync.com/architecture/architecture-overview#architecture-overview) as an aspect that would be important to enterprise customers who need to migrate away from Atlas Device Sync but otherwise want minimal changes to their existing architecture:

> “At WeKan, we have been at the forefront of helping enterprises build scalable and resilient applications using MongoDB. With Atlas Device Sync and Realm going end-of-life, businesses need a robust alternative for real-time data synchronisation. We are excited to collaborate with PowerSync to ensure MongoDB customers continue to have the best-in-class sync capabilities for their mission-critical applications”   
>   
> — **Pablo Jimenez** , CEO WeKan Enterprise Solutions

## Enterprise Ready

PowerSync’s MongoDB Connector has **GA status and is fully supported for production use**. Multiple MongoDB customers use PowerSync in production today. Read more about the [V1 release](https://powersync.com/blog/powersyncs-mongodb-connector-hits-ga-with-version-1-0).

The PowerSync Service is **source-available and self-hostable** , but is also available through the fully managed [PowerSync Cloud](https://powersync.com/pricing) offering. Premium support is available on both PowerSync Cloud and Enterprise Self-Hosted plans.

## WeKan’s Support For Implementing PowerSync

WeKan provides key services to support a transition to PowerSync:

  1. Assessment & Consultancy
  2. Proof-of-Concept (POC) Service
  3. Structured Migration Path
  4. Technical Support and Training

### Assessment & Consultancy

WeKan conducts a two-week assessment involving discovery workshops and technical deep dives to evaluate dependencies, security, performance, scalability, and future needs. The result is a customized migration roadmap with recommended solutions, architecture diagrams, and a strategy aligned with business goals.

### Proof-of-Concept (POC) Service

WeKan’s POC service ensures a reliable migration strategy. This phase allows businesses to test PowerSync against success criteria by building a sample mobile app that simulates the new environment. Through planning, implementation, testing, and documentation, WeKan assesses performance, integration, and feasibility—enabling informed decisions before proceeding with full-scale migration.

### Structured Migration Path

Once the assessment and POC phases are complete, WeKan executes a structured migration plan designed to minimize disruptions. The migration process is broken into key phases, including integrating new SDKs, optimizing data models, transitioning queries, and deploying a pilot before a full rollout. WeKan ensures that all code changes, data migrations, security configurations, and performance optimizations are handled efficiently, enabling a smooth transition with minimal downtime.

![](https://powersync.com/images/blog/wekan-partners-with-powersync-to-deliver-sync-solutions-for-mongodb-inline-e8299e3834.png "Example migration path structure")

## Conclusion

With Atlas Device Sync no longer available, organizations relying on MongoDB now face important decisions about their sync architecture. WeKan’s collaboration with PowerSync gives MongoDB users a practical path forward. Together, the teams have already helped customers navigate the shift and continue to build production-ready systems. As more organizations approach this transition, WeKan’s experience and structured approach aim to make the process as straightforward and reliable as possible.

[Get in touch](https://www.wekanenterprisesolutions.com/contact-us) with WeKan to schedule an assessment.

---

# PowerSync Update: February 2025

> February saw our highest user growth ever. We’ve already started checking off 2025 roadmap milestones with the release of prioritized sync and V1 of our MongoDB connector.

- Published: 2025-03-07
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-february-2025

---

February saw our highest user growth ever. Welcome to everyone new! If you haven’t seen our 2025 roadmap yet, check it out [right here](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility). We’ve already started checking off roadmap milestones with the release of **_prioritized sync_** and **V1 of our MongoDB connector**. Let’s get into it:

## Prioritized Sync: Ensure Critical Data Syncs First

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-30038fd868.png)

Introducing **Sync Bucket Priorities** , a new feature that optimizes sync performance by allowing you to control the order in which data syncs. Use this to ensure critical data syncs first, which can improve your app's responsiveness and user experience.

[Read the release notes](https://releases.powersync.com/announcements/prioritized-sync-ensure-critical-data-syncs-first)

## MongoDB Connector V1 Release

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-fd7d896fad.png)

Our MongoDB Connector has officially reached general availability (GA) status. This marks the transition from Beta to a fully stable release. For teams looking to run MongoDB as their backend database with PowerSync, V1 is ready and fully supported.

[Read the blog post](https://powersync.com/blog/powersyncs-mongodb-connector-hits-ga-with-version-1-0)

## Smoother Troubleshooting with Error Codes

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-de9969cb02.png)

We’ve upgraded PowerSync’s error handling so that most error messages will now include structured error codes that map to our troubleshooting docs, making it easier to debug issues.

[Read the docs](https://docs.powersync.com/resources/troubleshooting/error-codes)

## PowerSync FlutterFlow Library

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-d5eda314bd.png)

FlutterFlow’s recent introduction of _libraries_ together with their Supabase integration allowed us to create a dedicated library that provides a far better developer experience for implementing PowerSync in FlutterFlow apps.

[Read the blog post](https://blog.flutterflow.io/introducing-a-local-database-that-auto-syncs-with-supabase/)

## Improved Cursor Experience in Swift and Kotlin

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-94c3b23b7a.png)

In previous versions of our Swift and Kotlin SDKs, it was necessary to use numeric indexes to access columns in results of SQLite queries, based on the order in which the columns were defined in the schema. It is now possible to use column names instead, leading to a much better developer experience.

[See the note on Discord](https://discord.com/channels/1138230179878154300/1138520762618220635/1337049546689085515)

## One Postgres Server for Source Database and Sync Buckets

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-3b6ed3d069.png)

Self-hosters: you can now use the same Postgres server for both the replication source and sync bucket storage (available for Postgres 14.0+). Previously, this was not possible due to the risk of WAL feedback loops.

[Read the docs](https://docs.powersync.com/self-hosting/installation/powersync-service-setup#postgres-storage)

## Blog Post: Atlas Device Sync Migration Example: Healthcare App Moves To PowerSync

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-73d823c375.png)

This post shows how WeKan, a MongoDB implementation partner, moved a customer’s healthcare app from Realm and Atlas Device Sync to PowerSync.

[Read the post](https://powersync.com/blog/atlas-device-sync-migration-example-healthcare-app-moves-to-powersync)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-b2ab783082.png)

H/T Benoit Letondor for contributing two PRs:

One to [Avoid catching CancellationException in runWrappedSuspending](https://github.com/powersync-ja/powersync-kotlin/pull/122) and another for [fixing a concurrency crash](https://github.com/powersync-ja/powersync-kotlin/pull/121). Both for our Kotlin SDK.

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-fd4e429447.png)

**LingoPad:** language learning app for managing vocab, phrases and grammar rules. It also auto-generates flashcards!

Great work **Declan** 👏

See it [here](https://apps.apple.com/us/app/lingopad/id6504203995)

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-ae078fbcfc.png)

**FichasVetapp:** a mobile veterinary management app made for home veterinarians and pet guardians.

Made by **waluki 🙌**  

See it [here](https://www.fichasvetapp.cl/)

![](https://powersync.com/images/blog/powersync-update-february-2025-inline-a3adb7e71a.png)

**Poleshift:** a desktop application for marine research where users use the app for conducting eDNA studies in Antarctica 🇦🇶

Made by **nikothomas 🎉**  

See it [here](https://genomicsatsea.ucsd.edu/)

That's it for the February update, happy coding!

---

# PowerSync’s MongoDB Connector Hits GA With Version 1.0

> PowerSync's MongoDB Connector has officially reached general availability (GA) status. For teams looking to run MongoDB as their backend database with PowerSync, V1 is ready and fully supported.

- Published: 2025-03-05
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/powersyncs-mongodb-connector-hits-ga-with-version-1-0

---

We’re happy to share that our MongoDB Connector has officially reached general availability (GA) status. This marks the transition from Beta (which we [announced earlier](https://powersync.com/blog/powersync-mongodb-connector-module-now-in-beta)) to a fully stable release. For teams looking to run MongoDB as their backend database with PowerSync, V1 is ready and fully supported.

## Recap

When we released the Beta version of the MongoDB Connector, it was with the goal of learning from real-world use cases and gathering feedback on what worked (and what didn’t). As we see customers going to production without encountering any issues, our confidence in the readiness of our V1 release increases. This is what we have been seeing. Thanks to everyone in the community, especially those who tested the Beta in production environments, we’ve been able to stabilize and fine-tune the connector in a relatively short time.

## What’s New in V1

### 1\. Greater Stability

We focused on improved replication reliability, ensuring that data syncs consistently even in complex deployments. Issues uncovered during Beta have been addressed, making replication more resilient.

### 2\. Performance Optimizations

You’ll notice faster throughput when scaling your deployments. Under the hood, we’ve refined how PowerSync handles incremental writes to MongoDB, removing previous bottlenecks and improving overall sync speeds.

### 3\. Enhanced Feature Set

  * **Replication Progress Logging** : Better monitor replication processes.
  * **Improved Support for Atlas Flex Instances**
  * **Better Usability in the Dashboard and Docs** : Clearer error messaging, more intuitive connector setup, and streamlined configuration.

### 4\. Recommended Stable Channel

For ongoing reliability, we recommend switching your PowerSync Cloud instance to the **Stable channel** —this is where all updates to the MongoDB Connector will be automatically delivered once they pass our production checks.

## Upgrading or Getting Started

For PowerSync Cloud, V1 of the MongoDB Connector is already live—no extra steps needed.

For self-hosting setups, simply update your Docker image to the latest version (1.7.2):

```bash
docker pull journeyapps/powersync-service:latest
```

## Release Notes and Further Details

For the full rundown of V1 changes, head over to our [release notes](https://releases.powersync.com/announcements/mongodb-as-a-backend-database-now-in-v1). If you’re new to PowerSync or need a refresher on how to enable MongoDB support, check out our [MongoDB integration docs](https://docs.powersync.com/integrations/mongodb) and [installation docs for MongoDB](https://docs.powersync.com/configuration/source-db/setup#mongodb).

## Next Steps

We’re always looking for feedback as we continue evolving the connector. If you run into anything unexpected or have feature requests, drop by our [Discord community](https://discord.gg/powersync) to let us know.

**Thanks again** to everyone who contributed during the Beta phase. We’re excited to see what you build!

---

# Atlas Device Sync Migration Example: Healthcare App Moves To PowerSync

> In this post, we show how WeKan, a MongoDB implementation partner, moved a customer’s healthcare proof-of-concept (POC) app from Realm and Atlas Device Sync to PowerSync. Ranjan Moses, Partner & Global Head - Presales & Solutions at WeKan and his team spoke to PowerSync about their experience. You’ll see what motivated their migration, how they did it, and why PowerSync works for offline-first healthcare projects — or any apps that rely on MongoDB and need offline access.

- Published: 2025-02-13
- Author: Phillip van der Merwe
- Category: Showcase
- Source: https://powersync.com/blog/atlas-device-sync-migration-example-healthcare-app-moves-to-powersync

---

## Introduction

In this post, we’ll show how [WeKan](https://www.mongodb.com/company/partners/wekan), a MongoDB implementation partner, moved a customer’s healthcare proof-of-concept (POC) app from Realm and Atlas Device Sync to PowerSync. **Ranjan Moses** , Partner & Global Head - Presales & Solutions at WeKan and his team spoke to PowerSync about their experience.

You’ll see what motivated their migration, how they did it, and why PowerSync works for offline-first healthcare projects — or any apps that rely on MongoDB and need offline access.

## Why Migrate?

WeKan’s customer had three critical reasons to migrate:

### 1\. Move away from complex custom sync solution

Maintaining their own sync solution was getting more and more complicated: “they were handling all of the networking and the sync process — the online state, the offline state — through APIs and, you know, essentially maintaining their own sync system, if you can call it that”, Ranjan noted.

With an expansion of the app to handle large Electronic Health Records (EHR) on the horizon, this was becoming more urgent.

### 2\. Offline capabilities

An offline-first architecture was critical: “They need the capability to have their appointments offline because doctors keep moving in and out of places with network coverage. They may not necessarily be sitting in the consulting room waiting for someone to show up: they could have a loss of connectivity and still need their schedule available.”

### 3\. Atlas Device Sync and Realm deprecation

Realm and Atlas Device Sync met those needs at first, but with their [deprecation](https://www.mongodb.com/products/updates/product-support-deprecation), WeKan sought a new option. They chose PowerSync because it offers real-time data sync, offline capabilities, and fits neatly into the customer’s existing MongoDB stack.

Another reason was that WeKan wanted to create a real-world example app that MongoDB customers can reference: “It's pretty easy for someone to spin this up and try this out themselves, soup to nuts”.

## The Healthcare POC App

![](https://powersync.com/images/blog/atlas-device-sync-migration-example-healthcare-app-moves-to-powersync-inline-c8990d4971.png "_Click to enlarge_")

WeKan built a simple app with two user types:

  * **Doctors** : View incoming appointments, add notes, and mark appointments as complete.
  * **Patients** : Schedule appointments and add dependents under a single profile.

Two collections support this flow:

  * **Appointments** : Stores times, dates, locations, and whether they’re active or complete.
  * **Users** : Identifies each doctor or patient and their associated data.

Where data was shared between users like doctors and patients (like appointment data, for example) data updated should sync to relevant users in real-time.

![](https://powersync.com/images/blog/atlas-device-sync-migration-example-healthcare-app-moves-to-powersync-inline-d62e9ba9a3.gif)

## Replacing Realm and Atlas Device Sync with PowerSync

WeKan took their existing Realm-based app and:

  1. **Duplicated the Project**
  2. **Added Auth0 for Authentication:**[Auth0](https://auth0.com/) provided a straightforward user authentication solution.
  3. **Removed Realm Logic:** Stripped out Realm references and replaced them with PowerSync equivalents in the Swift code, using PowerSync’s [Swift SDK](https://docs.powersync.com/client-sdk-references/swift).
  4. **Tied In PowerSync Cloud:** Using the PowerSync [Dashboard](https://docs.powersync.com/usage/tools/powersync-dashboard), they created a hosted instance of the PowerSync Service and connected it to MongoDB.
  5. **Separated Reads and Writes:** The PowerSync Service ensures real-time sync so that in-app databases are always up to date for local reads, and a simple Node.js backend was used to process uploads of local writes (another option would have been to use PowerSync’s turnkey [backend functionality](https://powersync.com/blog/turnkey-backend-functionality-conflict-resolution-for-powersync)).

The entire migration took a single frontend developer about two weeks.

## Testing Offline Features

Offline features mattered most to the customer. To test them:

  * They turned off network connections on a test device.
  * They booked a new appointment.
  * When the device went back online, the appointment synced to the server and appeared on the doctor’s screen.

This flow is vital for roaming healthcare workers who may not have stable connections: “Every time the shift changes, they sync downstream and hold that data for the next eight hours or nine hours or whatever that shift is on the device."

## Lessons Learned

Here’s what WeKan found:

  1. **Minimal Code Changes:** Because the backend still used MongoDB, the data models needed little work.
  2. **Simple Swift SDK:** They replaced Realm calls with equivalent calls in PowerSync’s Swift SDK.
  3. **Offline-First Architecture:** The app uses an on-device database to work fully offline, and syncs when users reconnect.
  4. **Reasonable Migration Time:** Two weeks of focused work got the POC running on PowerSync.
  5. **All Managed by a Frontend Developer:** A single frontend developer could manage the entire migration without support from a backend team.

> “Our developer (a mobile engineer) was able to set up this whole thing without support from a backend developer. This gives us the confidence that it's going to be pretty easy for customers to migrate from Realm to PowerSync”

– Ranjan Moses, Partner & Global Head - Presales & Solutions at WeKan

## Why PowerSync?

PowerSync offers:

**Offline-First Functionality** : Perfect for staff who need stable access to patient data.

**Scalability** : Handles heavy data loads like EHR records.

**Security** : Runs on secure MongoDB backends, with encryption where needed.

**Flexibility** : Connects to your chosen authentication provider and allows custom backend logic for accepting writes to MongoDB.

## Conclusion

If you rely on MongoDB Realm and Atlas Device Sync, now is the time to plan your migration. WeKan’s experience shows that switching to PowerSync can be quick and painless. The healthcare POC app retained its core functionality — real-time data sync, offline access, and easy user management — and is now free of deprecated dependencies.

## Need Help?

Contact us at [PowerSync](https://powersync.com/contact) to learn how we can guide your migration from Realm and Atlas Device Sync.

---

# PowerSync Update: January 2025

> We’re excited to share our roadmap for 2025! Also read on to see what we shipped in January, including using the latest SQLite implementation for web and the release of CloudCode which lets you deploy necessary backend components directly on our cloud environment.

- Published: 2025-02-07
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-january-2025

---

We’re excited to share our roadmap for 2025! Also read on to see what we shipped in January, including using the latest SQLite implementation for web and the release of CloudCode which lets you deploy necessary backend components directly on our cloud environment. Oh, and [Simon Binder joined our team](https://powersync.com/blog/simon-binder-joins-powersync)!

## 2025 Roadmap: SQLite, Web, Speed & Versatility

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-8b284c6e0a.png)

Announcing our roadmap for 2025 that will level-up PowerSync for the **new era of web apps powered by sync engines** , while preserving our offline & mobile DNA.

[Read here](https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility)

## New: Turnkey Backend Functionality with CloudCode

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-4b53d9fb6c.png)

**CloudCode** is a component that makes it possible to implement the backend API and JWT generation functionality required for using PowerSync directly on our cloud environment.

This makes PowerSync easier to implement for developers who prefer not having to maintain their own backend code and infrastructure. Initial support for MongoDB.

[Read the post](https://powersync.com/blog/turnkey-backend-functionality-conflict-resolution-for-powersync)

## OPFS Outshines IndexedDB

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-1eb3fffdfc.png)

Advancements in browser standards now enable SQLite to use filesystem storage via the OPFS browser APIs.

Version 1.13.0 of our **JS Web SDK** introduces support for this, with significantly improved performance over storing SQLite block data in IndexedDB.

Thanks to **@json** , **@Yahya** , **@ak11** , **@Oussama** and **@rhashimoto** for their help!

[Read the docs](https://docs.powersync.com/client-sdk-references/javascript-web#sqlite-virtual-file-systems)

## Self-Hosters Can Now Use Postgres for Bucket Storage

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-abf0854eb9.png)

Self-hosting PowerSync no longer has a requirement to use MongoDB for sync bucket storage — you can use Postgres instead!

H/T **@Isaac Hinman** , **@grinko** , **@Venkatesh Chittimuri** and **@noteeeeer**.

[Read the release notes](https://releases.powersync.com/announcements/introducing-postgres-for-sync-bucket-storage)

## JVM Compatibility for Kotlin Multiplatform

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-68c350648f.png)

The latest version of our **Kotlin Multiplatform SDK** introduces support for the JVM target, which means that you can now deploy your PowerSync app to desktop platforms including Linux, Windows, and macOS.

Take a look at our `**hello-powersync`** demo app, which now includes the JVM target. 

H/T **@SalomonBrys**!

[View the demo app repo](https://github.com/powersync-ja/powersync-kotlin/blob/main/demos/hello-powersync/composeApp/build.gradle.kts)

## Encryption Support for Flutter Web

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-2aca325926.png)

Version 0.1.4 of `**powersync_sqlcipher`** brings database encryption support to Flutter Web using SQLCipher. Note that using the `**powersync_sqlcipher`** package replaces the need for the `**powersync`** package.

Thanks to **@sbeltran10** and **@willsmanley** for spurring us on here :)

[View the package](https://pub.dev/packages/powersync_sqlcipher)

## New Tutorial: Sequential ID Mapping

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-074c774c37.png)

When using auto-incrementing or sequential IDs in your backend database, how do you handle offline client-side record creation?

A good solution is to use a secondary UUID on the client, then map it to a sequential ID when performing an update on the backend database.

[See the tutorial](https://docs.powersync.com/tutorials/client/data/sequential-id-mapping)

## Blog Post: Migrating a MongoDB Atlas Device Sync App to PowerSync

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-e8e14d839d.png)

Moving away from MongoDB Atlas Device Sync / Realm? This is for you.

[See the post](https://powersync.com/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync)

## Blog Post: How Fast is Our Flutter SDK?

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-72cf6265b4.png)

Benchmarks of our **Flutter Client SDK** , focusing on two key metrics: initial sync time and incremental sync latency.

[Read the post](https://powersync.com/blog/how-fast-is-powersync-performance-benchmarks-for-flutter)

## Blog Post: Ditto vs PowerSync

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-2c7b364319.png)

We’ve completed a thorough analysis of the two systems and can share our findings.

[Read the post](https://powersync.com/blog/ditto-vs-powersync)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-january-2025-inline-f128d0f6d7.png)

**New starter kit:** PowerSync + Supertokens + Postgres + Email

Amazing work by **Guillem Puche** 👏

See it [here](https://github.com/guillempuche/selfhost_fullstack_in_vps)

That's it for the January update, happy coding!

---

# PowerSync 2025 Roadmap: SQLite, Web, Speed & Versatility

> Today we are announcing our roadmap for 2025 that will level-up PowerSync for the new era of web apps powered by sync engines, while preserving our offline & mobile DNA. Since browsers have arguably become the dominant platform for delivering modern applications, we’re doubling-down on web-focused enhancements to accelerate the sync engine revolution.

- Published: 2025-02-06
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility

---

> **Warning**
>
> **December 2025 update** : This blog post is outdated and no longer accurate in several respects. We published a new blog post with an update on the 2025 roadmap [here](https://powersync.com/blog/2025-powersync-roadmap-update). Our implementation plans changed regarding several aspects mentioned in the blog post below, including Simplified Sync Rules mental model, On-Demand Buckets vs Pre-Synced Buckets, and Caching Helper APIs. All of those have been superseded by our new Sync Streams system.

PowerSync began as a sync engine for apps that need to work _offline_. But more and more developers are using sync engines for always-online web apps. Why? Because they make web apps super-fast [^1], and significantly simplify state management [^2]. 

PowerSync has some strong qualities, like how it exposes standard SQLite, and its robust offline capabilities. Yet it has areas where it needs to evolve to work better for online web apps.

Today we are **announcing our roadmap for 2025** that will level-up PowerSync for the new era of web apps powered by sync engines,  while preserving our offline & mobile DNA. Since browsers have arguably become the dominant platform for delivering modern applications, we’re doubling-down on web-focused enhancements to accelerate the sync engine revolution.

Before we dive in to our roadmap, we want to take a quick look at the foundation that we’re building on:

## The principles guiding us: SQLite front and center

In 2024 we made substantial progress with the core PowerSync product and grew our community by 16x [^3].

The number one product principle that has guided us is to provide an open-source _real database_ on the client-side, with a specific focus on SQLite [^4]. This is as opposed to some kind of cache, key-value store or proprietary relational datastore [^5].

This approach **leverages the power of SQLite** and its ecosystem:

  * **SQL functionality & concepts:** Millions of developers are already well-versed in SQL constructs and syntax, which means that there’s an instant familiarity with using SQLite. It also means having access to its rich functionality such as aggregations, joins, advanced indexing and JSON support [^6].
  * **Ecosystem & extensibility:** SQLite brings a lot with it: You can use popular ORMs that you’re already [familiar](https://bsky.app/profile/did:plc:tcjpnay5ei2qmis3vv26izm3/post/3lhckukxb622j) with, such as Drizzle, Kysely and Drift. You can use SQLite extensions such as SQLCipher for encryption and FTS5 for full-text search [^7]. You can use standard tools for inspecting the database and doing more in-depth debugging. You get all the benefits of the SQLite community and the innovation around it: SQLite just keeps becoming more popular, and people keep doing more new interesting things with it.
  * **Performance & maturity:** SQLite is also _really_ fast, and extremely battle-tested: the SQLite team [estimates](https://www.sqlite.org/mostdeployed.html) that there are more than a trillion SQLite databases deployed, and every line in the codebase has 600 lines of test code.

The ubiquity of SQLite also creates opportunities for adopting PowerSync in the SQLite “installed base”: wherever you find SQLite, you can likely use PowerSync too [^8].

How we use SQLite is related to another guiding principle: **Low lock-in**. PowerSync is designed to be a “pluggable middleware” layer rather than a high lock-in monolithic system. It sits between popular backend databases on the server-side, and SQLite on the client-side. Replacing it with a different sync engine is fairly straightforward [^9]. Since PowerSync is built to work with open technologies and is itself [open](https://powersync.com/blog/new-open-era-for-powersync) too, you can have an end-to-end stack optimized for low risk.

## SQLite marches on to the web

SQLite is best known as a database for mobile apps, desktop apps, and other embedded use cases. But lately it’s also becoming a force to be reckoned with on the web.

We’ve [written extensively](https://powersync.com/blog/sqlite-persistence-on-the-web) about the evolution of SQLite persistence in web browsers. The early implementations were hack-y, but we’ve reached a point where using it is much more mature. By letting SQLite use filesystem storage via the OPFS browser APIs, the performance is substantially improved compared to the previous common practice of persisting SQLite block data in IndexedDB, which is essentially [a hack](https://powersync.com/blog/exploring-sqlite-implementations-for-web#storage-layer-caveats)!

I was recently speaking to a product VP at a database company about embedded databases, and he told me: “Clearly, SQLite has won”. We are betting that SQLite will win the web too, because it strikes the best balance between powerful capabilities and being lightweight [^10].

## Roadmap for 2025: Leveling-up on the web

So how should PowerSync evolve to meet the needs of web apps? We started by taking a deep look at how we currently stack up:

  * **Sync Rules defined server-side only:** PowerSync currently requires defining “[Sync Rules](https://docs.powersync.com/usage/sync-rules)” upfront on the server-side to specify what data to sync to which client. From the moment when a client connects to PowerSync, all data that they are supposed to have will sync as quickly as possible. Sync Rules can make use of dynamic parameters from the client-side, but the architecture still limits flexibility. When you’re developing web apps, it’s more intuitive to dynamically request data from the client-side at runtime, since the client is almost always online.
  * **Managing client-size storage size:** When the client is generally always online, it’s less of a concern if some data is not present in client-side storage, since you can easily sync data from the server at will. This means that you can treat the client-side storage more like a cache and expunge data from it if you want. It’s possible to accomplish this with PowerSync’s [client parameters](https://docs.powersync.com/usage/sync-rules/advanced-topics/client-parameters#client-parameters), but we don’t have elegant built-in tooling for this.
  * **Web performance:** Client-side performance is not fully optimized for web apps yet. For example, PowerSync currently refires “live queries” when any row in the underlying tables has changed. This leads to performance limitations with complex queries used in UIs displaying lots of information, as you would find in sophisticated web apps.

Accordingly, we decided on these key items for our 2025 roadmap:

### 1\. On-demand syncing of data in addition to pre-syncing data

We’ll introduce the ability to sync data on-demand from the client at runtime. This will tie into the concept of “[buckets](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets)” (logically-grouped subsets of your data): We will have **On-Demand Buckets** as well as **Pre-Synced Buckets** — the latter refers to what is currently supported by PowerSync [^11].

On-Demand Buckets would eliminate the need to design Sync Rules upfront based on what kind of data you anticipate will be needed by clients. The idea is that you can request specific data at any time in your client-side code [^12]

On-Demand Buckets would also open up the ability to do “hybrid queries” — i.e. combining data that is already present in the client-side SQLite database with data synced on-demand from the backend database; or in other words, combining “offline” & “online” data.  

We will also provide **Caching Helper APIs** in the client SDK that make it easier to manage which buckets should be kept on the device vs. which can be expunged [^13]. It will include time-based caching: setting an “expiration time” for buckets.

### 2\. Web performance optimizations

We will focus on speeding up initial sync as well as client-side query performance on the web. This is critical since creating super-fast apps with instantly-responsive UI/UX is one of the primary value propositions of sync engines on the web.

This will include things such as compression of the data traveling over the network, “prioritized syncing” (being able to prioritize certain buckets of data to sync before others), and an incrementally-updating version of our live query / watched query APIs, to avoid re-running entire queries continuously whenever any row in an affected table is updated.

## 2025 roadmap beyond the web

We’re also planning major enhancements focused on all users, not just web: 

  * **Improved querying flexibility by syncing from incrementally materialized views:** PowerSync currently has limited querying flexibility in Sync Rules, e.g. when it comes to multi-level joins and many-to-many relationships. Therefore, we’ll introduce the server-side ability to create materialized views that you can sync from, which are automatically incrementally updated using an Incremental View Maintenance (IVM) or a similar algorithm.
  * **Simplified Sync Rules mental model:** Our “mental model” is more complex than necessary for many use cases. To address this, we will introduce Simple Sync Rules that can be used for per-user data and global data with a simplified syntax, while still allowing for Advanced Sync Rules that allow explicitly naming buckets and making use of parameter queries.
  * **Developer onboarding experience:** It takes too long to get started with PowerSync. Self-hosting our Open Edition for local development is also painful. Accordingly, we will optimize the onboarding journey for PowerSync, focused on two “golden paths”: (1) PowerSync Cloud — We have a range of improvements planned to the PowerSync Dashboard, including integrating serverless cloud functions into the stack for backend functionality. (2) PowerSync Open Edition + CLI: We have a substantial set of improvements planned!

## What we’re building towards

Our aim is to provide **optionality to optimize for offline and/or online use cases.**

This ensures that PowerSync can adapt as you expand the scope of your software project or product: For example, you may start with building an online web app and later realize you want to also offer an offline-capable desktop or mobile app. Or the other way around. Whichever way you go, PowerSync will have you covered.

  * _For always-online apps:_ On-Demand Buckets with the ability to temporarily “cache” them on the client and expunge them later.
  * _For offline-capable apps_ : Pre-Synced Buckets that ensures data will be available on-device before a user unexpectedly goes offline [^14].

![](https://powersync.com/images/blog/powersync-2025-roadmap-sqlite-web-speed-and-versatility-inline-e06234ddbc.png "_Click to enlarge_")

We will also continue to go **all-in on open technologies** , with a major focus on SQLite.

## It starts now

We have already taken the first steps towards our product vision:

  * On January 28th, 2025 we released support for [using OPFS](https://docs.powersync.com/client-sdk-references/javascript-web#sqlite-virtual-file-systems) as a virtual file system (VFS) for SQLite on the web. Our testing [showed](https://github.com/powersync-ja/powersync-js/pull/418) significant performance gains.
  * On January 21st, 2025 we introduced the ability to use your own SQLite [extensions](https://github.com/powersync-ja/powersync-js/tree/main/packages/powersync-op-sqlite#loading-sqlite-extensions) with OP-SQLite on React Native. This is the first step toward better support for custom extensions in general [^7].
  * On January 15th, 2025 Simon Binder [joined](https://powersync.com/blog/simon-binder-joins-powersync) our team. Simon is prominent in the SQLite community, known for creating and maintaining the [Drift](https://drift.simonbinder.eu/) library for Flutter. He will help us accelerate many of our 2025 goals.

It’s an exciting time for web apps: sync engines make it easier and faster to build much higher-quality web apps. We believe, along with a growing cohort of developers, that sync engines are the application architecture of [the future](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web) — and they will define the new baseline for modern web apps. Stay tuned for updates!

## Questions? Feedback? 

Please feel free to [get in touch](https://powersync.com/contact) or talk to us [on Discord.](https://discord.gg/powersync)

[^1]: Sync engines allow your app code to make use of a local client-side database that automatically syncs with a backend database in the background. This means there’s zero network latency involved in working with data. Because of a reduced reliance on the network, it also means better reliability and availability for the user. When users are online, data is typically synced in real-time, allowing for real-time multi-user collaboration. We’ve written about all of this before [here](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web).
[^2]: For developers, sync engines are emerging as the new preferred way of dealing with state: They make state transfer and state management much easier than working with request/response APIs — which involve a ton of drudge work for developers. Sync engines abstract away a huge amount of complexity that normally necessitates that drudge work — almost everything related to APIs and dealing with the unpredictability of moving data over the network (e.g. error handling and rollbacks). And we’re not just talking about discrete state transfer, but also keeping state up-to-date in real-time on the client and reconciling those real-time updates with local state. We envision sync engines disrupting REST, GraphQL and gRPC — and those technologies becoming legacy ways of dealing with state transfer and state management in applications. We previously wrote about this [here](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web) and [here](https://powersync.com/blog/local-first-software-origins-and-evolution#the-developer-benefits-are-by-far-the-biggest-win-of-local-first).
[^3]: After [launching](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer) PowerSync as a standalone sync engine in late 2023, in 2024 we mainly focused on maturing the core product: We added support for MongoDB and MySQL as backend source databases in addition to Postgres. We moved to an open-core model, [releasing](https://powersync.com/blog/new-open-era-for-powersync) the Open Edition of PowerSync, which developers can freely use and self-host. We expanded our set of client SDKs to include Kotlin Multiplatform and Swift in addition to Flutter, JavaScript web and React Native. We added support for ORMs including Kysely, Drift and Drizzle. We shipped supporting tools, including monitoring & alerting for managing PowerSync in production. We implemented performance optimizations. The list goes on 😄
[^4]: Our initial focus is SQLite because we see it as the top choice, but we may make this more pluggable in the future and support other popular open-source databases on the client-side. Something else you might wonder about is — why does PowerSync not support SQLite on the backend too? It currently only supports Postgres, MongoDB and MySQL as backend databases. There is a case to be made for this and it’s something we may support in the future. SQLite-to-SQLite sync could work well for scenarios where you have per-user data, and even for situations where you’re sharing data in a point-to-point way. However, many use cases have a large set of data that’s shared between users. In a situation like this, we believe the most sensible way to solve it is to use a database designed for a high volume of shared data on the backend (e.g. Postgres, MySQL, MongoDB) and SQLite on the client-side containing the data relevant to a specific user. Syncing between these backend databases and SQLite on the client-side introduces a unique set of challenges — which is what PowerSync is focused on. Another way of looking at it is that PowerSync supports the most popular backend databases on the server-side, as well as the most popular embedded database on the client-side.
[^5]: How do we think about the key-value stores provided by state management libraries? There’s an [argument to be made](https://sqlsync.dev/posts/stop-building-databases/) that every client-side key-value store or cache eventually approaches the complexity of an actual database. Which is why we figured putting a real database like SQLite on the client-side is the way to go. There’s also some downsides to how state management frameworks tend to work: You typically need to define a lot of things centrally, such as what actions are allowed on the state. With a real database on the client-side, components directly read and write on the database, allowing dealing with state to be decentralized to individual components. With SQLite paired with PowerSync, the local database also provides a consistent view of the data, meaning you don’t need to keep track of cache invalidation and keep different instances of the data consistent with each other.
[^6]: These are some of the major reasons why we originally [set out](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer#why-we-built-powersync-a-need-for-a-sql-focused-sync-engine) to build a SQL & SQLite focused sync engine: because of SQL’s universality and how effective SQLite is for advanced querying.
[^7]: It’s possible to use any other SQLite extensions such as Spatialite, sqlite-vec and more — we are working on better surfacing and documenting this
[^8]: In fact, the core of PowerSync is [structured](https://github.com/powersync-ja/powersync-sqlite-core) as a SQLite extension, making it very pluggable to existing SQLite “installations”. For existing installations of SQLite, syncing the data in it is becoming more and more of a table stakes feature, for collaboration, multi-device access and backups.
[^9]: You most likely wouldn’t even need to change your client-side queries or ORM code if you were to do this.
[^10]: Some developers may still have concerns about using SQLite for persistence on the web — such as its bundle size and performance. Our stance is that these factors are already not a major concern for most web apps, and their impact will further diminish over time, e.g., bundle size will be less and less of a concern because of increasing bandwidth (and compression).
[^11]: Whereas Pre-Synced Buckets are persistent in the PowerSync Service, On-Demand Buckets would be created on-demand in the PowerSync Service, by doing a snapshot from the source backend database and then keeping track of updates through the CDC stream. Least recently used (LRU) On-Demand Buckets would be garbage-collected in the PowerSync Service. If a client tries to use an On-Demand Bucket that was already garbage-collected, it would be re-created dynamically in the PowerSync Service. Details of how authorization/permissions will work are still TBD.
[^12]: Note that to go to production, for security purposes you would still need to specify permissions/authorization to ring-fence what data clients are allowed to sync/query. See preceding point.
[^13]: This will include the ability to automatically combine parameters for data needed across multiple UI components and/or multiple browser tabs.
[^14]: The benefit is that you don’t have to care about where in the lifecycle of the application to sync/query the data, and it therefore maximizes the probability that data will be available on-device before a user unexpectedly goes offline.

---

# Ditto Vs PowerSync

> We’ve been asked how PowerSync compares to Ditto, especially since MongoDB has deprecated its Atlas Device Sync product and indicated both Ditto and PowerSync as potential migration paths. We’ve put together this overview to answer this question more thoroughly.

- Published: 2025-01-29
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/ditto-vs-powersync

---

> **Warning**
>
> Since this post was published, PowerSync has released [Sync Streams](https://docs.powersync.com/sync/streams/overview) — where you define reusable streams and clients subscribe to them with parameters. References to Sync Rules below describe the legacy system.

We’ve been asked how PowerSync compares to [Ditto](https://ditto.live/), especially since MongoDB has [deprecated](https://www.mongodb.com/products/updates/product-support-deprecation) its Atlas Device Sync product and [indicated](https://www.mongodb.com/docs/atlas/app-services/sync/device-sync-deprecation/) both Ditto and PowerSync as potential migration paths. We’ve put together this overview to answer this question more thoroughly.

Note that this comparison was created by the PowerSync team based on public Ditto documentation as it existed around mid-January 2025. As such, there might be areas of Ditto we did not focus on or have inadvertently overlooked. Please feel free to [get in touch](https://powersync.com/contact) or talk to us [on Discord](https://discord.gg/powersync) if you have any questions or comments, or would like to highlight any corrections or omissions.

## Executive summary

Both Ditto and PowerSync are sync engines providing overlapping functionality (such as offline-first architecture, query-based partial syncing, real-time syncing, live queries on the client-side and consistency guarantees), but there are major differences:

  * **Ditto enables peer-to-peer (P2P) syncing** **whereas PowerSync has a more traditional client-server architecture** where data is always synced to clients via a server. Ditto’s P2P functionality is innovative and powerful but introduces complexities that might be unfamiliar to developers who are used to a client-server architecture.
  * **PowerSync exposes a standard SQLite database to developers on the client-side whereas Ditto exposes a proprietary datastore interface** [^1] that lacks certain functionality compared to SQLite. SQLite is a widely-used open-source database and developers can use popular SQLite tools with PowerSync such as ORMs.
  * **The source code for PowerSync is open, whereas Ditto is closed-source**. This allows anyone to inspect and modify the core PowerSync system. Relatedly, PowerSync can be run locally and self-hosted, whereas Ditto cannot.
  * **Ditto is a fully-fledged database whereas PowerSync is a pluggable “middleware” sync layer** that acts as a bridge to existing backend databases (Postgres, MongoDB and MySQL) with bidirectional syncing. To sync data unidirectionally from Ditto to an external backend database requires integration using Kafka (an optional premium upgrade). For bidirectional syncing with an external database, Ditto’s MongoDB Connector could be used in the case of MongoDB (which is in preview and not yet production-ready at the time of writing) or a custom solution would be needed. 
  * **Ditto has some prescriptiveness and restrictions around how authentication and authorization** can be accomplished, whereas PowerSync allows for more flexibility.
  * **Ditto uses CRDTs to merge changes** and resolve conflicts automatically. In comparison, PowerSync’s authoritative-server architecture makes conflict resolution behavior such as “last write wins” straightforward, while also allowing more customizability if needed.

  
Below, these similarities and differences are explored in more detail.

## Similarities between Ditto and PowerSync

Here are some of the surface-level similarities between the two products:

| Topic | Ditto | PowerSync |
| --- | --- | --- |
| Cloud/server environment | The Ditto [Big Peer](https://docs.ditto.live/cloud/overview) is described in parts of the Ditto documentation as a “server” although it is in most ways another peer in the distributed Ditto mesh network. Typically deployed in the cloud, it acts as a “trusted peer” in the network that provides services such as authentication, acting “as a conduit for mesh-generated data” (e.g. exposes an HTTP API) and allowing for integration with external databases. The Big Peer [facilitates](https://docs.ditto.live/sdk/latest/sync/concepts/transports-overview) “device-to-cloud-to-device” syncing as opposed to device-to-device (P2P) syncing that is also supported by Ditto [^2]. | The PowerSync Service is the server-side component of PowerSync, and is in many ways analogous to the Big Peer in Ditto. It streams changes from the source backend database (Postgres, MongoDB, MySQL) and syncs them in real-time to clients based on [Sync Rules](https://docs.powersync.com/usage/sync-rules), which also control authorization [^2]. |
| Client environment | [Small Peers](https://docs.ditto.live/home/about-ditto#small-peers) that embed the Ditto SDK are analogous to “clients” in a client-server architecture. Small Peers are typically end-user environments such as mobile, web, desktop or embedded apps. | [PowerSync client SDKs](https://docs.powersync.com/client-sdk-references/introduction) are embedded into mobile, web, desktop or embedded apps. |
| Supported client SDKs | Ditto [supports](https://docs.ditto.live/sdk/latest/install-guides/install-guides) an impressive range of SDKs, including Swift, Kotlin, Flutter, React Native, JavaScript Web, C#/.NET, Java, Rust and C++ [^3]. | PowerSync currently [supports](https://docs.powersync.com/client-sdk-references/introduction) Flutter, React Native, JavaScript Web, Swift, Kotlin, Node.js and .NET client SDKs, and others on the [roadmap](https://roadmap.powersync.com/tabs/5-roadmap). |
| Offline-first architecture | Provides for an offline-first architecture, enabling uninterrupted functioning of the app even if the network or cloud services become unavailable. Ditto supports P2P syncing of data which allows Small Peers to sync with each other even if connectivity to the wide area network is unavailable. | Provides for an offline-first architecture, enabling uninterrupted functioning of the app even if the network or cloud services become unavailable. While apps can continue to access their local database and read and write data while offline, PowerSync does not provide any built-in functionality to allow clients to sync with each other (P2P) when connectivity to the wide area network is unavailable. |
| Query-based partial syncing | Using [Subscriptions](https://docs.ditto.live/sdk/latest/sync/syncing-data) defined on the client-side [^4]. | Using [Sync Rules](https://docs.powersync.com/usage/sync-rules) defined on the server-side, which can accept parameters from the client-side [^4]. |
| Real-time syncing | Provides for real-time syncing (P2P or via the Big Peer) | Provides for real-time syncing whenever clients are connected to the PowerSync Service |
| Reactivity on the client-side | Using [Store Observers](https://docs.ditto.live/sdk/latest/crud/observing-data-changes#observing-data-changes) | Using live queries |
| Delta syncing for efficiency | Syncs deltas for efficiency, using CRDTs | Syncs deltas (field-level operations) for efficiency |
| Authentication | Conceptually similar to PowerSync, although technical details differ significantly: • [OnlinePlayground](https://docs.ditto.live/sdk/latest/auth-and-authorization/cloud-authentication) authentication for development / testing [^5] • [OnlineWithAuthentication](https://docs.ditto.live/sdk/latest/auth-and-authorization/cloud-authentication#onlinewithauthentication-identity) to integrate with existing authentication / login and authorization systems. Other advanced authentication schemes are also offered. | Conceptually similar to Ditto, although technical details differ substantially: • [Development Tokens](https://docs.powersync.com/installation/authentication-setup/development-tokens) for development / testing • [Authentication integration](https://docs.powersync.com/installation/authentication-setup) for production |
| Attachments (binary files) | Attachments are “stored outside the main database” — only tokens/pointers to attachments are stored in the database. Attachments [are not](https://docs.ditto.live/sdk/latest/data-types/attachment) automatically synced and need to be explicitly fetched. Support for attachments is built-in to the core Ditto product. | Recommends that attachments are stored outside the database — only tokens/pointers to attachments should be stored in the database. Attachments need to be fetched as needed. Attachments are supported outside of the core product using [helper packages](https://docs.powersync.com/usage/use-case-examples/attachments-files). |
| Consistency guarantees | [Causal consistency](https://docs.ditto.live/cloud/backend-architecture/cloud-optional-design#consistency-considerations) is enforced on the Big Peer. Note: Only eventual consistency is provided on the Small Peers — see below. | [Causal consistency](https://docs.powersync.com/architecture/consistency) guarantee |
| Monitoring tools | [Device dashboard](https://docs.ditto.live/cloud/portal/capturing-small-peer-info) showing per-device information | [Monitoring & alerting](https://docs.powersync.com/usage/tools/monitoring-and-alerting) tools including usage metrics dashboard, instance logs, issue alerts and metric alerts (deliverable as webhooks) |

## Key differences between Ditto and PowerSync

### #1: P2P architecture vs. server-client architecture

| Ditto | PowerSync |
| --- | --- |
| Ditto has a decentralized P2P architecture and provides for P2P syncing (transfer directly between devices), with the exception of web browsers: P2P syncing is [not available](https://docs.ditto.live/support/faq#can-i-use-both-connectivity-types-device-device-and-device-server-device-at-the-same-time) for web apps. | PowerSync has a more traditional client-server architecture, where clients sync data via the PowerSync Service. |
| Ditto Small Peers [pull](https://docs.ditto.live/sdk/latest/sync/concepts/mesh-networking-101#query-subscription-system) data from other peers whereas the Big Peer can also [push](https://docs.ditto.live/cloud/backend-architecture#soft-state-satellite-api-nodes) data to Small Peers. | PowerSync always pushes data from the PowerSync Service to clients. |
| Ditto is an innovative and powerful product for use cases that require P2P syncing. That being said, for many developers, the P2P/distributed architecture is a new and different paradigm to adapt to, and it comes with potential pitfalls and idiosyncrasies. We have listed some of these [in an Annexure](https://powersync.com/blog/ditto-vs-powersync#annexure-p2p-complexities) below (the security threat modeling is likely amongst the most important considerations.) | PowerSync’s client-server architecture is a familiar architecture pattern for many developers, and therefore the system is relatively easy to reason about. PowerSync aims to provide a simple and robust architecture with comprehensive sync capabilities. It also aims to be extensible (developers can build on top of its simple yet capable core) and inspectable (developers are able to see what is happening within the system). |
| While Ditto enforces causal consistency on the Big Peer as mentioned above, only eventual consistency is [provided](https://docs.ditto.live/cloud/backend-architecture/cloud-optional-design#consistency-considerations) on the Small Peer. This means that causally-related updates can appear out-of-order on Small Peers. | PowerSync provides causal consistency on the client. This means that updates will always appear in causal order. |
  
### #2: Open common technologies vs. proprietary technologies

| Ditto | PowerSync |
| --- | --- |
| Ditto exposes a proprietary datastore interface and query language (DQL) to developers [^1]. | PowerSync exposes a standard open-source SQLite database to developers on the client-side. SQLite is the most [widely deployed](https://www.sqlite.org/mostdeployed.html) database in the world. |
| Functionality such as aggregations, `GROUP BY`, joins, querying from multiple collections in the same query, and cross-collection transactions are [not implemented](https://docs.ditto.live/dql/roadmap) in Ditto at the time of writing. Since Ditto is a proprietary database, the Ditto team has to build these features from the ground up. | PowerSync allows developers to leverage the mature capabilities that have existed in SQLite for many years, including its strong support for aggregations, joins, advanced indexing, transactions and JSON. |
| Ditto reportedly [does not](https://docs.ditto.live/support/faq#is-the-data-in-the-database-encrypted) provide client-side database encryption. | PowerSync provides integrations with commonly-used SQLite libraries such as SQLCipher for client-side database encryption. |
| Ditto operates as a document database storing JSON-like documents. | PowerSync syncs [schemaless](https://docs.powersync.com/architecture/powersync-protocol) JSON data and dynamically applies a client-side schema to the JSON data in SQLite using SQLite views. As a result, PowerSync adapts easily to working with both SQL and NoSQL backend source databases (e.g. Postgres or MySQL vs. MongoDB) and client-side schema migrations are generally not needed. Yet PowerSync still allows access to rich SQLite querying functionality. |
| Ditto introduces its own data types (e.g. `REGISTER`, `MAP`). | PowerSync leverages SQLite’s simple type system, [type affinity](https://www.sqlite.org/datatype3.html#type_affinity), and its powerful JSON capabilities to work with JSON data, including embedded documents. |
  
### #3: Open vs. closed-source, running locally and self-hosting

| Ditto | PowerSync |
| --- | --- |
| Ditto is a closed-source proprietary product. | PowerSync client SDKs and supporting client-side packages are open-source (Apache 2.0 & MIT) while the server-side PowerSync Service is source-available under the Functional Source License (FSL). Anyone can inspect the code for the core product, contribute to it, fork it, etc. |
| The Ditto Big Peer [cannot run](https://docs.ditto.live/best-practices/IJCASYeQiLW9avEk1AiEj#can-i-run-the-big-peer-on-my-local-laptop) on the developer’s local machine. | PowerSync can freely be run locally for development / testing purposes and can be self-hosted anywhere. |
  
### #4: Vertically-integrated database vs. pluggable sync layer

| Ditto | PowerSync |
| --- | --- |
| Ditto is conceptually a full-stack database in and of itself. When it comes to data sync functionality, it is essentially a [“syncing datastore”](https://x.com/aboodman/status/1843049082237170036) rather than a _sync engine_. | PowerSync is designed to be a sync engine that can be plugged into a developer’s existing preferred database stack. PowerSync can be thought of as a middleware layer. The PowerSync Service acts as a thin syncing layer between the primary source-of-truth backend database (Postgres, MongoDB, MySQL) and the client-side database (SQLite). |
| The datastore nature of Ditto introduces more complexity in certain areas, for example: (1) To sync data unidirectionally from Ditto to an external backend database requires using Kafka change data capture (an optional premium upgrade). To sync data bidirectionally, Ditto’s MongoDB Connector can be used in the case of MongoDB (not yet production-ready at the time of writing), or a custom solution would need to be developed. There are potential pitfalls with using the Kafka integration. For example, when the replication falls too far behind, one has to use the HTTP API to [requery](https://docs.ditto.live/cloud/cdc#event-failures) the entire dataset and then resume incremental replication using the Kafka CDC stream. (2) Migrating data between applications [requires](https://docs.ditto.live/best-practices/IJCASYeQiLW9avEk1AiEj#how-do-i-migrate-data-between-applications) the help of the Ditto support team. | PowerSync’s architecture as a bidirectional sync layer between the source-of-truth backend database and the client-side database makes it relatively simple to deploy and manage. Server-to-client sync path: The PowerSync Service pre-processes and pre-indexes data from the source-of-truth backend database (Postgres, MongoDB, or MySQL) for efficient syncing to clients, based on the [Sync Rules](https://docs.powersync.com/usage/sync-rules) configuration for the specific application. Therefore, the PowerSync Service is stateful in the sense that it maintains a “rebuildable cache” of data to be synced to clients. The data in the PowerSync Service can be cleared and recreated from the source backend database at any time. PowerSync automatically takes care of snapshotting data from the source database and keeping it up-to-date using the CDC stream provided by the source database, as needed. Client-to-server sync path: See details at #6 below. |
  
### #5: Ease of authentication & authorization

| Ditto | PowerSync |
| --- | --- |
| Ditto’s approach to authentication requires proxying an authentication request through the Ditto Big Peer to an “authorization endpoint” (webhook URL) provided by the developer. This authorization endpoint needs to conform to a certain implementation [specification](https://docs.ditto.live/sdk/latest/auth-and-authorization/cloud-authentication#server): it needs to accept arguments in a certain format and return a payload in a certain format. | PowerSync allows the developer to define [their own](https://docs.powersync.com/installation/client-side-setup/integrating-with-your-backend) client-side `fetchCredentials()` function that retrieves a JWT from their backend, which in turn allows the PowerSync client SDK to authenticate against the PowerSync Service. This allows for more flexibility and developer choice in implementation. |
| When it comes to authorization, there are restrictions that apply, which will likely require the developer to make system changes for proper implementation: Ditto [only supports](https://docs.ditto.live/sdk/latest/auth-and-authorization/data-authorization#using-the-id-field) specifying a permission query on the `_id` field of a document [^6]. Permissions on mutable document properties are not supported. Therefore, in order to use other document fields in a permission query, they need to be duplicated into a compound `_id` field and treated as immutable. These restrictions also have [implications](https://docs.ditto.live/cloud/mongodb-connector#id-mapping-between-systems) for Ditto’s MongoDB Connector. | Authorization for the read path is controlled using [Sync Rules](https://docs.powersync.com/usage/sync-rules) which are defined using SQL-like queries. Sync Rules can make use of parameters from the JWT as well as client-provided parameters, and have flexibility to reference any of the columns/fields in tables/collections in the backend source database. Writes are persisted to the backend database (Postgres, MongoDB, MySQL) via the developer’s [backend](https://docs.powersync.com/installation/app-backend-setup/writing-client-changes) of choice, where they can apply their own custom authorization rules. In most cases, developers would already have some kind of validation and authorization in place for writes (e.g. on their existing backend API), which they can reuse with PowerSync. |
  
### #6: CRDT distributed architecture vs. authoritative backend architecture

| Ditto | PowerSync |
| --- | --- |
| Ditto uses CRDTs to merge document changes and resolve conflicts. This is a necessary byproduct of the fact that Ditto is a distributed system: since an authoritative server is not part of the system architecture, a deterministic distributed method of merging changes and conflict resolution is required, which is provided by CRDTs. | Since PowerSync has a more traditional server-client architecture, the server is considered authoritative and is used to merge changes and resolve conflicts: The client-side application can perform writes directly on the local SQLite database. Those writes are also automatically placed into an upload queue by the PowerSync client SDK. The SDK then uses a developer-defined `uploadData()` function to manage the uploading of those writes to the backend. In the `uploadData()` function, the developer calls their backend API of choice. Because of the [server-authoritative](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer#server-authority-instead-of-distributedcrdt-architecture) nature of PowerSync, whatever is written to the backend database will automatically be reflected on all clients (without overwriting [local changes](https://docs.powersync.com/architecture/consistency#local-client-changes) that have not yet been uploaded). The developer can either use their own backend completely separate from PowerSync, or use templatized turnkey [cloud functions](https://docs.powersync.com/usage/tools/cloudcode) provided by PowerSync. While PowerSync’s core protocol is not based on CRDTs, it is still possible to [use CRDT](https://docs.powersync.com/usage/use-case-examples/crdts) data structures within PowerSync for applicable use cases. |
| The use of CRDTs means that conflict resolution is restricted to the predefined behavior provided by Ditto for its built-in data types (e.g. registers and maps). | The developer can customize the conflict resolution behavior according to their exact needs, including using CRDTs if desired. If they want simple behavior such as “last write wins”, this is straightforward and turnkey. |
  
### #7: Production-readiness for MongoDB

| Ditto | PowerSync |
| --- | --- |
| Ditto has a [MongoDB Connector](https://docs.ditto.live/cloud/mongodb-connector) which is in preview status (pre-GA) at the time of writing, and is currently subject to various [limitations](https://docs.ditto.live/cloud/mongodb-connector#current-limitations) that would prevent it from being used in production: • The connector “only performs ongoing replication between Ditto and MongoDB” — it cannot yet sync any data already pre-existing in MongoDB. • “The connector only supports the use of the REGISTER datatype within Ditto. Other datatypes such as MAP are not synchronized by the MongoDB connector”. • “Filtering of data to synchronize with MongoDB is done at the collection level, filtering data within a collection to synchronize is not possible”. • “Connection to a MongoDB Atlas cluster is routed via the internet rather than private networking options.” • “It is not possible to change the configuration (e.g. add or remove a collection, change password) from a running connector. You must delete the connector then create it again with the new configuration”. Taken together, limitations 1 and 5 mean that a new MongoDB database has to be created from scratch any time the configuration needs to be changed. | PowerSync’s support for MongoDB is in [V1 GA status](https://powersync.com/blog/powersyncs-mongodb-connector-hits-ga-with-version-1-0) as of March 2025 and has been in production use by customers since December 2024. • It supports initial replication of existing data in MongoDB as well as ongoing replication. • It supports [mapping](https://docs.powersync.com/usage/sync-rules/types#mongodb-beta-type-mapping) between MongoDB types and SQLite types. • It supports filtering data at the collection level as well as within collections — i.e. the standard [Sync Rules](https://docs.powersync.com/usage/sync-rules) functionality provided by PowerSync. • It [supports](https://docs.powersync.com/configuration/source-db/setup/private-endpoints) MongoDB Atlas private endpoints. • The configuration can be changed on existing instances. |

## Annexure: P2P complexities

Ditto’s P2P functionality is innovative and powerful but introduces complexities that might be unfamiliar to developers who are used to a client-server architecture. Here are some examples:

  * **Accessing data:** If one tries to access data on the Big Peer using its HTTP API, the data associated with a specific transaction that happened somewhere in the mesh [might not exist](https://docs.ditto.live/cloud/http-api/auth-and-params#transactions) on the Big Peer yet, since it may require time to propagate through the mesh network (potentially through a multi-hop path)
  * **Deleting data:** There are various intricacies involved with deleting data, with soft-deleting patterns vs eviction of data vs hard-deleting data being applicable in different scenarios, each with its own considerations. For example:   

    * [Soft-Deletion](https://docs.ditto.live/support/mongodb-migrationguide#delete): _“In a distributed data system like Ditto, deletion follows a ‘soft delete’ pattern. This means that when you mark an item as deleted, it’s not immediately removed from the collection or local storage. Instead, the item is flagged as deleted to ensure that other devices in the network remain in sync. To fully remove the item and free up space, you’ll need to evict these ‘soft deleted’ items.”_  
    * [Eviction:](https://docs.ditto.live/sdk/latest/crud/delete) _“The EVICT method, once invoked, immediately removes the specified document from the local Ditto store, making it inaccessible by local queries. Although the document you evicted is removed from the local Ditto store, the document stored within remote Ditto stores persists. To prevent the evicted data from reappearing on the screen in a single flicker, make sure to stop subscriptions before you call EVICT”_
    * [Time-to-Live Eviction Strategy](https://docs.ditto.live/best-practices/time-based-replication): This eviction strategy needs to be managed from the Big Peer to ensure that locally stored documents sync with the Big Peer before eviction (see also [Device Storage Management](https://docs.ditto.live/best-practices/pCZgBpKcap9tMliT8K4p_#lK5WD)).
    * Hard-deleting data from the Big Peer: This feature is currently available [on request](https://docs.ditto.live/dql/evict#removing-data-from-big-peer). Alternatively, deleting data from a Big Peer needs to be done using the legacy HTTP API, which creates Tombstones that cannot be removed themselves.
  * **Data integrity:** The complexities regarding deletion above also segue into complexities around data integrity:   

    * [Delete Considerations](https://docs.ditto.live/sdk/latest/crud/delete#considerations): Permanent data loss: _“If documents are evicted from a local peer and don't exist on any other peer this data is lost and is unrecoverable.”_  
    * [Immutable ID fields](https://docs.ditto.live/sdk/latest/auth-and-authorization/data-authorization#using-the-id-field) _: “Fields used in the id mapping must be immutable and always present to achieve convergence between the two systems. If these requirements are not met, it will result in undefined behavior, such as duplicate Ditto documents with different IDs, or failure to synchronize the document between MongoDB and Ditto.”_  
    * [Small-Peer-Based Eviction](https://docs.ditto.live/best-practices/pCZgBpKcap9tMliT8K4p_#cancel-affected-subscriptions): _“To maintain data integrity, you must cancel any active subscription that the eviction update may impact before executing your eviction process. Otherwise, an undesirable loop may result in which Ditto continuously evicts documents from the local Ditto store and then automatically re‑syncs them, leading to increased memory usage.”_   

      * This is also a [consideration](https://docs.ditto.live/best-practices/pCZgBpKcap9tMliT8K4p_#create-new-subscriptions) for creating new subscriptions: _“You must declare your subscription object from the top-most scope of your app to ensure access throughout the life cycle of your app. Otherwise, you cannot modify or cancel your subscription from any part of your code, resulting in difficulty and potential errors when managing the subscription's lifecycle."_
    * [Conflicts with Tombstone and Modify](https://docs.ditto.live/sdk/latest/data-types/map#conflicts-with-tombstone-and-modify): _“If a tombstone (deletion flag) and a modification (INSERT) operation occur across two peers simultaneously, the resulting state depends on the causal order of these changes.”_
  * **Security:** Additional complexities and considerations are involved in the security model:   

    * Authorization: As mentioned above, permissions queries [must use](https://docs.ditto.live/sdk/latest/auth-and-authorization/data-authorization#using-the-id-field) compound immutable `_id` fields.
    * [Threat modeling](https://docs.ditto.live/sdk/latest/auth-and-authorization/data-authorization#threat-modeling-in-p2p-networks): _“Ditto peers are only able to synchronize data directly from a peer that has the authority to write that document. In other words, small peers are only able to trust writes from other peers that have the authority to make those writes. They cannot trust each other as a source of data that they aren’t authorized to write to, since they can’t tell the difference between an edit they made on their own and one which came from a further hop.”_   

      * _"Today Ditto enforces that data which has to propagate peer-to-peer must have mutual write permissions. If integrity is at risk, you have to sign the payloads yourself at the application level."_
    * [App-level security](https://docs.ditto.live/sdk/latest/auth-and-authorization/data-authorization#app-level-security) vs. identity-level security trade-offs: _“For apps with weaker security requirements, a developer may choose to relax the access rules inside the Ditto certificate, and instead restrict access in their application code. [...] The disadvantage is that an unprivileged user does have a device containing privileged data.”_
  * **Data size management:** Ditto recommends careful management of the amount of data on the device:   

    * [Access Frequency and Relevance Considerations](https://docs.ditto.live/sdk/latest/crud/delete#access-frequency-and-relevance-considerations): _“The fewer the number of documents replicated, the less the likelihood that peer devices run out of disk space and experience memory leaks, and the performance of the peer-to-peer mesh network that interconnects them degrades.”_
    * [Timing Subscriptions and Evictions](https://docs.ditto.live/sdk/latest/crud/delete#timing-subscriptions-and-evictions): _“Use Evict to manage local storage capacity and improve performance by routinely purging data stored locally.”_
    * [Wi-Fi Interference and Client Load](https://docs.ditto.live/best-practices/wi-fi-interference-and-client-load): _“Manage Data Size and Query Complexity: Large document syncs and verbose logging can slow down the network. It's important to manage the size of the data being synced and optimize queries to limit the amount of data processed at any given time. This can be done by evicting irrelevant data periodically and ensuring that only necessary data is queried.“_
    * [Device Storage Management](https://docs.ditto.live/best-practices/pCZgBpKcap9tMliT8K4p_): Eviction can slow down the Mesh: _“Remember that before invoking the EVICT method, you must cancel relevant subscriptions and then restart them. This results in an increase in network usage, which can degrade sync performance. Call EVICT on a regular basis, but no more than once per day during periods of minimal disruption, such as after hours and at night.”_ This relates to the [Time-to-Live Eviction Strategy](https://docs.ditto.live/best-practices/pCZgBpKcap9tMliT8K4p_#time-to-live-eviction-strategy) 
    * [Memory-usage caution:](https://docs.ditto.live/support/troubleshooting#app-is-using-too-much-memory-why) _“A common issue we see in reactive apps is a failure to dispose of resources as conditions change. Your app could create a large accumulation of publishers that infinitely grow. Every liveQuery and subscription in ditto must be explicitly stopped using the stop or cancel API.”_
    * See also: [Troubleshooting](https://docs.ditto.live/support/troubleshooting#synchronization-seems-slow-or-comes-to-a-halt-over-time): _Synchronization seems slow, or comes to a halt over time_
  * **Bandwidth limitations:** Bandwidth limitations of the P2P network (such as limited bandwidth on Bluetooth/BLE) as well as the inherent higher bandwidth usage of a mesh network should be considered. Note that Ditto allows [disabling](https://docs.ditto.live/sync/customizing-transport-configurations#OyUOQ) specific types of mesh network transports.   

    * [Wireless Infrastructure:](https://docs.ditto.live/best-practices/network-deployment#wireless-infrastructure)_“While Ditto does its best to be bandwidth-efficient, meshes are inherently more bandwidth-intensive than a typical hub-and-spoke server model. For larger meshes (e.g. more than 30 devices), LAN issues can start to really play a role in performance degradation.”_
    * [Embedded Maps are Slow](https://docs.ditto.live/best-practices/9lD49ZtExskKuBX-Kq8Jn#6R_dI): _“Deeply nested objects result in slow replication and data store performance”_
    * [End-User Defined Peer Metadata](https://docs.ditto.live/sync/using-mesh-presence#m96Kx): _"Keep the size of peer metadata to a minimum, especially when syncing over Bluetooth LE or similar low-bandwidth transports. This is because peer metadata exceeding 128 KB, the maximum limit, results in the operation failing and Ditto throwing an error."_
  * **Battery life and CPU usage considerations:**   

    * [Managing Redundant Bluetooth LE Connections](https://docs.ditto.live/sdk/latest/sync/managing-redundant-bluetooth-le-connections#considerations-by-mesh-size): _“Maintaining redundant Bluetooth LE connections can impact sync performance, especially in larger meshes with approximately 65 to 100 devices or more, where increased network overhead may cause a slowdown in the data replication process._ ”
    * [Transport Overview: Connections](https://docs.ditto.live/sdk/latest/sync/concepts/transports-overview#connections): _“Each additional LAN connection consumes more CPU time but also depletes radio energy. Bluetooth Low Energy (LE) faces particularly stringent constraints — devices can only handle a few concurrent connections, and each connection initiation can take several seconds.”  _
  * **Local networking configuration complexities:** Use of Ditto’s P2P syncing is dependent on network configuration and permissions considerations.   

    * Ditto P2P syncing over the local network and/or Bluetooth is reliant on the user granting the necessary permissions.
    * Ditto P2P connectivity requires ports to be accessible on devices for external connections.
    * Ditto’s discovery protocol is [dependent](https://docs.ditto.live/sdk/latest/sync/concepts/transports-overview#limitations-4) on the _Client Isolation Mode_ feature on Wi-Fi routers or access points to be disabled.
    * IP multicasting entitlements and related permissions [need to be](https://docs.ditto.live/sdk/latest/sync/concepts/transports-overview#performance-4) enabled for connectivity between iOS and other devices.
    * [Deployment Best Practices:](https://docs.ditto.live/best-practices/prioritizing-bluetooth-connections-in-high-density-mesh-networks) “ _When deploying applications that require multiple Bluetooth devices in a mesh network, it is crucial to prioritize connections to critical devices like payment readers. On iOS, where native prioritization may not be available, developers should implement custom logic to ensure that essential devices maintain a stable connection.”_  
    * Direct WiFi connections can only be used between iOS devices or between Android devices, not cross-platform (see [FAQ](https://docs.ditto.live/support/faq#can-android-and-ios-devices-sync-with-each-other-over-wifi-direct-using-ditto))
    * _“Web browsers do not support peer-to-peer transports. That means a web app will only be able to connect to the Big Peer over WebSockets.”_ ([see here](https://docs.ditto.live/support/faq#can-i-use-both-connectivity-types-device-device-and-device-server-device-at-the-same-time))

[^1]: It appears that the Ditto datastore on Small Peers may use SQLite as its underlying persistence layer, but regardless, the developer interface to the data is Ditto’s proprietary datastore interface and DQL syntax.

[^2]: The Ditto Big Peer acts as a fully-fledged database (built on RocksDB). By contrast, the PowerSync Service acts more like a “rebuildable cache” that sits between the source-of-truth backend database (Postgres, MongoDB or MySQL) and client applications. The PowerSync Service pre-processes and pre-indexes data from the source backend database for efficient syncing to clients (organized into “[buckets](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets)”). This pre-processed “bucket data” is stored in a pluggable storage layer (MongoDB and Postgres are currently supported as bucket storage databases).

[^3]: [Ditto Tools](https://docs.ditto.live/best-practices/integrate-ditto-tools-for-kotlin-swift-and-c-net-in-15-minutes) (debugging and monitoring tools) are not available for all languages/frameworks — they are only available for Android (Kotlin), Swift and C# .NET

[^4]: The fact that subscriptions are defined on the client-side in Ditto result in additional [considerations](https://docs.ditto.live/support/mongodb-migrationguide#6-set-up-subscriptions): _“Start your subscription as early in the application lifecycle as possible. Keep a reference to the created subscription, so you can manage it and it doesn’t get garbage collected”_. These considerations do not apply to PowerSync since its Sync Rules are defined on the server-side.

[^5]: In Ditto, enabling OnlinePlayground Authentication is an app-wide setting enabled on the Ditto cloud portal. The playground token also [appears](https://docs.ditto.live/cloud/portal/getting-playground-token-credentials) to be a global shared token for everyone testing a particular app. In PowerSync, [Development Tokens](https://docs.powersync.com/installation/authentication-setup/development-tokens) are generated for a specific user and expire after a certain period of time.

[^6]: Another caveat is that permissions queries [must be](https://docs.ditto.live/sdk/latest/auth-and-authorization/data-authorization#using-the-id-field) written using the legacy query syntax and not DQL.

---

# Turnkey Backend Functionality & Conflict Resolution For PowerSync

> We’re adding turnkey functionality for writing to the backend database and generating JWTs, making PowerSync even easier to implement for developers who prefer not having to maintain their own backend code and infrastructure.

- Published: 2025-01-27
- Updated: 2026-03-19
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/turnkey-backend-functionality-conflict-resolution-for-powersync

---

**Quick summary:** We’re adding optional turnkey backend functionality for PowerSync that handles writing to the backend database (with initial support for MongoDB) and generating JWTs. This makes PowerSync easier to implement for developers who prefer not having to maintain their own backend code and infrastructure.

## Background: Bring-Your-Own-Backend Architecture

When we [launched](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer) PowerSync as a standalone product in 2023, one of our key architectural decisions was to allow developers to use their own backend to persist writes to their source database (e.g. Postgres or MongoDB). We believe that many developers would want to apply their own custom business logic, data validations and authorization rules to these write operations.

Accordingly, we designed PowerSync to handle the read and write paths of syncing differently:

  * **Read path** : Sync data directly from the source backend database (using change data capture to detect changes) via the PowerSync Service to a client-side SQLite database.
  * **Write path** : The client-side application can perform writes directly on the local SQLite database. The writes are also automatically placed into an upload queue by the PowerSync client SDK. The SDK then uses a developer-defined `uploadData()` function to manage the uploading of those writes to the backend. In the `uploadData()` function, the developer calls their backend API.

In this way, the developer gets the benefits of a sync engine in that it simplifies state transfer between backend and frontend (for example: real-time streaming updates; no need to worry about network errors or retry logic), while not sacrificing control over writes, or even needing to give write permissions to the sync engine.

The developer’s backend also typically plays a role in [authentication](https://docs.powersync.com/installation/authentication-setup): it can be used to generate JWTs for PowerSync (the other option is to reuse existing JWTs from your authentication provider).

### Conflict Resolution & Consistency

In this paradigm, conflict resolution is relatively straightforward with PowerSync as long as developers are comfortable with “bringing their own backend”. Because of the [server-authoritative](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer#server-authority-instead-of-distributedcrdt-architecture) nature of PowerSync, whatever is written to the backend database will automatically be reflected on all clients (without overwriting [local changes](https://docs.powersync.com/architecture/consistency#local-client-changes) that have not yet been uploaded). The simplest backend implementation is to apply writes as they are received, which typically means “last update wins; deletes always win” conflict resolution behavior. The developer can implement more sophisticated conflict resolution logic in their backend API if needed.

Consistency is also automatically provided by PowerSync. The developer ensures that the backend database is in a consistent state, and PowerSync reflects that state to clients: it syncs operations to clients until it reaches a consistent state (called a [checkpoint](https://docs.powersync.com/architecture/consistency)) and then [atomically](https://en.wikipedia.org/wiki/Atomicity_\(database_systems\)) updates the client-side SQLite database with that state.

## Need for Turnkey Backend Functionality

In contrast to PowerSync, MongoDB’s Atlas Device Sync ([deprecated](https://www.mongodb.com/products/updates/product-support-deprecation) in September 2024) provided turnkey writes/uploads to the backend database. As a result, we have seen that many developers who are [migrating](https://powersync.com/blog/powersync-as-alternative-to-mongodb-atlas-device-sync) to PowerSync from Atlas Device Sync are expecting equivalent functionality in PowerSync.

While the original PowerSync architecture optimizes for customizability, this kind of “baked-in” backend functionality of Atlas Device Sync optimizes for convenience and low maintenance overhead instead: you don’t have to write any backend code or deal with having to host a separate backend yourself.

We therefore decided to move quickly to enhance PowerSync with more turnkey backend options for developers. Today we are announcing our first solution, as well as our roadmap for future improvements.

## Phase 1: Serverless Cloud Functions for Turnkey Backend Functionality

PowerSync was [spun off](https://powersync.com/company) from JourneyApps Platform, a full-stack app platform that our company originally created. One of the components of JourneyApps Platform is [CloudCode](https://docs.journeyapps.com/reference/cloudcode/cloudcode-overview), a serverless cloud functions engine based on Node.js and AWS Lambda. 

It is now possible to use JourneyApps Platform CloudCode for turnkey backend functionality for PowerSync when used with a MongoDB backend source database. We have added a template to CloudCode that developers can quickly spin up that provides the needed backend functionality “out of the box”, including endpoints for generating JWTs and uploading writes.

Developers have the ability to customize the template, or they can use it as-is. CloudCode is provided as a fully-managed service running on the same cloud infrastructure as the rest of PowerSync Cloud. PowerSync and JourneyApps Platform exist as sibling products that share the same accounts backend. This means that you can use the same username and password as you use to log in to PowerSync to access the [JourneyApps Admin Portal](https://accounts.journeyapps.com/portal/admin/), from where you can manage CloudCode projects.

We have added [documentation](https://docs.powersync.com/usage/tools/cloudcode) with more step-by-step instructions on how to use this template in CloudCode. At this time you will also need a short “white-glove” onboarding session with our team — [please get in touch](https://powersync.com/contact). Lastly, before going into production with this solution, you will also need to set up authentication on the HTTP endpoints exposed by the CloudCode tasks — we can also assist with this.

### Turnkey Conflict Resolution

Using the MongoDB backend template in CloudCode gives developers **turnkey conflict resolution** behavior that is roughly equivalent to what was [provided](https://www.mongodb.com/docs/atlas/app-services/sync/details/conflict-resolution/) by MongoDB Atlas Device Sync: deletes always win, last update wins, and primary keys designate object identity.

![](https://powersync.com/images/blog/turnkey-backend-functionality-conflict-resolution-for-powersync-inline-69f6a30b94.png)

## Phase 2: First-Class Backend Package/Service in PowerSync

The next step on our roadmap is an even more turnkey option: A first-class package that can run alongside the PowerSync Service that provides backend functionality. We may also provide this as a managed service as part of PowerSync Cloud. 

## Making PowerSync Easier to Use

By making these turnkey options available, our aim is to give developers the best of both worlds: “bring your own backend”, or a hassle-free managed option if that is preferable. And even if you use CloudCode, you still get deep customizability: you can customize the template to fit your exact needs.

We’d love to hear your thoughts. If you have any feedback or questions, please [get in touch](https://powersync.com/contact)!

## PS: Migration Path for Atlas Data API and Custom HTTPS Endpoints

As you can see, our CloudCode functionality can also serve as a replacement for MongoDB’s [deprecated](https://www.mongodb.com/docs/atlas/app-services/data-api/data-api-deprecation/) Atlas Data API and Atlas Custom HTTPS Endpoints. If you use these deprecated features, are interested in migrating from them to CloudCode, and would like some assistance, please [get in touch](https://powersync.com/contact).

---

# Simon Binder Joins PowerSync

> Hello there! I’m Simon, and I’m excited to be joining the PowerSync team. In this blog post, I share my motivation for joining PowerSync and what this means for the Flutter SQLite ecosystem.

- Published: 2025-01-15
- Author: Simon Binder
- Category: Announcement
- Source: https://powersync.com/blog/simon-binder-joins-powersync

---

## Hello there!

Hello there! I’m Simon, and I’m excited to be joining the PowerSync team. 

Some of you might know me better under my GitHub handle, [@simolus3](https://github.com/simolus3). I created (and continue to maintain) some popular database packages in the Dart and Flutter ecosystem, like [drift](https://pub.dev/packages/drift) and the [sqlite3](https://pub.dev/packages/sqlite3) package which provides FFI and WebAssembly bindings to SQLite. 

In this blog post, I’ll share my motivation for joining PowerSync and what this means for the Flutter SQLite ecosystem.

I’ve been fascinated by developer tools and databases for a long time. While still a student, I created the drift project: a database library for Dart and Flutter apps that makes it easier to access SQLite databases in a typesafe and reliable way. As I explored newer technologies that emerged after I created drift (like [dart:ffi](https://dart.dev/interop/c-interop) and [WebAssembly](https://webassembly.org/)), I was inspired to create the sqlite3 package which provides direct access to SQLite on all Dart platforms.

Last year I finally finished my Master’s degree (even my thesis was about optimizing database engines). I also first got in touch with the PowerSync team last year, initially as an independent contractor working on open-source packages that make it easier to access sqlite3 on the web with Dart and Flutter.

During the almost six years that I’ve now spent developing drift, I’ve added countless features to make working with SQLite databases in Flutter apps easy. I think SQLite is an excellent database choice for mobile apps, and my goal has always been to make drift an obvious solution when using SQLite in Flutter apps.

While SQLite itself is a great component for mobile apps, its boundaries can be a source of friction during development. And while I hope I’ve managed to lower the boundary between the database and the UI with drift, a common challenge I’ve heard about is related to keeping the local state in SQLite up-to-date with the backend. This is why I’m really excited to join PowerSync’s mission of making SQLite even more powerful through their impressive sync engine! In addition to their synchronization technology, PowerSync’s approach of plugging into existing libraries both on the frontend and the backend puts it into a position that’s uniquely easy to adopt. So by joining the team at PowerSync, our contributions to the PowerSync SDK for Dart and Flutter will make SQLite an even better database for Flutter apps, without forcing developers to give up any control over their data.

For users of my Dart database projects like drift and package:sqlite3, nothing will change! I will continue to maintain them as independent projects. As a matter of fact, I will actually have even more time for them as PowerSync generously allows me to work on the drift and sqlite3 packages as part of my role. While some of the upcoming work will be most useful to PowerSync users, everyone will benefit from new features, changes to keep up with the ecosystem (like adopting macros and native assets) and bug fixes. So I hope you’re as excited as I am for what’s happening with databases in Dart and Flutter thanks to PowerSync!

---

# How Fast Is PowerSync? Performance Benchmarks For Flutter

> Performance is critical for developers building modern, data-intensive applications. This post looks at performance benchmarks of our Flutter Client SDK, focusing on two key metrics: initial sync time and incremental sync latency. These benchmarks are designed to help developers assess PowerSync’s performance across various devices and deployment scenarios.

- Published: 2025-01-13
- Author: Ralf Kistner
- Category: Engineering
- Source: https://powersync.com/blog/how-fast-is-powersync-performance-benchmarks-for-flutter

---

Performance is critical for developers building modern, data-intensive applications. This post looks at performance benchmarks of our **Flutter Client SDK** , focusing on two key metrics: **initial sync time** and **incremental sync latency**.

These benchmarks are designed to help developers assess PowerSync’s client-side performance across different types of devices and client environments.

## Where Performance Matters in Sync

When implementing a sync engine with a client-server architecture, two important performance metrics stand out:

  1. **Initial Sync Time** : How quickly can a user start interacting with their data after logging in? 
  2. **Incremental Sync Latency** : How quickly are changes propagated to devices via the server?

We benchmarked the PowerSync Flutter SDK on these dimensions to provide transparency into its performance across desktop, mobile, and web environments.

## Benchmark Setup: Testing for Real-World Relevance

Our tests aim to isolate client-side performance while minimizing server-side variability. Here’s how we set up the benchmarks:

  * Client ↔ Server Latency and Server-Side Overhead: Minimized by running the server stack locally.
  * Data Volume: Benchmarked with datasets ranging from 10,000 to 10 million rows.
  * Devices Tested:
    * Linux Desktop (Ryzen 9 7900X, ext4 filesystem)
    * Android (Pixel 8a, Android 14)
    * Web (Flutter web with IndexedDB and OPFS storage)

> Note: iOS benchmark tests are not yet available but will be included in an upcoming update to this post.

The metrics represent the mean of 10 test runs.  

## Key Metrics

### 1\. Initial Sync Time

Initial sync time measures the duration from when the sync connection opens to when all data is available locally. This is crucial for ensuring fast app load times, especially for users syncing large datasets.

  * **Desktop** : Up to 27.6k rows/sec
  * **Mobile** : Slower throughput, averaging 7.1k rows/sec on Android for 10k rows synced.
  * **Web** : Performance varies significantly based on storage backends, with OPFS outperforming IndexedDB.

> Note: Throughput decreases slightly as more rows are synced. See the table at the end of this post for the full dataset.

![](https://powersync.com/images/blog/how-fast-is-powersync-performance-benchmarks-for-flutter-inline-0cb7937e4e.png "_Click to enlarge_")

### 2\. Incremental Sync Latency

Incremental sync latency tracks the round-trip time for updates to propagate through the system:

  * Client creates a new record in its local database.
  * Record is uploaded to the server, persisted in the backend database (Postgres in the case of these benchmarks) and the change is processed by PowerSync.
  * Record is streamed back to the client. We include a default value for one of the columns populated by Postgres, which allows the client to detect that the roundtrip has completed and measure the latency.

We tested 1 update, 100 updates and 1,000 updates. For the 100 and 1,000 cases, the updates are uploaded as a single batch API call and persisted to Postgres using a single transaction.

The benchmarks showed that incremental syncing is quite fast. On **Android** , syncing 100 updates takes ~200ms for the full round-trip. On **desktop** , it’s even faster, clocking in at ~40ms.

> Note: As app queries run locally, user interactions have zero network latency: the UI instantly updates, in the next frame.

## Summarized Benchmark Results

| Client | Rows Synced | Initial Sync Time | Throughput | Incremental Sync Latency (100 updates) |
| --- | --- | --- | --- | --- |
| Flutter, Linux desktop | 100k | 4.2s | 23.8k/s | 39.7ms |
| Flutter, Android | 100k | 21.8s | 4.6k/s | 229.0ms |
| Flutter-Web (IndexedDB) | 100k | 17.8s | 5.6k/s | 146ms (100-200ms) |
| Flutter-Web (OPFS) | 100k | 10.4s | 9.6k/s | 121ms (110-130ms) |
  
_For the complete dataset, see the table at the end of this post._

## Insights from the Benchmarks

### Initial Sync

  * **Throughput changes relative to dataset volume** : Throughput is highest on native desktop environments but decreases with larger datasets and on web/mobile platforms.
  * **OPFS vs. IndexedDB** : Flutter-Web using OPFS delivers faster performance compared to IndexedDB, especially with datasets over 100k rows.

### Incremental Sync

  * **Consistent latency** : Even with 1M+ rows, incremental sync latency remains consistent, demonstrating efficiency in managing large datasets.
  * **Web challenges** : Concurrency limitations in Flutter-Web affect responsiveness during incremental updates.

## Conclusion

PowerSync is engineered to handle demanding sync scenarios efficiently, across platforms. Benchmarks demonstrate that PowerSync delivers consistent performance, even with high client-side data volumes.

## Full Benchmark Results

| Client | Rows Synced | Initial Sync Time | Throughput (calculated) | Incremental Sync Latency (1 update) | Incremental Sync Latency (100 updates) | Incremental Sync Latency (1000 updates) |
| --- | --- | --- | --- | --- | --- | --- |
| Flutter, Linux desktop | 10k | 0.36s | 27.6k/s | 18.5ms | 42.3ms | 223ms |
| Flutter, Linux desktop | 100k | 4.2s | 23.8k/s | 16.9ms | 39.7ms | 218ms |
| Flutter, Linux desktop | 1M | 60.6s | 16.5k/s | 16.6ms | 41.0ms | 218ms |
| Flutter, Linux desktop | 10M | 724s | 13.8k/s | 17.3ms | 46.5ms | 251ms |
| Flutter, Android, Pixel 8a | 10k | 1.4s | 7.1k/s | 183.9ms<br />(70-300ms) | 178.5ms | 528ms |
| Flutter, Android, Pixel 8a | 100k | 21.8s | 4.6k/s | 200.0ms | 229.0ms | 613ms |
| Flutter, Android, Pixel 8a | 1M | 344s | 2.9k/s | 143.8ms | 162.6ms | 544ms |
| Flutter-Web, Linux desktop, Chrome, IndexedDB | 10k | 2.5s | 4k/s | 147ms<br />(60-240ms) | 120ms<br />(90-150ms) | 800ms<br />(300-3000ms) |
| Flutter-Web, Linux desktop, Chrome, IndexedDB | 100k | 17.8s | 5.6k/s | 72ms<br />(60-100ms) | 146ms<br />(100-200ms) | 913ms<br />(350-3000ms) |
| Flutter-Web, Linux desktop, Chrome, OPFS | 10k | ~0.6s | 16.7k/s | 151ms<br />(70-230ms) | 98ms<br />(80-120ms) | 300ms |
| Flutter-Web, Linux desktop, Chrome, OPFS | 100k | 10.4s | 9.6k/s | 171ms<br />(70-260ms) | 117ms<br />(70-200ms) | 296ms |
| Flutter-Web, Linux desktop, Chrome, OPFS | 1M | 254s | 3.9k/s | 172ms<br />(90-290ms) | 121ms<br />(110-130ms) | 336ms |

---

# PowerSync Update: December 2024

> We expect 2025 to be a breakout year for sync engines, driven by growing demand for zero-latency apps and simpler state management. We have some exciting plans to share, but first, let’s look at how PowerSync evolved this past month.

- Published: 2025-01-08
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-december-2024

---

We expect 2025 to be a breakout year for sync engines, driven by growing demand for zero-latency apps and simpler state management. We have some exciting plans to share, but first, let’s look at how PowerSync evolved this past month.

## New Sync Rules Functions

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-73c73dad4f.png)

In November, we released three new Sync Rules functions, `substring(text, start, length)`, `json_each(data)` and `json_keys(data)`. In December, community member **Jorge S (@hyperion)** also added two additional functions:

  * `uuid_blob`: converts a UUID string to bytes. The ID can then be transformed to base64 (e.g. `base64(uuid_blob(id))`) for more performant querying on clients.
  * `iif(x,y,z)`: adds if/else support that returns y if x is true, otherwise returns z.

Thank you, Jorge!

[Read the docs](https://docs.powersync.com/usage/sync-rules/operators-and-functions)

## MongoDB Connector in Beta

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-7a278b59df.png)

**MongoDB** is by far the most popular NoSQL database [[1](https://db-engines.com/en/ranking/document+store)], so supporting it has been key to our vision of prioritizing developer choice as a backend database-agnostic sync engine. In December, we advanced our MongoDB connector to Beta status, meaning that it’s **now ready for production use**.

[Read the announcement post](https://powersync.com/blog/powersync-mongodb-connector-module-now-in-beta)

## Swift Client SDK in Beta

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-1c30752604.png)

This Beta release introduces a Swift-native wrapper around the core of our Swift SDK generated from our Kotlin Multiplatform SDK. This delivers a more intuitive, Swift-friendly interface with improved type-safety. Other challenges were also addressed, such as introducing multi-threading support for transactions.

[Read the release notes](https://releases.powersync.com/announcements/beta-release-of-the-powersync-swift-sdk)

## SolidJS Hooks for PowerSync Queries

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-ebf6126664.png)

Community member **Joakim C** kindly shared his `powersync-solid` project that implements PowerSync hooks for SolidJS. We’ve added this project under the _Notable Community Projects_ section in our docs. Thanks, Joakim!

[Visit the repo](https://github.com/aboviq/powersync-solid)

## New Tutorial Section In Docs

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-32865336fa.gif)

We've released a new _Tutorials_ section in our docs, which already contains some helpful guides, such as:

### New Tutorial: Improve Supabase Connector Performance

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-1aa6db86fb.png)

The demos in our `powersync-js` monorepo provide a minimal working example but are not necessarily optimized for performance, and can therefore be improved.

This tutorial demonstrates how to improve the Supabase backend connector’s performance by implementing two batching strategies that reduce the number of database operations for processing uploads to Supabase.

[See the tutorial](https://docs.powersync.com/tutorials/client/performance/supabase-connector-performance)

### New Tutorial: Use AWS S3 for Attachment Storage

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-cf67b622a9.png)

This tutorial covers how to use AWS S3 for handling attachments in our **React Native To-Do List** example app.

[See the tutorial](https://docs.powersync.com/tutorials/client/attachments-and-files/aws-s3-storage-adapter)

### New Tutorial: Using our Attachment Helper for PDF Attachments

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-da8e9ccf88.png)

The current version of our **React Native To-Do List** example app implements a `PhotoAttachmentQueue` class which enables photo attachments (specifically JPEG) to be synced. This tutorial will guide you on the changes needed to support PDF attachments instead.

[See the tutorial](https://docs.powersync.com/tutorials/client/attachments-and-files/pdf-attachment)

### New Tutorial: How to Perform a Cascading Delete

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-240e2b30d3.png)

Since PowerSync utilizes SQLite views on the client-side instead of standard tables, SQLite features like constraints, foreign keys, or cascading deletes are not available. Currently, there is no direct support for cascading deletes on the client. However, you can achieve this in two different ways, one of which is covered in this tutorial.

[See the tutorial](https://docs.powersync.com/tutorials/client/data/cascading-delete)

### New Tutorial: Generating Development Tokens for Self-Hosted Instances

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-8cc6e89f95.png)

Development tokens are useful for:

  * Getting started quickly without implementing full authentication configuration
  * Sanity-checking your Sync Rules configuration (whether they were applied correctly)
  * Temporarily impersonating a specific user to debug specific issues

This tutorial shows how.

[See the tutorial](https://docs.powersync.com/tutorials/self-host/generate-dev-token)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-4905b2f26e.png)

### Contributions

Thank you to these contributors!

  * **js2702** for [2x new Sync Rules functions](https://docs.powersync.com/usage/sync-rules/operators-and-functions), 
  * **joakimbeng** for [SolidJS hooks](https://github.com/aboviq/powersync-solid),
  * **mkieselmann** for [adding missing healthcheck endpoints to the PowerSync Service](https://github.com/powersync-ja/powersync-service/pull/143), and
  * **LucDeCaf** for adding support for [EdDSA](https://github.com/powersync-ja/powersync-service/pull/142) and [ECDSA](https://github.com/powersync-ja/powersync-service/pull/158) signing algorithms when generating custom JWTs.

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-ac9658b795.png)

### Developer Case Study: Aspen Square

**Chris Primavera** joined us to discuss how Aspen Square uses PowerSync in their property operations management app.

[Read the developer case study](https://powersync.com/blog/developer-case-study-chris-primavera-aspen-square)

That's it for the December update, happy coding!

---

# Migrating A MongoDB Atlas Device Sync App To PowerSync

> In this guide we show how to migrate an existing MongoDB Realm & Atlas Device Sync application to use PowerSync. This guide uses the PowerSync React Native SDK and we’ve based this guide on Realm’s rn-mbnb example app.

- Published: 2025-01-06
- Author: Mike Barnes
- Category: Engineering
- Source: https://powersync.com/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync

---

## Introduction

In this guide we’ll showcase how to migrate an existing MongoDB Realm & [Atlas Device Sync](https://www.mongodb.com/docs/atlas/app-services/sync/device-sync-deprecation/) application to use PowerSync. This guide uses the [PowerSync React Native SDK](https://www.npmjs.com/package/@powersync/react-native) and we’ve based this guide on Realm’s `rn-mbnb` example app, which can be found [here](https://github.com/realm/realm-js/tree/main/examples/rn-mbnb).

The complete source code for the migrated application can be found [here](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb).

### Overview of Migration Steps

  1. PowerSync Service setup
     1. Configure Sync Rules
     2. Test your Sync Rules
  2. Backend API setup
  3. Client-side code migration
     1. Install PowerSync
     2. Remove Realm
     3. Migrate Realm schema
     4. Add PowerSync Backend Connector
     5. Set up PowerSync database and connect UI
     6. Accessing the database
     7. Migrate database queries
     8. Migrate render function

[Video: Migrating a MongoDB Atlas Device Sync App to PowerSync](https://www.youtube.com/watch?v=3686e88a8e884d25b679d716268520d4)

## Migration Steps

### PowerSync Service Setup

To get started with PowerSync, we recommend starting with the setup of a PowerSync Service instance. This guide uses [PowerSync Cloud](https://powersync.com/pricing), but an alternative would be to spin up a [self-hosted](https://docs.powersync.com/self-hosting/getting-started) instance of PowerSync.

To create a PowerSync Cloud instance, follow these steps:

  1. [Sign up](https://accounts.powersync.com/portal/powersync-signup) for free for PowerSync if you’ve not done so already.
  2. Create a new project in the [PowerSync Dashboard](https://accounts.powersync.com/)
  3. Create a new PowerSync instance in the project
  4. Enter the MongoDB connection details
     1. Before you save and deploy, hit ‘Test connection’
     2. See our [documentation](https://docs.powersync.com/configuration/source-db/setup#permissions-required-mongodb-atlas) for required permissions if the connection is failing
  5. Once the connection has been established, select ‘Save and deploy’

#### Configuring Sync Rules

PowerSync allows configuring [Sync Rules](https://docs.powersync.com/usage/sync-rules) that specify which MongoDB data to sync with which users. Sync Rules allow for dynamic filtering and user-specific data partitioning to ensure that only the relevant data subsets are synced to individual app users.  

Copy these sample Sync Rules into your `sync-rules.yaml` file in the [PowerSync Dashboard](https://accounts.powersync.com/):

```javascript
bucket_definitions:
  global:
    data:
      - SELECT _id as id, * from "listingsAndReviews"
```

Note: Since MongoDB uses `_id` for the ID of a document whereas PowerSync [uses](https://docs.powersync.com/usage/sync-rules/client-id) `id` on the client-side, we need to `select _id as id` in the Sync Rules to extract the `_id` field and use it as the id of the `listingsAndReviews` table which will be exposed by PowerSync.  

In this example we’re creating a “[global bucket](https://docs.powersync.com/usage/sync-rules/example-global-data)” to sync all `listingsAndReview` documents. In production apps, global app data should be added to such a “global bucket”, whereas user-specific data should be placed into appropriate [separate buckets](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets). Buckets can be thought of as logical groupings of data that the user needs on their device for the app to function.  

Once you’ve created the Sync Rules, go ahead and deploy them in the PowerSync Dashboard.

#### Test Your Sync Rules

A quick and easy way to test and simulate your Sync Rules is to use the PowerSync [Diagnostics app](https://github.com/powersync-ja/powersync-js/tree/main/tools/diagnostics-app). To do so, you’ll need a [development token](https://docs.powersync.com/installation/authentication-setup/development-tokens) (a temporary authentication token that can be used during development). Take the following steps:

  1. Right click on the PowerSync instance in the PowerSync Dashboard
  2. Select ‘Generate development token’
  3. Since we are only using a single Global Bucket for now, you can enter anything into the ‘Token Subject’ popup 
  4. Hit ‘Continue’ and copy the development token
  5. Open [diagnostics-app.powersync.com](https://diagnostics-app.powersync.com/)
  6. Paste in the development token
     1. The Endpoint URL will auto-populate because it’s embedded in the development token  

Once you’ve logged in, you should see something like this:

![](https://powersync.com/images/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync-inline-09c7d73e31.png)

The Diagnostics app is very useful when it comes to debugging and quickly validating Sync Rules. There is also a _SQL Console_ that you can use to query data in the client-side SQLite database provided by PowerSync to get a feel for how PowerSync works.

#### More About Sync Rules

Our example Sync Rules above are pretty straightforward. What if we want to do something more advanced, such as syncing specific data to the user? Let’s say we want to sync listings for a specific country. We could do the following:

```javascript
bucket_definitions:  
  by_country:
    parameters: SELECT request.jwt() ->> 'country' as country
    data:
      - SELECT _id as id, * FROM "listingsAndReviews" WHERE address ->> 'country' = bucket.country
```

In the above example, we create a [parameter query](https://docs.powersync.com/usage/sync-rules/parameter-queries) which creates a [bucket](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets) for the country that matches the result of the parameter query. We assume that the signed in user’s [JWT](https://docs.powersync.com/installation/authentication-setup) contains a `country` property in the payload. To extract values from the JWT payload, we can use the JSON operator e.g. `request.jwt() ->> 'country'`. If the `country` field was in a nested JSON object, let’s say `address`, we can use the same JSON operator to query on `address.country`.  

For more details on how to use Sync Rules in PowerSync, refer to the [docs](https://docs.powersync.com/usage/sync-rules).

### Backend API Setup

PowerSync stores all client-side data modifications in an upload queue in SQLite, and allows developers to control exactly how entries in this queue are written back to MongoDB, by uploading modifications to the developer’s own [backend API](https://docs.powersync.com/installation/app-backend-setup/writing-client-changes). (For a detailed overview of the overall PowerSync architecture, see [our docs](https://docs.powersync.com/architecture/client-architecture).)  

We’ll illustrate what that would entail through a stub Node.js backend API implementation that uses [Express](https://expressjs.com/). This API will receive uploads from the client. 

If there are local modifications present in the upload queue, the PowerSync client SDK will automatically connect to the configured backend API to upload the modifications sequentially. The Realm demo `rn-mbnb` that we based this guide on does not write data back to the source MongoDB database. However,  we’ve included this functionality in this guide to demonstrate how it can be implemented, as client applications often need to sync local changes back to the MongoDB database.  

First let’s create a file called `[mongoPersistence.ts](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/backend/src/mongo/mongoPersistence.ts)`. This will focus on the MongoDB client connection and the operations that need to be written to the source MongoDB database:

```javascript
import {Db, MongoClient, ObjectId} from "mongodb";
export type UpdateEvent = {
    table: string;
    data: any;
}

export default class MongoPersistence {
    private client: MongoClient;
    private database: Db;
    constructor(config: { name: string, uri: string }) {
        this.client = new MongoClient(`${config.uri}`);
        this.database = this.client.db(config.name);
    }
    async init () {
        await this.client.connect();
    }
    async update (updateEvent: UpdateEvent): Promise<void> {
        try {
            console.log(updateEvent);
            const filter = { _id: new ObjectId(updateEvent.data.id) };
            const collection = this.database.collection(updateEvent.table);
            const updateDoc = {
                $set: { ...updateEvent.data }
            };
            const result = await collection.updateOne(filter, updateDoc);
            console.log(result);
        } catch (error) {
            console.log(error);
            throw error;
        } finally {
            await this.client.close();
        }
    }
    async upsert (updateEvent: UpdateEvent): Promise<void> {
        try {
            console.log(updateEvent);
            const filter = { _id: new ObjectId(updateEvent.data.id) };
            const collection = this.database.collection(updateEvent.table);
            const updateDoc = {
                $set: { ...updateEvent.data }
            };
            const options = {
                upsert: true,
            };
            const result = await collection.updateOne(filter, updateDoc, options);
            console.log(result);
        } catch (error) {
            console.log(error);
            throw error;
        } finally {
            await this.client.close();
        }
    }
    async delete (updateEvent: UpdateEvent): Promise<void> {
        try {
            console.log(updateEvent);
            const filter = { _id: new ObjectId(updateEvent.data.id) };
            const collection = this.database.collection(updateEvent.table);
            const result = await collection.deleteOne(filter);
            console.log(result);
        } catch (error) {
            console.log(error);
            throw error;
        } finally {
            await this.client.close();
        }
    }
}
```

This class will initialize and connect to MongoDB using the Node.js `MongoClient` driver. There are three different functions that will write changes to MongoDB depending on the type of change that occurred on the client (`PUT`, `PATCH`, `DELETE` correspond to types of [client-side changes](https://docs.powersync.com/installation/app-backend-setup/writing-client-changes) tracked by the PowerSync client SDK).  

Next, we have our [API layer](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/backend/src/controllers/dataController.ts) which exposes endpoints to accept uploads from client applications. It will use the `MongoPersistence` class above to process the changes:

```javascript
import {Router, Request, Response} from "express";
import config from "../../config";
import MongoPersistence from "../mongo/mongoPersistence";

export default class DataController {
    public router: Router;
    constructor() {
        this.router = Router();
        this.initRoutes();
    }
    private initRoutes() {
        this.router.patch("/", this.update);
        this.router.put("/", this.put);
        this.router.delete("/", this.delete);
    }
    private async update(req: Request, res: Response) {
        try {
            if (!req.body) {
                res.status(400).send({
                    message: 'Invalid body provided'
                });
                return;
            }
            const mongoPersistence = new MongoPersistence({
                name: config.database.database,
                uri: config.database.uri
            });
            await mongoPersistence.init();
            await mongoPersistence.update(req.body);
            res.status(200).send();
        } catch (err) {
            console.log(err);
            res.status(500).send({
                message: err,
            });
        }
    }
    private async put(req: Request, res: Response) {
        try {
            if (!req.body) {
                res.status(400).send({
                    message: 'Invalid body provided'
                });
                return;
            }
            const mongoPersistence = new MongoPersistence({
                name: config.database.database,
                uri: config.database.uri
            });
            await mongoPersistence.init();
            await mongoPersistence.upsert(req.body);
            res.status(200).send();
        } catch (err) {
            res.status(500).send({
                message: err,
            });
        }
    }
    private async delete(req: Request, res: Response) {
        try {
            if (!req.body) {
                res.status(400).send({
                    message: 'Invalid body provided'
                });
                return;
            }
            const mongoPersistence = new MongoPersistence({
                name: config.database.database,
                uri: config.database.uri
            });
            await mongoPersistence.init();
            await mongoPersistence.delete(req.body);
            res.status(200).send();
        } catch (err) {
            res.status(500).send({
                message: err,
            });
        }
    }
}
```

### Client-Side Code Migration 

#### Install PowerSync Dependencies

To get started in the client-side app code, we need to set up dependencies, so go ahead and install the following:

```javascript
npm install @powersync/react @powersync/react-native @journeyapps/react-native-quick-sqlite @azure/core-asynciterator-polyfill
```

Here’s a quick rundown of these packages:

  * `@powersync/react`: This package provides React hooks for use with the PowerSync JavaScript Web SDK or React Native SDK. These hooks are designed to support reactivity — they are used to automatically re-render React components when query results update. They can also be used to access PowerSync connectivity status changes.
  * `@powersync/react-native`: This is the [PowerSync SDK](https://docs.powersync.com/client-sdk-references/react-native-and-expo) for React Native clients.
  * `@journeyapps/react-native-quick-sqlite`: This is a PowerSync fork of the SQLite library react-native-quick-sqlite that includes custom SQLite extensions built specifically for PowerSync. 
  * `@azure/core-asynciterator-polyfill`: This library provides a polyfill for `Symbol.asyncIterator` for platforms that do not support it by default.

#### Remove Realm 

Now with all of the required dependencies for PowerSync installed, we can go ahead and remove the Realm dependencies:

```javascript
npm uninstall @realm/react realm
```

We can also remove all directories and files related to Realm:

  * The `backend` directory
  * `sync.config.js`
  * `AnonAuth.tsx`
  * `localModels.tsx`
  * `localRealm.tsx`
  * `syncedModels.tsx`
  * `syncedRealm.tsx`

#### Migrate Realm Schema to PowerSync

It’s important to note that unlike Realm, PowerSync does not require separate local and “syncing” models or schemas. With PowerSync, you only need to define a single client-side schema.   

Models/schemas in Realm are defined using objects of type `Realm.ObjectSchema`. Here is an example of that from the `rn-mbnb` repo:

```javascript
import Realm from "realm";

export const listingsAndReviewSchema: Realm.ObjectSchema = {
  name: "listingsAndReview",
  properties: {
    _id: "string",
    access: "string?",
    accommodates: "int?",
    address: "listingsAndReview_address",
    // ... snipped for brevity ...
    security_deposit: "decimal128?",
    space: "string?",
    summary: "string?",
    transit: "string?",
    weekly_price: "decimal128?",
  },
  primaryKey: "_id",
};
```

To migrate the schema above over to PowerSync, we’ll need to refactor a few things.   

Generally it’s best to create a directory in your project for all the PowerSync-related classes and functions. Let’s create a new `powersync` directory. The directory structure would look something like this:

![](https://powersync.com/images/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync-inline-107cb5d32a.png)

Now let’s create a new file called `[AppSchema.ts](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/powersync/AppSchema.ts)` — i.e. `powersync/AppSchema.ts` and add the following code to migrate our Realm object schema to PowerSync. Since PowerSync uses [SQLite](https://en.wikipedia.org/wiki/SQLite) as its client-side database, it makes use of three of SQLite’s supported [data types](https://docs.powersync.com/usage/sync-rules/types): `text`, `integer` and `real`:

```javascript
import {column, Schema, Table} from "@powersync/react-native";

const listingsAndReview = new Table({
  access: column.text,
  accommodates: column.integer,
  address: column.text,
  amenities: column.text,
  availability: column.text,
  bathrooms: column.integer,
  bed_type: column.text,
  bedrooms: column.integer,
  beds: column.integer,
  calendar_last_scraped: column.text,
  cancellation_policy: column.text,
  cleaning_fee: column.text,
  description: column.text,
  extra_people: column.integer,
  first_review: column.text,
  guests_included: column.integer,
  host: column.text,
  house_rules: column.text,
  images: column.text,
  interaction: column.text,
  last_review: column.text,
  last_scraped: column.text,
  listing_url: column.text,
  maximum_nights: column.text,
  minimum_nights: column.text,
  monthly_price: column.text,
  name: column.text,
  neighborhood_overview: column.text,
  notes: column.text,
  number_of_reviews: column.integer,
  price: column.text,
  property_type: column.text,
  review_scores: column.text,
  reviews: column.text,
  room_type: column.text,
  security_deposit: column.text,
  space: column.text,
  summary: column.text,
  transit: column.text,
  weekly_price: column.text
});

export const AppSchema = new Schema({
  listingsAndReview
});

export type Database = (typeof AppSchema)["types"];
export type ListingsAndReview = Database['listingsAndReview'];
```

Because we have a `listingsAndReviews` collection in MongoDB that we referenced in our Sync Rules above, we define a corresponding `Table` and specify all the columns that map to the fields of the objects in the MongoDB collection.  

For nested objects, such as `host`, we map them to `text` in PowerSync and use JSON functions in the app to query, parse, and display the data in SQLite. We’ll cover this further down in this guide.  

Some things to note:

```javascript
const listingsAndReview = new Table({
...
}, { indexes: { listingsAndReviews: ['name'] });
```

  1. If you’re using PowerSync Cloud, you can generate a client schema using the [PowerSync Dashboard](https://docs.powersync.com/usage/tools/powersync-dashboard) based on the Sync Rules you’ve defined for your application. Right-click on your instance and select “Generate client-side schema”.

![](https://powersync.com/images/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync-inline-a00bc1f6b0.png)

2. We don’t need to explicitly define an `id` column in our PowerSync client schema, as PowerSync will automatically create the `id` column. This column maps to the `_id` property of the MongoDB document, as we specified in our Sync Rules.

  3. PowerSync allows for indexes on columns in the SQLite database. This can be added as follows:

  4. As noted above, Realm requires two different models to be defined — a local model (for local-only data) and a synced model (for data that needs to sync with the source MongoDB database). This is not the case with PowerSync and it’s somewhat simplified with PowerSync. To treat certain data as [local-only](https://docs.powersync.com/usage/use-case-examples/offline-only-usage#local-only-usage) with PowerSync (not synced back to source MongoDB database) you can create a `Table` and mark it as `localOnly`, e.g.:

Now that we have the schema defined, let’s go ahead with migrating the rest of our app code to use PowerSync.

#### Add PowerSync Backend Connector

Before we instantiate the PowerSync database on the client-side, we first need to define a `PowerSyncBackendConnector` class that PowerSync uses for two things: 

  1. `fetchCredentials`: A function that PowerSync calls to obtain a valid JWT to allow the client app to authenticate against the PowerSync Service. For the purposes of this guide, we’ll do anonymous authentication using a [development token](https://docs.powersync.com/installation/authentication-setup/development-tokens). In production, you would want to connect this function with your authentication provider (see the [Authentication](https://docs.powersync.com/installation/authentication-setup) section in our docs for more details).
  2. `uploadData`: A function that PowerSync uses to process the upload queue. When changes to data are made in the client-side SQLite database, PowerSync queues up the changes and uses the `uploadData` function to send the updates to the source MongoDB database via the backend API that we defined previously.  

Let’s define a backend connector in our `powersync` directory e.g. [BackendConnector.ts](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/powersync/BackendConnector.ts):

```javascript
import { AbstractPowerSyncDatabase, CrudEntry, PowerSyncBackendConnector, UpdateType } from '@powersync/react-native';
import { AppConfig } from './AppConfig';
import { ApiClient } from './ApiClient';

export class BackendConnector implements PowerSyncBackendConnector {
  public apiClient: ApiClient;

  constructor () {
    this.apiClient = new ApiClient(AppConfig.backendUrl);
  }

  async fetchCredentials() {
    return {
      endpoint: AppConfig.powersyncUrl ?? '',
      token: AppConfig.powerSyncDevelopmentToken ?? '',
    };
  }

  async uploadData(database: AbstractPowerSyncDatabase): Promise<void> {
    const transaction = await database.getNextCrudTransaction();
  
    if (!transaction) {
      return;
    }
  
    let lastOp: CrudEntry | null = null;
  
    try {
      for (const op of transaction.crud) {
        lastOp = op;
        const record = { table: op.table, data: { ...op.opData, id: op.id } };
        switch (op.op) {
          case UpdateType.PUT:
            await this.apiClient.upsert(record);
            break;
          case UpdateType.PATCH:
            await this.apiClient.update(record);
            break;
          case UpdateType.DELETE:
            await this.apiClient.delete(record);
            break;
        }
        await transaction.complete();
      }
    } catch (ex: any) {
      console.debug(ex);
      console.error("Data upload error - discarding:", lastOp, ex);
      await transaction.complete();
    }
  }
}
```

Some things to note:

```javascript
const myLocalTable = new Table({
...
}, { localOnly: true });
```

  1. We are using a [development token](https://docs.powersync.com/installation/authentication-setup/development-tokens) in the `fetchCredentials` function above. When preparing for production, the `fetchCredentials` function should retrieve the signed-in user’s JWT from local storage or via an additional API call in the function. 
  2. Development tokens are not long-lived — they expire after 12 hours.  

To wrap up the backend connector, we’re going to need an `[ApiClient](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/powersync/ApiClient.ts)` class which will use `fetch` to send the changes to the source MongoDB database. This is where dedicated functions will exist that map to the endpoints we defined above in our example Node.js backend API:

```javascript
export class ApiClient {
  private readonly baseUrl: string;
  private readonly headers: any;

  constructor(baseUrl: string) {
    this.baseUrl = baseUrl;
    this.headers = {
      'Content-Type': 'application/json'
    };
  }

  async update(data: any): Promise<void> {
    const response = await fetch(`${this.baseUrl}/upload_data/`, {
      method: 'PATCH',
      headers: this.headers,
      body: JSON.stringify(data)
    });
    if (response.status !== 200) {
      throw new Error(`Server returned HTTP ${response.status}`);
    }
  }

  async upsert(data: any): Promise<void> {
    const response = await fetch(`${this.baseUrl}/api/upload_data/`, {
      method: 'PUT',
      headers: this.headers,
      body: JSON.stringify(data)
    });
    if (response.status !== 200) {
      throw new Error(`Server returned HTTP ${response.status}`);
    }
  }

  async delete(data: any): Promise<void> {
    const response = await fetch(`${this.baseUrl}/api/upload_data/`, {
      method: 'DELETE',
      headers: this.headers,
      body: JSON.stringify(data)
    });
    if (response.status !== 200) {
      throw new Error(`Server returned HTTP ${response.status}`);
    }
  }
}
```

Now that we have our `BackendConnector` defined, let’s add the last file named [AppConfig.ts](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/powersync/AppConfig.ts):

```javascript
export const AppConfig = {
  powerSyncDevelopmentToken: process.env.EXPO_PUBLIC_POWERSYNC_DEVELOPMENTAL_TOKEN || '',
  powersyncUrl: process.env.EXPO_PUBLIC_POWERSYNC_URL,
  backendUrl: process.env.EXPO_PUBLIC_BACKEND_URL,
};
```

This will have three variables:

  * `powersyncUrl`: This is the PowerSync Service instance URL that the client application will use to stream changes from. 
  * `powerSyncDevelopmentToken`: This is the [development token](https://docs.powersync.com/installation/authentication-setup/development-tokens) we generated in the section earlier on. In production you would remove the development token — they are used only for testing purposes.
  * `backendUrl`: This is the URL that points to the backend API and is used by the `ApiClient` to send changes to the source MongoDB database via the backend.  

#### Set up PowerSync Database and Connect UI

In our `powersync` directory, let’s add a new file called `[System.ts](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/powersync/System.ts)`. This will be used later on in our PowerSync Provider. Here we instantiate the backend connector and client-side PowerSync database, and create a `useSystem` hook that wraps React’s `useContext` to make these available as context to React components:

```javascript
import '@azure/core-asynciterator-polyfill';
import React from 'react';
import { PowerSyncDatabase } from '@powersync/react-native';
import { BackendConnector } from './BackendConnector';
import { AppSchema } from './AppSchema';

export class System {
  powersync: PowerSyncDatabase;
  backendConnector: BackendConnector;

  constructor() {
    this.backendConnector = new BackendConnector();
    this.powersync = new PowerSyncDatabase({
      schema: AppSchema,
      database: {
        dbFilename: 'sqlite.db'
      }
    });
  }

  async init() {
    await this.powersync.init();
    await this.powersync.connect(this.backendConnector);
  }
}

export const system = new System();

export const SystemContext = React.createContext(system);
export const useSystem = () => React.useContext(SystemContext);
```

Some important things to note:

  1. We import `@azure/core-asynciterator-polyfill` because we’re going to be using watched queries, and this polyfill is required to do so.
  2. When instantiating the `PowerSyncDatabase`, we must specify the `schema` and the database options. The most important part here is the `dbFilename`. 
  3. The `init` function on `System` calls the `init()` and `connect()` functions on the `PowerSyncDatabase` to start the sync process with PowerSync.
     1. The `connect()` function requires a `BackendConnector` instance, because the PowerSync database will call the `fetchCredentials` function when PowerSync tries to authenticate, and the `uploadData` function to process the upload queue and send writes back to the source MongoDB database via the API we defined earlier.  

To use the provider, we need to update the existing `[AppWrapper.tsx](https://github.com/realm/realm-js/blob/main/examples/rn-mbnb/app/AppWrapper.tsx)` file. Here’s what that file looks like with Realm, before migrating to PowerSync:

```javascript
export const AppWrapper: React.FC<{
  appId: string;
}> = ({ appId }) => {
  return (
    <>
      <SafeAreaView style={styles.screen}>
        <AppProvider id={appId}>
          <UserProvider fallback={<AnonAuth />}>
            <SyncedRealmProvider
              shouldCompact={() => true}
              sync={{
                flexible: true,
                onError: (_, error) => {
                  // Comment out to hide errors
                  console.error(error);
                },
                existingRealmFileBehavior: {
                  type: OpenRealmBehaviorType.OpenImmediately,
                },
              }}
            >
              <LocalRealmProvider>
                <AirbnbList />
              </LocalRealmProvider>
            </SyncedRealmProvider>
          </UserProvider>
        </AppProvider>
      </SafeAreaView>
    </>
  );
};
```

You can see that the Realm implementation uses `AppProvider`, `UserProvider` and `SyncedRealmProvider`. The `SyncedRealmProvider` also requires some options to be set such as callback functions for error handling and other options.  

To migrate this to use PowerSync, we need to update a few things, starting with removing the Realm providers and importing our newly-created `System.ts` file. Then we use our `useSystem` hook and call `init()` to initialize the client-side PowerSync database and connect to the PowerSync Service instance. We then memoize the `system` and pass that to our `PowerSyncContext` provider. Here is what `[AppWrapper.tsx](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/AppWrapper.tsx)` would look like:

```javascript
import { System, useSystem } from "./powersync/System";

export const AppWrapper: React.FC = () => {

  const system: System = useSystem();

  React.useEffect(() => {
    system.init();
  }, []);

  const db = useMemo(() => {
    return system.powersync;
  }, []);

  return (
    <PowerSyncContext.Provider value={db}>
      <SafeAreaView style={styles.screen}>
          <AirbnbList />
      </SafeAreaView>
    </PowerSyncContext.Provider>
  );
};
```

As you can see above, `AirbnbList` is the component mainly used for the UI in the `rn-mbnb` app, and therefore that’s what we will focus on next.  

#### Accessing the Database

In `[AirbnbList.tsx](https://github.com/realm/realm-js/blob/main/examples/rn-mbnb/app/AirbnbList.tsx)` in the original `rn-mbnb` example app, you will notice that both ‘local’ and 'synced’ Realm databases are used, which are accessed using `useLocalRealm` and `useSyncedRealm` hooks:

```javascript
import { useLocalQuery, useLocalRealm } from "./localRealm";
import { useSyncedQuery, useSyncedRealm } from "./syncedRealm";

export const AirbnbList = () => {
  // ...
  const localRealm = useLocalRealm();
  const syncedRealm = useSyncedRealm();
  // ...
}
```

By contrast, PowerSync only has a single client-side database, which we set up in `System.ts` above and passed to our `PowerSyncContext.Provider`. We then access it with the `usePowerSync` hook from the `[@powersync/react` package](https://www.npmjs.com/package/@powersync/react):

```javascript
import { usePowerSync, useQuery } from "@powersync/react";

export const AirbnbList = () => {
  const powersync = usePowerSync();
  // ...
}
```

#### Migrate Database Queries

In the Realm `rn-mbnb` repo, a search function using [MongoDB Atlas Search Index](https://www.mongodb.com/docs/atlas/atlas-search/tutorial/create-index/) was used to search for listings, however, for the purposes of demonstrating how one would migrate an app from Realm / Atlas Device Sync to PowerSync, we’ve opted to use standard SQLite queries with PowerSync in this guide. (PowerSync does offer advanced client-side search capabilities using the SQLite FTS5 extension — see [our docs](https://docs.powersync.com/usage/use-case-examples/full-text-search#full-text-search) for more information.)  

The Realm version of the `rn-mbnb` example app uses a [search function](https://github.com/realm/realm-js/blob/main/examples/rn-mbnb/app/AirbnbList.tsx#L103) in `AirbnbList.tsx` that checks a cache or Realm database for results: (note that in the `rn-mbnb` example app, the user can simulate offline or online mode, and this is what the `offlineMode` state variable refers to)

```javascript
// Perform the search method based on the current state
const doSearch = async () => {
  if (searchTerm !== "") {
    // Check the cache first
    if (cache.length > 0) {
      const ids = cache[0].results.reduce((res, cur) => {
        res.push(cur);
        return res;
      }, []);
      setResultIds(ids);
      setResultMethod(ResultMethod.Cache);
      // If we are in offline mode, we will do a full text search on the current Realm
    } else if (offlineMode) {
      const localSearchResults = syncedRealm
        .objects(ListingsAndReview)
        .filtered("name TEXT $0", searchTerm);
      const ids = localSearchResults.map((item) => item._id);
      setResultIds(ids);
      setResultMethod(ResultMethod.Local);
      // If we are online, we will call the search function on the user object
    } else {
      const { result, error } = await user.functions.searchListings({
        searchPhrase: searchTerm,
        pageNumber: 1,
        pageSize: 100,
      });
      if (error) {
        console.error(error);
      } else {
        const ids = result.map((item) => item._id);
        setResultIds(ids);
        setResultMethod(ResultMethod.Remote);
        // Cache the results
        localRealm.write(() => {
          localRealm.create(SearchCache, {
            searchTerm: searchTerm.toLowerCase(),
            results: ids,
          });
        });
      }
    }
  } else {
    setResultIds([]);
  }
};
```

In the PowerSync version of `[AirbnbList.tsx](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/blob/main/app/AirbnbList.tsx)`, we do away with the dedicated search function and update the search term based on user input, and then use the PowerSync `useQuery` hook to create a watched query against the SQLite database (a watched query will execute whenever the results of the query change):

```javascript
const { data: records } = useQuery<ListingsAndReviewRecord>(`
      SELECT * FROM ${LISTINGS_REVIEW_TABLE} WHERE name LIKE '%${searchTerm}%'
      `);
```

The SQLite query selects all the columns from `listingsAndReviews` and filters the results based on the pattern matching condition (using the `LIKE` operator). The pattern `'%${searchTerm}%'` means that the query will look for any entries in the `name` column that contain the value of `${searchTerm}` anywhere within the string.  

In addition to the `useQuery` hook for watched queries, other APIs provided by PowerSync to execute queries include:

  * `powersync.get()` — executes a read-only query and returns the first result
  * `powersync.execute()` — executes a write (`INSERT`/`UPDATE`/`DELETE`) query  

#### Migrate Render Functions

The `renderListing` function in the Realm version of `AirbnbList.tsx` uses [FastImage](https://github.com/DylanVann/react-native-fast-image), a component which improves the performance of React Native’s `Image` component by applying aggressive caching amongst other things:

```javascript
const renderListing: ListRenderItem<ListingsAndReview> = useCallback(
  ({ item }) => (
    <Pressable
      onPress={() => {
        alert(JSON.stringify(item.toJSON()));
      }}
    >
      <View style={styles.listing}>
        <FastImage
          style={styles.image}
          source={{
            uri: item.images.picture_url,
            priority: FastImage.priority.normal,
            cache: FastImage.cacheControl.immutable,
          }}
        />
        <Text>{item.name}</Text>
      </View>
    </Pressable>
  ),
  []
);
```

In the PowerSync version, we opted to simply use React Native’s `Image` component instead.  

In the code snippet above, you will notice that `picture_url` is a nested field on `images` in the `listingsAndReviews` collection. Here is an example document from the demo dataset for the example app:

![](https://powersync.com/images/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync-inline-35b63b5c78.png)

When we migrated the schema earlier in this guide, we noted that we mapped nested objects in MongoDB to `text` in the client-side SQLite database with PowerSync, so that we can work with them as JSON data.  

Accordingly, there are a couple of ways to handle nested objects on the client with PowerSync:  

_Option 1: Extract nested field using SQLite `json_extract` function:_ If you want to keep the schema on the client as close as possible to the schema in the backend MongoDB database, this would be the preferred approach.  

We can extract the `picture_url` from the `images` object using `[json_extract()](https://www.sqlite.org/json1.html#the_json_extract_function)`. With this approach it’s important to note that the client-side schema does not contain a reference to the `picture_url` column — we only have the top-level `images` field in our schema which is of type `text` and will contain JSON. We therefore need to update the return type of `useQuery` to include the additional column:  `useQuery<ListingsAndReviewRecord & { picture_url: string }>`

```javascript
const { data: records } = useQuery<ListingsAndReviewRecord & { picture_url: string }>(`
    SELECT *, json_extract(images, '$.picture_url') AS picture_url FROM ${LISTINGS_REVIEW_TABLE} WHERE name LIKE '%${searchTerm}%'
    `);
```

_Option 2: Extract nested field in the Sync Rules:_ If the other data in the nested object is never used on the client, this approach would be appropriate.  

To extract `picture_url` from the `images` document in our Sync Rules, we can do the following in `sync-rules.yaml`:

```javascript
SELECT _id as id, images ->> 'picture_url' AS picture_url, * from "listingsAndReviews"
```

We also need to update our client-side PowerSync schema accordingly (in `AppSchema.ts`):

```javascript
const listingsAndReviews = new Table({
  ...
  picture_url: column.text,
  ...
});
```

To finish migrating the `renderListing` function, we can use React Native’s `Image` component and simply display the image URI contained in the `picture_url`:

```javascript
const renderListing: ListRenderItem<ListingsAndReview> = useCallback(
  ({ item }) => (
    <Pressable
      onPress={() => {
        alert(JSON.stringify(item));
      }}
    >
      <View style={styles.listing}>
        <Image
          style={styles.image}
          source={{uri: item.picture_url}}
        />
        <Text>{item.name}</Text>
      </View>
    </Pressable>
  ),
  []
);
```

## Conclusion

Migrating from MongoDB Realm & Atlas Device Sync to PowerSync involves a bit of work but is straightforward as the high-level architecture is similar. On the client-side, SQLite replaces Realm as the in-app database. On the server-side, the PowerSync Service replaces Atlas Device Sync, with the notable difference that data uploads from the client app are sent to your own backend API and not back to the PowerSync Service. Flexible Sync Rules allow you to control which data each user should have local access to. We hope this guide helps you migrate your app to PowerSync with confidence!

## Appendix: Further rn-mbnb Migration Notes

The following notes are specific to migrating the `rn-mbnb` example app and do not necessarily apply generally to any Realm / Atlas Device Sync to PowerSync migration. We have included them here to help developers compare the [PowerSync implementation](https://github.com/powersync-ja/powersync-react-native-mongodb-mbnb/tree/main) of the `rn-mbnb` example app with the original [Realm implementation](https://github.com/realm/realm-js/tree/main/examples/rn-mbnb).

### Effect Hooks

The Realm version does a few things using React `useEffect` hooks related to cache management and Realm subscriptions:

```javascript
useEffect(() => {
  const allIds = fullCache.reduce((acc, cache) => {
    acc.push(...cache.results);
    return acc;
  }, []);
  const uniqueIds = [...new Set(allIds)];
  syncedRealm
    .objects(ListingsAndReview)
    .filtered("_id in $0", uniqueIds)
    .subscribe({ name: "listing" });
  setCachedIds(uniqueIds);
}, [fullCache]);
useEffect(() => {
  getDatabaseSize();
  getCacheSize();
});
```

By contrast, the PowerSync version has a single `useEffect` hook to manage the connection state based on `offlineMode` (as mentioned above, in the `rn-mbnb` example app, the user can simulate offline or online mode, and this is what the `offlineMode` state variable refers to). We use `disconnect()` for “offline mode” which closes the sync connection to the PowerSync Service instance, and `connect()` when going back online, which reopens it.

```javascript
useEffect(() => {
  offlineMode
    ? powersync.disconnect()
    : powersync.connect(new BackendConnector());
}, [offlineMode]);
```

PowerSync also provides a `disconnectAndClear()` function, which disconnects and clears the SQLite database. This is typically used when the user logs out.

### Cache Management

There is a `clearCache` function in the Realm version which clears image and database caches:

```javascript
// Clear the image cache and Realm databases
const clearCache = useCallback(async () => {
  await FastImage.clearMemoryCache();
  await FastImage.clearDiskCache();
  // NOTE: If you are offline, the data will not clear until you go online
  // Atlas will return a change set which will remove the data.
  syncedRealm.subscriptions.update((mutableSubs) => {
    mutableSubs.removeAll();
  });
  // WARNING: This will delete all data in the synced Realm database.
  // Permissions should be set so the user cannot actually perform this.
  // Atlas Device Sync will revert this change.
  // This should only be necessary if offline.
  if (offlineMode) {
    syncedRealm.write(() => {
      syncedRealm.deleteAll();
    });
  }
  // Clear the local cache
  localRealm.write(() => {
    localRealm.deleteAll();
  });
  alert("Cache cleared!");
}, []);
```

The PowerSync version does not implement any explicit cache management. The local SQLite database contains all of the data that the client app requires, and [Sync Rules](https://docs.powersync.com/usage/sync-rules) are used to determine what data should be persisted on the client device.

### State Management

Related to its more advanced search and caching implementation, the Realm version has several state management variables such as `resultIds`, `cachedIds`, `resultMethod`, `syncedDbSize`, `localDbSize`, and `cacheSize`, in addition to `offlineMode` and `searchTerm`:

```javascript
const [resultIds, setResultIds] = useState<string[]>([]);
const [offlineMode, setOfflineMode] = useState(false);
const [searchTerm, setSearchTerm] = useState("");
const [cachedIds, setCachedIds] = useState<string[]>([]);
const [resultMethod, setResultMethod] = useState<ResultMethod>(ResultMethod.None);
```

The PowerSync version has fewer state management variables: `offlineMode`, `searchTerm`, `inputValue`, and `records` (the search query results):

```javascript
const [offlineMode, setOfflineMode] = useState(false);
const [searchTerm, setSearchTerm] = useState("");
const [inputValue, setInputValue] = useState("");
const { data: records } = useQuery<ListingsAndReviewRecord>(`
    SELECT * FROM ${LISTINGS_REVIEW_TABLE} WHERE name LIKE '%${searchTerm}%'
    `);
```

---

# Announcing The Beta Release Of PowerSync’s MongoDB Connector

> The PowerSync MongoDB Connector is now in Beta. This means that PowerSync is now ready to be used in production MongoDB environments (either self-hosted or Atlas), and is fully supported under our commercial agreements including premium support SLAs.

- Published: 2024-12-27
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/powersync-mongodb-connector-module-now-in-beta

---

## Production-Ready MongoDB Sync Engine

We are excited to announce that PowerSync’s MongoDB Connector has advanced to Beta status. With this release, PowerSync is now ready for production use in both self-hosted and MongoDB Atlas environments, offering robust support under our commercial agreements, including premium support SLAs.

This release underscores the strategic partnership between MongoDB and PowerSync in shaping the future of the sync engine market. Sync engines simplify state management between databases and applications. They manage state transfer between the backend database and the app asynchronously in the background, freeing developers up from writing low-level data transfer plumbing logic: a tedious task fraught with technical complexity. This enables developers to focus on building valuable features for their customers.

Following our partnership [announcement](https://www.mongodb.com/blog/post/mongodb-atlas-power-sync-future-offline-first-enterprise-apps) with MongoDB in October, we’ve collaborated extensively with their leadership, engineers, and sales teams to assist customers in preparing for the rapidly approaching Atlas Device Sync end-of-life in September 2025. We’ve also seen a steady influx of customers on our Discord server where our engineers assist with technical migrations. 

Several MongoDB customers ranging from enterprises to startups have already selected PowerSync to replace Atlas Device Sync. Examples include UK package delivery service [Yodel](https://yodel.co.uk/), POS solution [KaHero](https://www.kahero.co/), and dairy management system [Ordenha Facil](https://ordenhafacil.com.br/). PowerSync provides a range of engagement models and pricing plans to suit the needs of businesses of varying types and sizes, including self-service and enterprise options.

## Consistency Guarantees For Synced Data

Many developers don’t realize the importance of [consistency](https://jepsen.io/consistency/models/causal) guarantees when it comes to distributed state management. Consistency issues are notoriously difficult to diagnose and debug and even though consistency may not be an issue from the outset, it can become a huge pain for serious deployments. This is why we prioritized providing rock-solid causal consistency guarantees for our Beta release. This is important for any use cases where ordering of any type is required to make sense of the data or interpret the state. 

After consulting with the Atlas Device Sync architecture team, we adopted a similar approach to Atlas Device Sync of using `changeStreamPreAndPostImages` to guarantee causal consistency. In addition to automatically configuring this for synced collections, we also provide [manual configuration options](https://docs.powersync.com/configuration/source-db/setup#post-images) for environments with stricter security requirements.

## Flexibility of CRUD Uploads

A significant architectural advantage of PowerSync over the soon-to-be-discontinued Atlas Device Sync is the enhanced control it offers developers over the handling of local mutations and their processing into MongoDB. By default, the PowerSync client SDK queues and sends local mutations to the developer’s backend API, so that custom business logic and/or validations can be applied before writing the changes to MongoDB. As an alternative to running their own backend API, some customers are using the customizable serverless CloudCode environment provided by PowerSync to host these write endpoints. Contact us for more information on this option.

## Roadmap to V1

See the [Beta release notes](https://releases.powersync.com/announcements/mongodb-as-a-backend-database-now-in-beta) for more information on what we worked on to get from Alpha to Beta.

As we progress towards Version 1, our roadmap remains adaptable, guided by customer feedback. Our focus includes enhancing usability, improving documentation, developing reference/demo applications, and exploring support for sharded MongoDB clusters and Atlas Private Endpoints. If you’d like to see any of these features, please visit our [product roadmap](https://roadmap.powersync.com/) and upvote/submit ideas. 

## Using PowerSync

Begin your journey with PowerSync by signing up for a free PowerSync Cloud account [here](https://accounts.powersync.com/portal/powersync-signup). PowerSync can also be fully self-hosted in your own environment, and our [MongoDB self-host-demo app](https://github.com/powersync-ja/self-host-demo/tree/main/demos/nodejs-mongodb) is a good place to get a feel for the system. 

## Appendix: Client SDK Release Status

PowerSync supports a wide range of client SDKs and frameworks. The release status of various SDKs at the time of writing is summarized below 

| SDK | Status | Next Milestone and ETA |
| --- | --- | --- |
| Swift | Beta | V1 in 2025Q1 |
| KMP | Beta | V1 in 2025H1 |
| KMP JVM Support | [WIP](https://github.com/powersync-ja/powersync-kotlin/pull/88) | Beta in 2025Q1 |
| JS Web | V1 | N/A |
| JS Web: React Hooks | V1 | N/A |
| JS Web: TanStack Query | Alpha | Beta in 2025Q1 |
| JS Web: Drizzle | Alpha | Beta in 2025Q1 |
| JS Web: Vue | Beta | Beta in 2025Q1 |
| JS Web: SolidJS | [Community-maintained](https://github.com/aboviq/powersync-solid) | |
| React Native | V1 | N/A |
| React Native Web | Beta | V1 in 2025H1 |
| Flutter | V1 | N/A |
| Flutter Web | Beta | V1 in 2025Q1 |
| Node.js | PoC | Alpha in 2025H1 |
| .NET | WIP | Alpha + Beta in 2025Q1 |

---

# Introducing PowerSync for MySQL To Local SQLite Sync

> PowerSync now syncs MySQL with local SQLite databases, enabling developers to create zero-latency, local-first apps for desktop, mobile, and the web. The PowerSync MySQL database connector (alpha) is now available on both PowerSync Cloud and self-hosted PowerSync.

- Published: 2024-12-13
- Author: Phillip van der Merwe
- Category: Product Update
- Source: https://powersync.com/blog/introducing-powersync-for-mysql-to-local-sqlite-sync

---

PowerSync now syncs MySQL with local SQLite databases, enabling developers to create zero-latency, local-first apps for desktop, mobile, and [the web](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web).

The PowerSync MySQL database connector (alpha) is now available on both PowerSync Cloud and [self-hosted PowerSync](https://docs.powersync.com/self-hosting/getting-started).

## Bidirectional Sync to Bring Local-First to MySQL

PowerSync enables bidirectional sync between a MySQL database on the backend, and SQLite databases embedded in client applications. These applications can read and write directly on the local SQLite database which is kept in sync with MySQL through the [PowerSync Service](https://docs.powersync.com/architecture/powersync-service), enabling a local-first architecture which allows:

  * **Zero-latency UX:** The UI responds instantly to the user, since there is no network latency on the critical path. This applies both to loading data and updating data.
  * **Real-time streaming:** MySQL data updates are streamed to local databases in real-time, and reactive queries running against the local SQLite automatically update with fresh data.
  * **Multi-user collaboration** : Users can immediately see updates made to shared data by other users.
  * **Offline resilience** : With data available locally and writes performed locally, apps are resilient to any network interruptions, or even complete downtime of the network connection or backend.

## What does PowerSync provide, and how is it used?

Here’s a quick rundown of how PowerSync works and the key features it provides:

  * The [PowerSync Service](https://docs.powersync.com/architecture/powersync-service) connects to standard MySQL databases to perform _dynamic partial replication_ of data to users. This is controlled through [Sync Rules](https://docs.powersync.com/usage/sync-rules) which contain [SQL-like queries](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets) that can make use of dynamic parameters.
  * When Sync Rules are created, the PowerSync Service pre-processes and caches data and operation history from the MySQL database to efficiently and scalably sync to users. The PowerSync Service initially takes a snapshot of data defined in the Sync Rules, and then incrementally updates its cache whenever the data changes, using a MySQL [binlog](https://dev.mysql.com/doc/refman/8.4/en/binary-log.html) listener.
  * On the client side, the developer includes a PowerSync [client SDK](https://docs.powersync.com/client-sdk-references/introduction) in the app project. The developer wires up the SDK to fetch a JWT from their application backend, which is then used for authentication between the PowerSync Service and the client SDK.
  * The client SDK keeps a local SQLite database in sync with MySQL in real-time, based on the Sync Rules configuration. The SDK allows for live queries from SQLite (which re-run whenever underlying data changes), allowing the developer to enable real-time reactivity in their app UI. It generally eliminates the need for a state management library.
  * Whenever the app performs writes to the local SQLite database, the write transactions are also placed in an upload queue [^1]. The developer defines a function used by the client SDK to upload the writes to their backend application, where custom business logic can be applied before committing the changes to the MySQL database. If the user is offline or network connectivity is unreliable, the PowerSync client SDK will automatically retry uploading the changes in the queue.

## A simpler developer experience

In addition to enabling a high-quality UX for end-users, sync engines also provide a better experience for developers, by replacing imperative API calling with a [declarative system](https://powersync.com/blog/api-calling-is-to-sync-engines-as-jquery-is-to-react).

PowerSync simplifies data transfer and state management: developers define Sync Rules and the PowerSync Service ensures that each local SQLite database contains the latest relevant data. Developers no longer need to worry about how and when APIs are called, handling error states and retries, or implementing caching and purging strategies.

Developers can work with a real local database in the front-end (SQLite) and PowerSync ensures it stays in sync with the MySQL backend database. Developers get the full power of SQLite — including joins and aggregations.

## How MySQL’s binlog enables real-time sync with SQLite

PowerSync uses MySQL’s [binary log](https://dev.mysql.com/doc/refman/8.4/en/binary-log.html) and a listener that emits events for database changes in order to achieve similar functionality to Postgres’s Logical Replication.

The [ZongJi](https://github.com/vlasky/zongji) Node.js library is used to connect to a MySQL server, read the binary log and emit events for database changes, including:

  * **INSERT** : Rows added to a table.
  * **UPDATE** : Changes to existing rows.
  * **DELETE** : Rows removed from a table.

The PowerSync Service partially replicates data from MySQL according to Sync Rules defined by the developer, as described above. This data is then streamed to SQLite databases embedded in users’ applications, by means of the PowerSync client SDK. Client SDKs are currently available for [web (JavaScript)](https://docs.powersync.com/client-sdk-references/js-web), [React Native](https://docs.powersync.com/client-sdk-references/react-native-and-expo), [Flutter](https://docs.powersync.com/client-sdk-references/flutter), [Kotlin Multiplatform](https://docs.powersync.com/client-sdk-references/kotlin-multiplatform), [Swift](https://docs.powersync.com/client-sdk-references/swift), [Node.js](https://docs.powersync.com/client-sdk-references/node) and [.NET](https://docs.powersync.com/client-sdk-references/dotnet).

![](https://powersync.com/images/blog/introducing-powersync-for-mysql-to-local-sqlite-sync-inline-bdc920a724.png)

## Control how client-side uploads are applied to MySQL

PowerSync gives developers control over how writes from clients are applied to MySQL, by routing them through the developer’s own backend API. 

On the client-side, whenever writes are made to the local SQLite database, PowerSync also places those writes into an upload queue, and then attempts to upload the transactions in the queue sequentially to the developers’ backend API, based on custom logic defined by the developer. Developers can perform server-side validations, authorization and conflict resolution in the backend API implementation that accepts the writes. The simplest backend API implementation accepts all client uploads for last-write-wins conflict resolution behavior.

PowerSync treats the server as authoritative and automatically ensures all clients converge to the server state with [causal consistency](https://docs.powersync.com/architecture/consistency#powersync-designed-for-causal-consistency).

![](https://powersync.com/images/blog/introducing-powersync-for-mysql-to-local-sqlite-sync-inline-f31ae9e430.png)

## Design goals

PowerSync has been developed with specific design goals in mind, which have remained the same as we added MySQL support:

  * It should be easy to adopt for new (greenfield) and existing (brownfield) systems. It should not be invasive to the developer’s stack, especially the database: it should not require substantial reconfiguration or additions to the MySQL database. 
  * Dynamic partial replication is a key capability, and it should be possible to adapt the sync controls at any time without complexity.
  * The database is sacrosanct: don’t write directly to their database. Don’t bypass the developer’s existing business logic, authorization and validation.
  * Low maintenance. In particular, schema and data migrations should be as painless as possible.
  * A simple, robust and proven architecture, not over-engineered.
  * Provide strong consistency guarantees.

## Get Started

Start building today! Check out PowerSync’s [MySQL documentation](https://docs.powersync.com/configuration/source-db/setup#mysql-alpha) for quick setup instructions.

Create a free [PowerSync Cloud account](https://accounts.powersync.com/portal/powersync-signup), or [self-host using Docker](https://docs.powersync.com/self-hosting/getting-started) (note that the PowerSync Dashboard is currently not available in the self-hosted PowerSync Open Edition).

[^1]: With PowerSync, you can do local transactions in SQLite and then place the whole transaction into the upload queue as a batch, which your backend can then either reject or accept.

---

# Developer Case Study: Chris Primavera / Aspen Square

> Aspen Square is a leading property management company overseeing 17,000 apartments in 16 states, whose on-site operations include executing work orders, inspections, renovations, and other field activities. We were joined by Chris Primavera (Director of Application Development) to discuss Aspen Square’s operations platform, an in-house web and mobile app.

- Published: 2024-12-10
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-chris-primavera-aspen-square

---

## Background

[Aspen Square](https://www.aspensquare.com/) is a leading property management company overseeing 17,000 apartments in 16 states, whose on-site operations include executing work orders, inspections, renovations, and other field activities. We were joined by Chris Primavera (Director of Application Development) to discuss Aspen Square’s operations platform, an in-house web and mobile app.

### App details

| App name | Aspen Square Operations Platform |
| --- | --- |
| Platform(s) | Mobile |
| App framework | React Native |
| Backend API | Supabase (PostgREST) |
| Backend database | Supabase (Postgres) |
  
### TL;DR

  * Aspen Square adopted PowerSync for offline capabilities in its operations platform.
  * Chris highlighted the smooth developer experience of working with a local SQLite database, especially compared to web APIs.
  * Chris believes sync engines should be a go-to for mobile and native apps, and is also interested in exploring their use in web apps.

## Interview

**PowerSync**  
Hi Chris, thanks for joining us, it’s so valuable to have the opportunity to get feedback from developers. It looks like you tried a few sync tools in the past. You’ve used MongoDB Atlas Device Sync, is that right?

**Chris Primavera**  
Yeah, that’s exactly right. So, we’ve been planning to release this operations platform for a couple of years. We initially looked at a bunch of vendors, did some beta testing, and ultimately decided to build the operations platform in-house.

We were looking at MongoDB Atlas Device Sync + Realm for probably a year or more before MongoDB deprecated it. So we ended up moving late in the process. We discovered PowerSync from poking around online, looking at sync engines. I think we ended up in a better spot — the stack feels a lot better than the MongoDB Realm stack felt to me at the time.

**PowerSync**  
Did you ever end up implementing Atlas Device Sync, MongoDB’s solution?

**Chris Primavera**  
No, we didn’t deploy it. It was more of an advanced POC.

**PowerSync**  
Okay. So you’re now using Supabase on the backend. What does your client-side stack look like?

**Chris Primavera**  
React Native. We also have some web apps.

**PowerSync**  
Are you using PowerSync just in React Native for now?

**Chris Primavera**  
Yes. The main use case was offline capability — being able to sync as technicians go into spotty areas of service.

**PowerSync**  
That makes sense. Most developers who use PowerSync adopt it for offline support. However, we’re seeing more developers using it for improved online user experience, as working with a local SQLite database has near-zero latency. There are also developer experience benefits, like avoiding API request/response and state management complexities. Were any of those factors important to you, or was it mainly offline support?

**Chris Primavera**  
We weren’t thinking about those factors going in, but I agree they’re true. Working with a local-first SQLite database feels like working with in-memory state management — so much smoother than a request-response model. When we switch between developing native apps with PowerSync and web apps using the Supabase APIs, the local database experience is way better.

**PowerSync**  
That’s great to hear. Were there any other sync tools you evaluated before choosing PowerSync?

**Chris Primavera**  
Not really. We were already comfortable with MongoDB as a database, which is why we focused on Realm.

**PowerSync**  
Are you currently connecting PowerSync to any MongoDB databases?

**Chris Primavera**  
Not at the moment. Only Supabase.

**PowerSync**  
You probably saw that we released support in PowerSync for MongoDB as a source database.

**Chris Primavera**  
Yeah.

**PowerSync**  
Great. Are there any features you feel are missing or areas where you faced challenges?

**Chris Primavera**  
The learning curve around Sync Rules was steep for us. We wanted to sync a relationship graph of active data — for example, syncing only open work orders and their history for a particular location. We implemented an edge function to recalculate sync flags for related entities.

We also ended up putting an asset ID in almost all our tables to manage syncing by property, as each bucket corresponds to an asset. Being able to sync from a Postgres view would’ve been ideal, but it isn’t possible with PowerSync at this time.

**PowerSync**  
We’re actively working on supporting views with joins in Sync Rules. It’s a complex problem, but something we hope to address in 2025.

**Chris Primavera**  
That sounds amazing.

**PowerSync**  
One more question: Do you see sync engines becoming a standard for app development, or do you think traditional request-response APIs will remain dominant?

**Chris Primavera**  
I’d say for mobile and native apps, I’d definitely use a sync engine again. For web apps, I haven’t explored the PowerSync SDK deeply enough to say. But if the developer experience for web matches the native experience, I’d consider it.

**PowerSync**  
That’s great feedback. Are there any broader trends in app development that excite you?

**Chris Primavera**  
I’ve been impressed by the advancements in local-first development and tools like Expo, which make transitioning between web and native much easier. Backend-as-a-service options like Supabase have also been a huge help. Advancements in WebAssembly, which is used in the PowerSync Web SDK, is also an exciting trend in app development.

**PowerSync**  
Thanks for sharing. Anything else you’d like to add?

**Chris Primavera**  
No, I think we’ve covered everything. I really appreciate the responsiveness of the PowerSync team and the support on Discord.

**PowerSync**  
Thank you so much for your time and feedback. We look forward to keeping you updated as we improve PowerSync.

**Chris Primavera**  
Great. Thanks.

---

# PowerSync Update: November 2024

> We continued progress on multiple fronts during November. In addition to product milestones, our Discord community is also growing rapidly. This post covers all the updates from November.

- Published: 2024-12-05
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-november-2024

---

We continued progress on multiple fronts during November. In addition to product milestones, our Discord community is also growing rapidly (invite [here](https://app.hubspot.com/contacts/6550460/record/0-1/21948144445)), now regularly seeing 500+ messages per week. Feel free to ask us anything: PowerSync engineers are based in multiple timezones and do their best to respond quickly. We’ve also introduced a **_Trusted Engineer_** badge for community members who’ve become PowerSync experts. On to other milestones:

## New Sync Rules Capabilities

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-009db38b0b.png)

We’re continuously working to make Sync Rules more intuitive and capable. In November, we released three new Sync Rules functions:

  * `**substring(text, start, length)**`: Extracts a portion of a string based on specified start index and length. Start index is 1-based. Example: `substring(created_at, 1, 10)` returns the date portion of the timestamp.
  * `**json_each(data)**`: Expands a JSON array or object from a request or token parameter into a set of parameter rows. Example: `SELECT value as project_id FROM json_each(request.jwt() -> 'project_ids')`
  * `**json_keys(data)**`: Returns the set of keys of a JSON object as a JSON array. Example: `select * from items where bucket.user_id in json_keys(permissions_json)`

[Read the docs](https://docs.powersync.com/usage/sync-rules/operators-and-functions)

## Issue Alerting Now Available On All Plans

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-0e079b6534.png)

Issue alerts are now available on all plans, allowing developers to catch connection, replication and sync issues early. Email notifications for all are coming soon. Pro, Team and Enterprise plan users can already wire up webhooks to send alert notifications to other systems.

[Read the docs](https://docs.powersync.com/usage/tools/monitoring-and-alerting#monitoring-and-alerting)

## Drizzle ORM Support

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-9488d163a8.png)

The `@powersync/drizzle-driver` package integrates Drizzle with our React Native and JavaScript/Web SDKs.

We know that developers often have strong opinions on using ORMs, so instead of enforcing one approach, we support everything from raw SQL queries to popular ORM libraries. For the JavaScript ecosystem, Drizzle joins Kysely as ORM options.

[Read the release notes](https://releases.powersync.com/announcements/drizzle-orm-integration-for-react-native-and-js-web-alpha)

## V1.0.0 of Docker Image

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-d6bb7889db.png)

This release introduces a major refactor of the PowerSync Service to support modular replication, along with alpha support for MongoDB and MySQL source databases. 

MongoDB and MySQL developers can now use the latest version of the Docker image: `image: journeyapps/powersync-service:latest`. This release also paves the way for the upcoming beta releases for these database technologies.

[See the docs](https://docs.powersync.com/self-hosting/getting-started)

## SQLCipher Support for Flutter

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-b768d6db09.png)

This release allows developers to implement E2E encryption for Flutter apps (note: Flutter Web does not yet support SQLCipher).

[Read the release notes](https://releases.powersync.com/announcements/sqlcipher-support-for-powersync-flutter)

## Healthcheck APIs for Self-Hosted PowerSync

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-d4f450a290.png)

New endpoints can be used to check the health of your self-hosted PowerSync Service instances. This provides a way to catch issues before they impact your users.

[Read the docs](https://docs.powersync.com/self-hosting/lifecycle-maintenance/healthchecks)

## New Use Case Example: Prioritized Sync

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-fe0ebcc3a5.png)

In some scenarios, you may want to sync some tables before others. For example, you may want to sync a subset of all tables first to log a user in as fast as possible, then sync the remaining tables in the background. This use case example explains how to achieve that.

[See the use case example](https://docs.powersync.com/usage/use-case-examples/prioritized-sync)

## Flutter Web Support Released Into Beta

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-c3f0f5ee1a.png)

This Beta release means that our Flutter Web support is now suitable for production use, given that you sufficiently tested your use cases.

This release introduces shared sync coordination across tabs — our final step to full Flutter Web support. This was achieved by offloading the task of synchronizing databases to a separate worker (`powersync_sync.worker.js`), allowing it to be coordinated across tabs.

Huge thanks to **Simon Binder** , the maintainer of Dart’s SQLite3 and Drift packages, who did the bulk of the initial work for this release.

[Read the release notes](https://releases.powersync.com/announcements/flutter-web-support-is-in-beta)

## PowerSync on AWS Marketplace

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-e618c7bdbe.png)

PowerSync is now available on the AWS Marketplace, simplifying procurement for enterprise customers.

This makes it easier for teams who use AWS to deploy PowerSync into their organizations. Currently, only our Enterprise plan is available on the AWS Marketplace.

[Read the blog post](https://powersync.com/blog/powersync-on-the-aws-marketplace)

## Video: Migrating From MongoDB Atlas Device Sync/Realm

Long-time Realm user, **Steve Nosse** , joined us to discuss his experience migrating from MongoDB Atlas Device Sync and Realm to PowerSync and Supabase.

## Community Focus

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-4905b2f26e.png)

### Contributions

High-fives to **Omnicpie**(2nd contribution!) and **ImSingee** who contributed PRs this month. The first [allows users to to specify a type for a given parameter in our diagnostics app](https://github.com/powersync-ja/powersync-js/pull/390) and the second [adds support for Drizzle’s casing capabilities](https://github.com/powersync-ja/powersync-js/pull/403).

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-5b0ede4399.png)

### [A short guide for self-hosting](https://github.com/guillempuche/selfhost_fullstack_in_vps)

A practical guide for hosting self-managed TypeScript apps on a VPS, with tools like Coolify, Postgres, PowerSync, and Supertokens. By **Guillem Puche**.

![](https://powersync.com/images/blog/powersync-update-november-2024-inline-0da9e954d5.png)

### [Developer Case Study: trakkd](https://powersync.com/blog/developer-case-study-timo-behrens-trakkd)

**Timo Behrens** joined us to discuss their meeting note management app, [trakkd](https://www.trakkd.com/).

That's it for the November update, happy coding!

[Video: PowerSync update — November 2024](https://www.youtube.com/watch?v=YNvkmVHPbBI)

---

# PowerSync On The AWS Marketplace

> PowerSync is now available on the AWS Marketplace, simplifying procurement for enterprise customers. With more and more developers using PowerSync to create high-performance, local-first applications, we’re making it even easier for teams who use AWS to deploy PowerSync into their organizations.

- Published: 2024-11-25
- Author: Phillip van der Merwe
- Category: Announcement
- Source: https://powersync.com/blog/powersync-on-the-aws-marketplace

---

PowerSync is now available on the AWS Marketplace, simplifying procurement for enterprise customers.

With more and more developers using PowerSync to create high-performance, local-first applications, we’re making it even easier for teams who use AWS to deploy PowerSync into their organizations.

## About the AWS Marketplace

The Amazon Web Services (AWS) Marketplace is a centralized catalog of software, data, and services from trusted third-party providers. Businesses can use it to discover, purchase, and manage solutions directly within their AWS account.

Some of the benefits of purchasing through the AWS Marketplace include:

  * Simplified procurement with purchases integrating into existing AWS procurement processes.
  * Consolidated billing through AWS.
  * Purchases count towards existing AWS spend commitments.

## Getting Started

Ready to integrate PowerSync into your AWS environment? Visit our [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-ynpzymrus4wyc) to get started.

## Frequently Asked Questions

**Which PowerSync plans are available through the AWS Marketplace?**  
Currently, only our **Enterprise** plan is available on the AWS Marketplace. See our [Pricing page](https://powersync.com/pricing) or [reach out](https://powersync.com/contact) to our team to see what plan is right for you. We are able to provide you with a custom private offer via AWS based on your specific requirements. Please [contact us](https://powersync.com/contact) for more details.

**Is the PowerSync solution on AWS Marketplace a SaaS offering?**  
Yes, PowerSync on the AWS Marketplace is a fully managed SaaS solution. There’s no need to provision or maintain additional AWS resources.

**How is billing handled for PowerSync?**  
All charges for PowerSync subscriptions are processed through your AWS account, appearing in your consolidated AWS bill.

**Does PowerSync offer a free trial through the AWS Marketplace?**  
PowerSync does not offer a free trial through the AWS Marketplace. Customers interested in trying out PowerSync can use the Free tier offering directly available from PowerSync.

---

# Interview: Migrating From Atlas Device Sync And Realm To PowerSync

> App developer Steve Nosse discusses the process of migrating from MongoDB Atlas Device Sync and Realm to PowerSync.

- Published: 2024-11-20
- Category: Showcase
- Source: https://powersync.com/blog/interview-migrating-from-atlas-device-sync-and-realm-to-powersync

---

## Intro

**Mike:** Thank you so much for joining us here today.

**Steve:** Thanks, Mike, it's my pleasure.

**Mike:** From what we can tell, you're working on a few apps — [Paper](https://papernotes.app/), a note-taking app, [BeFit](https://www.getbefitapp.com/) for exercise logging, and a few others. Could you please share a bit more about your background and the different apps you're currently working on?

**Steve:** Yeah, so to talk about myself a little bit, I’m [Steve](https://x.com/nossesteve). I live in France, and I spend most of my time writing and reading code. I've been doing this for a bit more than four years now, and I’m working full-time as a mobile developer.

I love to experiment and learn new things, which is why I spend a lot of time on pet projects. I use these pet projects to fill needs I have on a daily basis. For instance, I needed a simple note-taking app, so I built **Paper** , which is my biggest app today with a bit more than 1,000 active users.

![](https://powersync.com/images/blog/interview-migrating-from-atlas-device-sync-and-realm-to-powersync-inline-5cd43b859c.png "Paper, a note-taking app||landscape")

I also needed to track my progress at the gym, so I built BeFit. Additionally, I’ve created apps for specific needs for myself or my relatives.

![](https://powersync.com/images/blog/interview-migrating-from-atlas-device-sync-and-realm-to-powersync-inline-ffee75b8bc.png "BeFit, a workout and nutrition tracking app")

## Reacting to MongoDB's Deprecation Announcement

**Mike:** We recently noticed that you tweeted about migrating an app from MongoDB Atlas Device Sync to PowerSync with Supabase as your backend database. Many developers are in the same position you were, learning about MongoDB's decision to [deprecate Atlas Device Sync](https://www.mongodb.com/docs/atlas/app-services/sync/device-sync-deprecation/) and wondering about the best way forward. Could you take us through how you reacted to that news and some of the steps you took to migrate your apps?

**Steve:** I was already considering migrating off [Realm](https://github.com/realm) for a few reasons. I had tried the [Supabase](https://supabase.com/) \+ PowerSync combo on a project and loved it.

I found Realm extremely painful to work with — it was so rigid. Even small schema changes could result in runtime errors, which was frustrating. You had to rely on code generation, which felt like overkill. The process felt fragile, like walking on eggshells.

Beyond that, Realm felt overly complex. You had to manage sync rules, schema versions, and migrations — either upgrading schema versions or manually writing migration code when you made model changes.

Realm's authentication system was another hurdle — it wasn’t compatible with web apps. My users wanted a web app, but I couldn’t deliver one.

Finally, switching from local to synchronized mode in Realm required creating a new database file and manually copying data from the offline database. This was error-prone and didn’t feel right.

When MongoDB announced the deprecation, it gave me a solid reason to start migrating.

## Learning About PowerSync

**Mike:** How did you first learn about PowerSync, and what made you want to evaluate it further?

**Steve:** I think I saw a post about PowerSync on Twitter from [Sebastian Röhl](https://bsky.app/profile/sebastianroehl.bsky.social), the creator of [HabitKit](https://www.habitkit.app/). 

I checked it out and fell in love with the philosophy. Most of my apps don’t necessarily need an internet connection to work, so PowerSync’s approach — using a SQL database while synchronizing changes across users’ devices — spoke to me.

## The Migration Process

**Mike:** What were the steps you took to move from MongoDB Atlas Device Sync and Realm to Supabase and PowerSync?

**Steve:** For context, I was using Firebase for user authentication in the legacy system. Migrating involved a few key components:

  1. **Firebase to Supabase Migration** : This was straightforward, thanks to Supabase’s excellent migration tools.
  2. **User Data Migration:** This was more complex because we had:some text
     * Offline-only users without accounts (no cloud sync enabled).
     * Users with accounts, some with data spanning multiple devices in different states.

To use Supabase for authenticating the PowerSync client against the server, user IDs needed to come from Supabase, not Firebase. We had to handle user ID changes during migration while maintaining data ownership.

We implemented two key solutions:

  * **Client-Side Migration Flow** : This copied data from the Realm database to [SQLite](https://www.sqlite.org/index.html), ensuring offline users could still access their data.
  * **Remote Migration Tool** : This transferred data from MongoDB collections to Supabase tables. PowerSync then synchronized this data to users' local databases.

We relied on PowerSync’s [built-in conflict management](https://docs.powersync.com/usage/lifecycle-maintenance/handling-update-conflicts#handling-update-conflicts) for this process, which worked perfectly. We migrated 20,000 notes without any issues.

Finally, we implemented a forced upgrade mechanism in the mobile app to prevent users from saving data in the legacy system.

## Adjusting to SQLite and Sync Rules

**Mike:** How did you find the transition from working with Realm to SQLite and PowerSync’s [Sync Rules](https://docs.powersync.com/usage/sync-rules#sync-rules)?

**Steve:** I didn’t face any major issues. I was already familiar with Realm’s sync system (despite its flaws), and PowerSync has excellent documentation.

The YAML syntax for Sync Rules was intuitive, and PowerSync’s examples made it easy to get things working.

## Advice for Developers Reacting to MongoDB's Decision

**Mike:** What advice would you give to developers wondering how to respond to the Atlas Device Sync deprecation?

**Steve:** First, consider migrating to a new solution — MongoDB is shutting it down.

For me, PowerSync is ideal for several reasons:

  * Setup took only 1–2 hours the first time.
  * It’s non-intrusive, letting you retain control over how write operations are handled.
  * It supports MongoDB, MySQL, and PostgreSQL, so larger apps can use PowerSync as a sync engine without switching infrastructure.
  * Maintenance has been minimal. Everything just works, and I’ve only had to focus on adding new features.

## Closing

**Mike:** Thank you for joining us today and sharing your journey. We wish you all the best!

**Steve:** Thanks, it was my pleasure!

## Video

Watch the video of this conversation:

[Video: Interview: Migrating from Atlas Device Sync and Realm to PowerSync](https://www.youtube.com/watch?v=YNvkmVHPbBI)

---

# Developer Case Study: Timo Behrens / trakkd

> We were joined by Timo Behrens to talk about trakkd, a collaborative meeting productivity application that he is in the process of building. We spoke about what he sees as the benefits of local-first, the stack that he is using, and why he decided to use PowerSync.

- Published: 2024-11-19
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-timo-behrens-trakkd

---

## Background

We were joined by Timo Behrens to talk about [trakkd](http://www.trakkd.com/), a collaborative meeting productivity application that he is in the process of building. We spoke about what he sees as the benefits of local-first, the stack that he is using, and why he decided to use PowerSync.

### App details

| App name | [trakkd](http://www.trakkd.com/) |
| --- | --- |
| Platform(s) | Web |
| App framework | Vue + Nuxt.js (using web SDK) |
| Backend API | Supabase (PostgREST) |
| Backend database | Supabase (Postgres) |
  
### TL;DR

  * Use case: A collaborative meeting notes app to improve meeting culture, focused on real-time functionality for preparation and note-taking, with offline capability as a secondary feature. 
  * Selected PowerSync for its production readiness and decoupled architecture.
  * Uses Nuxt.js (Vue.js) without TypeScript to minimize development time.
  * Ranked real-time sync as the highest priority (10/10), followed by speed (8/10) and offline functionality (6/10). Evaluated alternatives like ElectricSQL, Replicache, Supabase Realtime, and TipTap but found PowerSync best suited to their needs.

![](https://powersync.com/images/blog/developer-case-study-timo-behrens-trakkd-inline-a36dcae935.png)

## Interview

**PowerSync**

Thanks so much for chatting with us. Could you tell us a bit about what you’re building?

**Timo**

I’m building a collaborative meeting notes application aimed at improving meeting culture in companies. The goal of my app is to make people more productive, prepared for meetings, and ensure no information gets lost or decisions aren’t tracked. A lot of companies use Google Docs for one-on-one or team sync meetings, but my app is focused on helping managers and executives stay organized.

For that, I need real-time functionality, something like Google Docs, so users can have the tool open alongside their call, add agenda items before meetings, and take notes during the meetings in real-time. I looked into a few local-first frameworks, and I really liked PowerSync because it felt more decoupled than others like ElectricSQL, and I didn’t want to invest in something that was too bleeding edge. PowerSync felt more production-ready, which gave me confidence to use it.

I also like the offline-first approach, where users can prepare for meetings or retrieve information even if they don’t have a connection, like when they’re on a train. But I mostly need the real-time functionality, and the offline feature is a nice-to-have.

**PowerSync**

It sounds like you’re implementing real-time collaborative document editing. We [demonstrated](https://powersync.com/blog/postgres-and-yjs-crdt-collaborative-text-editing-using-powersync) how PowerSync can be used for that, with data stored in Postgres and synced in real-time. Did you look at that example or are you doing something similar?

**Timo**

I checked out those technologies, but for now, I’m just using a simple strategy with PowerSync. I’m not doing anything complex like CRDTs. 

**PowerSync**  

Makes sense. Could you share what your front-end stack is?

**Timo**

I’m using Nuxt.js, so it’s based on Vue.js and plain JavaScript. I chose to avoid TypeScript because I’m trying to minimize development time. I’ve already opted for a lot of new technology, including PowerSync, and I had some initial struggles integrating it, mostly due to documentation - which is better now. But once it worked, it felt great. Building something like this from scratch wouldn’t have been doable for me as I’m bootstrapping everything.

**PowerSync**  

You’ve already touched on the reasons why you chose an offline-first or local-first architecture. Speed and real-time functionality were big factors for you. Can you rank the importance of these features — real-time sync, offline functionality, and speed — on a scale of 1 to 10?

**Timo**

Real-time is a 10, speed is an 8, and offline is a 6. 

**PowerSync**

As for alternatives you looked at before choosing PowerSync, were there any others besides ElectricSQL?

**Timo**  

I also considered Replicache, Supabase Realtime, and TipTap. Supabase Realtime does not provide a lot of functionality out of the box for my use case, and ElectricSQL wasn’t production-ready at the time. Replicache seemed inactive and had a difficult API. I didn’t need full CRDT functionality, as my app is more structured and doesn’t require free-form text editing. Therefore TipTap was not suitable. Ultimately PowerSync seemed to be the best choice for my app.

**PowerSync**

You mentioned PowerSync being more decoupled and production-ready. Were there any other standout features that led to your decision?

**Timo**

Yes, the active developer team and the fact that JourneyApps uses it gave me confidence. It’s a new project, but you seem committed, which was important to me.

**PowerSync**  

If you had to rate the importance of PowerSync’s decoupled nature versus its production-readiness and active development, which would you say is most important?

**Timo**  

The decoupled nature was very important for my project because I didn’t want to risk having to rewrite the entire application if something didn’t work. I started with Supabase and then integrated PowerSync, though I had to adjust my data model to fit the Sync Rules paradigm.

**PowerSync**

We’re working on improving the flexibility of Sync Rules to handle more complex relationships. On a more general note, given our goal to make local-first and offline-first applications easier to develop, do you have any suggestions for how we can improve PowerSync?

**Timo**

Documentation. I had some challenges, like certain commands in the documentation using pnpm that weren’t compatible with npm. It would be helpful to offer options for different package managers. I’ve hesitated to upgrade certain tools after bad experiences with breaking changes — like when I updated PrimeVue, and it cost me weeks of rework. That’s why I’ve stuck with what’s working for me. A bit more guidance on using different tools would help, especially for new users who might struggle with the steep learning curve. Your team has been fast with updates, and I’ve seen a lot of progress making PowerSync compatible with frameworks like Nuxt and Vue.

**PowerSync**  

That’s great feedback. Anything else you think would help improve the developer experience?

**Timo**  

One thing that could be nice is having a third instance included in the Pro plan. I’m currently using one for local, and one for staging, and I’ll need one for production soon. I noticed you offer additional instances for $25, but having a full package with three would be useful for most developers. I also noticed you offer local hosting, which I haven’t set up yet, so that might solve this issue for me.

**PowerSync**  

Yes, you can run PowerSync (Open Edition) locally, which might meet your needs without extra costs.

**Timo**  

That sounds like it could work for me. I haven’t had time to dive into it yet, but it’s good to know.

**PowerSync**  

Thanks so much for your time, Timo. We appreciate the feedback.

**Timo**  

Glad to help. Keep up the great work!

---

# API Calling Is To Sync Engines As jQuery Is To React

> Moving from API calling to sync engines is a very similar shift as moving from jQuery to React was: by going from an imperative to a declarative system where much complexity is abstracted away, we can take away a world of pain.

- Published: 2024-11-01
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/api-calling-is-to-sync-engines-as-jquery-is-to-react

---

Last week, I visited San Francisco to meet up with [Johannes Schickling](https://www.schickling.dev/), co-founder of [Prisma](https://www.prisma.io/) and an advocate for local-first software who is behind projects such as the [localfirst.fm podcast](http://localfirst.fm) and [Local-First Conf](https://www.localfirstconf.com/), both of which we’ve sponsored.

Johannes and I share a belief that local-first (or [at the least](https://x.com/schickling/status/1851664271249145864), the use of sync engines) will eventually become the dominant way of building apps, because of its [benefits](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web) to end-users and developers alike. 

This led to an important question: _What_ will make the use of sync engines spread like wildfire and achieve mass adoption? Are there key factors that will cause it to accelerate, and what can we do to catalyze it?

Johannes remarked that when React came around in the mid-2010s, it was obvious to almost everyone that it was superior to the old way of building apps using jQuery (which was arguably the dominant front-end library at that time). As Johannes said, “It became clear that 99% of web use cases are well-served by the React model”.

What we are looking out for is sync engines achieving a similar breakthrough. At the moment, most of the available sync engines are still fairly immature, and there are difficulties with using them. But as the tools improve and achieve breakthroughs that strike the right chord with developers (in terms of mental model, capabilities, developer experience, and so on), it will be easier for developers to recommend sync engines more generally due to the obvious cost vs. benefit, and we believe adoption will take off. 

## From Imperative to Declarative: jQuery to React

The transition from jQuery to React as the dominant front-end JavaScript library is a very interesting analogy to think about: 

[_Imperatively_](https://en.wikipedia.org/wiki/Imperative_programming) manipulating the web page [DOM](https://en.wikipedia.org/wiki/Document_Object_Model) was central to using jQuery (step-by-step finding of elements, adding/removing classes, changing text content, showing/hiding elements, etc.).

Dynamically updating the page [^1] was amazing in the early days of interactive web apps, but as web apps became more sophisticated and complex, managing the state of the DOM in response to changes in app state (e.g. events) became unwieldy very quickly, and large apps became quite painful to develop and maintain. It was not uncommon to have lots of spaghetti code for updating the UI. In addition, the complexity of front-end performance optimization was left in the hands of the developer.

As a lot of developers experienced that pain, the benefit of React was obvious when it arrived on the scene in the mid-2010s and introduced a _declarative_ approach to building web UIs. With React, we describe what we want the UI to look like at any given point, and React takes care of updating the actual DOM to match that desired state. We write components that represent the UI at various states and let React manage how and when to update the DOM based on changes to component data (state and props). 

This solved several aspects of the pain of jQuery: The code is more modular (through the use of components), more predictable and easier to reason about (since React abstracts away direct manipulation of the DOM), and more performant (because of React’s approach of computing a virtual DOM and updating the actual DOM with only the delta between current and previous states). 

![](https://powersync.com/images/blog/api-calling-is-to-sync-engines-as-jquery-is-to-react-inline-a18a4ca098.png)

## From Imperative to Declarative: API Calling to Sync Engines

Web/cloud apps are fundamentally a distributed computing environment, where we have to constantly move data between servers and clients (state transfer). The vast majority of web and cloud-backed apps use some form of RPC-style APIs to transfer data. Even with all the advances over the last two decades, such as REST, [IDLs](https://en.wikipedia.org/wiki/Interface_description_language), GraphQL and RPC frameworks, moving data around using these various forms of API calling is still fundamentally _imperative_ , requiring developers to:

  * Control how and when APIs are called.
  * Handle error states and retries, especially due to network unreliability.
  * Implement caching and keep track of data freshness or staleness. (This is a slippery slope that quickly devolves to essentially [building a database](https://sqlsync.dev/posts/stop-building-databases/) in the front-end, especially if you layer in optimistic updates.)
  * Optimize various aspects of performance

Most application developers burn many hours on this sort of undifferentiated busywork, and there’s plenty of pain involved.

Moving from API calling to sync engines is a very similar shift as moving from jQuery to React was: by going from an imperative to a _declarative_ system where much complexity is abstracted away [^2], we can take away a world of pain.

[![](https://powersync.com/images/blog/api-calling-is-to-sync-engines-as-jquery-is-to-react-inline-6521e3e456.png)](https://x.com/schickling/status/1826338840153571362)

With the right sync engine, the developer can _declaratively_ define what data should be present on the client. The sync engine then automatically takes care of the complexities of partial replication of the data, including all the complexities of dealing with the network (streaming real-time updates [^3], error handling, retries, online vs. offline state, etc.), reconciling local updates with remote changes, conflict resolution (in many cases), optimizing syncing performance, and so on.

![](https://powersync.com/images/blog/api-calling-is-to-sync-engines-as-jquery-is-to-react-inline-feaec86c21.png)

A good sync engine will expose a local database like SQLite which enables the developer to deal with a real local database in the front-end — significantly reducing the complexity of working with data. The sync engine ensures the local database stays in sync with the backend database as needed, just as React ensures the UI/DOM stays in sync with the application state.

This is the future that we are trying to help usher in. Many developers who are already using sync engines today can attest to how much of a better experience this is.

[^1]: This was of course possible before jQuery, using standard JavaScript browser APIs. However, using those raw APIs was cumbersome by comparison to jQuery, due to browser inconsistencies and more verbose code.
[^2]: The key is abstracting away complexity (declarative systems do not always inherently reduce complexity compared to imperative systems). It’s clear that most major mainstream advancements in software development boil down to abstracting away complexity in some way. The move from raw JavaScript to jQuery itself abstracted away complexities around browser inconsistencies and introduced a functional programming style to simplify acting on DOM elements. The move from PHP spaghetti backends to Rails abstracted away several sources of complexity (routing, ORM, security, MVC pattern, etc.). The move from bare metal servers to cloud infrastructure abstracted away the complexity of managing individual pieces of hardware and their failures. And so on and so on.
[^3]: In this way, sync engines are a replacement not just for API calling, but also for real-time streaming tools. And similarly, sync engines can abstract away the complexities associated with real-time streaming (such as local persistence, offline mutations, and reconciling local state with remote updates).

---

# PowerSync Update: October 2024

> After seeing our user base double from July through September, momentum has continued with another record for new users in October. We’ve been hard at work shipping too, with multiple releases every week in October. Let’s look at the highlights in this blog post.

- Published: 2024-11-01
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-october-2024

---

After seeing our user base double from July through September, momentum has continued with another record for new users in October. To support this growth, we’ve created a new team of exceptional engineers focused on developer success, headed up by Mike Barnes. Last week, the team was joined by Hein von Stein — welcome Hein! We’ve been hard at work shipping too, with multiple releases every week in October. Let’s look at the highlights:

## MongoDB Now Supported In PowerSync Cloud

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-8f1fa156ae.png)

After initially releasing support for MongoDB to our self-hosted Open Edition, we’ve added the ability to connect PowerSync Cloud instances to MongoDB through the PowerSync Dashboard. PowerSync Cloud can connect to either MongoDB Atlas or self-hosted MongoDB environments. It’s an important milestone for our partnership with MongoDB, which was also announced in October.

The short turnaround of this release was made possible because of the new modular architecture of the PowerSync Service. 

[Read the blog post](https://powersync.com/blog/powersync-cloud-now-supports-mongodb-as-a-source-database)

## MySQL Now Supported As Source Database

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-fa9ac19abb.png)

The modular architecture of the PowerSync Service also paved the way for us to implement support for MySQL as a source database. Although recently less prominent than Postgres, MySQL is still a wildly popular database, and we’re excited about the increased flexibility this additional option will give developers.

MySQL support is in alpha and available in PowerSync Cloud as well as self-hosted PowerSync (Open Edition & Enterprise Self-Hosted Edition).

[Read the release notes](https://releases.powersync.com/announcements/announcing-mysql-as-a-source-database-alpha)

## A Gentler Introduction To Sync Rules

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-2a5890126e.png)

Dominic Bauer wrote a helpful introduction: _Sync Rules from First Principles: Partial Replication to SQLite_. This is a great starting point for understanding their purpose, structure and operation. Thanks Dom!

[Read the post](https://powersync.com/blog/sync-rules-from-first-principles-partial-replication-to-sqlite)

## Major Client-Side Performance Improvements

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-463c49c3de.png)

As part of a multi-month project to boost performance across our entire stack, we released version 0.3.0 of our `powersync-sqlite-core` extension, which addresses performance bottlenecks during incremental sync. 

Previously, incremental sync had overhead proportional to the number of synced rows, which typically caused noticeable latency when syncing around 10k-100k+ rows. Now, clients can effectively sync an "unlimited" number of rows without any overhead. Of course, the local storage used and the time for initial sync will still be proportional to the number of rows synced to the client.

This has been released to all client SDKs: upgrade to the latest version to receive this update.

[See the release message on the PowerSync Discord](https://discord.com/channels/1138230179878154300/1138520762618220635/1295404395491758161)

## New Docs Site Live

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-c15461ffc2.gif)

We know how important high-quality documentation is to overall developer experience, so we’ve been investing in upgrading our docs site. It recently went live and we think there’s a lot to love, including:

  * Tabs for easily navigating higher-level topics
  * Faster loading times 
  * Syntax highlighting is back!
  * Light/dark mode 
  * (Good) AI-enabled search
  * Better styling

[See new docs site](https://docs.powersync.com)

## Introducing Advanced Instance Monitoring And Alerting

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-85702359c9.png)

We announced major new monitoring and alerting features for PowerSync Cloud users:

Instance logs are now available for all plans, accessible in the PowerSync Dashboard header. 

Fully configurable issue and metric alerting is also available on the Team and Enterprise plans, and issue alerts for fatal issues will come to the Pro plan soon. Webhooks are currently available for wiring up alert notifications to external systems, while support for email alert notifications is planned.

[Read the release notes](https://releases.powersync.com/announcements/powersync-cloud-introducing-instance-monitoring-and-alerting)

## OP-SQLite Supported in React Native SDK, Enabling Client-Side Encryption

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-4fca63e0e8.png)

We’re excited to add OP-SQLite to our React Native SDK because it allows developers to set up encryption through SQLCipher.

We’re excited to announce support for OP-SQLite in our React Native SDK as an alternative to the `react-native-quick-sqlite` package. OP-SQLite has become our preferred SQLite library for React Native.

The support for OP-SQLite also allowed us to implement support for SQLCipher on React Native, enabling client-side database encryption. Support for SQLCipher in our Flutter/Dart client SDK is coming soon.

[See the package README to get started](https://github.com/powersync-ja/powersync-js/tree/main/packages/powersync-op-sqlite)

## Support for Suspense in React Client SDK

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-31d9078564.png)

We’ve added support for React Suspense which allows you to _suspend_ rendering parts of an app until a particular condition is met (such as waiting for data to load). 

Specifically, the `useSuspenseQuery` hook allows you to access the results of a watched query, but its loading and fetching states are handled through `` `<Suspense>` ``, which, for example, allows you to display a fallback until data has finished loading.

[See the React package README](https://github.com/powersync-ja/powersync-js/tree/main/packages/react)

## TanStack Query Integration Now Available (Alpha)

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-8fec59ee30.png)

In addition to supporting React Suspense, we also implemented an integration with TanStack Query, enabling developers to use its powerful asynchronous state management features for React and React Native, including query caching.

[Read the release notes](https://releases.powersync.com/announcements/powersync-web-sdk-tanstack-query-integration-alpha)

## Swift Package Manager Now Supported

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-21d957f507.png)

We’ve released a version of our `powersync-sqlite-core` package that’s compatible with Swift Package Manager (SPM), meaning Swift developers are no longer required to use the Cocoapods version and can remove that reference from their applications.

Include it in your Swift projects with this GitHub URL: 

https://github.com/powersync-ja/powersync-sqlite-core-swift

## Community Focus

![](https://powersync.com/images/blog/powersync-update-december-2024-inline-4905b2f26e.png)

High-fives to community members **Omnicpie   **and **LucDeCaf** who contributed with PRs this month. We had pull requests adding the ability to [set client parameters](https://github.com/powersync-ja/powersync-js/pull/357) to our diagnostics app and [updating the schema](https://github.com/powersync-ja/powersync-js/pull/328) generated by the diagnostics app to use the latest Schema and Table syntax. Both are super useful!

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-c25d2ba12d.png)

[Developer Case Study: Blueprint / Friend](https://powersync.com/blog/developer-case-study-kei-otani-blueprint-friend)

**Kei Otani** joined us to discuss his AI-enabled app for people in Japan who want to practice English.

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-a7f3da0307.png)

[Developer Case Study: Portable PPB](https://powersync.com/blog/developer-case-study-ben-clark-campbell-kilgour-portable-ppb)

**Ben Clark** and**Campbell Kilgour** joined us to discuss their infield gold detection app.

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-fd4d70aced.png)

[Developer Case Study: Octologs](https://powersync.com/blog/developer-case-study-ben-mahr-octologs)

**Ben Mahr** joined us to discuss his scuba diving experiences logging app, Octologs.

![](https://powersync.com/images/blog/powersync-update-october-2024-inline-ccd16f4bb3.png)

[Developer Case Study: Xiroi.cat](https://powersync.com/blog/developer-case-study-guillem-puche-xiroi-cat)

**Guillem Puche** joined us to discuss his app for saving and managing inspirational quotes.

That's it for the October update, happy coding!

---

# Sync Rules From First Principles: Partial Replication To SQLite

> The purpose of this blog post is to explain why you need PowerSync’s “Sync Rules”, what they are, and how they can be implemented.

- Published: 2024-10-30
- Author: Dominic Bauer
- Category: Engineering
- Source: https://powersync.com/blog/sync-rules-from-first-principles-partial-replication-to-sqlite

---

> **Warning**
>
> This post covers Sync Rules, which are now the legacy method for controlling which data syncs to which users. PowerSync now supports [Sync Streams](https://docs.powersync.com/sync/streams/overview) — the recommended way to control which data syncs to which users.

The purpose of this blog post is to explain why you need PowerSync’s “Sync Rules”, what they are, and how they can be implemented.

## Why Have Sync Rules?

In typical cloud-first apps, your backend database (like Postgres or MongoDB) holds all your data, which is made available to users via an API. This approach requires data to be _fetched_ by client apps through API calls. 

By contrast, a sync engine like PowerSync _syncs_ all data relevant to a specific user to a local database embedded in the client-side app, allowing queries to run locally on the user's device. Data is synced through the PowerSync Service, a backend service that client apps connect to (more info on this architecture [here](https://docs.powersync.com/architecture/architecture-overview)).

Users are typically only authorized to access certain data in the backend database, and on top of that, there is typically too much data to sync to every user’s device. Therefore, it’s necessary to control which data is synced to users. In PowerSync, **Sync Rules** provide a way to specify which data should be synced to which users.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-1251b03ef8.png "Sync Rules determine what is synced from your database to your users’ devices")

## Sync Buckets

PowerSync has a concept of [**Sync Buckets**](https://docs.powersync.com/usage/sync-rules/glossary#bucket-bucket-instance) (or simply "Buckets") to organize data synced to users’ devices. The reason that Sync Buckets exist is to allow sharing sets of data between users where applicable. This [allows for](https://powersync.com/blog/what-powersync-open-edition-means-for-local-first#dynamic-partial-replication-deduplicated-for-high-scalability) deduplication of work and high scalability. 

These Buckets contain rows of data synced from one or more tables in your backend database, based on the defined Sync Rules:

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-449f4f77ee.png "An example bucket with n rows of information based on the declared Sync Rules")

## How to Define Sync Rules  

Sync Rules are specified in a `yaml` file. They must start with `bucket_definitions` and follow this structure:

```yaml
# sync-rules.yaml
bucket_definitions:
  bucket_name: # name of the buckets e.g. user_lists
    parameters: # (optional) query used to determine which buckets are synced 
    data: # query used to determine the data in each bucket
```
## How Sync Rules Work: An Example

Note: This example uses the terms “tables" and "rows” and assumes a SQL backend database. However, the same ideas can be applied to collections and documents in a NoSQL context.  

Let’s illustrate how to define Sync Rules with an example:

  1. **Data Setup** : Assume there is a `lists` table with three columns: `id`, `owner_id`, and `name`, containing seven rows.
  2. **User Ownership** : `user1` owns all lists with **odd** IDs, while `user2` owns all lists with **even** IDs.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-f21d0a5814.png "lists table that will be used in the proceeding examples")

### Types of Queries

You can use two types of queries in your Sync Rules when defining Buckets:  

  1. **Data queries —** define the content of a bucket
  2. **Parameter queries —** define which buckets to sync  

These queries are written with a SQL-like syntax (regardless of whether a SQL or NoSQL backend database is used with PowerSync). Note that not all SQL operators and functions are supported in PowerSync’s SQL-like query syntax — refer to limitations [here](https://docs.powersync.com/usage/sync-rules/operators-and-functions).  

### Data Queries

Data queries specify what data is included in a Bucket. In the below example, the data query is `SELECT * FROM lists` and is the only query used. This creates a Bucket of the lists that will sync to every single user. We refer to buckets that sync to all users as “global buckets”. In this example, all 7 rows are added to the global bucket and will be synced to all users.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-2e751b2ee4.png "Global bucket of lists based on the data query")

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-fd1ea60fec.png "Shows how each user’s device will have the all of the lists synced to it")

In the Sync Rules **YAML** file**:**

```yaml
# sync-rules.yaml
bucket_definitions:
  lists:
    data:
      - SELECT * FROM lists
```

### Parameter Queries

Parameter queries determine which Buckets should be synced to the user’s device. In the below example, the parameter query is `SELECT request.user_id() AS id`. The `request` variable provides access to the contents of the [JWT token](https://docs.powersync.com/usage/sync-rules/glossary#token-parameters) sent when making a request to the PowerSync Service. It contains a **user_id**(the "subject" from the JWT token) which is used to determine which buckets are synced to which device. 

Consider our example `lists` table with the 7 rows belonging to **user1** and **user2**. Given this parameter query and the sample data, 2 buckets would end up existing — one for **user1** and **user2**. 

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-55ac562814.png "Parameter query based on the `user_id` results in one bucket existing per `user_id`")

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-883c89161b.png "Each user syncs only the relevant buckets based on the parameter query.")

This is what our Sync Rules **YAML** file would look like after defining the parameter query in our example**.** We name our bucket `user_lists`:

```yaml
# sync-rules.yaml

bucket_definitions:
  user_lists:
    parameters: SELECT request.user_id() AS id
```

### Adding the Data Query

Now let's add the data query that defines what data is contained within the `user_lists` buckets:  

  * **Parameter query** : `SELECT request.user_id() AS id`
  * **Data query** : `SELECT * FROM lists WHERE owner_id = bucket.id`  

As explained above, these Sync Rules will result in 2 Buckets being created given the sample data: one for `user1` containing only their lists, and another for `user2` with only their lists. Each user will only see a single Bucket synced to their device.  

**Note that the parameter `id` is used in the data query as `bucket.id`. Every bucket parameter must be used in every data query.** This is a requirement inherent to the architecture of the Bucket system related to high performance.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-52d354c40a.png "Sync Rules using a parameter query and data query to only sync lists owned by a specific user")

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-165a07e0a1.png)

This is what our resulting Sync Rules **YAML** file now looks like**:**

```yaml
# sync-rules.yaml

bucket_definitions:
  user_lists:
    parameters: SELECT request.user_id() AS id
    data:
      - SELECT * FROM lists WHERE owner_id = bucket.id
```

### Join Tables

Two new tables, `todos` and `user_lists`, are introduced to explain how join operations work in PowerSync.  

**Todos:**  

  1. **Data Setup** : Assume there is a `todos` table with three columns: `id`, `list_id`, and `description`, containing seven rows.
  2. **Ownership** :  `list` with ID `1` owns all todos with **odd** IDs, while `list` with ID `2` owns all todos with **even** IDs.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-dbc03ac820.png "todos table where a todo belongs to a list")

**User Lists:**  

  1. **Data Setup** : Assume there is a `user_lists` table with three columns: `id`, `list_id`, and `user_id`, containing seven rows.
  2. **Ownership** :  Each `list_id` is matched to the `user_id` that owns the list.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-5592358aad.png "Join table that matches a list_id to a user_id")

  * **Parameter query** : `SELECT list_id FROM user_lists WHERE user_lists.user_id = request.user_id()`
  * **Data query** :
    * `SELECT * FROM lists WHERE id = bucket.list_id`
    * `SELECT * FROM todos WHERE list_id = bucket.list_id`

  
These Sync Rules generate a Bucket for each list. The bucket for `list_id=1` will include the `list` row and its four odd-numbered `todos` rows, while the bucket for `list_id=2` will include the `list` row and its three even-numbered `todos` rows. Buckets for the lists with IDs `3-7` will contain only the `list` row.

![](https://powersync.com/images/blog/sync-rules-from-first-principles-partial-replication-to-sqlite-inline-d801c72f88.png "Sync Rules showing how a join would work and the buckets that would be produced")

## Further Reading

More detailed information can be found in the [Sync Rules](https://docs.powersync.com/usage/sync-rules) section of our documentation.  

Note that there are additional possibilities around parameter queries regarding:  

  * [Using multiple bucket parameters](https://docs.powersync.com/usage/sync-rules/parameter-queries#multiple-bucket-parameters)
  * [Using multiple parameter queries](https://docs.powersync.com/usage/sync-rules/parameter-queries#using-multiple-parameter-queries)  

For details on handling more complex scenarios, see here:  

  * [Many to many relations and join tables](https://docs.powersync.com/usage/sync-rules/guide-many-to-many-and-join-tables)
  * [Passing parameters directly from the client](https://docs.powersync.com/usage/sync-rules/advanced-topics/client-parameters) (instead of via the JWT)

---

# Developer Case Study: Guillem Puche / Xiroi.cat

> We were joined by Guillem Puche to chat about his app for saving inspirational quotes. We spoke about what he sees as the benefits of local-first, why he decided to use PowerSync, and the future he sees for his app.

- Published: 2024-10-23
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-guillem-puche-xiroi-cat

---

## Background

We were joined by Guillem Puche to chat about his app for saving inspirational quotes. We spoke about what he sees as the benefits of local-first, why he decided to use PowerSync, and the future he sees for his app.

### TL;DR

  * Guillem is developing an app using React and React Native that stores personal quotes. He plans to launch soon.
  * Local-first was attractive because of the instantaneous user experience it enables.
  * After exploring alternatives like ElectricSQL and Replicache, Guillem chose PowerSync for its ease of setup, modular architecture, and flexibility. He also trusts the experienced team behind it.

### App details

| App name | Xiroi.cat |
| --- | --- |
| Platform(s) | Mobile and web |
| App framework | React and React Native |
| Backend API | NodeJS with Effect |
| Backend database | Supabase (Postgres) |
  
## Interview

**PowerSync**  
Thank you for taking the time to chat with us, Guillem. To start, could you tell us a little about yourself, what you're currently working on, and how you're using PowerSync?

**Guillem**  
I'm developing a mobile app in TypeScript for React and React Native. It's an app for personal quotes, like those from books, movies, or podcasts. The goal is to make it a consumer app. I aim to bootstrap everything myself. My plan is to launch the mobile app soon and then work on an e-commerce site later this year.

**PowerSync**  
That sounds exciting! Could you explain how the e-commerce aspect of your app will work?

**Guillem**  
The idea is to allow users to create personal collections of quotes. Initially, these will be private, but eventually, I'd like to build a community where users can share quotes and even create articles about the context and philosophy behind them. The e-commerce side will involve selling physical products like stickers with quotes, and maybe in the future, clothing. For now, I'm focusing on smaller, more sustainable products like stickers. Later on, I might expand into clothing.

The sticker editor will be AI-powered, where you’ll personalize your own stickers. The cool part? PowerSync stores all your previous sticker designs and even your order history locally, so you’ll always have everything right there, no matter your connection.

**PowerSync**  
When it comes to implementing a local-first or offline-first architecture, what motivated you to choose that?

**Guillem**  
For me, it’s all about the user experience. I want the app to feel like a notes app — something fast and responsive. Users should be able to save quotes even if they’re offline, like when reading a book on a train with no network. It has to be instantaneous, with no delays. Collaboration is also important because I want to eventually allow people to share collections of quotes with others.

**PowerSync**  
What alternatives did you consider before choosing PowerSync?

**Guillem**  
I looked at ElectricSQL, but I found it too tightly coupled. It was also quite difficult to set up. Another option was Replicache, but they were too expensive for my needs, especially considering my app will have a free tier. What stood out to me about PowerSync is that it integrates in a plug-and-play way with Postgres and lets the developer decide how conflict resolution should work.

**PowerSync**  
It sounds like you liked the flexibility that PowerSync offers. Was there anything specific about the way it works with backend databases that made it stand out for you?

**Guillem**  
Yes, I liked that PowerSync doesn’t take over the database. 

**PowerSync**  
What would you say is the most valuable thing about PowerSync for you? If you had to rank your reasons for choosing it, what would be number one?

**Guillem**  
Honestly, it’s the team behind PowerSync. I read about the history of JourneyApps and your experience with enterprise data sync use cases. Knowing there's a solid team with a track record gives me confidence. The modular architecture and your responsiveness in the community are also big pluses.

Also, you're able to improve the small details of your libraries that the community brings up. I feel a constant improvement of PowerSync.

**PowerSync**  
That’s great to hear. We’ve put a lot of effort into making PowerSync flexible and developer-friendly. It's good to know that our approach is working for you. Do you have any thoughts on how PowerSync could improve, or features you'd like to see?

**Guillem**  
You’re already growing a strong community, and it'll naturally improve as more people use the technology. My only suggestion is to keep up the fast support and community involvement. It makes a difference when you're a solo developer trying to build something independently.

**PowerSync**  
Thanks for the feedback. One more question: We're excited about local-first architecture due to its benefits for users (such as speed, offline access, and data ownership) and developers (such as simplified state management). We believe it will become the dominant app architecture, but its adoption depends on the availability of great developer tools. Our goal is to make local-first easier to adopt than cloud-first architecture. Given this, do you have any ideas or suggestions on where we should focus?

**Guillem**  
Sure, happy to help. One thing is collaborating with micro-influencers and developers who want to build something innovative. They often start from scratch and push the latest trends. I think focusing on people who influence developer communities will help your success.

**PowerSync**  
That’s great feedback. Thank you!

**Guillem**  
Happy to help! I’ll also promote PowerSync as my project grows.

---

# PowerSync Cloud Now Supports MongoDB As A Source Database

> This release provides a self-serve option for MongoDB users to deploy PowerSync as a sync engine for bidirectionally syncing data between MongoDB on the backend, and a local database on client devices. This is a crucial migration path for customers on Atlas Device Sync who need a MongoDB native solution to the end of life challenge. It also enables MongoDB customers to participate in the growing local-first movement that has significant developer productivity benefits.

- Published: 2024-10-17
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/powersync-cloud-now-supports-mongodb-as-a-source-database

---

This release provides a self-serve option for MongoDB users to deploy PowerSync as a sync engine for bidirectionally syncing data between MongoDB on the backend, and a local database on client devices. This is a crucial migration path for customers on Atlas Device Sync who need a MongoDB native solution to the end of life challenge. It also enables MongoDB customers to participate in the growing [local-first](https://evilmartians.com/chronicles/a-letter-to-founders-join-the-local-first-movement) movement that has significant developer productivity benefits.

We’ve worked hard towards this release and it is a key milestone for our partnership with MongoDB, [announced this week](https://venturebeat.com/business/powersync-partners-with-mongodb-to-offer-enterprise-grade-sync-engine/).

## How it works

PowerSync Cloud can connect to either MongoDB Atlas or self-hosted MongoDB environments, providing full deployment flexibility. Additionally, the PowerSync Service itself can also be [self-hosted](https://github.com/powersync-ja/powersync-service) for customers with stringent cloud sovereignty requirements.

The PowerSync Service has a modular architecture which is what enables a pluggable backend database which gives users maximum forward looking optionality. MongoDB replication uses Change Streams under the hood to replicate state to the client in real time.

All of the PowerSync Service source code is freely available under a source-available [license](https://github.com/powersync-ja/powersync-service/blob/main/LICENSE) ensuring business continuity for years to come.

## How to use it

Sign up for an account on powersync.com if you haven’t already. When creating a new PowerSync instance, you’ll be prompted to select a database type - select MongoDB.

![](https://powersync.com/images/blog/powersync-cloud-now-supports-mongodb-as-a-source-database-inline-c7e6192b0b.png)

After selecting MongoDB, enter your database URI, database name, username and password (see [documentation](https://docs.powersync.com/usage/installation/database-connection#mongodb-alpha-specifics) for details):

![](https://powersync.com/images/blog/powersync-cloud-now-supports-mongodb-as-a-source-database-inline-399f478d6f.png)

Hit “**Test connection** ” and if you have any issues connecting, reach out to our support engineers on our [Discord server](https://discord.gg/powersync).

---

# Developer Case Study: Ben Mahr / Octologs

> We were joined by Ben Mahr to dive into Octologs, his scuba diving experiences logging app. We spoke about what he sees as the benefits of local-first, the importance of offline capability and data security, and why he decided to use PowerSync.

- Published: 2024-10-15
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-ben-mahr-octologs

---

## Background

We were joined by Ben Mahr to dive into [Octologs](https://octologs.com/), his scuba diving experiences logging app. We spoke about what he sees as the benefits of local-first, the importance of offline capability and data security, and why he decided to use PowerSync.

### TL;DR

  * Ben chose offline-first architecture because his diving log app’s users often lack internet access in remote locations.
  * Local-first architecture was appealing due to user concerns about data privacy and storage, particularly in Europe.
  * PowerSync was the only solution that met both technical and user needs, offering ease of implementation and strong support.
  * Ben values PowerSync’s reliability, as it runs smoothly without crashes or issues.
  * Ben highlighted challenges with local database debugging, but PowerSync’s new diagnostics app and CLI help to address those concerns.

### App details

| App name | [Octologs](https://octologs.com/) |
| --- | --- |
| Platform(s) | Mobile (iOS and Android) |
| App framework | Flutter |
| Backend API | Supabase (PostgREST) |
| Backend database | Supabase (Postgres) |
  

![](https://powersync.com/images/blog/developer-case-study-ben-mahr-octologs-inline-e0172c98a7.png)

## Interview

**PowerSync**  
First question — why did you want to implement an offline-first or local-first architecture? You’ve mentioned using Supabase, and that they don’t have offline mode. What other factors, like speed or latency, played into this decision?

**Ben**  
Honestly, it was purely about offline capability. For a diving log app, users are often on boats or in remote locations without internet. If it weren't for that, I wouldn't have bothered with offline mode at all.

**PowerSync**  
That makes sense. Offline-first architecture has been gaining traction, but local-first is also emerging as important, especially for data ownership and protection. Was the appeal of local-first a factor for you at all?

**Ben**  
Yes, particularly in Europe, where data protection is a big deal. Some users don’t like their data being stored on any server, even if it's in Europe. So, I’ve considered a pure offline mode version.

**PowerSync**  
What options did you evaluate before settling on PowerSync? You mentioned previously looking into some solutions in a Supabase GitHub [thread](https://github.com/orgs/supabase/discussions/357).

**Ben**  
Yeah, I looked into a few but didn’t dig deep. PowerSync was the only one that fit my needs from both a technical and user perspective. The others seemed like too much work or didn't align well with what I needed.

**PowerSync**  
When you say it fit your needs, are you referring to the ease of implementation?

**Ben**  
Exactly. PowerSync had a company behind it, which meant I could get support. With other solutions, I would have been relying on online forums, and I didn’t want that.

**PowerSync**  
From your experience so far, what stands out as the most valuable aspect of PowerSync?

**Ben**  
Since launching Octologs with PowerSync in production, I don’t have to think about it. It just works, stays in the background, and gives me no issues.

**PowerSync**  
So, stability and low maintenance are key for you?

**Ben**  
Exactly. No crashes or weird error logs popping up — just smooth functionality.

**PowerSync**  
Last question: Our vision is to make local-first and offline-first architectures easier to implement than cloud-first. Do you have any suggestions to help us achieve that?

**Ben**  
Debugging the local database was tricky for me at first, especially on a Mac. There’s no straightforward way to inspect the local database. That’s an area where better documentation or tools would help.

**PowerSync**  
We’ve since introduced a [diagnostics app](https://docs.powersync.com/resources/troubleshooting#diagnostics-app). It helps you view what’s being synced in real time. Have you heard of it?

**Ben**  
No, I’ll have to check it out.

**PowerSync**  
You also mentioned in the past that you wanted a local CLI for PowerSync. We’ve released that, as well as a self-hosted Open Edition.

**Ben**  
Yes, that was my main request. Developing on a staging or production server was a big issue for me. Glad to see the CLI is now available.

**PowerSync**  
Are you planning to try it out soon?

**Ben**  
Definitely. I’ll give it a shot before I have to, just to be prepared.

**PowerSync**  
That’s all from us. Any other feedback or questions?

**Ben**  
Just want to shout out the support, especially from your team on Discord. It was really helpful.

**PowerSync**  
Thanks, Ben! We appreciate your feedback and support.

**Ben**  
Thank you. Have a great weekend!

---

# Developer Case Study: Ben Clark & Campbell Kilgour / Portable PPB

> Ben Clark and Campbell Kilgour from Portable PPB joined us to discuss their app for infield gold detection in the mining industry. We covered their stack, what they see as the benefits of local-first architecture and why they decided to use PowerSync.

- Published: 2024-10-07
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-ben-clark-campbell-kilgour-portable-ppb

---

## Background

Ben Clark and Campbell Kilgour from [Portable PPB](https://portableppb.com/) joined us to discuss their app for infield gold detection in the mining industry. We covered their stack, what they see as the benefits of local-first architecture and why they decided to use PowerSync.

### App details

| App name | [Portable PPB ](https://portableppb.com/) |
| --- | --- |
| Platform(s) | Mobile, Web, Windows |
| App framework | Flutter |
| Backend API | Supabase (PostgREST) |
| Backend database | Supabase (Postgres) |
  

## Interview

**PowerSync**

Could you tell us a bit more about what you’re building?

**Portable PPB**

Our main product is a gold detection system for mining and exploration. We've built a beta version over the last two and a half years, but we’re now rebuilding it to be more robust. 

**PowerSync**

What stack are you using for the rebuild?

**Portable PPB**

Our new stack will be based on Supabase, Flutter, and PowerSync.

**PowerSync**  

With the legacy version, did you build your own offline functionality?

**Portable PPB**  

Not really. It’s essentially just an XML file loaded into memory and saved back. It’s a simple and temperamental system prone to corruption if something crashes. We definitely needed a more reliable solution.

**PowerSync**  

So you’re moving to a proper local-first architecture with a local database? Was the main reason for that to support customers in remote areas with poor internet connectivity, or were there any other benefits that you're also hoping to get from a real local-first architecture?

**Portable PPB**  

There are a few different reasons beyond just the scarcity of internet connection. We operate in over 30 countries, some with unstable internet and power. Starlink is helping, but it’s not fully reliable yet. Another reason is to have a local backup of sensitive data. In case our servers go down, customers still have a local copy.

**PowerSync**  

Will this be deployed on phones, tablets, or computers?

**Portable PPB**  

We’re targeting Android, Windows, and web platforms, with potential future support for iOS and Linux.

**PowerSync**

For the web platform, will it be built with Flutter Web?

**Portable PPB**  

Yes, we’re using Flutter for everything. As a small team, we need the efficiency of a single codebase that works across platforms.

**PowerSync**  

We’ve seen developers use local-first architecture not just for offline mode but also for faster performance. Was speed also a consideration for you?

**Portable PPB**  

Speed was a secondary factor.

**PowerSync**  

What options did you evaluate for implementing local-first before choosing PowerSync?

**Portable PPB**

An important consideration for us is that we wanted to use Flutter, which is similar to C#, our primary development language. We considered Firebase but found Supabase better in terms of cost and features. We prefer open-source solutions, so Supabase was a better fit. With this locked in, we looked for offline-first solutions that work well with Supabase and Flutter. PowerSync was the only tool we found that provided an out-of-the-box solution, which was vital for our small team.

Also, a deciding factor for us at the time was the speed of development. We’re on a tight timeline, so the faster we can build, the better. 

**PowerSync**  

You mentioned that PowerSync being loosely coupled to Postgres was valuable to you. Can you elaborate?

**Portable PPB**  

As a small team, we prioritize flexibility. With Postgres, we could swap out Supabase for a different hosted Postgres database if needed. Personally, I like minimizing lock-in, as it allows for better adaptability, especially if the company evolves or gets acquired.

**PowerSync**  

What do you think is the most valuable aspect of PowerSync?

**Portable PPB**  

The simplicity of setup and great documentation. I had the system running and connected to Supabase in one afternoon, which is rare for other tools. We weren’t looking for the best option, just one that worked quickly, and yours fit the bill.

**PowerSync**  

So, ease of onboarding was key?

**Portable PPB**  

Yes, and your support team’s responsiveness has also been a big plus.

**PowerSync**  

Great feedback, thanks. Our vision is to make local-first app architecture as easy to implement as traditional cloud-first approaches. We believe local-first will then be the preferred choice for developers due to its advantages, such as speed and resilience against network issues. Given this goal, do you have any suggestions or recommendations on what we should focus on or improve?

**Portable PPB**  

Two things: First, your local development system is great, but we’re missing a CLI that works with the local environment to automate our CI/CD pipeline. That is a missing puzzle piece for us at the moment. 

Second, Sync Rules are quite limited. We can't join tables, which forces us to denormalize data, and our data is highly relational.

**PowerSync**  

Thanks for the feedback. We’re working on improving the flexibility of sync rules without impacting performance. Thanks for your time! 

**Portable PPB**

Thanks, it's been great working with you guys!

---

# PowerSync Update: September 2024

> We're excited to share that September saw our highest-ever number of new users sign up for PowerSync! We’re proud to be accelerating the adoption of local-first software, which we believe is fundamentally changing apps for the better. Here are some more highlights from the last month.

- Published: 2024-10-03
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-september-2024

---

We're excited to share that September saw our highest-ever number of new users sign up for PowerSync! We’re proud to be accelerating the adoption of local-first software, which we believe is fundamentally changing apps for the better. Here are some more highlights from the last month:

## MongoDB Now Supported As Source Database

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-ed250113e7.png)

In September, MongoDB announced that **Atlas Device Sync** and related services would be deprecated. Almost immediately, we heard from users who wanted to know if migrating to PowerSync was an option. While some were fine with moving their source database to Postgres, many wanted to keep their existing MongoDB backend database in place.

Thanks to PowerSync’s modular architecture and our decade-plus experience working with MongoDB, we managed to ship a MongoDB module a few days after the announcement. The module (currently in alpha) allows the PowerSync Service to connect to MongoDB as a source database, and is a step towards our vision of being a stack-agnostic sync engine.

[See the MongoDB Atlas Device Sync Migration Guide](https://docs.powersync.com/resources/migration-guides/mongodb-atlas)

## React Native Web Support Released

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-08d4d9ed69.png)

React Native users can now use React Native Web for a unified codebase across mobile and web. Introduced in version 1.8.0 of our JS/web client SDK and version 1.12.1 of our RN client SDK.

[See the demo app](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-native-web-supabase-todolist)

## Swift Client SDK In Open Alpha

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-272eab8032.png)

We’ve moved from a private to open alpha with the latest release of our Swift client SDK, meaning it can be used to validate whether PowerSync is a good fit for your project. We used SKIE for the alpha but we’ve decided to rebuild this SDK in native Swift as we move closer to our V1 release, so therefore we do not recommend production use at this time.

[Read the docs](https://docs.powersync.com/client-sdk-references/swift)

## KMP Client SDK Now In Beta

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-dc57bf9d8d.png)

The beta release of our Kotlin Multiplatform SDK means that it is now considered suitable for production use, if you've tested your use cases. The release includes various improvements, many of which stemmed from suggestions and contributions from the PowerSync community.

[Read the release notes](https://releases.powersync.com/announcements/the-powersync-kotlin-multiplatform-client-sdk-is-in-beta)

## PowerSync Cloud Team Plan Launched

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-255f262560.png)

We introduced the Team subscription plan for developer teams working on projects that require advanced features and support guarantees, but who prefer a self-service option rather than negotiating a custom Enterprise plan.

The Team plan is a usage-based plan and, like all our plans, is applied on an organization level, meaning that plan features are enabled for all projects within an organization.

[Read the announcement post](https://powersync.com/blog/introducing-the-powersync-cloud-team-plan)

## [New Demo Apps] Optional Sync / Starting Local-Only

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-5f34ab254b.png)

Allowing users to access app features without having to sign up for an account is an increasingly common design pattern. It’s compelling because it makes it as easy as possible for users to adopt an app, while respecting user data privacy and setting up an upgrade path for users who want to sync data with the cloud.

This new example implementation uses local-only tables to persist data before a user is registered / signed in, and optionally syncs this data with the backend at a later stage.

  * [Dart/Flutter demo](https://github.com/powersync-ja/powersync.dart/tree/main/demos/supabase-todolist-optional-sync)
  * [React demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-todolist-optional-sync)

## CLI Improvements With V0.6.0

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-3a3e80e122.png)

We shipped several improvements to the PowerSync CLI, many of which are intended to better support automation and CI/CD workflows. Here are two examples:

  * **IMPROVED** : Interactive commands are now also available as flags, e.g. `instance create -n postgres -p your-password -u postgres -h your-hostname`
  * **ADDED** : Ability to generate developer tokens from the CLI: `instance generate-dev-token -u my-user-id -e 43200`

[Read the release notes](https://releases.powersync.com/announcements/powersync-cli-beta-v0-6-0)

## [New Demo App] Native Android Kotlin

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-8b5a281361.png)

This demo app shows how our Kotlin Multiplatform client SDK's Android package can be used in a native Android Kotlin project.

Thanks to **@joseph** for spurring us on!

[See the demo app](https://github.com/powersync-ja/powersync-kotlin/blob/main/demos/android-supabase-todolist/README.md)

## [New Tutorial] PowerSync and Supabase: Just the Basics

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-e72629d520.png)

This video covers 7 distinct developer benefits of local-first development.This new no-frills tutorial is pure HTML, CSS and JS and is a contribution from community member **Zane Thomas** who writes:

> “...I wanted to get started with the web SDK in an empty scaffold and build up from there. This post will take you step-by-step through what I learned about how to set up and use PowerSync together with Supabase.”

H/T **@michael** who helped us understand the need for this.

[See the tutorial](https://powersync.com/blog/powersync-and-supabase-just-the-basics)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-42ee0f67ce.png)

High-fives to community members **Dieter_be** , **MrLightful** and **HeinrichvonStein** for their contributions this month. We had pull requests for [adding polish on our Django To-Do list app](https://github.com/powersync-ja/powersync.dart/pull/162), [a small fix on our Yjs demo](https://github.com/powersync-ja/powersync-js/pull/305), and a [bundling fix on our React Native To-Do list app](https://github.com/powersync-ja/powersync-js/pull/321).

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-f76b68465b.png)

[Developer Case Study: Krooka](https://powersync.com/blog/developer-case-study-patrik-wassberg-krooka-fishing)

**Patrik Wassberg** joined us to discuss his app for managing fishing competitions.

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-73c0817c07.png)

[Developer Case Study: WorkWeek](https://powersync.com/blog/developer-case-study-tristan-drummond-gideon-boshoff-workweek)

**Tristan Drummond** and **Gideon Boshoff** joined us to discuss their time tracking app, WorkWeek.

![](https://powersync.com/images/blog/powersync-update-september-2024-inline-eb15457f2a.png)

[Developer Case Study: PrayerMate](https://powersync.com/blog/developer-case-study-andy-geers-prayermate)

**Andy Geers** joined us to discuss his prayer organizing app, PrayerMate.

That's it for the September update, happy coding!

---

# Developer Case Study: Kei Otani / Blueprint "Friend"

> We were joined by Kei Otani from Blueprint to talk about the chat app he is building which is currently focused on users in Japan, with plans to expand to an international user base. We spoke to Kei about why he decided to follow a local-first approach, the stack he is using to build the solution, and what his experience has been like using PowerSync.

- Published: 2024-10-01
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-kei-otani-blueprint-friend

---

## Background

We were joined by Kei Otani from Blueprint to talk about the chat app he is building which is currently focused on users in Japan, with plans to expand to an international user base. We spoke to Kei about why he decided to follow a local-first approach, the stack he is using to build the solution, and what his experience has been like using PowerSync.

### App details

| App name | "Friend"* |
| --- | --- |
| Platform(s) | Mobile |
| App framework | Expo (React Native) |
| Backend API | Supabase (PostgREST) |
| Backend database | Supabase (Postgres) |
  
* _This app name is provisional and hasn’t been finalized yet._

## Interview

**PowerSync**

Kei, thank you for joining us today. Could you start by telling us a little bit about what you're building and the technology stack you're using?

**Kei**

Sure! Right now, I’m working on a chat application using Expo, with Supabase as the backend and edge function provider. I’m also incorporating offline-first capabilities using PowerSync, which is why we’re here today. The app is designed for people in Japan, enabling them to chat with AI or real people to practice English. It’s a text-based app, but I’m also trying to integrate real-time chat functionalities, ensuring the messages are transcribed and stored in the database.

**PowerSync**

Great, so with that context, our first question is what is the reason why you wanted to implement a local-first or offline-first architecture?

**Kei**

In today's world, users expect apps to work seamlessly, even with poor or no network connectivity. For instance, if a user is on a flight and wants to check their chat history or type a message, they expect the app to function. It’s become almost a standard for consumer apps to have offline capabilities. Without this feature, users experience frustration. So, ensuring the app works offline provides a much smoother user experience, and it is now less of a new feature and more the standard.

**PowerSync**

Absolutely, especially for chat apps. People are used to apps like WhatsApp that let them view messages offline. We've also seen that there is more interest from a broader set of developers in local-first architecture as a way of making the UI much faster because when you're querying from a local database — you basically have near-zero latency for queries. Was this also a factor for you in deciding to implement offline-first capabilities?

**Kei**

Yes, definitely. Users today expect instant responses. If an app lags, especially compared to mainstream apps, users will notice. While offline functionality is crucial, speed is equally important. PowerSync has simplified the implementation of both, allowing for fast response times without sacrificing reliability.

**PowerSync**

In addition to speed and offline capabilities, real-time collaboration is also a major advantage of using sync engines. How important are these features for your app, and how would you rank their importance?

**Kei**

Real-time syncing is essential for a chat app. Users want their messages to appear instantly, even with network interruptions. If I had to rank these features, I’d say offline functionality is the top priority, followed by speed and real-time updates.

**PowerSync**

Before choosing PowerSync, did you evaluate other options for implementing offline-first capabilities?

**Kei**

Yes, I looked into WatermelonDB, which also works with Supabase. However, one of the deciding factors for me was that PowerSync had a working example with React Native, which saved me a lot of time. Watermelon's documentation wasn’t as comprehensive, and the demos provided by PowerSync helped me accelerate the implementation.

**PowerSync**

Why did you start using PowerSync? And, once you started using PowerSync, what stood out to you as the most valuable aspect?

**Kei**

The system’s reliability and scalability were key for me. It worked consistently, which gave me confidence that it would perform well in a production environment. I was initially concerned about how PowerSync would handle scaling with a large number of users and messages, but the team assured me that it’s possible to scale up by using multiple database instances. So, it has a clear path for growth, which is reassuring.

**PowerSync**

Okay. So reliability, scalability, and stability were the main aspects of the value you see in PowerSync?

**Kei**

Yes, exactly. What I also found particularly valuable about PowerSync was its Sync Rules system. It goes beyond just syncing tables and records from Supabase; it allows for user permissions and data modifications in real-time. Although it took some time to understand, the system offered customization options that wouldn’t be possible with a direct connection, making it a powerful feature for my app.

**PowerSync**

That’s good to know. Have you had a chance to compare PowerSync’s Sync Rules with other products or frameworks, like WatermelonDB?

**Kei**  

I didn’t get too far with WatermelonDB, so I can’t compare them. The only other thing I’ve looked at is Supabase's native real-time engine, which they’re developing now. However, it doesn’t offer local database synchronization with React Native, so it’s not quite the same. I do appreciate that it looks like you have a good relationship with Supabase, and I hope that stays that way!

**PowerSync**

Could we dive a bit deeper into your experience with the learning curve of Sync Rules? What was that process like for you, and what resources did you find most helpful as you were learning?

**Kei**

That’s a great question. Initially, it was a bit tricky to understand why different buckets were needed, but once I realized it was due to the need for additional parameters beyond just user IDs, it started to make sense. One challenge I faced was dealing with arrays — the rules for parameters and data differed slightly, and I had to figure out how to compare values within arrays.

Another learning curve was figuring out how to work with JSONB data types. At first, I wasn’t sure if I could use arrays with JSONB in Supabase, but thankfully, it worked. These were small details, but they took some time to sort out.

One major point I missed in the documentation was that all the IDs had to follow a specific [format](https://docs.powersync.com/usage/sync-rules/client-id). Once I understood that, things started falling into place.

**PowerSync**

Is there anything we can do to support you? Is your app in production yet, or where are you in the development lifecycle?

**Kei**

Right now, we’re still in the development phase, working on the audio functionality, which is taking a bit longer than expected. We’re aiming to release it by the end of the year. I’m also really grateful for your pricing model, as it gives us flexibility with the number of synchronizations per month that I’ll be able to use, which is super helpful as we continue building and testing.

**PowerSync**

Our goal with PowerSync is to make local-first or offline-first architecture so easy to implement that developers choose it as the default approach, rather than the typical cloud-first model. This shift has huge benefits, like simplifying state management, reducing backend complexity, and improving app speed and network resilience. With that in mind, are there any improvements or features you’d like to see in PowerSync to help us reach that vision?

**Kei**

One thing that could improve the product is better support for real-time updates with JSON fields. Right now, since JSON is treated as a text string, it doesn’t automatically update. We solved it by using a naming convention, but it would be nice if that functionality was included out of the box. I’m sure you could come up with an even more elegant solution.

Another area that could use improvement is the clarity around the differences between HTTP streaming and WebSockets, especially in terms of benchmarking. Some projects on GitHub use WebSockets while others don’t, and it’s not always clear which is better or faster.

Additionally, more detailed scalability information would be helpful. I reached out to support and learned about using multiple database instances for larger apps, but it would be great to know when to switch to a multi-instance setup and what the cost implications might be.

Lastly, I think there’s some hesitation around self-hosting versus using your cloud solution. Providing clearer communication and support around the benefits of your cloud-hosted option could encourage more developers to stay on the cloud platform instead of self-hosting.

**PowerSync**

Those are all great points, and they make a lot of sense. We’re already working on publishing scalability benchmarks, which should give more clarity on PowerSync’s performance and how it scales. Comparisons with other products are also on our radar, so we hope to have more information on that in the future. Thank you for the feedback!

**Kei**

Of course, happy to help and looking forward to continuing working with you guys.

![](https://powersync.com/images/blog/developer-case-study-kei-otani-blueprint-friend-inline-d611e2d0bd.png "Pictured: Kei receiving friendly investment advice.||landscape")

---

# Developer Case Study: Andy Geers / PrayerMate

> Andy Geers joined us to discuss PrayerMate, a prayer organizing app. We spoke to Andy about the PrayerMate stack, why they decided to follow a local-first architecture, how they’ve implemented encryption, and what lies ahead.

- Published: 2024-09-26
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-andy-geers-prayermate

---

## Background

Andy Geers joined us to discuss [PrayerMate](https://www.prayermate.net/app), a prayer organizing app. We spoke to Andy about the PrayerMate stack, why they decided to follow a local-first architecture, how they’ve implemented encryption, and what lies ahead.

### App details

| App name | [PrayerMate ](https://www.prayermate.net/app) |
| --- | --- |
| Platform(s) | Mobile |
| App framework | Flutter |
| Backend API | PostgREST with Firebase Auth |
| Backend database | AWS RDS Postgres |
  

![](https://powersync.com/images/blog/developer-case-study-andy-geers-prayermate-inline-b1b55de2d9.png)

## Interview

**PowerSync**

Why was having a local-first architecture a priority for your team?

**Andy**

Offline functionality is crucial for us. Many users access the app in places without internet connectivity, like on subways, and some users are very privacy-conscious. They don’t want their data synced to the cloud, so ensuring full offline usability is a major priority.

**PowerSync**

Was latency or speed also a factor in this decision, or was it purely about offline functionality?

**Andy**

Latency does play a role, though it wasn’t the main consideration. It’s more of an additional benefit. But yes, having the app function offline reduces reliance on the cloud, which can improve responsiveness.

**PowerSync**

You also mentioned concerns about privacy. Are you implementing any encryption for the data when it is synced to the cloud?

**Andy**  

Yes, we encrypt the data on the device before it’s synced, and it remains encrypted on the server. This approach allows us to ensure we can’t read sensitive user data.

**PowerSync**  

Did you evaluate other options, and if you did, could you share why you chose PowerSync over those alternatives?

**Andy**  

We initially used Firebase Realtime Database, but it wasn’t suited to our needs. We needed something more reliable, especially when handling offline-first synchronization. Firebase Cloud Firestore, while better, would have been prohibitively expensive due to the way they charge per read and write operation. PowerSync provided a more cost-effective and robust offline-first solution, which was exactly what we needed.

**PowerSync**  

Can you tell us a bit more about the tech stack you’re using?

**Andy**

Our app originally had two native codebases, but we’ve moved the user interface to Flutter. Now, as we implement PowerSync, we’re also transitioning the entire backend logic to Flutter. We use a Postgres database on AWS, and Firebase handles our authentication.

**PowerSync**

What led you to choose PowerSync, and what aspects of it make it stand out compared to other alternatives?

**Andy**

The main reason we chose PowerSync is that it perfectly fits our need for an offline-first architecture. Before discovering it, we hadn’t come across any other solutions that offered a robust offline-first sync option. Offline functionality was our top priority, and PowerSync was built with that in mind. 

Additionally, the fact that PowerSync supports Flutter, which we use for our app, was a huge advantage. It also provides the reliability we need for syncing data without the complexities and potential costs of other solutions like Firebase Cloud Firestore. Overall, PowerSync just aligns with our requirements better than anything else we’ve found.

**PowerSync**

Our goal is to make local-first or offline-first architecture so simple that it’s easier to use than cloud-first systems. With local-first, you get fast offline access, real-time collaboration through built-in syncing, simpler state management, and less reliance on the backend. All of these benefits make local-first architecture appealing. If it were even easier to implement than cloud-first, we believe more developers would adopt it from the start. With this vision in mind, do you have any suggestions for making PowerSync easier to use?

**Andy**  

The initial setup could be made easier, especially around provisioning a Postgres database. For newer developers, this might be a bit daunting. But overall, it’s been much simpler than building custom solutions.

**PowerSync**

If you were building a new app, would you go with a local-first architecture again?

**Andy**

That’s a tough question. There’s a simplicity to having everything server-based, but the offline capabilities and cost savings from not constantly querying the cloud are appealing. Ask me again after I launch my next app!

**PowerSync**

Great feedback, thank you. Any final thoughts?

**Andy**  

Just that we’re really happy with PowerSync. It’s the perfect fit for what we’re trying to achieve, and we appreciate the support from your team.

---

# Introducing The PowerSync Cloud Team Plan

> Teams working on larger or more mature software implementations often need support guarantees and/or advanced features from the devtools and infrastructure tools that they rely on, but don't necessarily want to negotiate a custom subscription plan (as they would with our Enterprise plan). We're introducing our self-serve Team plan to solve for that need.

- Published: 2024-09-20
- Author: Phillip van der Merwe
- Category: Announcement
- Source: https://powersync.com/blog/introducing-the-powersync-cloud-team-plan

---

Teams working on larger or more mature software implementations often need support guarantees and/or advanced features from the devtools and infrastructure tools that they rely on, but don't necessarily want to negotiate a custom subscription plan (as they would with our Enterprise plan). We're introducing our self-serve Team plan to solve for that need.

## What's included in the Team plan?

Our Team plan brings support and uptime SLAs into a standard usage-based billing plan for PowerSync Cloud. Additionally, the plan provides for advanced DevOps needs by offering customizable roles and permissions within the PowerSync Dashboard, the option of Private Endpoints (via AWS PrivateLink), as well as customizable alerting (upcoming feature). The Team plan also bolsters compliance with access to security reports.

To summarize, the Team plan includes everything in the Pro plan, plus:

  * Priority email support with SLA
  * Uptime SLA
  * Customizable roles and permissions
  * Customizable alerting (upcoming feature)
  * Support for Private Endpoints (via AWS PrivateLink)
  * SOC2 report access

See a full comparison of all plans on our [Pricing page](https://powersync.com/pricing).

## Organization-based

As with Free and Pro plans, Team plans are set for your entire organization. This means that plan features are enabled for **all** projects within your organization. Usage is summed across all projects in a single, monthly invoice. Read more on our docs [here](https://docs.powersync.com/resources/usage-and-billing).

![](https://powersync.com/images/blog/introducing-the-powersync-cloud-team-plan-inline-61b78b697b.png  "Subscription plans are applied on the organization level.")

## Usage metrics 

The Team plan includes the same usage metrics dashboards that are available in the Free and Pro plans, which provide actual system usage data for every deployed instance. This allows you to see usage across your user base and review the impact of app updates.

## Monitoring & alerting (coming soon)

As an upcoming feature, the Team plan will additionally provide customizable monitoring & alerting functionality. This will include the ability to configure issue-based as well as metric-based alerts, with customizable thresholds and alerting targets (e.g. Webhooks, email, etc.).

## Differences between Team and Enterprise plan

The Team plan includes most of the same benefits as the Enterprise plan, although the Enterprise plan has more tight support SLAs. The main difference between the two is that the Team plan has **usage-based billing** whereas Enterprise plans can have **custom pricing**. For example, an Enterprise plan could provide more predictable costs by following a MAU-based pricing model that mitigates the risk of large spikes in usage affecting monthly bills.

## How to upgrade

To upgrade your PowerSync Cloud plan, go to **Plans & Billing** on the [PowerSync Dashboard](https://dashboard.powersync.com/].

## What's coming next

In addition to monitoring & alerting, the ability to set spending caps is currently in development, and will be available in a future release.

---

# Developer Case Study: Tristan Drummond & Gideon Boshoff / WorkWeek

> Tristan Drummond and Gideon Boshoff joined us to discuss implementing PowerSync for WorkWeek, a time tracking app that allows wage-earning workers to verify time worked, even when they’re on remote sites with no internet connectivity. We spoke about why they decided to follow a local-first approach, the stack they used to build the solution, and what their experience has been like using PowerSync.

- Published: 2024-09-13
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-tristan-drummond-gideon-boshoff-workweek

---

## Background

Tristan Drummond and Gideon Boshoff joined us to discuss implementing PowerSync for [WorkWeek](https://www.workweek.co.za/), a time tracking app that allows wage-earning workers to verify time worked, even when they’re on remote sites with no internet connectivity. We spoke about why they decided to follow a local-first approach, the stack they used to build the solution, and what their experience has been like using PowerSync.

### App details

| App name | [WorkWeek ](https://www.workweek.co.za/) |
| --- | --- |
| Platform(s) | Mobile (have a separate dashboard web app) |
| App framework | Flutter (initially FlutterFlow) |
| Backend API | Supabase (PostgREST) |
| Backend database | Supabase (Postgres) |
  

![](https://powersync.com/images/blog/developer-case-study-tristan-drummond-gideon-boshoff-workweek-inline-c07f09eaf1.png)

## Interview

**PowerSync**

Why did you decide to follow a local-first architecture for your app?

**WorkWeek**

Initially, our only need was around offline capability for the app as some of our customers use it on construction sites with poor connectivity. We implemented PowerSync because we didn't want to build [a sync engine] ourselves, and PowerSync met all of our technical requirements. This essentially opened the door to local-first for us.

Since then, we have benefited from other features inherent to local-first architecture. This includes low latency, which ended up being a nice perk even though it wasn't an initial consideration. Secondly, the sync bucket system is also nice and clean, it is such a great approach.

**PowerSync**

What options did you evaluate for implementing offline-first before choosing PowerSync?

**WorkWeek**

We didn't really consider any other off-the-shelf solutions. We did initially consider building a custom solution but decided against it as I mentioned before. Only after deciding to go with PowerSync did I investigate other solutions but they were either more complicated, didn't offer a hosted solution, or were closed source.

**PowerSync**

Why did you choose PowerSync over any other options? More specifically, what is the number one most valuable thing about PowerSync that makes it stand out over other options?

**WorkWeek**

Time was initially the biggest factor. There was strong customer demand for the app to be able to work offline and you guys helped us understand what resources building a custom solution would take. But I would say the number one most valuable thing was once we gained an understanding of the complexity of the problem, we didn’t have to handle the majority of the complexity, PowerSync did. Another big win was that PowerSync provides a managed service that scales — we didn’t want that as a problem.

**PowerSync**

Were there any other specific complexities that seemed like a heavy lift that PowerSync solved?

**WorkWeek**

Getting the right data to the right devices would have been a headache, but luckily PowerSync solves that with Sync Rules. Also, working with the different SDKs makes you realize how much is happening in the background that we would have had to figure out ourselves.

**PowerSync**

The vision we’re pursuing is to make offline-first or local-first architecture so easy to implement that people prefer implementing it for simplicity as opposed to traditional “cloud-first” architecture where you retrieve data from an API to display in the app.

Do you have any ideas or suggestions for what we should focus on in the product going forward to help us achieve that vision? 

**WorkWeek**

Firstly, that's a great vision for the product and we are both super behind it. I think one of the biggest hurdles for us was because we wanted to deviate our authentication strategy from what is in the documentation, we were immediately in no-man's-land. If the docs supported more use cases it would be easier. So, although I am sure most examples will get covered by the docs, if the idea is to make it as easy as possible I would recommend a push on the educational front on how the product is implemented in different scenarios.

Then, I’m not sure if this necessarily adds to the vision, but something I found to be of great value in the last while was the [diagnostics tool](https://docs.powersync.com/resources/troubleshooting#diagnostics-app). This tool is really helpful to remove the fear of this tech being a black box: I can see what's happening on the local DB, I can see what happens with the sync buckets and I can see what is happening on the backend DB. So, having good resources and having good insight into what's happening makes it a lot easier to just jump on board and get stuck in.

**PowerSync**

Thanks, that’s great feedback. Is there anything else you’d add?

**WorkWeek**

Yeah, so we are probably going to build another mobile app soon that probably won't need to function offline and in my mind, the early setup is still more difficult than a cloud-first approach. You can work hard at understanding it all, but then even if you do get close, in my mind there are still a couple of drawbacks. For instance, what happens if you do big schema changes and you want to change some of the SQL code on the device? Then you need to ship over-the-air updates. So there is a bit of risk to having the logic for the backend sit on the client side. I know that you have problems with that in the traditional server-client mentality, but I think maybe I just need to be educated and figure that flow out.

**PowerSync**

Thanks so much for all this feedback. It was super valuable.

**WorkWeek**

It's a pleasure. We're super happy and look forward to the next chapter.

---

# PowerSync and Supabase: Just the Basics

> Zane Thomas discovered PowerSync when he was looking for an offline-first solution for a mobile application he was working on. PowerSync provides a suite of demo apps, but he wanted to get started with the web SDK in an empty scaffold and build up from there. This post will take you step-by-step through what he learned about how to set up and use PowerSync together with Supabase.

- Published: 2024-09-12
- Author: Zane Thomas (guest author)
- Category: Tutorial
- Source: https://powersync.com/blog/powersync-and-supabase-just-the-basics

---

## Introduction

Recently I discovered PowerSync as I was looking for an offline-first solution for a mobile application I was working on. PowerSync provides a suite of [demo apps](https://docs.powersync.com/resources/demo-apps-example-projects), but I wanted to get started with the web SDK in an empty scaffold and build up from there. This post will take you step-by-step through what I learned about how to set up and use PowerSync together with Supabase.

## Create a Simple App

First you will create a simple application which consists of a web page, a text input, and a list to which input items are added, a button to clear the list, and the ability to edit an item. Later you will add PowerSync and then Supabase, after which the application will synchronize your data with a remote Supabase instance.

### Scaffold Project

Scaffold a project using Vite, documented [here](https://vitejs.dev/guide/#scaffolding-your-first-vite-project).

![](https://powersync.com/images/blog/powersync-and-supabase-just-the-basics-inline-f66402c64c.png)

### Update Files

Remove files `counter.js`, `javascript.svg`, `main.js`, `style.css`.

Replace the contents of index.html:

```htmlbars
<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <link rel="icon" type="image/svg+xml" href="/vite.svg" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Vite PowerSync Basic Setup</title>
  <script defer type="module" src="./src/index.js"></script>
  <link rel="stylesheet" href="./src/style.css">
</head>

<body>
  <div id="wrapper">
     <header>Vite PowerSync Basic Setup</header>
     <input type="text" id="inputField" placeholder="Type something and press Enter">

     <div id='listWrapper' style="width:fit-content; min-width: 400px;">
        <button id='clearButton' style="float:right" id="clearList">Clear List</button>
        <ul id="itemList">
        </ul>
     </div>
  </div>

</body>
</html>
```

Replace the contents of `.gitignore`:

```javascript
node_modules
.env
.env.*
dist
```

### Create Files

Create folder `src` in the project’s root.

Add `src/index.js`:

```javascript
let inputField;
let itemList;
let clearButton;
let editing = null;

document.addEventListener("DOMContentLoaded", (event) => {
 inputField = document.getElementById("inputField");
 itemList = document.getElementById("itemList");
 clearButton = document.getElementById("clearButton");

 inputField.addEventListener("keydown", keyDown);
 itemList.addEventListener("click", itemClick);
 clearButton.addEventListener("click", clearList);
});

const keyDown = async (event) => {
 if (event.key === "Enter") {
   if (!editing) {
     appendItem(inputField.value);
   } else {
     editing.innerText = inputField.value;
   }
   inputField.value = "";
   editing = null;
 }
};

const itemClick = async (event) => {
 editing = event.target;
 inputField.value = editing.innerText;
 inputField.focus();
};

async function clearList() {
 itemList.innerHTML = "";
 inputField.value = "";
 inputField.focus();
}

const appendItem = (name) => {
 const item = document.createElement("li");

 item.innerText = name;
 itemList.appendChild(item);
};
```

Add `src/style.css`:

```javascript
header {
  padding: 10px 0;
  font-size: larger;
}

#wrapper {
  margin: auto;
  width: fit-content;
}
#inputField {
  padding: 10px;
  font-size: 16px;
  width: 300px;
}

#listWrapper {
  margin-top: 0px;
  width:fit-content;
}
#itemList {
  margin-top: 0px;
  list-style-type: none;
  padding-left: 0;
  width:300px;
}

#itemList li {
  padding: 5px 0;
  font-size: 18px;
}
```

### Run Project

![](https://powersync.com/images/blog/powersync-and-supabase-just-the-basics-inline-00209f6f7e.png)

Enter items, edit an item by selecting it from the list, and clear the list. Enter a few items again and reload the page. The items are gone. PowerSync to the rescue!

## Add PowerSync

Next you will add packages and basic PowerSync functionality. After you have completed this step, items will be saved in a local WASM SQLite database; reloads will render the saved list items.

### Add Packages

`npm install vite-plugin-top-level-await vite-plugin-wasm`  
`npm install @journeyapps/wa-sqlite @powersync/web`

### Configure Vite

By default, Vite will crawl and bundle all of the files in your project. The `journeyapps/wa-sqlite` and `powersync/web` files must be excluded from that process. However, if your project does not use `js-logger`, you must include it or you will have an error when running dev. Also note that the WASM worker must be configured correctly.

Add `vite.config.js` to the root of the project:

```javascript
import path from "path";
import wasm from "vite-plugin-wasm";
import topLevelAwait from "vite-plugin-top-level-await";
import { defineConfig } from "vite";

// https://vitejs.dev/config/
export default defineConfig({
 root: ".",
 build: {
   outDir: "./dist",
   rollupOptions: {
     input: "index.html",
   },
   emptyOutDir: true,
 },
 resolve: {
   alias: {
     "@": path.resolve(__dirname, "./src"),
   },
 },
 envDir: ".", // Use this dir for env vars, not 'src'.
 optimizeDeps: {
   // Don't optimize these packages as they contain web workers and WASM files.
   // https://github.com/vitejs/vite/issues/11672#issuecomment-1415820673
   exclude: ["@journeyapps/wa-sqlite", "@powersync/web"],
   include: ["@powersync/web > js-logger",],
 },
 plugins: [wasm(), topLevelAwait()],
 worker: {
   format: "es",
   plugins: () => [wasm(), topLevelAwait()],
 },
});
```

### Create Schema

PowerSync uses a [schema](https://docs.powersync.com/usage/installation/client-side-setup/define-your-schema) to create and use tables in your local SQL database. 

Create file `src/database/schema.js`:

```javascript
import { column, Schema, TableV2 } from "@powersync/web";

const list = new TableV2({
 created_at: column.text,
 name: column.text,
});

export const schema = new Schema({
 list,
});
```

The schema defines a table list having columns created_at and name. The name column will store values entered into the input, created_at will be null for now. Later Supabase will provide values for created_at.

### Create PowerSync Database

PowerSync provides direct access to your SQLite database. 

Create the file `src/database/index.js`:

```javascript
import { PowerSyncDatabase } from "@powersync/web";
import { schema } from "./schema";

let PowerSync;

// Instantiate PowerSync database
const create = (config) => {
 console.log("Creating PowerSyncDatabase");
 PowerSync = new PowerSyncDatabase({
   schema,
   database: {
     dbFilename: config.dbFilename,
   },
 });
 console.log("PowerSyncDatabase Created");
};

export const openDatabase = async (config) => {
 create(config);
};

// Subscribe to changes in data
export function watchList(onResult) {
 PowerSync.watch(`SELECT * FROM list ORDER BY created_at`, [], {
   onResult: (result) => {
     onResult(result.rows);
   },
 });
}

export const insertItem = async (name) => {
 return PowerSync.execute(
   "INSERT INTO list(id, name) VALUES(uuid(), ?) RETURNING *",
   [name]
 );
};

export const updateItem = async (id, name) => {
 PowerSync.execute("UPDATE list SET name = ? WHERE id = ?", [name, id]);
};

export const deleteItem = async (id) => {
 PowerSync.execute("DELETE FROM list WHERE id = ?", [id]);
};

export const allItems = async () => {
 return PowerSync.getAll("SELECT * FROM list");
};

export const deleteAllItems = async () => {
 PowerSync.execute("DELETE FROM list");
};
```

After the `PowerSyncDatabase` has been created, you can freely use SQLite — your data will be persisted locally.

The function `watchList` makes it easy to react to changing data. The callback will be invoked whenever `allItems` and the functions which modify rows are invoked.

### Update src/index.js

Insert the following at the top of `src/index.js`:  

```javascript
import {
 openDatabase,
 insertItem,
 updateItem,
 allItems,
 deleteAllItems,
 watchList
} from "@/database";
```

Add the configuration:

```javascript
const config = {
 dbFilename: "powersync.sqlite",
};
```

Replace `document.addEventListener`:  

```javascript
document.addEventListener("DOMContentLoaded", async (event) => {
 inputField = document.getElementById("inputField");
 itemList = document.getElementById("itemList");
 clearButton = document.getElementById("clearButton");

 inputField.addEventListener("keydown", keyDown);
 itemList.addEventListener("click", itemClick);
 clearButton.addEventListener("click", clearList);

 inputField.disabled = true;
 inputField.placeholder = "Opening Database...";
 await openDatabase(config);

 watchList((rows) => {
   populateList(rows._array);
 });

 await allItems();

 inputField.placeholder = "Type something and press Enter";
 inputField.disabled = false;
});
```

Replace the `keyDown` function:

```javascript
const keyDown = async (event) => {
 if (event.key === "Enter") {
   if (!editing) {
     insertItem(inputField.value);
   } else {
     updateItem(editing.id, inputField.value);
   }
   inputField.value = "";
   editing = null;
 }
};
```

Replace the `clearList` function:

```javascript
async function clearList() {
 deleteAllItems();
 inputField.value = "";
 inputField.focus();
}
```

Replace the `appendItem` function:

```javascript
const appendItem = (row) => {
 const li = document.createElement("li");

 li.innerText = row.name;
 li.id = row.id;

 itemList.appendChild(li);
};
```

Add the `populateList` function:

```javascript
const populateList = (rows) => {
 itemList.innerHTML = "";
 for (const row of rows) {
   appendItem(row);
 }
};
```

### Run and Test

At the console enter `npm run dev`. Test adding, modifying, and deleting items. Ensure reloading the browser displays the items you have entered and modified. After you have verified the code is correct, move on to the next step.

## Create and Set Up PowerSync and Supabase Projects

Before you can add Supabase to your project you will need PowerSync and Supabase accounts. If you do not already have PowerSync and Supabase accounts you need to create them. You can create a new PowerSync account [here](https://accounts.powersync.com/portal/powersync-signup), and a new Supabase account [here](https://supabase.com/dashboard/sign-up). 

> **Warning**
>
> _A word of caution: The correct configuration of the accounts was, for me, the most error-prone part of creating a new Vite/PowerSync/Supabase project. But perhaps I rushed through a bit too quickly. Take your time and double-check each step to avoid later confusion._

## Supabase Project

Using the [Supabase Dashboard](https://supabase.com/dashboard/projects), create a new project named `powersync-basics`. You will need to enter a password. Don’t lose it, the password is needed for the next step.  You can accept the defaults; click `Create Project`.

On the left side of the home page is a menu; select the SQL Editor. After it opens, click the `New query` button, enter the following, and then click the `Run` button.

```sql
CREATE TABLE list (
  id uuid default gen_random_uuid() PRIMARY KEY NOT NULL,
  name text NOT NULL,
  created_at timestamp with time zone DEFAULT current_timestamp
);

create publication powersync for table public.list
```

The important point to note is the creation of a publication for PowerSync. This publication allows PowerSync to replicate changes made to your database, first to PowerSync and then to your application. Every table you want to use in your application must be listed; multiple tables are separated by commas.

Your application will need a URL (`VITE_SUPABASE_URL` in the `.env.local` file you will create later) for PowerSync to use to access the Supabase API and a token used for anonymous authentication (`VITE_SUPABASE_ANON_KEY`). In a real application you would sign up users and a token would be returned when they log in.

You will also need a URI to use when setting up PowerSync’s connection to Supabase. You will find them on the `Project Settings` view of the Home Page. Clicking the `Project Settings` button displays a list of `Configuration` items. 

Click on `Database`, at the top of the view you will see `Connection string`. Click the `Display connection pooler` checkbox so it is unchecked. Copy and save the `URI` for later.

In the `API` settings find the `Project URL` and `anon public` key, copy both and save for later.

In `Authentication` settings, enable `Allow anonymous sign-ins` in `User Signups`. Be sure to scroll down and click the `Save` button, that can easily be overlooked.

## PowerSync Project

On the [PowerSync Dashboard](https://accounts.powersync.com/), create a new project named `powersync-basics`. 

### Create and Configure a New Instance

Click `Create New Instance` and name it `supabase`, an `Edit Instance` dialog will be displayed. Click  `DB Connections` and then click `Add connection`. Paste the connection URI into the URI input. Paste your database password into the `Password` input. Enable `Allow querying data from the dashboard`, it’s useful for debugging.

Click `Test connection`. If the test fails, check all the parameters carefully.

![](https://powersync.com/images/blog/powersync-and-supabase-just-the-basics-inline-ea704d3d7e.png)

Click the `Client Auth` tab and enable `Use Supabase Auth`: 

![](https://powersync.com/images/blog/powersync-and-supabase-just-the-basics-inline-f36a388f14.png)

Click `Save and deploy`. While you wait, copy the URL of the instance by clicking the copy icon on the `supabase` instance which you will find under `Instances` on the left side of the page. After deployment has finished you will create Sync Rules.

### Create Sync Rules

PowerSync uses [Sync Rules](https://docs.powersync.com/usage/sync-rules) to determine what data from Supabase is synchronized to which of your application’s clients. In this application you will be using the simplest Sync Rules possible.

On the left side of your Powersync project, click on `sync-rules.yaml`, replace the contents:

```yaml
# Sync Rules docs: https://docs.powersync.com/usage/sync-rules
bucket_definitions:
 global:
   data:
     - SELECT * FROM list
```

All rows from the list table will be synced to all users. Click on `Validate` so PowerSync can verify that Supabase can satisfy the Sync Rules’ requirements. Assuming all is well, click `Deploy sync rules`.

## Add Supabase

You are now ready to connect PowerSync and Supabase.

### Install Supabase

`npm install @supabase/supabase-js`

Add file `.env.local` to the project root and insert the credentials you saved earlier:

```javascript
VITE_SUPABASE_URL=[insert your Supabase project URL]
VITE_SUPABASE_ANON_KEY=[insert your Supabase anon key]
VITE_POWERSYNC_URL=[insert your PowerSync instance URL]
```

### Add the Supabase Connector

Add file `src/supabase/index.js`:

```javascript
import { BaseObserver } from "@powersync/web";
import { createClient } from "@supabase/supabase-js";

const FATAL_RESPONSE_CODES = [
  // Postgres errors
  /^22\d{3}$/, // Data exception
  /^23\d{3}$/, // Integrity constraint violation
  /^42\d{3}$/, // Syntax error or access rule violation
  // Supabase errors
  /^PGRST\d{3}$/, // PostgREST errors
];

export class SupabaseConnector extends BaseObserver {
 constructor(config) {
   super();
   this.config = config;
   this.client = createClient(
     this.config.supabaseUrl,
     this.config.supabaseAnonKey,
     {
       auth: {
         persistSession: true,
       },
     }
   );
   this.currentSession = null;
   this.ready = false;
 }

 async fetchCredentials() {
   const {
     data: { session },
     error,
   } = await this.client.auth.getSession();

   if (!session || error) {
     throw new Error(`Could not fetch Supabase credentials: ${error}`);
   }

   console.log("session expires at", session.expires_at);

   const credentials = {
     endpoint: this.config.powersyncUrl,
     token: session.access_token ?? "",
     expiresAt: session.expires_at
       ? new Date(session.expires_at * 1000)
       : undefined,
   };
   console.log("credentials", credentials);
   return credentials;
 }

 async uploadData(database) {
   const transaction = await database.getNextCrudTransaction();

   if (!transaction) {
     return;
   }

   let lastOp = null;
   try {
     // Note: If transactional consistency is important, use database functions
     // or edge functions to process the entire transaction in a single call.
     for (const op of transaction.crud) {
       lastOp = op;
       const table = this.client.from(op.table);
       let result;
       switch (op.op) {
         case "PUT":
           const record = { ...op.opData, id: op.id };
           result = await table.upsert(record);
           break;
         case "PATCH":
           result = await table.update(op.opData).eq("id", op.id);
           break;
         case "DELETE":
           result = await table.delete().eq("id", op.id);
           break;
       }

       if (result.error) {
         console.error(result.error);
         throw new Error(
           `Could not update Supabase. Received error: ${result.error.message}`
         );
       }
     }

     await transaction.complete();
   } catch (ex) {
     console.debug(ex);
     if (
       typeof ex.code == "string" &&
       FATAL_RESPONSE_CODES.some((regex) => regex.test(ex.code))
     ) {
       /**
        * Instead of blocking the queue with these errors,
        * discard the (rest of the) transaction.
        *
        * Note that these errors typically indicate a bug in the application.
        * If protecting against data loss is important, save the failing records
        * elsewhere instead of discarding, and/or notify the user.
        */
       console.log(`Data upload error - discarding ${lastOp}`, ex);
       await transaction.complete();
     } else {
       // Error may be retryable - e.g. network error or temporary server error.
       // Throwing an error here causes this call to be retried after a delay.
       throw ex;
     }
   }
 }

 async loginAnon() {
   const {
     data: { session },
     error,
   } = await this.client.auth.signInAnonymously();

   if (error) {
     throw error;
   }

   this.updateSession(session);
 }

 updateSession(session) {
   this.currentSession = session;
   if (!session) {
     return;
   }
   this.iterateListeners((cb) => cb.sessionStarted?.(session));
 }
}
```

There’s a lot going on in that minimal implementation of `SupabaseConnector`. If you run into trouble when you first try to run the project, check the console output. 

The `fetchCredentials` function attempts to connect to your Supabase instance. Look for the credentials to show up in the console. If they do not, or if an error is thrown, make sure you have the correct values for `supabaseUrl` and `supabaseAnonKey`.

The `uploadData` function is used by PowerSync to send changes to Supabase.

Both of those functions could be used with some other database connector.

**NB.** If an exception is thrown in SupabaseConnector’s `uploadData` method an error will be logged in the console using `console.debug`. When debugging your application be sure to enable Verbose console output or you may not see important messages.

## Modify src/database/index.js

Just below the line `let PowerSync`; add 

`let Supabase;`

Add the following code after the `create` function:

```javascript
xport const connect = async (config) => {
 console.log("connecting to supabase ...");

 await PowerSync.connect(Supabase = new config.connector(config));

 console.log("connected to supabase");
 console.log("connected to powersync");
};
```

Add await `connect(config)` to `openDatabase`:

```javascript
export const openDatabase = async (config) => {
 create(config);
 await connect(config);
};
```

Add the function `loginAnon` after `connect`:

```javascript
export const loginAnon = async () => {
 await Supabase.loginAnon();
};
```

### Modify src/index.js

At the top of `src/index.js`, add `loginAnon` to the database imports. Import the `SupabaseConnector`.

```javascript
import {
 loginAnon,
 openDatabase,
 insertItem,
 updateItem,
 allItems,
 deleteAllItems,
 watchList,
} from "@/database";
import { SupabaseConnector } from "@/supabase";
```

Modify `config`:

```javascript
const config = {
 supabaseUrl: import.meta.env.VITE_SUPABASE_URL,
 powersyncUrl: import.meta.env.VITE_POWERSYNC_URL,
 supabaseAnonKey: import.meta.env.VITE_SUPABASE_ANON_KEY,
 connector: SupabaseConnector,
 filename: "add-supabase.sqlite",
};
```

In the `document.addEventListener` callback, add await `loginAnon()` after await `openDatabase(config)`;

Run the project

![](https://powersync.com/images/blog/powersync-and-supabase-just-the-basics-inline-4fb03a6213.png)

Finally, open your browser, enable developer tools, and run the project. Examine the console log. It might take a few seconds for PowerSync and Supabase to connect the first time you run the project.

If there are no errors, enter and edit items, reload the browser to ensure they have been persisted.

If there are errors and they do not directly indicate the source, then you should check `.env.local config`, login to your Supabase project and ensure it has the data, login to your PowerSync project and use SQL to retrieve the list items from Supabase. If you still haven’t discovered the source, you should check all of the PowerSync and Supabase settings.

---

# PowerSync As Alternative To MongoDB Atlas Device Sync

> News of MongoDB Atlas Device Sync's deprecation came as a surprise to many. The post provides an overview of migration options for Atlas Device Sync.

- Published: 2024-09-12
- Updated: 2025-09-30
- Author: Kobie Botha
- Category: Engineering
- Source: https://powersync.com/blog/powersync-as-alternative-to-mongodb-atlas-device-sync

---

_Updated: 2025-03-06_

In September 2024, MongoDB deprecated the following services:

  * Atlas Device Sync
  * Atlas Data API
  * Atlas Device SDKs

This post covers various options available to developers in light of this announcement.

## Overview of Atlas Device Sync Migration Options

Developers are currently faced with a couple of options if they want to migrate away from MongoDB Atlas Device Sync:

  * **1.** Stay on MongoDB
    * **1a** : Use PowerSync’s new MongoDB module. After MongoDB went public with the news of Atlas Device Sync’s deprecation, we decided to fast-track support for MongoDB as a backend database source in PowerSync. More details below.
    * **1b** : Alternatively, build your own sync engine
  * **2**. Migrate to a different database and sync engine combinations
    * For example, PowerSync provides production-ready support for syncing with Postgres on the backend.

In general, PowerSync is a good migration option since it’s architecturally quite similar to Atlas Device Sync and Atlas Device SDK:

![](https://powersync.com/images/blog/powersync-as-alternative-to-mongodb-atlas-device-sync-inline-7dc2fb0a1e.png)

Below are more details on the different migration paths available to developers:

### Option 1a: Stay on MongoDB and use PowerSync’s new MongoDB module

After Atlas Device Sync’s deprecation, the MongoDB team reached out to us here at PowerSync and encouraged us to implement support for MongoDB as a backend database source. We decided to pull the trigger on fast-tracking this, since it would open up a smoother migration path for the many developers currently relying on Atlas Device Sync.

As of March 2025, our MongoDB module has [**reached general availability (GA) status**](https://powersync.com/blog/powersyncs-mongodb-connector-hits-ga-with-version-1-0). It is currently available both self-hosted and in PowerSync Cloud. An end-to-end demo app is [available here](https://github.com/powersync-ja/self-host-demo/tree/main/demos/nodejs-mongodb). Please refer to the README for instructions on running it using Docker Compose.

We have also published further information in our [docs here](https://docs.powersync.com/resources/migration-guides/mongodb-atlas) and have published a migration [example here](https://powersync.com/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync). You can also vote on our roadmap for MongoDB [here](https://roadmap.powersync.com/c/109-mongodb) to stay subscribed to further updates.

On the client-side, using PowerSync will require moving away from Realm to SQLite, since that’s what the PowerSync Client SDKs use under the hood.

### Option 1b: Stay on MongoDB and build your own sync engine

For some very basic use cases, this could be feasible and there are some good tools on the market such as [TinyBase](https://tinybase.org/) and WatermelonDB.

### Option 2: Migrate to a different database and sync engine combination

For developers who are willing and able to migrate to a different database than MongoDB, there are options such as using Postgres along with PowerSync. PowerSync provides mature production-ready support for syncing with Postgres.

Users that aren’t already running Postgres need to decide between using a hosted Postgres provider or hosting Postgres themselves. We can highly recommend taking a look at [Supabase](https://docs.powersync.com/integration-guides/supabase-+-powersync) (either hosted or self-hosted) as a great way to introduce Postgres to your stack.

## PowerSync & Postgres Compatibility Checklist

  * Can you add Postgres to your stack?
  * If you plan on using a hosted Postgres provider, do they support creating logical replication publications? This is required by PowerSync: [here](https://docs.powersync.com/usage/installation/database-connection) is a list of supported providers.
  * Does PowerSync have a client SDK in your language of choice? Here is the [list](https://docs.powersync.com/#client-sdk-references) of supported clients.

For other options, see Section 2 (“Build”) [here](https://localfirstweb.dev/).

---

# Developer Case Study: Patrik Wassberg / Krooka Fishing

> Patrik Wassberg, joined us to discuss Krooka Fishing, an app for organizing and running fishing competitions that keeps working even when participants are fishing in remote locations without internet connectivity. We spoke to Patrik about the Krooka stack, why they decided to follow a local-first architecture and what the future holds for them.

- Published: 2024-09-06
- Category: Showcase
- Source: https://powersync.com/blog/developer-case-study-patrik-wassberg-krooka-fishing

---

## Background

Patrik Wassberg, joined us to discuss [Krooka Fishing](https://www.krooka-fishing.com/), an app for organizing and running fishing competitions that keeps working even when participants are fishing in remote locations without internet connectivity. We spoke to Patrik about the Krooka stack, why they decided to follow a local-first architecture and what the future holds for them.

### App details

| App name | [Krooka ](https://www.krooka-fishing.com/)*† |
| --- | --- |
| Platform(s) | Web and mobile |
| App framework | React, Vite (web) and React Native (mobile) |
| Backend API | Custom (Go) |
| Backend database | Postgres |
  
* _Krooka is still in development, with a release planned for later this year._

† _“Krooka” is a Swedish verb / slang for “to hook [a fish]”._

## Interview

**PowerSync**

Why did you decide to follow a local-first architecture for your app?

**Patrik**

The main reason was offline functionality. The whole reason why we started building this app was because there are issues when you're out fishing in the sea or at a lake deep in the woods: you can have a terrible internet connection. My friends and I have used other apps [that weren’t offline-first] and most of the time we weren't able to upload anything when we were actually fishing. 

But also the instant UI — you get changes in milliseconds instead of maybe two or three seconds, and if you have a bad connection, it can be even worse. But apart from that, I also found that in terms of state management, I don't have to handle as much as I do with like [Zustand](https://github.com/pmndrs/zustand) or [Redux](https://redux.js.org/) because since it's so quick, you basically have everything on the phone and it gives you that data in milliseconds so there’s no need for any advanced state management.

I also plan on using [the sync engine] kind of like a content management system, because it gets messages to users really quick through the PowerSync Service, because you can just make an entry into the database and then it syncs to all the users. This could include outages, promos — if you have in-app purchases and stuff like that, or anything you want your users to know of quickly.

**PowerSync**

What was the main thing about PowerSync that stood out to you? Or, put a different way, what would you consider to be the most valuable thing about PowerSync?

**Patrik**

It’s really easy to use your Supabase example and try it out. It felt like it checked all the criteria that I had, so after playing around a bit, I started planning the actual application. I think you guys launched around the same week that I started looking — maybe in October or November [of 2023] so it was a lucky match!

**PowerSync**

Some of the feedback that we've gotten from other developers that are using PowerSync has been similar: they’re looking for reliability, robustness, stability. So that is kind of a theme. 

Another piece of feedback that we’ve heard often is around PowerSync’s non-invasive architecture: you can basically view it as middleware between your Postgres backend database and your app and you can also take it out again. You don't have to modify your backend or your Postgres database extensively as you have to with some of these other tools. Developer experience or kind of just ease of getting started is also feedback that we've heard developers talk about. Developer control or customizability: for example, you can define how writes get applied to your database, so there's a level of customizability there. So those are some examples of feedback that we've gotten. Do any of those resonate with you as well as far as things that you found valuable in PowerSync?

**Patrik**

Yeah I would say the non-invasive part resonates: it feels like I could very easily disconnect PowerSync and just start using a normal API again. It’s nice because you don’t have to rewrite anything if you for some reason want to stop using it or move to something else.

**PowerSync**

How about ease of getting started? It’s really easy if you start with Supabase but maybe a bit more complicated if you're not using Supabase. Was there a learning curve getting started with PowerSync?

**Patrik**

Yeah I think there was. I have a lot of complex queries — a lot of joins and stuff like that — so when I started I basically thought I could write any kind of SQL in [Sync Rules] so that it was a bit of a learning curve. But I guess it's also on users who are maybe not really reading the documentation properly, maybe just going off the examples and then trying to customize them to our needs without actually reading what we can do. But I got some help from [the PowerSync team] and after that I kind of understood how I could solve some of the more complex stuff.

**PowerSync**

We’re obviously big believers in local-first or offline-first architecture because it has a lot of benefits. You've touched on several of them, simplified state management, low latency UI because of the speed of queries, offline mode, real-time, those kinds of things. 

In the past, a lot of people didn't implement a local-first or offline-first architecture because it was difficult to implement. But what we want to help do is to make local-first so easy to implement that people just go straight to a local-first architecture for a new application instead of the traditional cloud-first approach. In light of that, are there any ideas that come to mind that could be useful for us to consider?

**Patrik**

Now that I’ve been working with PowerSync for some months, I don't think it's that harder than a traditional API-only solution. I would say that it's easier: I have to write less API routes and endpoints for fetch and stuff like that. The big hurdle is if you’re not using Supabase, yeah — writing your own API and connecting that stuff. I can't really think of anything else that would make it easier.

**PowerSync**

Thanks. Can we talk about your web app? What stack are you using for that?

**Patrik**

It’s going to be React with Vite. I was doing Next.js first but I didn’t like the developer experience and I don’t need SSR for the web app. Next.js is a good framework, just not for me.

**PowerSync**

Will the web app be using your own APIs?

**Patrik**

Yes, it’s going to use our own APIs and PowerSync.

**PowerSync**

Great. So you'd actually have all the web app’s user data in SQLite, in the browser and have essentially the same architecture as mobile, just in a browser.

**Patrik**

Yes

**PowerSync**

On the API: do you have a single fat endpoint or a bunch of endpoints?

**Patrik**

Oh, I have a bunch of endpoints. Like 90% of my work is frontend and then I have a friend who does some of the backend stuff.

**PowerSync**

So, on the client, your upload data implementation is quite a few lines of code checking for various scenarios and writing to various endpoints based on whatever is happening in the upload queue. Is that correct? 

**Patrik**

Yeah. And I also have some wrapper functions for stuff like parsing JSON and stuff like that.

**PowerSync**

And are you using transactions or just the regular CRUD batch?

**Patrik**

Transactions, yeah.

**PowerSync**

And what was the main restriction on Supabase that sent you down the route of building your own API with Go?

**Patrik**

Yeah, a lot of different things… We have complex queries and different tables that need to be [updated]. Like if I insert into one table, I need to insert a row in one or two other tables [as well]. I was using Postgres functions but it got so messy: it was hard to write — at least for me. It was just easier to create our own backend API, and handle it that way.

**PowerSync**

Okay, and Supabase Edge Functions weren't really sufficient for doing those kinds of things?

**Patrik**

Yea I played around with it a bit, but I didn’t like the developer experience, you could say. I felt it was just easier to have my own API and if we want to change stuff in the future it feels like we have way more control over our data and how things work. We are actually still using Supabase for Edge Functions for push notifications and for authentication — just because of time constraints. Although I don’t know if we will have the time to migrate away anytime soon.

**PowerSync**

Okay, understood. Thank you so much for joining us Patrik, we really appreciate your time!

---

# PowerSync Update: August 2024

> August has been our busiest month yet, with all-time highs for the number of developers actively building with PowerSync — for both PowerSync Cloud and our self-hosted version, PowerSync Open Edition. We’ve been hard at work too — here’s what went down this past month:

- Published: 2024-09-04
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-august-2024

---

August has been our busiest month yet, with all-time highs for the number of developers actively building with PowerSync — for both PowerSync Cloud and our self-hosted version, PowerSync Open Edition. We’ve been hard at work too — here’s what went down this past month:

## JS/Web SDK: Performance Improvements for Large Datasets

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-92d2ab59f4.png)

Improved handling of update notifications on the JS/Web SDK has led to significant performance improvements: tests show a 20-25X improvement in initial download times for large datasets.

[See the pull request](https://github.com/powersync-ja/powersync-js/pull/266)

## JS/Web: Log Queries on the Performance Timeline

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-feefb097f3.png)

Enabling the `debugMode` flag in the JavaScript Web SDK logs all SQL queries on the Performance timeline in Chrome's Developer Tools (after recording). This can help identify slow-running queries.

This includes:

  * PowerSync queries from client code.
  * Internal statements from PowerSync, including queries saving sync data, and `begin`/`commit` statements.

[Read the docs](https://docs.powersync.com/resources/troubleshooting#javascript-web-logging-queries-on-the-performance-timeline)

## Easily Use the Diagnostics App With a Local Development Setup

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-aada9c75a8.png)

A _Test Client_ is available as part of the `powersync-service` repo, and now contains a script to generate a JWT from a given powersync.yaml config file – similar to generating development tokens from the Dashboard for PowerSync Cloud instances. This token can then be used to e.g. sign into the Diagnostics app with a self-hosted setup.

Available via the command:

`node dist/bin.js generate-token --config path/to/powersync.yaml`

Shout out to the folks at **XOi** who spurred us on here.

[View the Test Client in the repo](https://github.com/powersync-ja/powersync-service/tree/main/test-client)

## ElectricSQL electric-next vs PowerSync

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-8fe097ff53.png)

On July 17th 2024, ElectricSQL announced a “clean rebuild” of their product, which is being called ‘electric-next’. They also announced that they’ve stopped development on the legacy ElectricSQL, as it’s being superseded by electric-next. 

In this post we compare their new direction to PowerSync.

[Read the article](https://powersync.com/blog/electricsql-electric-next-vs-powersync)

## Flutter: New Demo Project for Using Drift ORM with PowerSync and Supabase

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-73c2f1c0fd.png)

This demo app is an extension of the Supabase Todo List App and showcases how to set up and use the `drift_sqlite_async` library (an integration with Drift ORM) with PowerSync.

[Explore the project](https://github.com/powersync-ja/powersync.dart/tree/main/demos/supabase-todolist-drift)

## JS/Web & RN: Most Polyfills Now Pre-Bundled

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-5c5df46e17.png)

We’ve simplified the installation process for our React Native and JS/web SDKs by pre-bundling all polyfills that could support this. 

Thanks to **@frankcalise,** **@tommy** and everyone else who shared their feedback on this!

[See the pull request](https://github.com/powersync-ja/powersync-js/pull/237)

## JS/Web & RN: WebSocket Streaming Now the Default Connection Method

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-042a0e8380.png)

WebSocket streaming is the recommended connection method and was made the default in versions 1.6.0 of our JS/Web SDK and 1.11.0 of our React Native SDK.

WebSocket streaming is more robust against network inspectors on RN and can support new capabilities such as BLOB column types. Sync speeds also appear faster with using WebSocket on RN, but we're still working on benchmarks.

HTTP streaming remains available as a connection method.

[See the docs for JS/Web ](https://docs.powersync.com/client-sdk-references/js-web#connecting-via-websocket-or-http-stream) [and RN](https://docs.powersync.com/client-sdk-references/react-native-and-expo#connecting-via-websockets-or-http-streams)

## Flutter: Streamlined Client SDK Web Support

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-1086d14601.png)

For Flutter Web, downloading the required `sqlite3.wasm` and `powersync_db.worker.js` files is no longer a manual step. Simply run: `dart run powersync:setup_web`.

[See the Dart package README](https://pub.dev/packages/powersync)

## [Video] Developer Benefits Of Local-First

This video covers 7 distinct developer benefits of local-first development.

## Community Focus

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-013744f7b7.png)

Notable projects from the community are now listed in a new section in our docs! Let us know if you have any for us to add.

[Check out Notable Community Projects](https://docs.powersync.com/resources/demo-apps-example-projects#notable-community-projects)

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-dec3905652.png)

“BeFit is your pocket personal trainer, helping you track workouts, stay consistent, and see real progress.” — built by **Steve Nosse**.

[Check out BeFit](https://trybefit.app/)

## [Newsletter] _Local-First News_

![](https://powersync.com/images/blog/powersync-update-august-2024-inline-c2d2f8bf40.png)

Local-First News is an _open contribution_ newsletter that summarizes the latest local-first:

  * News and discussions
  * Tools and resources
  * Apps

No spam, free to sign up, sent weekly on Thursdays. Sponsored by PowerSync.

[Subscribe here](http://localfirstnews.com)

[Video: Local-First News newsletter](https://www.youtube.com/watch?v=ovdcUtW4tWY)

---

# ElectricSQL electric-next Vs PowerSync

> A comprehensive comparison of electric-next and PowerSync.

- Published: 2024-08-28
- Updated: 2026-10-14
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/electricsql-electric-next-vs-powersync

---

> **Warning**
>
> **Electric Cloud has shut down.** Electric has joined Databricks. The original Electric "will likely not be actively built out as is". This comparison is retained for historical context. If you are considering moving from Electric to PowerSync, see our guide: [Migrate from Electric Cloud to PowerSync Cloud](https://powersync.com/blog/migrate-from-electric-cloud-to-powersync-cloud).

> **Warning**
>
> Since this post was published, PowerSync has released [Sync Streams](https://docs.powersync.com/sync/streams/overview) — where you define reusable streams and clients subscribe to them with parameters. References to Sync Rules below describe the legacy system.

_Updated 2024-09-11_

On July 17th 2024, ElectricSQL [announced](https://electric-sql.com/blog/2024/07/17/electric-next) a “clean rebuild” of their product, which was originally called ‘electric-next’. They also announced that they’ve stopped development on the [legacy ElectricSQL](https://legacy.electric-sql.com/) [^1], as it’s being superseded by electric-next. 

The ElectricSQL team included a [detailed rationale](https://electric-sql.com/blog/2024/07/17/electric-next#why-build-a-new-system) for this decision: The initial ElectricSQL system was too large and complex in scope, and the team had a hard time getting it to a point where it was stable and reliable. With their rebuild, they are aiming to deliver a stable system that is significantly reduced in scope, and more modular and loosely coupled.

What is interesting is that ElectricSQL’s simplified architecture has a number of similarities to PowerSync’s architecture, which is perhaps not surprising since in designing PowerSync, we [aimed](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer) for a “simple, robust and proven architecture” for a Postgres-SQLite sync engine.

While both products are still sync engines that work with Postgres databases, electric-next is more limited in scope than PowerSync at the time of publishing this blog post. Below, we look at notable similarities and differences between the two.

## Similarities between ElectricSQL’s electric-next and PowerSync

| **ElectricSQL's electric-next** | **PowerSync** |
| --- | --- |
| Uses Postgres logical replication and stores sync data relating to ‘shapes’ and a log of their operation history in either an in-memory cache, or persistent storage. | Uses Postgres logical replication and stores sync data relating to ‘buckets’ and their operation history in pluggable persistent storage used by the PowerSync Service (currently MongoDB is supported). |
| Dynamic partial replication via Shapes: With the current version of [shapes](https://electric-sql.com/docs/guides/shapes) in electric-next, the client syncs one or more shapes, and each shape contains a linear log of changes to sync, sorted by “offset”. A shape is [defined](https://electric-sql.com/openapi.html) by a single table and a WHERE clause. No automatic syncing of related data is presented yet, and it’s currently not possible to accomplish this manually. We expect the shape functionality to expand over time, but it’s not yet clear what will be supported or how it will be implemented. | Dynamic partial replication via Sync Streams: PowerSync has the concept of [buckets](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets) and clients sync one or more buckets, with each bucket [containing](https://powersync.com/blog/what-powersync-open-edition-means-for-local-first#dynamic-partial-replication-deduplicated-for-high-scalability) operation history for the data in that bucket, sorted by an ‘operation ID’ (op_id). The data to be synced in each bucket is defined by [Sync Rules](https://docs.powersync.com/usage/sync-rules) which consist of parameter queries (to retrieve all relevant parameters), and one or more data queries that can make use of those parameters. |
| Decoupling of writes and no [finality of writes](https://electric-sql.com/blog/2024/07/17/electric-next#why-build-a-new-system#a-note-on-finality-of-local-writes): No provision is made for writes to be applied to data via electric-next. Processing of writes has to be implemented [separately](https://electric-sql.com/blog/2024/07/17/electric-next#why-build-a-new-system#write-patterns) from electric-next. This also means that ElectricSQL’s “finality of writes” principle is inherently not part of the current system design. However, it will be reconsidered later: _“[W]e are committed in the longer term to building support for finality of local writes. However, it is no longer a key tenet of the system design.”_ | The write path is decoupled from the read path of data: PowerSync allows the developer to [write directly](https://docs.powersync.com/overview/readme-1#reading-and-writing-data) to the local SQLite database. Syncing with Postgres is optional, and if syncing is enabled, the writes to SQLite are also placed into an upload queue. The PowerSync client SDK then sequentially processes writes in the upload queue using an uploadData() function [defined](https://docs.powersync.com/usage/installation/client-side-setup/integrating-with-your-backend) by the developer. Therefore, the developer is in control of how writes are applied to Postgres, typically via their backend API.  PowerSync does not provide for finality of local writes. Writes can be processed on the backend server with any logic of the developer’s choosing, and all clients will update their local state to the server-authoritative state after writes have been processed on the server and syncing subsequently takes place (see [here](https://docs.powersync.com/architecture/consistency) for details). |
| Server-authoritative event-sourcing vs. CRDT-based architecture: There is no mention of CRDTs in the new system. In the future, once writes are included in the scope of electric-next, CRDTs might be reintroduced, similar to the legacy ElectricSQL architecture, but the details remain to be seen. | Server-authoritative event-sourcing vs. CRDT-based architecture: Although local offline writes are supported, PowerSync does not use CRDTs as part of its protocol. Pending local writes are applied on top of the server-authoritative state, and once all local writes have been uploaded/processed by the backend, the local state is updated to match the server-authoritative state (see [here](https://docs.powersync.com/architecture/consistency) for details). |
| Loose coupling between client and server: The legacy ElectricSQL had tight coupling between the client and server (sync service), and several pieces of functionality were reliant on this tight coupling. By contrast, electric-next has much looser coupling, with a few notable impacts such as: • Schema management: _"it can be the responsibility of the client to connect with the correct schema."_ • Type safety in the client: _“use of types is optional and in many cases types can be provided by ORMs and other client-libraries.”_ • Framework integration such as React and others: these are now external to the core system. | Somewhat loose coupling between client and server: PowerSync provides a set of client SDKs which work in conjunction with the server-side PowerSync Service to keep data in sync between the backend database and a client-side SQLite database, based on the Sync Rules configuration. However, some aspects of the system are similarly loosely-coupled compared to electric-next, for example: • It is the responsibility of the client to connect with a valid client-side schema. This can be generated [automatically](https://docs.powersync.com/usage/installation/client-side-setup/define-your-schema) from the backend Postgres schema and Sync Rules. • [ORMs](https://powersync.com/blog/using-orms-with-powersync) and other client libraries can be used to provide type safety. |
| Reduced state required on the server: The legacy ElectricSQL system relied on a significant degree of per-client state stored on the server (in-memory and/or persisted), which made the system very memory-intensive as it would scale to larger numbers of connected clients and rows synced. The new electric-next system requires the client to keep track of sync progress (by keeping track of its “offset” per shape). Since the new electric-next architecture does not rely on keeping an entire graph of data to sync for each connection, the inherent legacy scalability constraints have been addressed. | Minimal state required on the server: With its system of buckets, PowerSync allows changes to data to be grouped together in order to [deduplicate](https://powersync.com/blog/what-powersync-open-edition-means-for-local-first#powersync-design-amp-architecture-15-years-in-the-making) work. As a result, PowerSync does not have to keep track of individual client-side state on the server. The system can scale to high volumes of data and users with an efficient memory footprint. The PowerSync Service stores bucket state and operation history (indexed for efficient querying) in persistent storage and only stores limited information in memory. The “offset” per shape in electric-next is similar to PowerSync’s op_id per bucket which the client keeps track of. |
  

## Differences between ElectricSQL’s electric-next and PowerSync

| **ElectricSQL's electric-next** | **PowerSync** |
| --- | --- |
| No built-in SQLite support: Unlike the legacy ElectricSQL, the current version of electric-next does not sync data into a local SQLite database. The electric-next system only provides an HTTP API which exposes shape data. However, ElectricSQL’s adjacent PGlite project has a [sync package](https://github.com/electric-sql/pglite/tree/main/packages/pglite-sync) available, which acts as an electric-next client (and uses the electric-next HTTP API) that can sync data into a local WASM-based Postgres database (PGlite) | PowerSync automatically syncs data into a local SQLite database, where it can be utilized by the client application. Local offline writes to the SQLite database are also supported, as detailed below. |
| Currently read-only; [no handling](https://electric-sql.com/blog/2024/07/17/electric-next#write-patterns) of writes: Writes to data are not in scope for electric-next — it is the responsibility of the developer to build tooling for writes. This also means that if the developer needs support for offline writes, they need to implement that themselves. | Tooling for offline writes as well as asynchronously uploading writes to the backend are built into the PowerSync client SDKs. |
| Shapes are dynamically requested from the client, rather than pre-defined on the server. An [HTTP API](https://electric-sql.com/docs/api/http) is provided whereby shapes can be requested and polled from the client-side. | [Sync Rules](https://docs.powersync.com/usage/sync-rules) / buckets are defined on the server-side. This means that a separate permission / access control layer is not needed on the server-side, since Sync Rules serve as both authorization for access to data as well as defining which data to sync to which users. Future support is planned for allowing data to be dynamically requested from the client side, based on permissions / authorization rules defined on the server-side. |
| Protocol uses HTTP instead of WebSockets. The current implementation relies on HTTP long-polling, but it appears that HTTP stream support is planned. The [reason](https://electric-sql.com/blog/2024/07/17/electric-next#http-protocol) for using HTTP is to minimize state and to integrate with standard HTTP tooling such as proxies and CDNs. | WebSockets and HTTP streams are supported. |
| No provision for consistency: At the time of publishing this blog post, there is no provision in the electric-next protocol to get a consistent set of data across multiple shapes. | Consistency guarantees across all synced data is a core part of the PowerSync protocol and client SDKs. See [here](https://docs.powersync.com/architecture/consistency) for more details. |
| Authentication and permissions require a proxy to be built in front of electric-next: see the [documentation](https://electric-sql.com/docs/guides/auth) for details. | Authentication makes use of [JWTs](https://docs.powersync.com/usage/installation/authentication-setup), and permissions for access to data are controlled through [Sync Rules](https://docs.powersync.com/usage/sync-rules). |
| Flutter community client deprecated: The legacy ElectricSQL had an unofficial Flutter client that was maintained by members of the community. When the electric-next rebuild was announced, the maintainers of the Flutter client announced that the Flutter client can be considered deprecated. At the time of publishing this blog post, clients are available for [TypeScript](https://electric-sql.com/docs/api/clients/typescript) and [Elixir](https://electric-sql.com/docs/api/clients/elixir), and a [React](https://electric-sql.com/docs/api/integrations/react) integration is also available. | PowerSync provides officially-supported client SDKs for [Flutter/Dart](https://docs.powersync.com/client-sdk-references/flutter), [React Native](https://docs.powersync.com/client-sdk-references/react-native-and-expo), [web/JavaScript](https://docs.powersync.com/client-sdk-references/js-web) (with [React and Vue](https://docs.powersync.com/client-sdk-references/js-web/javascript-spa-frameworks) integrations), [Kotlin Multiplatform](https://docs.powersync.com/client-sdk-references/kotlin-multiplatform), [Swift](https://docs.powersync.com/client-sdk-references/swift), [Node.js](https://docs.powersync.com/client-sdk-references/node), and [.NET](https://docs.powersync.com/client-sdk-references/dotnet). |
  
## Expanded use cases

With electric-next, ElectricSQL now aims to support a wider range of [use cases](https://electric-sql.com/blog/2024/07/17/electric-next#use-cases), such as syncing to edge workers, pointing to a more general-purpose sync engine rather than one aimed exclusively at local-first application use cases. PowerSync does not currently have specific plans for such an expanded set of use cases.

## Feedback or questions?

Join us [on Discord](https://discord.gg/powersync) to discuss.

[^1]: We previously [published](https://powersync.com/blog/electricsql-vs-powersync) a comparison between the legacy ElectricSQL and PowerSync.

---

# Developer Benefits Of Local-First

> Local-first is about building better apps. Apps are better for users because they’re instantly responsive, they enable collaboration and they’re resilient to the network dropping. But local-first also promises a better developer experience. So what are the developer benefits of a local-first architecture and how compelling are they? Let’s get into it in this blog post.

- Published: 2024-08-21
- Author: Phillip van der Merwe
- Category: Engineering
- Source: https://powersync.com/blog/developer-benefits-of-local-first

---

Local-first is about building better apps. Apps are better for users because they’re instantly responsive, they enable collaboration and they’re resilient to the network dropping. But local-first also promises a **better developer experience**.

So what are the developer benefits of a local-first architecture and how compelling are they?

## What's happening with local-first adoption

Local-first apps bring amazing speed and continuity to the user experience. So much so that, for apps that users spend a lot of time in, user experience benefits alone can be enough to lead developers to prefer a local-first architecture.

![](https://powersync.com/images/blog/developer-benefits-of-local-first-inline-3c32b28fae.jpeg  "Shared by @zx_loro on X / Twitter.")

The project management app [Linear](https://linear.app/) is a good example of where gains in speed and network resilience add up to significant time savings and significantly less frustration for users — allowing a (now much-loved) product to be successful in a space that was already dominated by established incumbents. However, developers aren’t waiting for end-users to demand better UX before adopting local-first in their projects. The reason? A simpler developer experience.

Now, if local-first provides a simpler developer experience, why is local-first adoption only taking off now? Hasn’t it always been an option? The reason is that building your own sync engine used to be a huge barrier to local-first adoption. The complexity and engineering effort involved meant that it was only undertaken by the bravest or most passionate among us — like the folks at Linear. But now that sync engines are being productized more and more, developers can much more easily add them to their software.

![](https://powersync.com/images/blog/developer-benefits-of-local-first-inline-324cb67ffb.png)

So what benefits do you get from local-first, once you have a sync engine in place? Let’s look at 7 distinct developer benefits of local-first.

## 7 Developer Benefits of Local-First

### 1\. Latency resilience

Local-first apps have super-fast UI because they use a local database with near-zero latency.

This fundamental shift in app architecture means that since data is stored exactly where it’s needed (in the user’s app or browser) the network is completely eliminated from the interaction path. And because of that, countering network latency is unnecessary: there’s no need for implementing caching on the front-end, using edge CDNs or deploying multi-region backends. Your app is resilient to network latency.

### 2\. Forget the network

Since dealing with the network is abstracted away by sync engines, there’s no need to write networking code for app functionality or for most error handling code. For the most part, you can forget about the network.

```tsx
import React, { useState, useEffect } from 'react'; 

function DataFetchingExample() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect (() => {
    fetch('https://jsonplaceholder.typicode.com/todos')
      .then(response => response.json())
      .then(data => {
        setData(data);
        setLoading(false);
      })
      .catch(error => {
        setError (error);
        setLoading(false);
      });
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return ( 
    <div>
      <h1>Fetched Data</h1>
	  <pre>{JSON.stringify(data, null, 2)}</pre> 
	</div>
  );
}
```
Here's a pseudo code example given by Tuomas Artman that illustrates this difference:

Code example with a typical _cloud-first_ architecture:

Code example after a local-first architecture has been adopted:

```tsx
issue.comments.elements.map(comment => {
  return <>{comment.bodyTextContent}</>
});
```
### 3\. Simpler state management

State management becomes simple when your app state is just what’s in your local database. When underlying data changes, live query hooks made available by sync engines allow query results and the UI to be automatically updated. State management frameworks become unnecessary for most use cases.

### 4\. Move logic to the frontend

Since all required data is available on the client, most logic can be moved to the client too. This can greatly simplify the backend. 

It also allows new app features to be prototyped without having to consider the backend: queries run against the local database and updates are written there too.

Here's how Anselm Eikhoff explained the change in developer experience that local-first enables:

![](https://powersync.com/images/blog/developer-benefits-of-local-first-inline-854dae96e1.png)

![](https://powersync.com/images/blog/developer-benefits-of-local-first-inline-bbc75acede.png  "Anselm Eikhoff at Local-First Conf in Berlin.")

### 5\. Less dependence on backend uptime

Since apps keep working with their local database even when the backend is down, there is much less of a need for site reliability engineering and for a team doing on-call rotation. 

### 6\. Reduced backend infrastructure costs

The simplified backend architecture that sync engines enable have a major effect on infrastructure costs. The picture given by Linear is: with the 1,000 concurrent users in their EU data center (for about 10,000 total) they “could run all of [that] with effectively just two CPU cores in Europe; which costs you maybe 80 bucks a month.”

![](https://powersync.com/images/blog/developer-benefits-of-local-first-inline-56df905911.png  "Example given in Tuomas Artman's Local-First Conf talk.")

### 7\. Real-time streaming for free

The benefits of having a real-time sync engine as part of your stack extends to being able to easily add collaboration functionality like group chats or multi-user document editing. Built-in real-time streaming also makes it easy to push alerts or messages to users.

## Video

Local-first clearly promises a great deal, but does it deliver? In the next few videos of the Local-First Key Concepts series, we’ll take a look at these benefits in more detail and show implementation examples.

[Video: Local-First Key Concepts: Developer Benefits of Local-First](https://www.youtube.com/watch?v=ovdcUtW4tWY)

---

# PowerSync Supports Fair Source

> On May 31, 2024, we announced a new open era for PowerSync and launched PowerSync Open Edition: a free, self-hosted and source-available version of PowerSync that engineers can run on their own servers. We believe that the newly launched Fair Source initiative represents a constructive step forward in the software licensing world: by coining a new term (“fair source”) that provides clarity to users of the software regarding the principles and spirit of how software is licensed. Setting clear expectations is exactly what we sought to achieve when we chose the FSL to license PowerSync.

- Published: 2024-08-06
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/powersync-supports-fair-source

---

On May 31, 2024, we [announced a new open era for PowerSync](https://powersync.com/blog/new-open-era-for-powersync) and launched [PowerSync Open Edition](https://powersync.com/blog/powersync-open-edition-release): a free, self-hosted and source-available version of PowerSync that engineers can run on their own servers.

## From closed to open

This launch was a significant milestone for us: a once-tightly integrated part of our proprietary app development [platform](https://journeyapps.com/) had become an openly available, standalone sync engine with code that could easily be inspected and hosted. It was part of our plan to accelerate the adoption of [local-first](https://powersync.com/blog/what-powersync-open-edition-means-for-local-first) app development by making a mature sync engine available to all developers eager to experience the developer benefits of the local-first paradigm.

This was no easy journey: besides the significant engineering work to be done, we needed to carefully consider how this edition would be licensed.

## Licensing PowerSync Open Edition

As we [wrote in May](https://powersync.com/blog/new-open-era-for-powersync), our licensing discussions happened against the backdrop of the “open-source licensing war”:  

> Big cloud providers have taken successful open-source products and provided them as a service, capturing virtually all the value and not investing back into the community. This has been widely characterized as against the spirit of open-source. The creators of major open-source projects fought back by switching to licenses that protect them against “free-riding” and unfair competition — by restricting other cloud service providers from offering the product as a service, while preserving the principles of openness, transparency, and collaboration. 

> However, these changes in licensing were not without significant controversy: Developers saw it as a bait-and-switch. For years, major open-source projects flourished under fully permissive licensing, and then changed the licensing after achieving widespread adoption. 

> In deciding on licensing for the PowerSync Open Edition, we realized that _we never wanted to be in a future position where we had to backtrack on our licensing_. We wanted to choose a license from the start that we can stick to indefinitely.

This led us to the [Functional Source License (FSL)](https://fsl.software/), now the [flagship license of the Fair Source initiative](https://fair.io/licenses). As we wrote in May:

> The goal of the FSL is to balance user freedom and developer sustainability. [As Sentry explains](https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/), “In plain language, you can do anything with FSL software except economically undermine its producer through harmful free-riding. You can read it, learn from it, run it internally, modify it, and propose improvements back to the producer.”

> The FSL gives you freedom to do almost anything you could do with a regular open-source license: copy, modify, and redistribute the code for non-commercial and commercial use. The only thing it disallows is providing a paid offering that is competitive to the creator — that right is reserved for the main creator/maintainer of the project. 

In summary: the only difference between the FSL and an [OSI-approved open-source license](https://opensource.org/licenses) is the non-compete: you may not use the code to offer something in competition with the licensed project. Additionally, all code under an FSL converts to an OSI-approved license after a period of two years.

## Fair Source: a constructive step forward

We believe that the newly launched [Fair Source](https://fair.io/) initiative represents a constructive step forward in the software licensing world: by coining a new term (“fair source”) that provides clarity to users of the software regarding the principles and spirit of how the software is licensed. Setting clear expectations is exactly what we sought to achieve when we chose the FSL to license PowerSync.

Moreover, key principles of Fair Source align well with our aims in licensing PowerSync under the FSL:

  * Fair Source provides a reasonable balance between user freedom and developer sustainability.
  * Fair Source software is safe for companies to share and for developers to use.

Therefore, we are excited and proud to align ourselves with the Fair Source movement and to help advance its cause.

---

# PowerSync Update: July 2024

> Many enhancements were shipped in July — let’s get into them.

- Published: 2024-08-02
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-july-2024

---

Many enhancements were shipped in July — let’s get into them.

## Improvements to Sync Rules Syntax

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-38a7300f68.png)

Sync Rules control what Postgres data gets synced with individual in-app SQLite databases.

It’s useful to think of Sync Rules as a two stage ETL pipeline: the first stage, the parameter query, takes the auth JWT as input and returns a result set. The second stage takes the parameter query results and applies the data query/queries to them.

The previous syntax for Sync Rules’ parameter queries had unintuitive mappings between JWT data and accepted parameters.  

Now, the full JWT is passed to Sync Rules as a JSON string, so any JWT field can be referenced:

```yaml
user_list:
parameters: SELECT id AS list_id FROM lists WHERE email = request.jwt() ->>
'email'
```

[Read the release notes](https://releases.powersync.com/announcements/improved-parameter-query-syntax-in-sync-rules)

## Support for Passing Parameters From PowerSync Clients Directly

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-53bd209a14.png)

We also added support for client parameters - they provide an alternative way to pass parameters to Sync Rules. This opens new possibilities for dynamic syncing, which is useful for:

  1. Lazy-loading large datasets on the client app.
  2. Syncing data based on state in the client app. For example: only sync data for the customer currently selected.
  3. Syncing different data based on the client version.

It’s important to keep in mind that client parameters are not server-authoritative. Read more [here](https://docs.powersync.com/usage/sync-rules/advanced-topics/client-parameters-beta#security-consideration).

Support for client parameters is available in the following SDK versions:

  * Flutter v1.5.3
  * React Native v1.7.2
  * JS Web v1.1.0

[Read the release notes](https://releases.powersync.com/announcements/client-parameter-support-in-flutter-react-native-and-js-web)

## Bucket History Compacting

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-fcd3112661.png)

V0.5.1 of the PowerSync Service implements a `compact` command, which compacts sync bucket history, optimizing sync performance for client applications.

In most cases it will reduce the number of sync operations to clients, thereby reducing load on the sync service. Note:

  * PowerSync Cloud instances are automatically compacted once per day
  * Self-hosted instances can be compacted using a `docker run` command

[Read the release notes](https://releases.powersync.com/announcements/bucket-compacting)

## Flutter Client SDK Web Support

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-21b92d80d0.png)

We shipped version 1.6.3 of the PowerSync Dart SDK, which includes many improvements to our Flutter Web support.

  * Use of the new `sqlite3_web` package from Simon Binder, the maintainer of Dart’s SQLite3 and Drift packages:
    * This gives us support for database connections being shared between multiple tabs and it also seems to result in a much more responsive Flutter Web application.
  * More robust multiple tab support
    * We also implemented Navigator locks which are shared between tabs, making multiple tab support more reliable (in the future we'll implement shared sync coordination between tabs).
  * Web support in `sqlite_async.dart` (our Dart SQLite library used by our Flutter/Dart SDK)
    * This allows using the Drift ORM helper package in Flutter Web.
  * Flutter Web support is now available in the main `powersync` package (no longer in the separate `-alpha` branch)

[Read the release notes](https://releases.powersync.com/announcements/flutter-web-improvements)

## [Post] React Native Database Performance Comparison

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-5e4be5918c.png)

Our fork of `react-native-quick-sqlite` contains some changes and enhancements. To test its performance, we ran it through performance benchmark tests. We then ran other popular React Native SQLite libraries through the same tests so that we could compare relative performance.

We tested the following SQLite libraries for React Native:

  1. `op-sqlite`
  2. `react-native-quick-sqlite`
  3. PowerSync fork of `react-native-quick-sqlite`
  4. `expo-sqlite`

[Read the post](https://powersync.com/blog/react-native-database-performance-comparison)

## [Newsletter] _Local-First News_ Launched

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-ffeedce4cc.png)

We’re continuously keeping track of the latest developments in the local-first space and imagine many developers are doing the same. Since there’s so much happening, it’s easy to miss things if you’re not constantly on top of it.

We set up _Local-First News_ as a weekly newsletter that covers our own research, but also allows anyone to contribute with their finds or releases.

[Visit localfirstnews.com](http://localfirstnews.com)

## PowerSync Swag Loading…

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-3ebf03908a.png)

Our first swag order is in the works. We’re celebrating the availability of PowerSync V1.0 — which marked PowerSync becoming one of the few sync engines ready for production use. Here’s to our next big milestone!

Want to get in on some free swag? Send us your T-shirt size and a shipping address!

[Mail hello@powersync.com](mailto:hello@powersync.com)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-4f12df988a.png)

Fig is a tool for freelancers to plan for taxes and save for retirement, with automated bookkeeping and retirement planning, being built with PowerSync. We’re cheering **Jason Lewicki** on!

[Check out Fig](https://figwealth.io/)

![](https://powersync.com/images/blog/powersync-update-july-2024-inline-14547b700a.png)

Shout-out to the folks at time tracking solution WorkWeek who have recently been hitting some impressive product milestones. Keep winning **Trist Drummond** and team!

[Check out WorkWeek](https://www.workweek.co.za/)

That's it for the July update, happy coding!

---

# Local-First Key Concepts: Offline-First Vs Local-First

> What is Local-First and how does it compare to Offline-First? In this blog post we investigate how much the two terms overlap.

- Published: 2024-07-30
- Author: Phillip van der Merwe
- Category: Engineering
- Source: https://powersync.com/blog/local-first-key-concepts-offline-first-vs-local-first

---

What is Local-First and how does it compare to Offline-First? In this blog post we investigate how much the two terms overlap.

## The Evolution of Software

To understand the difference between local-first vs offline-first software, we need to start at the evolution of software.

### The Era of Desktop Apps

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-1f9a8fa4fc.png)

The first wave of consumer software ran locally on user’s computers, reading and writing files on disk. These “old school apps” are also commonly called desktop apps, local apps, or standalone apps. They worked offline and your data was private to you. The biggest downside was that your data was trapped on one device.

### The Cloud Era

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-27d3580289.png)

The era of the cloud and web apps meant that software increasingly moved online. Servers in the cloud store data centrally, and users get access on-demand via the internet.

Cloud apps became extremely popular because users could access their data from any device, and online collaboration with other users became possible.

### Offline-First

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-3815dfe1ca.png)

A bit later, in the early 2010s smartphones and mobile internet connectivity took off, and the downsides of cloud apps became clear: network latency can make apps slow and if you’re not connected to the internet, you can’t access your data. 

Developers realized that retrofitting cloud apps to work offline was complicated and prone to insidious bugs. 

The offline-first movement was born: The idea was to design apps to work offline from the start, rather than as an afterthought.

### The Local-First Era

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-3f317edd37.png)

In the late 2010s,  developers realized that we lost something else with the move to the cloud: users no longer truly owned and controlled their data.

In response, local-first was born to get the best of both worlds: the local ownership and control over data of old-school apps, and the cloud’s convenient cross-device access and multi-user collaboration.

Research lab [Ink & Switch described](https://www.inkandswitch.com/local-first/) the end-user benefits of local-first as 7 ideals:

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-aa8b5dab96.png)

2 of these ideals overlap directly with offline-first:

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-ec5b96c748.png)

2 of the ideals are about retaining the advantages of cloud apps:

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-cc8a37adf4.png)

While the remaining 3 are about giving users indefinite access to software and control over their data without being at the mercy of any service provider:

![](https://powersync.com/images/blog/local-first-key-concepts-offline-first-vs-local-first-inline-ed222ebcce.png)

The core local-first idea is that this can be achieved by architecting apps in a way similar to resilient distributed systems: where a single node can continue working even when disconnected from the larger network because:

  1. The data it needs to function is always available locally, and
  2. It can seamlessly rejoin the larger network at any time.

## The Local-First Movement

Local-first has also become more than just a description of app architecture: it is [a](https://www.localfirstconf.com/) [growing](https://localfirstweb.dev/) [movement](https://www.localfirstnews.com/).

Developers are coming together to work on generalized tools that simplify local-first development for everyone.

To achieve the ideals of local-first requires building complex distributed systems, and it doesn’t make sense to reinvent the wheel by implementing custom solutions for every project.

The local-first community has emerged as a space for like-minded developers to address this challenge, meeting and discussing ideas and solutions.

[Video: Local-first vs offline-first — short explainer](https://www.youtube.com/watch?v=kjOx-Le5gB8)

---

# React Native Database Performance Comparison

> Our fork of react-native-quick-sqlite contains some changes and improvements. To test its performance, we ran it through performance benchmark tests. We then ran other popular React Native SQLite libraries through the same tests so that we could compare relative performance.

- Published: 2024-07-12
- Updated: 2024-07-18
- Author: Mugi Khan
- Category: Engineering
- Source: https://powersync.com/blog/react-native-database-performance-comparison

---

_Updated 2024-07-18_

Our fork of `react-native-quick-sqlite` contains some changes and enhancements. To test its performance, we ran it through performance benchmark tests. We then ran other popular React Native SQLite libraries through the same tests so that we could compare relative performance.   

We tested the following in-app SQLite libraries for React Native:

  1. [`op-sqlite`](https://github.com/OP-Engineering/op-sqlite)
  2. [`react-native-quick-sqlite`](https://www.npmjs.com/package/react-native-quick-sqlite)
  3. [PowerSync fork](https://github.com/powersync-ja/react-native-quick-sqlite) of `react-native-quick-sqlite`
  4. [`expo-sqlite`](https://www.npmjs.com/package/expo-sqlite)

## Summary

  * The databases offer similar performance on iOS and varying performance on Android (dependent on device).
  * Using transactions and batching queries makes a significant difference.
  * Using WAL mode in SQLite is a great way to improve the performance of many smaller write transactions.  

## Methodology  

  * [Benchmark tests](https://github.com/powersync-ja/react-native-database-benchmarks) were loosely based on old [SQLite benchmarks](https://www.sqlite.org/speed.html) that include 16 separate tests, of which 15 were used.
  * Where available, two implementations of each database engine were tested:  

    * A ‘**default** ’ implementation where implementation simplicity was prioritized over performance: only simple optimizations such as grouping multiple writes into a single operation were included.
    * A ‘**batched** ’ implementation (if the library supported it) which aimed to reduce async operation overhead. While this may be a bit more complex to implement it does provide a performance improvement.
  * Only performance improvements that are easily found in the documentation or examples provided by the library were implemented.  

### **List of all benchmark tests used:**

  * Test 1: 1000 INSERTs
  * Test 2: 25000 INSERTs in a transaction
  * Test 3: 25000 INSERTs into an indexed table
  * Test 4: 100 SELECTs without an index
  * Test 5: 100 SELECTs on a string comparison
  * Test 7: 5000 SELECTs with an index
  * Test 8: 1000 UPDATEs without an index
  * Test 9: 25000 UPDATEs with an index
  * Test 10: 25000 text UPDATEs with an index
  * Test 11: INSERTs from a SELECT
  * Test 12: DELETE without an index
  * Test 13: DELETE with an index
  * Test 14: A big INSERT after a big DELETE
  * Test 15: A big DELETE followed by many small INSERTs
  * Test 16: Clear table  

## Notes

  1. Some differences from the SQLite benchmarks:  

     * Tables and indexes are pre-created to better match typical usage and to allow fair comparison with databases that don't support dynamic tables and indexes.
     * Tables have an explicit integer primary key "id", auto-populated by the respective databases. This is not directly used in the tests.
     * Clear instead of drop tables.
     * The exact queries may be different, but the outcome should be roughly the same.
     * The results in the tables below were averaged over 3 runs.  

  2. Notes on specific tests:  

     * Test 1: This does individual inserts — no batching or transactions. This is not recommended for large volumes, but does demonstrate the overhead per transaction.
     * Test 6: Not present, since it only creates indexes, which are avoided in these benchmark tests.
  3. Only asynchronous/non-blocking APIs are used. We think it's preferable to stay away from synchronous calls altogether because they have the potential to stutter or block the UI.  

  4. Benchmark limitations:  

     * The benchmark implementation does not measure UI performance during database operations yet. Despite the database operations being async, it may still block the UI thread in some cases.
     * No UI yet — all results are logged to the console.
     * The benchmark implementation does not test concurrent operations.

## Database-specific notes  

`op-sqlite`

  * Created as a successor to `react-native-quick-sqlite`.  

`expo-sqlite`

  * Does not provide an API to do batching operations; however Expo provides prepared statements to achieve functionality similar to batching.

PowerSync (fork of `react-native-quick-sqlite`)

  * With the read connections set to 0 and WAL mode being disabled the results are a lot closer to `react-native-quick-sqlite`. However, WAL being enabled does provide the advantage of concurrency.

## Results

All test results were averaged over 3 consecutive runs. Times are in milliseconds.  

### iOS tests

iPhone 15 Pro iOS 17.5: Expo 51

![](https://powersync.com/images/blog/react-native-database-performance-comparison-inline-f41cbf6a18.png "Table showing performance benchmark test results for each React Native database when tested on iOS. Results are in milliseconds.")

![](https://powersync.com/images/blog/react-native-database-performance-comparison-inline-1e213f4f12.png "Summed time to run all React Native performance benchmark tests, when tested on iOS (lower is better).")

  

### Android tests  

Samsung S22 Android 13: Expo 51

  * At the time of writing, `react-native-quick-sqlite` has not been updated to accommodate the `minSDK` version 23 required by Expo 51 which resulted in a build error and was addressed with a manual patch.

![](https://powersync.com/images/blog/react-native-database-performance-comparison-inline-193865b018.png "Table showing performance benchmark test results for each React Native database when tested on Android. Results are in milliseconds.")

![](https://powersync.com/images/blog/react-native-database-performance-comparison-inline-8be1b5ddbb.png "Summed time to complete all React Native performance benchmark tests, when tested on Android (lower is better).")

---

# PowerSync Update: June 2024

> The release of PowerSync Open Edition at the end of May brought the first wave of self-hosted PowerSync users in June. We’re delighted by the uptake we’ve seen so far: opening access to this mature sync engine promises to add further momentum to the local-first movement.

- Published: 2024-07-03
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-june-2024

---

The release of [PowerSync Open Edition](https://docs.powersync.com/self-hosting/getting-started) at the end of May brought the first wave of self-hosted PowerSync users in June. We’re delighted by the uptake we’ve seen so far: opening access to this mature sync engine promises to add further momentum to the local-first movement.

June also included some other product highlights, let’s get into them.

## Simplified Constructor for JavaScript SDKs

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-844bed9702.png)

The JavaScript client constructor has been simplified along the lines of our Flutter/Dart SDK. It is now possible to create client databases as follows:

```typescript
export const db = new PowerSyncDatabase({
   schema: AppSchema,
   database: {
     dbFilename: 'example.db'
   }
 });
```

[Read the release notes](https://releases.powersync.com/announcements/powersync-js-web-client-sdk)

## PowerSync Cloud: Sign Up With or Link Your GitHub Account

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-340f5d0b6a.png)

We’ve added GitHub as an SSO option for PowerSync Cloud, providing lower friction access for those who prefer this.

If you have already created a PowerSync account using your email, you can link your GitHub account for future sign-ins, provided the email addresses of the two accounts match. To do this, sign out of the Admin Portal and sign back in using "Sign in with GitHub" to connect your accounts.

[Go to your dashboard](https://accounts.powersync.com)

## Flutter SDK Updated to Use Common Rust Core

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-2d47a037f8.png)

V1.4 of our Flutter SDK introduced the use of the `powersync-sqlite-core` native extension. This is our common Rust core which means all PowerSync SDKs now use the same core logic for PowerSync functionality, improving maintainability and support.

[Read the release notes](https://releases.powersync.com/announcements/flutter-client-sdk)

## [Tutorial] Vue + PowerSync + Supabase

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-323e947b56.png)

We’ve released a step-by-step tutorial for creating an offline-first ToDo app using Vue, Supabase and PowerSync. The tutorial starts with a base app in the repo that contains basic functionality and then integrates PowerSync, using Supabase as the backend Postgres database.

The fully implemented app is also available as a branch on the repo for reference.

Thanks to **Poya Shad** for working on this!

[See the tutorial](https://powersync.com/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync)

## [Post] WebSockets as Alternative to HTTP Streaming in RN

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-43af9f8cc4.png)

PowerSync engineer **Steven Ontong** wrote engineering notes on implementing WebSocket support in our React Native SDK and PowerSync Service. The article includes a summary of the pain points with HTTP streaming in React Native, the differences between the two connection methods, and how RSocket was used.

[Read Steven’s post](https://powersync.com/blog/websockets-as-alternative-to-http-streaming-in-react-native)

## LoFi Software Discord Dev Build Day

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-3c9abffe9f.png)

Dom Bauer, Conrad Hofmeyr and Kobie Botha hosted a PowerSync Build Day on the LoFi Software Development Discord server on June 14th.

The Build Day covered the process of building a chat app using React and the PowerSync Web SDK, and self-hosting the PowerSync Service using Docker. All clients synced with a shared Fly.io Postgres, with data sync managed through Sync Rules.

[Watch the recording](https://youtu.be/uAec6W-Cp3o)

## Community Focus

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-e380f62afd.png)

Octologs, a free dive tracking app, is built with PowerSync and now available on the Apple App Store — congratulations to **Ben Mahr**!

[Check out Octologs](https://apps.apple.com/us/app/dive-log-octologs/id6449296808)

![](https://powersync.com/images/blog/powersync-update-june-2024-inline-575be7d2d8.png)

Community member **Guillem Puche** published a full guide for creating a CRUD app that uses PowerSync to enable a local-first architecture and syncs to a Neon database. We’re impressed!

[See Guillem’s guide](https://github.com/guillempuche/localfirst_react_server)

## **[Video] Local-First vs Offline-First in 100 seconds**

We’ve launched a new video series that covers key concepts behind local-first development in a concise format. Let us know what you think!

[Video: Local-First Key Concepts Series](https://www.youtube.com/watch?v=kjOx-Le5gB8)

That's it for the June update, happy coding!

---

# Local-First Software: Origins And Evolution

> Developer interest in local-first software is continuing to grow rapidly in 2024. At the same time, it’s also apparent that developers currently have different views on what they consider to be ‘local-first software’, ranging from narrower to broader definitions. This prompted us to take a closer look at the origins and evolution of local-first.

- Published: 2024-07-02
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/local-first-software-origins-and-evolution

---

Developer interest in local-first software is continuing to grow rapidly in 2024. At the same time, it’s also apparent that developers currently have different views on what they consider to be ‘local-first software’, ranging from narrower to broader definitions. This prompted us to take a closer look at the origins and evolution of local-first.

### Local-first software: The original manifesto

The research lab [Ink & Switch](https://www.inkandswitch.com/) published the original [manifesto essay](https://www.inkandswitch.com/local-first/) which coined the term ‘local-first’ in 2019, authored by [Martin Kleppmann](https://martin.kleppmann.com/), Adam Wiggins, Peter van Hardenberg and Mark McGranaghan.

Ink & Switch’s rationale __ for local-first is to get the best of both worlds of stand-alone desktop apps (so-called “old-fashioned” software) and cloud software: _“We would like both the convenient_** _cross-device access and real-time collaboration_** _provided by cloud apps, and also the_** _personal ownership of your own data_** _embodied by ‘old-fashioned’ software”._

The manifesto proceeds to define local-first as software that _“prioritizes the use of local storage (the disk built into your computer) and local networks (such as your home WiFi) over servers in remote data centers”._

It also puts emphasis on the primacy of the local copy of data: _“In local-first applications [...] we treat the copy of the data on your local device [...] as the primary copy. Servers still exist, but they hold secondary copies of your data in order to assist with access from multiple devices.”_

Expanding on this, the manifesto identifies [7 ideals](https://www.inkandswitch.com/local-first/#seven-ideals-for-local-first-software) “to strive for in local-first software”:

  * **Fast:** By accessing data locally, the software should respond near-instantaneously to user input.
  * **Multi-Device:** Data should be synchronized across all of a user’s devices.
  * **Offline:** The user should be able to read and write their data anytime, even while offline.
  * **Collaboration:** Support real-time collaboration that is on par with the best cloud apps today.
  * **Longevity:** A user’s data should continue to be accessible indefinitely, even after the company that produced the software is gone.
  * **Privacy:** The software should use end-to-end encryption.
  * **User Control:** No company should be able to restrict what a user is allowed to do with the software.

### Decentralized vs centralized architecture

One of the sometimes contentious aspects of local-first is whether it necessarily requires a decentralized architecture to be considered truly local-first. The Ink & Switch manifesto states: _“[T]o fully realize the longevity goal of local-first software, we want applications to outlive any backend services managed by their vendors, so_** _a decentralized solution is the logical end goal._**_”_

Yet if you watch [talks](https://www.youtube.com/playlist?list=PL4isNRKAwz2O9FxP97_EbOivIWWwSWt5j) from [Local-First Conf](https://www.localfirstconf.com/), listen to interviews on [localfirst.fm](https://www.localfirst.fm/), or attend [LoFi meetups](https://localfirstweb.dev/), there are several systems that describe themselves as local-first despite using a server-authoritative instead of decentralized architecture ([including](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer) our own product, PowerSync). Or at the very least, many have a critical dependency on servers for parts of their lifecycle. What gives?

I would argue that a big reason is the ultimate _complexity_ of local-first as defined by the 7 ideals: there are many thorny challenges that the developer community has yet to solve in order to enable usable and practical decentralized architecture. CRDTs address one aspect of decentralization on a data structure level (deterministic merging of updates without central server authority), but there’s much more to it. (More on this later.)

### Local-first is an ongoing movement to evolve software

That being said, prominent voices in the local-first community (including co-authors of the original manifesto) have made it clear that they believe that local-first software is a movement in pursuit of a worthy idea, and that they expect it to take years to solve the big challenges. They also encourage developers to innovate freely and bring different approaches to market in gradual pursuit of the “end-goal” of local-first.

#### Adam Wiggins’ commentary

Wiggins gave [a talk](https://youtu.be/RTa0XkQiEG8?t=2589) at the LoFi/14 meetup about local-first economics, wherein he described the Ink & Switch paper as “full of lofty principles” that asks for “a seismic shift in data persistence”. He noted that vendors offering end-user local-first software today and monetizing using a SaaS model mostly have an “authoritative server in the middle”, and that “everything to do with peer-to-peer, self-hosting and federation is still research”. 

He called for “avoiding purity calls and [No True Scotsman](https://en.wikipedia.org/wiki/No_true_Scotsman)”, and said that he believes that it is fair to describe systems with a server-authoritative architecture as ‘local-first’ as long as they focus on achieving ideals such as user ownership of data and longevity. “That is a judgment call for each individual business”.

![](https://powersync.com/images/blog/local-first-software-origins-and-evolution-inline-b87426a3bb.png)

In closing, Wiggins shared:

> “For me it’s a win if the parts of local-first that are production-ready make it into software that people are using in the real-world, especially at scale. And in the meantime, there's a huge role for the academic community and wider community [...] to take the parts that aren't ready for real-world usage yet [...] and figure out how to push that further.”

#### Martin Kleppmann’s commentary

Kleppmann gave [a talk](https://www.youtube.com/watch?v=NMq0vncHJvU) at Local-First Conf 2024 (similar to his [talk](https://www.youtube.com/watch?v=6Q0yb_ROUBQ&list=PLTbD2QA-VMnXFsLbuPGz1H-Najv9MD2-H&t=276s) at the LoFi/12 meetup) about the “past, present and future of local-first” wherein he said local-first can currently be considered “somewhat of a gradient where there’s a gray area of being somewhat local-first but not satisfying all of the ideals”. He added: “We’ve since come to realize that these 7 ideals aren’t really a good definition of what local-first is. They’re actually more about the [end-user] benefits that local-first can bring”.

He promised a follow-up to the original local-first [manifesto essay](https://www.inkandswitch.com/local-first/) and proposed a new interim definition: “In local-first software, the availability of another computer should never prevent you from working”. Kleppmann explains:

> “If [the software] doesn’t work if the app developer goes out of business and shuts down their servers, it’s not local-first. What we’re trying to get at here, is robustness not only against availability in the network sense, but availability of another computer in the sense that it got shut down and deleted all of its data. [...] On some level, the software should be resilient against the creators of that software just disappearing”.

Importantly, Kleppmann acknowledges that this vision is not yet practically achievable: The existing ways of accomplishing it (e.g. self-hosting a server, peer-to-peer architecture, [file syncing](https://tonsky.me/blog/crdt-filesync/) using mainstream tools) are not really easily workable in practice today.

![](https://powersync.com/images/blog/local-first-software-origins-and-evolution-inline-6f89f8f936.png)

However, Kleppmann goes on to propose a very interesting future solution to this problem, which he called “The Local-First Endgame”: What if an **interoperable standard sync protocol based on an open standard** existed that any vendors could implement, so that end-users could sync their data with interchangeable services? In this way, if a vendor goes out of business and shuts down their servers, end-users can seamlessly switch to an equivalent service.

![](https://powersync.com/images/blog/local-first-software-origins-and-evolution-inline-ac0782e810.png)

This is a _very appealing_ hypothetical solution. It would go a long way towards Ink & Switch’s local-first ideals, although there would still be many complexities left to solve (as we will explore a bit later).

Kleppmann is of the opinion that it’s too early to start building this kind of standardization layer. “Right now, we don’t understand the trade-offs well enough yet. But **in a few years’ time** [...] we can start our standardization committee.” 

In the meantime, he is encouraging experimentation: 

> “I’m very open-minded to lots of people building different technologies. I think that’s a great thing that there’s such lively activity in this ecosystem. The simple answer is that we don’t know yet what will work and what won’t work. **We need those thousand flowers blooming** so that we can gain experience of different approaches and understand the trade-offs better.”

He also stressed that “local-first is a set of principles and values, it’s not any one technology”.

![](https://powersync.com/images/blog/local-first-software-origins-and-evolution-inline-141a883c07.png)

The implication of Kleppmann’s proposition is quite profound: It means that **the practicable way of achieving the promise of local-first does not yet exist and won’t exist any time soon.**

### So what is ‘local-first’ in reality today?

While the end-game vision of local-first is still a work-in-progress, what would be a good description of actual “local-first” implementations today? In my view, I would say the following: (and other developers hold [similar](https://bricolage.io/some-notes-on-local-first-development/) [views](https://www.youtube.com/watch?v=VLgmjzERT08&list=PL4isNRKAwz2O9FxP97_EbOivIWWwSWt5j&index=4))

> **Note**
>
> Local-first implementation today generally refers to **apps that work with a local client database which syncs automatically with a backend database in the background**. All reads and writes go to the local database first.

We could also state it more generically: Apps with implicit automatic state transfer in the background between backend and end-user device. 

This architecture holds the promise of moving towards Martin Kleppmann’s envisioned architecture of “interoperable sync services” in the future, which would bring the software closer to achieving the local-first end-goals.

### Isn’t that about the same as offline-first?

‘Local-first’ implementations that exist in practice today are indeed typically very similar to many offline-first implementations, a term [coined in 2013](https://alistapart.com/article/offline-first/) (“[F]or a proper offline-first experience, you [...] want to store the data in the front end, and you want it to sync to the server’s data store”).

This is not surprising, since the authors of the local-first manifesto spoke of local-first as a superset of offline-first. As [Kleppmann says](https://www.youtube.com/watch?t=565&v=NMq0vncHJvU&feature=youtu.be): "Offline-first is a part of local-first. You can't be local-first without being offline-first".

Looking at Ink & Switch’s 7 ideals for local-first, the first 4 correspond directly to cloud-backed offline-first software, whereas the last 3 ideals are what makes local-first unique from offline-first. (Also see our short [explainer video](https://www.youtube.com/watch?v=kjOx-Le5gB8) on local-first vs. offline-first.)

![](https://powersync.com/images/blog/local-first-software-origins-and-evolution-inline-b111015754.png)

### Even ‘just offline-first’ is already a big win

I don’t think it’s a bad thing that local-first implementations today are largely similar to offline-first implementations.

As someone who has been at the coalface of building offline-first systems [since 2009](https://powersync.com/company), my impression is that offline-first didn’t gain as much traction in the 2010s because it was too difficult or engineering-intensive for most teams to implement, despite organizations and individual developers being well-aware of its benefits (e.g. speed and network resilience for end-users).

Therefore, in a sense the local-first movement is reinvigorating the adoption of offline-first and this is spurring a new wave of innovation in tools such as sync engines, which I believe will cause “local-first” architecture to become mainstream in a way that offline-first did not. And this would already be a win for software quality.

In fact, I’d even venture to say that the _average software end-user_ will probably care more about the end-user benefits stemming from the first 4 ideals of local-first than the latter 3: All end-users hate loading spinners and errors, and they expect to be able to access their data from anywhere and collaborate with other people. Hence, cloud-backed offline-first software gives them benefits that really matter to them:

![](https://powersync.com/images/blog/local-first-software-origins-and-evolution-inline-6d83357790.png)

On the other hand, I feel that _power users_ are more likely to care about considerations such as whether their software will continue working years in the future when its creators disappear. I think everyday end-user concerns will certainly evolve over time, e.g. end-to-end-encryption (related to #6 above: privacy) is arguably gradually on the rise as a concern of the average end-user in light of increasing high-profile data breaches.

In my experience, apps from the top software companies in the world who have virtually unlimited engineering resources (Google, Meta, etc.) still suffer from loading spinners and network-related error states in various spots in urban areas, despite aggressive caching and use of content delivery networks in edge locations. Therefore, apps with local-first/offline-first architecture which use a local data store and sync with servers in the background will have an immediate positive end-user impact. 

It is however true that the need for network resilience may slowly lessen over time as mobile network connectivity keeps improving, and technologies such as [Starlink](https://www.starlink.com/us) become more ubiquitous. Yet I don’t think that will slow down the adoption of local-first, because of one big and very important reason:

### The developer benefits are by far the biggest win of local-first

I believe that the **developer benefits of local-first are a bigger deal than the end-user benefits, and will be the biggest driver of local-first’s growth** as a software movement and architecture.

I [wrote](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web) about this in 2023, highlighting benefits such as:

  * Reduced backend complexity
  * Reduced backend compute load, dependency and cost (which also leads to increased robustness)
  * Simplified state management (local-first essentially provides “magic state transfer” from the perspective of the developer) 
  * Real-time collaboration being built-in to the architecture.

Subsequently, I’ve noticed it increasingly coming up in discussions around local-first. Here’s just a small sample of recent comments:

  * [Kleppmann](https://youtu.be/NMq0vncHJvU?t=1303) at Local-First Conf 2024: _“This is another piece that we missed in our original local-first essay 5 years ago: [It] focused very much on the [end-user] benefits, which is important, but since then, we realized that actually the benefits to the app developer are perhaps at least as big as those to the end-user”._ Kleppmann goes on to mention benefits such as: No backend engineering team needed, no 24/7 on-call rotations to keep the backend running, no more writing network error handling code, no more “paying through the nose” for cloud computing, and overall, “much simpler app development”.
  * [Tuomas Artman](https://www.youtube.com/watch?v=VLgmjzERT08&list=PL4isNRKAwz2O9FxP97_EbOivIWWwSWt5j&index=4) of Linear mentioned similar benefits at Local-First Conf 2024, and went on to say: _"_**_I'm sure I won’t ever go back to working any other way_** _. The benefits of going local-first as an engineer are so humongous that I wouldn't want to waste my time handling network errors and making network calls.”_
  * [Søren Bramer Schmidt](https://youtu.be/keZYUjAYSJM?t=229): _“[With local-first], we can have a better, faster and easier way to build applications that also delivers a much better user experience.”_
  * [André Terron](https://youtu.be/Q83xhiS2enY?list=PLTbD2QA-VMnXFsLbuPGz1H-Najv9MD2-H&t=1736) at LoFi/16: _“I get to interact with fewer layers, [I get] features for free such as collaboration, data versioning, offline-support, multi-device [...]. And it lets me build higher quality apps for less effort.”_

The impact of the developer benefits is mainly why I’m very bullish on the growth in local-first adoption that lies ahead.

### Why are the ideals of local-first difficult to achieve?

As I alluded to above, there are significant technological challenges that need to be solved for the local-first 7 ideals as envisioned by Ink & Switch to be broadly achieved. Here is just a small taste of some of the topics of ongoing exploration and research: (many of which are mentioned in the Ink & Switch [essay](https://www.inkandswitch.com/local-first/))

  * Authentication / user identity in a distributed environment.
  * Distributed authorization and permissions, especially as it intersects with collaboration and versioning: users should be able to share subsets of their data with other peers with varying permissions, and have the ability to revoke access, without servers mediating the interactions. In addition, users can go offline periodically and keep working. The essay does a good job of highlighting several of the complexities involved with this (see for example the section discussing the “kaleidoscopic complexity to our data”).
  * Peer-to-peer communication and syncing without mediation by servers, or syncing with interchangeable backend services using a standard protocol (as envisioned by Martin Kleppmann).
  * Versioning of apps and schemas (and schema migrations) in a decentralized context. _“Different collaborators may be using different versions of an application, potentially with different features. As there is no central database server, there is no authoritative ‘current’ schema for the data.”_
  * Change history accumulation.

At PowerSync, we are keeping a close eye on the developments in these domains, and will contribute to research and experimentation where it makes sense for us to do so. In the meantime, we have [documented](https://docs.powersync.com/resources/local-first-software) how developers building with PowerSync can bring their software closer to the ideals of local-first.

### Looking ahead

Local-first is a very promising software movement which will make a big difference in the quality of software, as well as the developer experience and productivity of building software. We’re excited to play a part in it, and look forward to seeing where it will go in the next few years.

---

# WebSockets As Alternative To HTTP Streaming In React Native

> Using HTTP streaming in React Native for real-time data synchronization comes with limitations, and workarounds can be cumbersome. Fortunately, React Native supports WebSockets — however, this is not a simple drop-in replacement. Thankfully, the RSocket library provides a way to implement robust WebSocket support.

- Published: 2024-06-24
- Author: Steven Ontong
- Category: Engineering
- Source: https://powersync.com/blog/websockets-as-alternative-to-http-streaming-in-react-native

---

## Streaming sync operations

Our client SDKs rely on a connection to the backend [PowerSync Service](https://github.com/powersync-ja/powersync-service) in order to sync changes from the upstream backend database to the local SQLite database. The syncing is achieved by the client following a set of commands from the server.  

Sync commands typically relate to:

  * Checking diffs between the server and local SQLite.
  * Updating sync buckets with bucket items.
  * Validation of sync [checkpoints](https://docs.powersync.com/architecture/consistency).  

Initial client SDKs used [HTTP streaming](https://www.pubnub.com/guides/http-streaming/) to create a long-lived connection which streams commands from the server to client in real-time.  

## Problems with HTTP streaming

We aim to provide support for PowerSync to a wide range of frameworks and development environments, including Flutter, React Native, web, Kotlin and Swift.   

We noticed some pain points for using HTTP streaming when developing our React Native SDK.  

React Native supplies an implementation of the common JavaScript `fetch` method. This implementation unfortunately does not support streaming request responses. If a default React Native `fetch` implementation tried to connect to our PowerSync Service instance, then sync commands would not be accessible to the client as they are emitted from the server. The client would buffer the commands — only yielding a set of commands once the HTTP request resolved completely. Typically the connection would only resolve when the token used to create it expires —which is typically in the order of magnitude of hours. This is very far from real-time syncing.   

Luckily the React Native community has encountered this issue before and created a [community implementation](https://www.npmjs.com/package/react-native-fetch-api) of `fetch` which does support HTTP streaming. Given the right setup conditions, this allows for real-time syncing between the React Native client and the server.  

Unfortunately, the setup conditions for the `fetch` method are quite cumbersome. Multiple polyfills are required, and in some cases code changes to native platform project files are required. React Native projects are no strangers to having to use JavaScript polyfills. These can be readily applied by using the [polyfills](https://www.npmjs.com/package/react-native-polyfill-globals) package which the community fetch implementation is included in. However, the network inspector and Flipper debug tools (if using Expo < 51) need to be disabled (in the native `android` project folder) if developing on the Android platform. This requirement leads to lengthy and rather complicated installation steps for our React Native SDK.  

## WebSockets are supported in React Native

React Native also has WebSocket support [available](https://reactnative.dev/docs/network). WebSockets typically also provide a long-lived connection where messages can be bi-directionally sent between a server and client in real-time.   

This connection method does not directly require any JavaScript polyfills or native project changes to provide real-time streaming. This makes it an appealing connection method for React Native clients.  

## Differences between HTTP streaming and WebSockets

Given the above, it might seem that WebSockets are a simple drop-in replacement for HTTP streams. This is unfortunately not the case.  

WebSockets provide event-driven communication while HTTP streams provide streaming communication. The devil is in the details when comparing the connection methods.  

### **Back-pressure:**

One key difference is the handling of back-pressure. The server will send commands to the client as commands are needed, but the server needs to not overload the client with a large queue of unprocessed commands. At the same time, the client should not cause a large backlog of buffered events on the server side.   

HTTP streams utilize protocol-level flow control mechanisms (`WINDOW_UPDATE` frames) to manage each stream independently. Additionally, the `Stream` and `AsyncIterator` classes, when combined, can provide built-in back-pressure support.   

The chain of the server yielding sync commands via an `AsyncGenerator` to a `ReadableStream`, which is sent over HTTP(S) to the client, which consumes a `ReadableStream` to `AsyncIterator`, which asynchronously processes the sync commands (e.g. saving data to SQLite), is automatically kept in constant balance.   

WebSockets are transmitted over TCP which also offers a protocol level of back-pressure management, but additional application logic is required to provide the same level of support as HTTP streams in conjunction with `AsyncIterator`s. This is mostly due to the server not knowing when the client has finished processing the yielded commands.  

The bi-directional nature of a WebSocket does allow for feedback from the client to mitigate the effects of back-pressure. This has to be implemented on the application layer. As we aim to provide support to multiple programming languages and frameworks, any solution needs to be supported on a wide range of languages.   

## RSocket

Implementing a cross language communications protocol with back-pressure support over WebSockets is not a minor task. Finding an off-the-shelf solution which has wide support and is highly customizable and configurable would be ideal. When searching for an existing solution, the [RSocket](https://rsocket.io/) library ticked all the criteria boxes:  

  * Its [reactive streams](https://rsocket.io/about/motivations/#reactive-streams-requestn-async-pull) provide back-pressure support by default.
  * It’s an open-source project.
  * A wide range of programming languages and pluggable network transport layers are supported:

![](https://powersync.com/images/blog/websockets-as-alternative-to-http-streaming-in-react-native-inline-90373befc9.png)

  * It’s a well-designed solution with a well thought-out specification. See the [protocol](https://rsocket.io/about/protocol/) for more information.   

Reactive streams work on a client credit basis. See the [docs](https://rsocket.io/about/protocol/#flow-control) for more information. Essentially, the client requests N amount of commands from the server. The client is free to take its time to process these commands as they arrive. The server will only yield and respond with more commands once the client has requested them — which is typically triggered once the client has finished processing a subset of instructions  

## Implementing RSocket in Server and Client

Our backend PowerSync Service is a TypeScript project, with source now available (see [here](https://github.com/powersync-ja/powersync-service)). We made use of the `rsocket-core` and `rsocket-websocket-server` packages to implement the routing for our `/sync/stream` endpoint.   

Due to React Native containing the most pain points with HTTP streaming, we added socket support to our JavaScript/TypeScript SDKs using the `rsocket-core` and `rsocket-websocket-client` packages.  

We currently default to using HTTP streaming in our React Native client SDK, and allow developers to switch to WebSockets using a configuration parameter. See our [docs](https://docs.powersync.com/client-sdk-references/react-native-and-expo#developer-notes) for details.

## Next steps

We started with React Native due to the reasons mentioned above, but the next step for us is to implement WebSockets in our other client SDKs.

## Thoughts or questions? Get in touch

If you have any questions or feedback, [join us on Discord](https://discord.gg/powersync).

---

# Vue Tutorial: Offline-First ToDo App With Supabase And PowerSync

> Using an in-app SQLite database with Vue enables instantly reactive user experiences. This step-by-step tutorial covers constructing an offline-first ToDo app using Vue, Supabase, and PowerSync. Allocate approximately 30 to 45 minutes to complete this tutorial.

- Published: 2024-06-12
- Author: Poya Shad (Guest author)
- Category: Tutorial
- Source: https://powersync.com/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync

---

(See this tutorial on GitHub [here](https://github.com/powersync-ja/vue-supabase-todolist-template/blob/main/README.md))

Offline-first Vue apps enable instantly reactive user experiences by leveraging a local in-app database. This tutorial will guide you through the process of constructing an offline-first ToDo app using Vue, Supabase, and PowerSync. Allocate approximately 30 to 45 minutes to complete this tutorial.

![](https://powersync.com/images/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync-inline-f7792eb4f6.png  "PowerSync lets you sync only relevant data to each user, while retaining control of what data should be written back to your backend database.")

## Prerequisites

Before diving in, ensure you have active accounts with both Supabase and PowerSync. If you haven't signed up yet, do not worry, you can get started with PowerSync for free [here](https://accounts.powersync.com/portal/powersync-signup), and with Supabase [here](https://supabase.com/dashboard). Additionally, make sure you have Vue set up on your system.

We will cover the following steps:

  1. Set up a Supabase project and publication to PowerSync.
  2. Configure PowerSync.
  3. Set up the Vue Project.
  4. Integrate PowerSync.
  5. Test the offline-first functionality.

## 1\. Set Up a Supabase Project and Publication to PowerSync

### 1.1. Create a New Supabase Project

  1. Navigate to the Supabase dashboard.
  2. Create a new project.
  3. Remember to **save the password** the database password as it will be required later.
  4. Wait for the project to be created.
  5. For easier testing, in your Supabase dashboard, go to Authentication > Providers > Email > Toggle Confirm Email. This will remove the need to verify test user email addresses. 

![](https://powersync.com/images/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync-inline-3610c2e1a5.png  "For easier testing, disable email verification.")

### 1.2. Create Tables for the ToDo App

Navigate to the SQL editor and execute the following SQL query to create the tables:

```sql
create table public.todos (
  id uuid not null default gen_random_uuid(),  
  created_at timestamp with time zone not null default now(),  
  description text not null,  
  completed boolean not null default false,  
  constraint todos_pkey primary key (id)
) tablespace pg_default;
```

### 1.3. Add Tables to the Publication

```sql
create publication powersync for table public.todos
```

## 2\. Configure PowerSync

### 2.1. Connect PowerSync to your Supabase database

**1\. Create a New Instance:**

  * Navigate to the PowerSync dashboard Project tree.
  * Click on "Create new instance".

![project-tree](https://powersync.com/images/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync-inline-39f7f7b194.png)

  * Provide a name for your instance, e.g., "Supabase testing".

**2\. Adjust Cloud Region (Optional):**

  * Under the "General" tab, modify the cloud region if needed (e.g. from US to EU or JP).

**3\. Set Up Database Connection:**

  * In the "DB Connections" tab, click on the + icon.

**4\. Retrieve Connection Details from Supabase:**

  * In your Supabase dashboard, navigate to "Project Settings" -> "Database" -> "Connection string" and select the "URI" tab.
  * Uncheck the "Display connection pooler" checkbox. 

![](https://powersync.com/images/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync-inline-daeabfc0ed.png)

  * Copy the connection string. The hostname should be db..supabase.co, and not, for example, aws-0-us-west-1.pooler.supabase.com
  * Paste it into the PowerSync Instance URI field.
  * Enter the password that you saved earlier - the one you used to create the database

**5\. Test Connection:**

  * Click "Test Connection" and resolve any errors.

**6\. Client Auth:**

  * Under the "Client Auth" tab, enable "Use Supabase Auth".

**7\. Save Changes:**

  * Click "Save and Deploy".

### 2.2. Set Up Sync Rules

Sync Rules empower developers to manage data synchronization to user devices, employing a SQL-like syntax within a YAML file. The rules are deployed to the PowerSync instance, ensuring that the data is synchronized correctly. In this tutorial, we will use a simple sync rule to synchronize the ToDo app data.

```yaml
# Sync Rules docs: https://docs.powersync.com/usage/sync-rules
bucket_definitions:
  global:
    data:
      # Sync all todos
      - SELECT * FROM todos
```

  1. Open the **sync-rules.yaml** file.
  2. Replace its contents with the following:

So it looks like this:

![](https://powersync.com/images/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync-inline-88030f2f3d.png)

3. In the top right corner of the sync-rules panel, click **\"Validate sync rules\"** to ensure the syntax is correct. 4. In the top right corner, click **\"Deploy sync rules\"** and select the instance you created earlier. 5. Confirm in the dialog and wait for the deployment to complete.

## 3\. Set Up the Vue Project

Download this repository and navigate to the project directory. Run the following command to install the required dependencies:

```bash
pnpm install
```

Also install ``vite-plugin-wasm`` and ``vite-plugin-top-level-await`` for the WebAssembly and top-level await support and ``js-logger`` for logging:

```bash
pnpm install vite-plugin-wasm vite-plugin-top-level-await js-logger
```

Add ``.env.local`` file in the root directory and add the following environment variables:

You will find the ``supabase url`` and ``anon key`` in the Supabase dashboard under the project settings > API.

The ``powersync url`` can be found in the PowerSync dashboard by right-clicking on the instance and selecting "Edit instance". The URL is displayed in the "General" tab.

```javascript
VITE_SUPABASE_URL=https://<your-supabase-url>.supabase.co
VITE_SUPABASE_ANON_KEY=<your-supabase-anon-key>
VITE_POWERSYNC_URL=https://<your-powersync-url>.journeyapps.com
```

Start the development server:

```bash
pnpm dev
```

Quit the development server by pressing ``Ctrl + C``

## 4\. Integrate PowerSync & Supabase

Install the Supabase client library:

```bash
pnpm install @supabase/supabase-js
```

### 4.1. Create a Supabase Connector

In the folder named ``library`` in the ``src`` directory and create a file named ``SupabaseConnector.ts``.

```typescript
import {
  AbstractPowerSyncDatabase,
  BaseObserver,
  CrudEntry,
  PowerSyncBackendConnector,
  UpdateType,
} from "@powersync/web";

import { Session, SupabaseClient, createClient } from "@supabase/supabase-js";

export type SupabaseConfig = {
  supabaseUrl: string;
  supabaseAnonKey: string;
  powersyncUrl: string;
};

/// Postgres Response codes that we cannot recover from by retrying.
const FATAL_RESPONSE_CODES = [
  // Class 22 — Data Exception
  // Examples include data type mismatch.
  new RegExp("^22...$"),
  // Class 23 — Integrity Constraint Violation.
  // Examples include NOT NULL, FOREIGN KEY and UNIQUE violations.
  new RegExp("^23...$"),
  // INSUFFICIENT PRIVILEGE - typically a row-level security violation
  new RegExp("^42501$"),
];

export type SupabaseConnectorListener = {
  initialized: () => void;
  sessionStarted: (session: Session) => void;
};

export class SupabaseConnector
  extends BaseObserver<SupabaseConnectorListener>
  implements PowerSyncBackendConnector
{
  readonly client: SupabaseClient;
  readonly config: SupabaseConfig;

  ready: boolean;

  currentSession: Session | null;

  constructor() {
    super();
    this.config = {
      supabaseUrl: import.meta.env.VITE_SUPABASE_URL,
      powersyncUrl: import.meta.env.VITE_POWERSYNC_URL,
      supabaseAnonKey: import.meta.env.VITE_SUPABASE_ANON_KEY,
    };

    this.client = createClient(
      this.config.supabaseUrl,
      this.config.supabaseAnonKey,
      {
        auth: {
          persistSession: true,
        },
      }
    );
    this.currentSession = null;
    this.ready = false;
  }

  async init() {
    if (this.ready) {
      return;
    }

    const sessionResponse = await this.client.auth.getSession();
    this.updateSession(sessionResponse.data.session);

    this.ready = true;
    this.iterateListeners((cb) => cb.initialized?.());
  }

  async login(username: string, password: string) {
    const {
      data: { session },
      error,
    } = await this.client.auth.signInWithPassword({
      email: username,
      password: password,
    });

    if (error) {
      throw error;
    }

    this.updateSession(session);
  }

  async fetchCredentials() {
    const {
      data: { session },
      error,
    } = await this.client.auth.getSession();

    if (!session || error) {
      throw new Error(`Could not fetch Supabase credentials: ${error}`);
    }

    console.debug("session expires at", session.expires_at);

    return {
      endpoint: this.config.powersyncUrl,
      token: session.access_token ?? "",
      expiresAt: session.expires_at
        ? new Date(session.expires_at * 1000)
        : undefined,
    };
  }

  async uploadData(database: AbstractPowerSyncDatabase): Promise<void> {
    const transaction = await database.getNextCrudTransaction();

    if (!transaction) {
      return;
    }

    let lastOp: CrudEntry | null = null;
    try {
      // Note: If transactional consistency is important, use database functions
      // or edge functions to process the entire transaction in a single call.
      for (const op of transaction.crud) {
        lastOp = op;
        const table = this.client.from(op.table);
        let result: any;
        switch (op.op) {
          case UpdateType.PUT:
            const record = { ...op.opData, id: op.id };
            result = await table.upsert(record);
            break;
          case UpdateType.PATCH:
            result = await table.update(op.opData).eq("id", op.id);
            break;
          case UpdateType.DELETE:
            result = await table.delete().eq("id", op.id);
            break;
        }

        if (result.error) {
          console.error(result.error);
          throw new Error(
            `Could not update Supabase. Received error: ${result.error.message}`
          );
        }
      }

      await transaction.complete();
    } catch (ex: any) {
      console.debug(ex);
      if (
        typeof ex.code == "string" &&
        FATAL_RESPONSE_CODES.some((regex) => regex.test(ex.code))
      ) {
        /**
         * Instead of blocking the queue with these errors,
         * discard the (rest of the) transaction.
         *
         * Note that these errors typically indicate a bug in the application.
         * If protecting against data loss is important, save the failing records
         * elsewhere instead of discarding, and/or notify the user.
         */
        console.error(`Data upload error - discarding ${lastOp}`, ex);
        await transaction.complete();
      } else {
        // Error may be retryable - e.g. network error or temporary server error.
        // Throwing an error here causes this call to be retried after a delay.
        throw ex;
      }
    }
  }

  updateSession(session: Session | null) {
    this.currentSession = session;
    if (!session) {
      return;
    }
    this.iterateListeners((cb) => cb.sessionStarted?.(session));
  }
}
```

### 4.2. Create a Supabase Plugin

In the folder named `plugins` in the `src` directory, create a file named ``supabase.ts``.

```typescript
// src/plugins/supabase.ts
import { SupabaseConnector } from "../library/SupabaseConnector";

export const supabase = new SupabaseConnector();
```

### 4.3. Install the PowerSync SDK and Vue Wrapper

```bash
pnpm install @powersync/web @powersync/vue @journeyapps/wa-sqlite
```

### 4.4. Create a PowerSync Vue Plugin

In the folder named ``plugins`` in the ``src`` directory and create a file named ``powersync.ts``.

```typescript
// src/plugins/powersync.ts
import { AppSchema } from "../library/AppSchema.ts";
import { WASQLitePowerSyncDatabaseOpenFactory } from "@powersync/web";
import { createPowerSyncPlugin } from "@powersync/vue";

export const powerSync = new WASQLitePowerSyncDatabaseOpenFactory({
  dbFilename: "vue-todo.db",
  schema: AppSchema,
}).getInstance();

export const powerSyncPlugin = createPowerSyncPlugin({ database: powerSync });
```

### 4.5. Create a PowerSync Database Schema

In the folder named ``library`` in the ``src`` directory, create a file named ``AppSchema.ts``.

```typescript
// src/library/AppSchema.ts
// the id column is automatically added to all tables so you don't need to define it here
import { column, Schema, TableV2 } from "@powersync/web";

export const TODOS_TABLE = "todos";

const todos = new TableV2({
  created_at: column.text,
  description: column.text,
  completed: column.integer,
});

export const AppSchema = new Schema({
  todos,
});

export type Database = (typeof AppSchema)["types"];
export type TodoRecord = Database["todos"];
```

### 4.6. Initialize PowerSync

In your ``main.ts`` file, set up app-wide accessibility of PowerSync composables.

```typescript
// main.ts
import { createApp } from "vue";
import { createAppRouter } from "./plugins/router";
import App from "./App.vue";
import "./style.css";
import { powerSyncPlugin } from "./plugins/powersync";

const app = createApp(App);
const router = createAppRouter();

app.use(router);
app.use(powerSyncPlugin);
app.mount("#app");
```

### 4.7. Update the App.vue File to Initialize PowerSync and Supabase

Update the ``App.vue`` file to initialize PowerSync and Supabase when the app is mounted.

```typescript
<script setup lang="ts">
import { onMounted } from "vue";
import Logger from "js-logger";
import { powerSync } from "./plugins/powersync";
import { supabase } from "./plugins/supabase";

Logger.useDefaults();
Logger.setLevel(Logger.DEBUG);

onMounted(async () => {
  await powerSync.init();
  await powerSync.connect(supabase);
  await supabase.init();
});
</script>

<template>
  <router-view />
</template>
```

### 4.8. Update the TodoList.vue File

Update the ``TodoList.vue`` file to use the PowerSync SDK for managing todos. Uncomment the code blocks in the HTML template section.

Replace the script section with the following code:

```typescript
// TodoList.vue
<script setup lang="ts">
import { ref } from "vue";
import { usePowerSync, useQuery, useStatus } from "@powersync/vue";
import { TodoRecord } from "../library/AppSchema";
import { supabase } from "../plugins/supabase";
import { useRouter } from "vue-router";

const powersync = usePowerSync();
const router = useRouter();
if (!supabase.ready) {
  supabase.registerListener({
    initialized: () => {
      /**
       * Redirect if on the entry view
       */
      if (supabase.currentSession) {
        router.push("/");
      } else {
        router.push("/login");
      }
    },
  });
} else {
  router.push("/");
}

const status = useStatus();

// Log out and return to the log in screen
// Clears the local database
const logout = async () => {
  await powersync.value.disconnectAndClear();
  await supabase.client.auth.signOut();
  router.push("/login");
};

// Define a type for the Todo item
type Todo = TodoRecord;

const newTodo = ref<string>("");
const { data: todos } = useQuery<Todo>("SELECT * from todos");

const addTodo = async () => {
  if (newTodo.value.trim()) {
    await powersync.value.execute(
      "INSERT INTO todos (id, created_at, description, completed) VALUES (uuid(), datetime(), ?, ?) RETURNING *",
      [newTodo.value, 0]
    );
    newTodo.value = "";
  }
};

const updateTodo = async (index: number) => {
  const todo = todos.value[index];
  await powersync.value.execute("UPDATE todos SET completed = ? WHERE id = ?", [
    !todo.completed,
    todo.id,
  ]);
};

const removeTodo = async (index: number) => {
  const todo = todos.value[index];
  await powersync.value.execute("DELETE FROM todos WHERE id = ?", [todo.id]);
};
</script>
```

As you can see, we've defined a type for the Todo item and updated the methods to interact with the PowerSync database.

  * The ``usePowerSync`` composable is used to access the PowerSync instance. The ``execute`` method is used to execute SQL queries,
  * The ``useQuery`` composable is used to have a live view of a certain SQL query from the database, if the underlying data changes the query will automatically re-execute. It's stored in the ``todos`` ref.
  * The ``newTodo`` ref is used to store the text of the new todo.
  * The ``todos`` ref is automatically updated after adding, updating, or removing todos from the database.
  * The ``addTodo``, ``updateTodo``, and ``removeTodo`` methods are used to add, update, and remove todos from the database, respectively.
  * The ``useRouter`` composable is used to navigate between routes. If the user is not logged in, they are redirected to the login page.

### 4.9. Go to Login.vue and Register.vue and uncomment the commented code and code blocks

In the ``Login.vue`` and ``Register.vue`` files, uncomment the code blocks that handle the login and registration logic.

### 4.10. Update the Vite Config

Update the ``vite.config.ts`` file to include the following configuration:

```typescript
import { defineConfig } from "vite";
import vue from "@vitejs/plugin-vue";
import wasm from "vite-plugin-wasm";
import topLevelAwait from "vite-plugin-top-level-await";
import { fileURLToPath, URL } from "node:url";

export default defineConfig(({ command }) => {
  const isDev = command === "serve";

  return {
    plugins: [vue(), wasm(), topLevelAwait()],
    define: { "process.env": {} },
    resolve: {
      alias: {
        "@": fileURLToPath(new URL("./src", import.meta.url)),
      },
      extensions: [".js", ".json", ".jsx", ".mjs", ".ts", ".tsx", ".vue"],
    },
    optimizeDeps: {
      // Don't optimize these packages as they contain web workers and WASM files.
      // https://github.com/vitejs/vite/issues/11672#issuecomment-1415820673
      exclude: ["@journeyapps/wa-sqlite", "@powersync/web"],
      include: [
        "@powersync/web > uuid",
        "@powersync/web > event-iterator",
        "@powersync/web > js-logger",
        "@powersync/web > lodash/throttle",
        "@powersync/web > can-ndjson-stream",
        "@powersync/web > bson",
        "@powersync/web > buffer",
        "@powersync/web > rsocket-core",
        "@powersync/web > rsocket-websocket-client",
        "@powersync/web > cross-fetch",
      ],
    },
    worker: {
      format: "es",
      plugins: () => [wasm(), topLevelAwait()],
    },
    build: {
      sourcemap: !isDev, // Disable sourcemaps in development
    },
  };
});
```

## 5\. Test the Offline-First Functionality

After setting up everything, you can test the offline-first functionality by disconnecting your device from the internet and ensuring that the ToDo app continues to work seamlessly.

  1. Build the app

```bash
pnpm build
```

  2. Serve the app

```bash
pnpm serve
```

  1. Open ``localhost:5173`` in your browser you will be redirect to the login page. Click on register a new account and then use the credentials to login.
  2. Add a new todo and then disconnect your device from the internet.
  3. Add, update, or remove todos while offline.
  4. Reconnect to the internet and observe the synchronization of the todos.
  5. Verify that the todos are synchronized and shown in the supabase dashboard.

[Video: Vue Tutorial: Offline-First Todo App with Supabase and PowerSync](https://www.youtube.com/watch?v=P4FowRuFGLU)

Congratulations! You have successfully built an offline-first ToDo app using Vue, Supabase, and PowerSync.

## Complete Implementation Available

An example with everything above implemented is available on the ``completed`` branch [here](https://github.com/powersync-ja/vue-supabase-todolist-template/tree/completed).

---

# PowerSync Update: May 2024

> Self-host PowerSync for free: PowerSync Open Edition is now available. Read more about everything that went down in May.

- Published: 2024-06-04
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-may-2024

---

Big news came right at the end of May at Local-First Conf in Berlin: **PowerSync Open Edition** is now available!

This release should build even more momentum in the local-first movement which seems to be gathering speed on a daily basis, most recently evidenced by the first ever Local-First Conf, held last week.

## **Now Available: PowerSync Open Edition**

![](https://powersync.com/images/blog/powersync-update-may-2024-inline-bc35a40989.png)

PowerSync Open Edition is a free, self-hosted, source-available version of PowerSync that contains all the same core functionality as PowerSync Cloud.

As PowerSync was initially spun-off from a closed-source project, a significant amount of work was required to get to this major milestone for us. We also hope this will be a catalyst for the local-first movement: a battle-tested sync service is now freely available for anyone to run.

The Open Edition is licensed under the Functional Source License (FSL), which lets you use, modify and redistribute the code for commercial and non-commercial use. Software under FSL converts to a OSI-approved open-source license 2 years after it is released.

Read about the [New Open Era for PowerSync](https://powersync.com/blog/new-open-era-for-powersync) and [What PowerSync Open Edition Means for Local-First](https://powersync.com/blog/what-powersync-open-edition-means-for-local-first).

## **JS Web SDK Now V1 Stable**

![](https://powersync.com/images/blog/powersync-update-may-2024-inline-48ba213565.png)

Our JS Web SDK is now v1 stable. Since we initially released our web SDK into Beta in November 2023, we’ve kept our usual mantra in mind: Keep it stable, make it scale, zero data loss. We’re happy that the Web SDK is now ready for production use. We also added a mechanism for throttling watch callback executions as part of this release.

Thanks to everyone who used the beta version and gave feedback!

[Read the release notes](https://releases.powersync.com/announcements/powersync-js-web-client-sdk)

## **WebSocket Support for React Native and JS Web SDKs**

![](https://powersync.com/images/blog/powersync-update-may-2024-inline-e599b7f8ad.png)

WebSocket support for streaming sync updates from the PowerSync Service has been added as a connection option and is available in our React Native and JS Web SDKs. WebSocket support will be released to other client SDKs soon (these currently use HTTP streams). This is a foundational release for our planned support of BLOB column types.

This release coincided with a few other performance improvements including a roughly 3x reduction in peak memory usage in the PowerSync Service when clients sync large volumes of data.

Thanks to **Frank C** and **@BitVoyager** , for your valuable input.

[Read the release notes](https://releases.powersync.com/announcements/improved-performance-web-socket-support-and-more-updates-to-the-powersync-service)

## **Inspect a Local Database With The Diagnostics App**

![](https://powersync.com/images/blog/powersync-update-may-2024-inline-471d1ebf1c.png)

This diagnostics app presents data from the perspective of a specific user (no server-side stats) and can be used to:

  * See stats about the user's local database.
  * Inspect tables and sync buckets on the device.
  * Get started quickly — play around with a SQLite database without creating an app.
  * Serve as a baseline to compare your own apps against if you run into issues.

[Check out the app](https://github.com/powersync-ja/powersync-js/tree/main/tools/diagnostics-app)

## **Better Organization and Project Management**

![](https://powersync.com/images/blog/powersync-update-may-2024-inline-d1fc5844e4.png)

Some major behind-the-scenes releases have leveled up administrative functionality for PowerSync Cloud users. In addition to adding developers to organizations, organizations and projects can now be renamed and subscription billing plans are available for self-sign up and management.

[Go to your dashboard](https://accounts.powersync.com/)

## **Enterprise Self-Hosted Edition Released**

![](https://powersync.com/images/blog/powersync-update-may-2024-inline-7c1d6944d3.png)

In addition to the Open Edition, we released a self-hosted version of our Enterprise plan, for enterprise customers who require advanced features, support and compliance, while also needing control of their own hosting.

This edition will eventually also offer additional premium features focused on larger and more complex deployments.

[Compare self-host versions](https://powersync.com/pricing)

## **[Video] PowerSync in 100 Seconds**

H/T [**Fireship**](https://www.youtube.com/fireship) for inspiring us to explain PowerSync in this format.

That's it for the May update, happy coding!

[Video: PowerSync update — May 2024](https://www.youtube.com/watch?v=MGQP3DmZG00)

---

# A New Open Era For PowerSync

> Today we announced a big milestone at Local-First Conf: the launch of PowerSync Open Edition, a free self-hosted and source-available version of PowerSync. In this post, I will provide background on the philosophy and vision that led us here and will guide us into the future.

- Published: 2024-05-31
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/new-open-era-for-powersync

---

Today we [announced](https://powersync.com/blog/powersync-open-edition-release) a big milestone at _Local-First Conf_ : the launch of PowerSync Open Edition, a free self-hosted and source-available version of PowerSync. In this post, I will provide background on the philosophy and vision that led us here and will guide us into the future.

## Why an Open Edition?

There are undoubtedly many benefits to open-source software: End-users benefit from the transparency and freedom — they can freely access, use, review, copy, modify, redistribute and collaborate on the code. Creators/maintainers benefit from the fact that open collaboration within a developer community is the best way to build software. Having a community of developers reviewing, giving feedback and contributing to code results in the best possible end-product.

Not surprisingly, many organizations and individuals value the freedom and openness that comes with open-source software. At the same time, in recent years many developers have realized that _sustainability_ is key to open-source. Underfunding of open-source projects has [caused](https://en.wikipedia.org/wiki/Heartbleed#Root_causes,_possible_lessons,_and_reactions) disastrous cases such as the OpenSSL Heartbleed and Log4Shell vulnerabilities. Adequately funding the investment in open-source development is important. As a result, organizations creating open-source projects have prioritized the ability to build a healthy business. Models have emerged such as open-core, where the core of the product is open-source, and premium/advanced features (typically aimed at larger commercial deployments) are available as add-ons.

Even before we launched the first beta of PowerSync in mid-2023, we planned on moving to an “open-core”-like model, and have now made that a reality.

## What is the Open Edition?

Your first reaction to this news may be to wonder whether the “Open Edition” is merely a watered-down or hamstrung version of PowerSync. We wanted to avoid that mistake. It was important for us to make sure that our Open Edition is powerful and capable — it should include everything that makes the core value proposition of PowerSync possible. 

Here is how we decided to structure the available editions of PowerSync:

  * **PowerSync Cloud** : The cloud-hosted version of PowerSync that’s been available since we originally launched in 2023. Offers Free, Pro and Enterprise plans. The Enterprise plan will eventually [offer](https://powersync.com/pricing) some premium features focused on larger enterprises. Includes the [PowerSync Dashboard](https://docs.powersync.com/usage/tools/powersync-dashboard): a visual interface for managing PowerSync instances.
  * **PowerSync Enterprise Self-Hosted Edition** : ([released 2024-05-16](https://powersync.com/blog/introducing-our-enterprise-self-hosted-edition)) A self-hosted version of our Enterprise plan, for enterprise customers who require advanced features, support and compliance, while also needing control of their own hosting. This edition will eventually also [offer](https://powersync.com/pricing) additional premium features focused on larger and more complex deployments.
  * **PowerSync Open Edition** : The free, self-hosted, source-available version of PowerSync that contains all the same core functionality as PowerSync Cloud and Enterprise Self-hosted. Does not include the [PowerSync Dashboard](https://docs.powersync.com/usage/tools/powersync-dashboard).

We are already investing millions of dollars into the R&D of PowerSync, and our commercial editions will enable us to continue to support and sponsor our Open Edition.

## Why now?

PowerSync [was spun off](https://powersync.com/company) in 2023 from a closed-sourced cloud-hosted product (a rapid app development platform). Offering an open-core self-hosted product was not something that we had done before. Getting the organizational, legal and technical aspects ready was altogether a significant project for us. We started laying the groundwork last year, and have now reached our release milestone.

## How is it licensed?

If you’ve been paying attention to major open-source projects in the last few years, you may be well aware of the “open-source licensing war”. Big cloud providers have taken successful open-source products and provided them as a service, capturing virtually all the value and not investing back into the community. This has been widely characterized as against the spirit of open-source. The creators of major open-source projects fought back by switching to licenses that protect them against “free-riding” and unfair competition — by restricting other cloud service providers from offering the product as a service, while preserving the principles of openness, transparency, and collaboration. 

However, these changes in licensing were not without significant controversy: Developers saw it as a bait-and-switch. For years, major open-source projects flourished under fully permissive licensing, and then changed the licensing after achieving widespread adoption. 

In deciding on licensing for the PowerSync Open Edition, we realized that _we never wanted to be in a future position where we had to backtrack on our licensing_. We wanted to choose a license from the start that we can stick to indefinitely.

After careful consideration, we settled on adopting the [Functional Source License](https://fsl.software/) (FSL) created by Sentry. The goal of the FSL is to balance user freedom and developer sustainability. [As Sentry explains](https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/), “In plain language, you can do anything with FSL software except economically undermine its producer through harmful free-riding. You can read it, learn from it, run it internally, modify it, and propose improvements back to the producer.”

The FSL gives you freedom to do almost anything you could do with a regular open-source license: copy, modify, and redistribute the code for non-commercial and commercial use. The only thing it disallows is providing a paid offering that is competitive to the creator — that right is reserved for the main creator/maintainer of the project. 

Another important aspect of the FSL is that the licensed software converts to a permissive license 2 years after its release. In the case of PowerSync Open Edition, we chose the Apache 2.0 license as our ‘Future License’ in the FSL. Unlike the MIT license, the Apache 2.0 license includes an explicit grant of patent rights from contributors/maintainers to users, which protects our users from patent litigation related to their use of the software. Since we are the primary maintainers, and since we hold related patents, we felt the Apache 2.0 license would provide users with peace of mind and legal clarity.

FSL is not technically “open-source”, because it doesn’t meet the strict criteria of the [Open Source Initiative](https://opensource.org/) (OSI) which governs the official open-source definition (in which no usage restrictions are permitted). FSL is better described as a “source-available” license. Some folks have described FSL as “eventually open-source” because of the conversion to an OSI-approved license after 2 years. As [Confluent has noted](https://www.confluent.io/confluent-community-license-faq/), some people use the phrase “open-source” in a loose sense to mean that you can freely download, modify, and redistribute the code, and those things are all true under a license like the FSL.

Lastly, it’s worth noting that only the server-side [PowerSync Service](https://docs.powersync.com/architecture/powersync-service) is licensed under FSL. Since we want to make our software as open as possible, our client SDKs and other supporting client-side packages are [open-source](https://powersync.com/open-source) under OSI-approved permissive licenses (Apache 2.0 and MIT).

## Looking ahead

We are excited to enter this new era of openness and transparency. We look forward to collaborating with the PowerSync developer community to take PowerSync to new heights, as well as with the broader local-first community to [help accelerate](https://powersync.com/blog/what-powersync-open-edition-means-for-local-first) the adoption of local-first.

We are pleased that the release of the Open Edition brings several immediate benefits to developers using PowerSync: You can inspect the code. You can debug it more easily. You can fork and modify it when needed. You can use it without having to worry about pricing or any commercial aspects. And you are not locked into a proprietary vendor, so you never have to worry about the future of the project’s creator.

Feedback or questions? Join us [on Discord](https://discord.gg/powersync) to discuss.

---

# PowerSync Open Edition Release

> Today we officially announced our Open Edition at Local-First Conf. We are making the PowerSync source code open, free to use and free to modify under the Functional Source License. Unless you’ve been closely following the open-source wars, you’ve probably never heard of this license. For more details on it and why we chose it, see this accompanying blog post.

- Published: 2024-05-31
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/powersync-open-edition-release

---

Today we officially announced our Open Edition at [Local-First Conf](https://www.localfirstconf.com/). We are making the PowerSync source code open, free to use and free to modify under the [Functional Source License](https://powersync-v5.design.webflow.com/legal/fsl). Unless you’ve been closely following the open-source wars, you’ve probably never heard of this license. For more details on it and why we chose it, see this [accompanying blog post](https://powersync.com/blog/new-open-era-for-powersync).

With the Open Edition, customers will be able to develop on a fully local stack and also deploy a mature, production-grade sync system into their architecture for complete data sovereignty and control. This has been a long time in the making!

## The PowerSync Open Edition

With our Open Edition, you get a fully-featured sync service for building local-first apps that can be used in your preferred local development and/or your preferred deployment environment.  

The Open Edition is currently marked as a beta release — this is because we’re still polishing the docs and developer experience. The core tech itself is stable and ready for production deployments.

Our Open Edition is fully featured. It’s important to us that our Open Edition customers don’t experience it as hamstrung or arbitrarily restricted, and I strongly believe we have delivered on this front. Our Open Edition is feature equivalent with what you get if you sign up for [PowerSync Cloud](https://powersync.com/pricing), and we intend on keeping it that way.   

The code is [available on GitHub](https://github.com/powersync-ja/powersync-service) and an image is published on [Docker Hub](https://hub.docker.com/r/journeyapps/powersync-service). 

The sync service ([PowerSync Service](https://docs.powersync.com/architecture/powersync-service)) is a Node.js app that uses:

  * A fork of `pgwire` for streaming changes from Postgres
  * MongoDB for storing sync buckets internally, and
  * RSocket for WebSocket streaming to clients (HTTP streaming also supported).

See the diagram below for the components of a successful deployment:

![](https://powersync.com/images/blog/powersync-open-edition-release-inline-44eb7f1016.png)

In the diagram above, the direction of the data flow does not always match up with the networking requests, so the below table lists the connection paths and types.

| Request Originator | Destination | Protocol | Description |
| --- | --- | --- | --- |
| PowerSync Service | Postgres | TCP | Stream WAL |
| PowerSync Service | MongoDB | TCP | Write sync buckets |
| PowerSync Service | OpenTelemetry Collector | TCP or UDP | Push usage metrics |
| PowerSync Service | JWKS Endpoint | TCP (HTTPS) | Get JWT public key(s) |
| App Client | PowerSync Service (via LB) | TCP (HTTPS) | Get PowerSync JWT |
| App Client | App Backend | TCP (HTTPS) | Upload local changes |
| App Backend | Postgres | TCP | Write changes to Postgres |
  
Core activities required by you to integrate PowerSync into your self-hosted stack are therefore:

  1. Enable logical replication in your Postgres
  2. Configure the PowerSync Service
  3. Update your backend (generate a JWT for clients with a new or existing endpoint; expose a new endpoint (or endpoints) to accept client changes)
  4. Import the client SDK into your app

We have an ever-expanding library of demos for all the above available [here](https://docs.powersync.com/resources/demo-apps-example-projects).

## Roadmap

Some highlights form our near-term roadmap for the Open Edition are:

  * Wrap up housekeeping e.g. enable building from source (we’re still removing the last internal component)
  * Additional deployment templates, e.g. [Fly.io](https://fly.io/) and [Railway](https://railway.app/)
  * Extensibility. The service is built using a pluggable architecture so customers will eventually be able to inject their own sync modules e.g. custom logging and alerting handlers and eventually things such as custom ETL engines.
  * The Open Edition will inherit all the features we have planned for our PowerSync Cloud edition, such as support for client parameters and support for BLOB columns.

## Product version matrix

I included one of these in our [V1 announcement post](https://powersync.com/blog/powersync-v1-0-stable-release), and thought I’d recap where all our components stand now:

| Component | Status |
| --- | --- |
| [SDK: JS Web](https://github.com/powersync-ja/powersync-js/tree/main/packages/web) | GA/Stable |
| [SDK: Flutter](https://github.com/powersync-ja/powersync.dart) | GA/Stable |
| [SDK: React Native](https://github.com/powersync-ja/powersync-js/tree/main/packages/react-native) | GA/Stable |
| [SDK: Kotlin Multiplatform](https://github.com/powersync-ja/powersync-kotlin) (KMP) | Alpha |
| SDK: Swift | Private Alpha |
| [SDK: Flutter Web](https://github.com/powersync-ja/powersync.dart) | Alpha |
| [React Components](https://github.com/powersync-ja/powersync-js/tree/main/packages/react) | GA/Stable |
| [Vue Package](https://github.com/powersync-ja/powersync-js/tree/main/packages/vue) | Beta |
| [ORM: JS Kysely](https://github.com/powersync-ja/powersync-js/tree/main/packages/kysely-driver) | Beta |
| [ORM: Flutter Drift](https://github.com/powersync-ja/drift_sqlite_async/) | Alpha |
| [Attachments Library: JS](https://github.com/powersync-ja/powersync-js/tree/main/packages/attachments) | GA/Stable |
| [Attachments Library: Dart](https://github.com/powersync-ja/powersync.dart/tree/master/packages/powersync_attachments_helper) | GA/Stable |
| CLI | Beta |
| Self-Hosting Enterprise Edition | GA/Stable |
| Self-Hosting Open Edition | Beta |
| Postgres Ingester | Stable |
| MySQL Ingester | WIP |
| Microsoft SQL Server Ingester | WIP |
  
## Machine Specs

A minimal "development" setup (e.g. for a staging or a QA environment) is:

  1. A single PowerSync "compute" instance (API + replication) with 512MB memory, 1 vCPU
  2. A single MongoDB node in replica set mode, 2GB memory, 1 vCPU. M10+ when using Atlas.
  3. Load balancer for TLS

This setup has no redundancy. If the replica set fails, you may need to recreate it from scratch which will re-sync all clients.

For production, we recommend running a high-availability setup:

  1. 1x PowerSync replication instance, 1GB memory, 1 vCPU
  2. 2+ PowerSync API instances, 1GB memory each, 1vCPU each.
  3. A 3-node MongoDB replica set, 2+GB memory each. Refer to the [MongoDB documentation](https://www.mongodb.com/docs/) for deployment requirements.  M10+ when using Atlas.
  4. A load balancer with redundancy.

For scaling up, add 1x PowerSync API instance per 100 connections. The MongoDB replica set should be scaled based on CPU and memory usage.

These numbers are a basic starting point. Depending on the application load, it could be scaled up or down.

Memory usage is primarily driven by row size and concurrent connections (syncing 100x 10MB rows will use a lot more memory than 1,000x 1MB rows).

## Contributing

We welcome contributions to the PowerSync codebase! Please see our [CONTRIBUTING.md](https://github.com/powersync-ja/powersync-service) for details.

---

# What PowerSync Open Edition Means For Local-First

> As we wrote about before, we believe that local-first is poised to eventually become the default architecture for the majority of apps, given its significant benefits for developers and end-users. To bring about this future state faster, our goal is to accelerate local-first adoption.

- Published: 2024-05-31
- Updated: 2025-09-30
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/what-powersync-open-edition-means-for-local-first

---

As we wrote about before, [we believe](https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web) that local-first is poised to eventually become the default architecture for the majority of apps, given its significant benefits for developers and end-users. To bring about this future state faster, our goal is to accelerate local-first adoption.

In 2024 so far, local-first has continued to gain momentum. More and more developers are adopting local-first architecture and evangelizing it. There is now a [local-first conference](https://www.localfirstconf.com/), a dedicated [podcast](https://www.localfirst.fm/), and the [community](https://localfirstweb.dev/) is growing.

## A promising movement in pursuit of more mature tooling

When it comes to tooling that gives developers leverage in implementing local-first architecture, while there is plenty of early-stage innovation, the local-first space has not yet achieved significant and widespread maturity of tooling.

Mature tooling is valuable regardless of the type of team/organization using and deploying the tooling: For enterprises, it’s important because reliability is mission-critical and the stakes are high. For startups, it’s important because they can’t afford to waste cycles on struggling with tooling.

In light of this, we believe that PowerSync has an important role to play. Some of the hardest challenges of local-first are the distributed systems challenges, such as data consistency, concurrency and fault tolerance. With the significant R&D efforts and production battle-hardening that has gone into the PowerSync system over more than a decade, we can bring the strengths of our system to bear to meet some of these key challenges, and thereby help to accelerate the nascent local-first movement. 

As we talked about in our [v1.0 introduction blog post](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer), the team behind PowerSync has been building and refining iterative generations of our sync technology since 2009. The stand-alone PowerSync product [is a spin-off](https://powersync.com/company) from a full-stack app platform product where the sync architecture has been in production for more than a decade, and is in daily use around the world by tens of thousands of enterprise users at Fortune 500 companies in industries such as energy, manufacturing and mining. The system has been proven to provide high performance and reliability in real-world production use cases in hostile environments, with large data volumes.

That being said, while we believe we have a valuable contribution to make to the local-first community, PowerSync had two noteworthy structural shortcomings up till now: We had not yet fully opened the source code of the system, and it was not yet self-hostable (it was only available as a cloud service.)

That has now changed with the [launch of our Open Edition](https://powersync.com/blog/powersync-open-edition-release): a source-available and self-hosted version of PowerSync. We believe that PowerSync is now better positioned to be a catalyst for the growth of local-first. This is not to say that PowerSync is the right solution for all local-first use cases, but our aim is to make a significant impact.

## PowerSync design & architecture: 15 years in the making

In our [PowerSync v1.0 introduction blog post](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer), we covered some of the architectural decisions and engineering challenges behind the PowerSync system. In this post, we aim to expand on that with more color regarding the evolution of the system. 

We have learned significant lessons from the original implementation of the system and its evolution and production use over more than a decade, and have incorporated these lessons into the design and architecture of the stand-alone PowerSync product.

During this journey, we have strived to achieve a simple and robust architecture, avoiding nonessential complexity and brittleness, while making the system stable, reliable, performant and capable of handling a wide range of production workloads.

### Dynamic partial replication, deduplicated for high scalability

Dynamic partial replication is known to be a thorny problem to solve: given a large primary database, how do you sync varying subsets of data with different distributed clients/replicas? Solving this in a highly scalable way compounds the challenge further. 

In the original generation of our sync system, we implemented support for dynamic partial replication and have refined it through several iterations to arrive at our current production-grade capabilities that have been battle-tested through years of real-world use.

The core scalability problem is that if you have **n** rows each synced to **m** clients, the naive approach to sync incremental changes to clients would effectively treat that as **n*m** individual sync operations, which is awful for scalability.

By contrast, the PowerSync architecture involves grouping data into [buckets](https://docs.powersync.com/usage/sync-rules), which in simple terms allows sharing data between different users. Buckets allow us to group together changes to data in order to deduplicate work, so that the aforementioned equation becomes **n*b** sync operations per row, where **b** is the average number of buckets per row.

The bucket approach also allows for a very simple sync protocol. The client keeps track of the latest ‘operation ID’ (op_id) of each bucket, and the protocol just streams new changes (operation history) for each bucket from that point.

As a result of this architecture, PowerSync does not have to keep track of individual client-side state on the server. The system can scale to high volumes of data and users with an efficient memory footprint: PowerSync stores bucket state and operation history (indexed for efficient querying) in persistent storage (pluggable storage used by the PowerSync Service) and only stores limited information in memory: Bucket parameters for each bucket for each active connection, and data actively being sent to clients.

Another result of this architecture is that PowerSync is able to handle clients that go offline for longer periods of time (e.g. days, weeks, etc.) without adversely affecting the user experience of those clients. This is because the change data capture stream from the backend database (i.e. the WAL / logical replication stream in the case of Postgres) is preprocessed based on the bucket configuration, and arbitrary ranges of the operation history for buckets can be retrieved efficiently by the PowerSync Service.

### Checksum system for data integrity

Each generation of our sync system has had integrity checks using checksums, providing an additional safety net to ensure that data is correctly in sync between the client and the server. During normal operation of the system, a checksum mismatch should never occur, but if any data corruption creeps in unexpectedly for any reason, the integrity check protects against that.

The original generations of our sync system used a somewhat complex approach: in response to a checksum failure, the system would recursively break down a range of data into smaller ranges in order to find the precise location of the checksum failure. This meant that the system could theoretically recover incrementally from checksum failures: if there was one row of data with a checksum failure, the system could locate that row and re-download only that part of the data 

In practice, this was not particularly performant. This was because operations such as adding or removing a bucket are spread over many individual operations, which effectively "fragments" the checksum failures, making the recursive checksum recovery very ineffective. Moreover, calculating checksums for different ranges of data was slow and imposed a scalability limit on the system, since it had to iterate through all data and calculate checksums for many records and sum them together. This started having a significant performance impact once we crossed the threshold of 100k synced records. 

The PowerSync system is significantly simpler: Checksums are calculated on a bucket level. When a bucket checksum fails, the system re-downloads the whole bucket. It makes the protocol simpler and in practice it’s not meaningfully slower. The checksum calculation is easier to optimize and the system scales better. For example, we can easily cache a checksum calculation without causing consistency issues.

### Checkpoint system for consistency guarantees

When we spun off PowerSync as a stand-alone product, we introduced improved consistency guarantees through a checkpoint system. On the client-side, local writes are applied on top of the last consistent checkpoint received from the server and stored in an upload queue. Once the client’s upload queue is empty and the server checkpoint has been fully downloaded, the client-side state is updated to the latest consistent server-authoritative checkpoint. This means that the PowerSync system provides causal consistency guarantees, and the client-side is never in an inconsistent state.

### Providing wide client platform/framework support

Another strength of PowerSync is its relatively wide set of client SDKs. At the time of publishing this blog post, we support Flutter, React Native, web, Kotlin Multiplatform, Swift, Node.js and .NET.

This was made possible in part due to our [Rust-based SQLite extension architecture](https://github.com/powersync-ja/powersync-sqlite-core), which allowed us to implement support for more client frameworks relatively quickly. This architecture was inspired by [CR-SQLite](https://github.com/powersync-ja/powersync-sqlite-core) who did it before us. Using Rust also gives us some performance advantages: We can have low-level code running alongside the core SQLite, rather than building our client SDKs on top of higher-level SQLite libraries.

## Looking ahead

We believe that PowerSync can play a valuable role in the local-first space by bringing a unique combination of attributes to the table: It has received substantial R&D investment to iteratively improve its architecture and design, while undergoing significant production battle-hardening. It works with any Postgres database that supports logical replication, in a non-invasive way. It supports a relatively wide range of client-side frameworks. And it is [now source-available](https://powersync.com/blog/new-open-era-for-powersync) and self-hostable (while also being available as a managed cloud service for those who prefer that deployment option).

We are excited to continue to help accelerate local-first adoption. 

Feedback or questions? Join us [on Discord](https://discord.gg/powersync) to discuss.

---

# ElectricSQL (Legacy) Vs PowerSync

> A comprehensive overview of the similarities and differences between ElectricSQL (Legacy) and PowerSync in enabling local-first architecture for developers.

- Published: 2024-05-23
- Updated: 2026-10-14
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/electricsql-vs-powersync

---

> **Warning**
>
> **Electric Cloud has shut down.** Electric has joined Databricks. The original Electric "will likely not be actively built out as is". This comparison is retained for historical context. If you are considering moving from Electric to PowerSync, see our guide: [Migrate from Electric Cloud to PowerSync Cloud](https://powersync.com/blog/migrate-from-electric-cloud-to-powersync-cloud).

> Note: This blog post applies to the original [legacy version](https://legacy.electric-sql.com/) of ElectricSQL. On July 17, 2024, Electric [announced](https://electric-sql.com/blog/2024/07/17/electric-next) a “clean rebuild” of their sync engine, which was initially called ‘electric-next’. Development of the legacy version of ElectricSQL has been stopped. We have published a new blog post comparing ‘electric-next’ to PowerSync [here](https://powersync.com/blog/electricsql-electric-next-vs-powersync).

Several people have asked us how PowerSync compares to [ElectricSQL](https://legacy.electric-sql.com/). We’ve put together this overview to answer this question more thoroughly. Please feel free to chat to us [on Discord](https://discord.gg/powersync) if you have any questions or comments.

## Similarities between ElectricSQL (Legacy) and PowerSync

On the surface, the legacy ElectricSQL and PowerSync have similar goals and enable similar outcomes for developers: Both are designed to be a plug-in sync layer for existing application stacks — offering bi-directional syncing of data between standard Postgres [^1] and client-side databases (e.g. SQLite). 

Both ElectricSQL and PowerSync provide:

  * Instant reactivity for your apps (by allowing your app front-end to work with a local database, with live queries)
  * Offline operation of apps (read and write to a local database, and then data syncs in the background automatically when connectivity is available — both systems use some kind of upload queue on the client-side)
  * Real-time multi-user collaboration (by keeping data in sync between users and devices in real-time)

Both can be used in greenfields and brownfields projects. Both use JWTs for authentication. Both use Postgres [logical replication](https://www.postgresql.org/docs/current/logical-replication.html) / the [WAL](https://www.postgresql.org/docs/8.0/wal.html) to monitor the database for changes to be streamed to clients. Both provide causal consistency guarantees.

## Key differences between ElectricSQL (Legacy) and PowerSync

While there are broad similarities between ElectricSQL and PowerSync, there are important differences in architecture.

### Summary: ElectricSQL vs. PowerSync architecture

Here’s a brief overview of the fundamental differences in architecture. Some of these are explored in more detail below.

| **ElectricSQL architecture** | **PowerSync architecture** |
| --- | --- |
| Writes are made directly to your Postgres database via the Electric sync service (bypassing your backend application), using [CRDTs](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) to merge changes [deterministically](https://en.wikipedia.org/wiki/Deterministic_algorithm). This means that custom business logic cannot be applied to writing changes to your database on the server-side. It also has other important implications for the developer as discussed below. | Writes are sent through your own application backend, allowing you to customize how they're handled: You can apply your own business logic, fine-grained authorization, validations and server-side integrations, you can resolve conflicts using the techniques/algorithms of your choosing, and you can reject changes from clients if needed. Your backend is authoritative: After processing the write on your backend, the state will correctly and consistently replicate to clients. This does mean that some additional work is required to implement writes. Writes and conflict resolution are not automatic like with ElectricSQL. |
| Makes extensive modifications to your Postgres database (schema additions, additional storage, triggers and typically subscribing to a logical replication stream from the Electric sync service). | Does not make modifications to your Postgres database. Operation history is stored in the PowerSync Service. |
| Tightly coupled to your Postgres schema and configuration. | Loosely coupled to Postgres — creating a layer of flexibility/independence between itself and Postgres. |
| Sync controls are defined partly on the server-side (access control / permissions) and partly on the client-side (Shapes, controlling what data is synced). _Note: As of the time of publishing this blog post, Shapes are currently[experimental](https://electric-sql.com/blog/2024/04/10/electricsql-v0.10-released)._ | Sync controls are defined on the server-side (Sync Rules) and can make use of dynamic parameters from the client. |
| ElectricSQL has a high memory footprint on the server-side, which impacts scalability. It keeps a graph in memory per client of all rows synced to that client and acknowledged by the client. Memory overhead is proportional to the number of client connections times the average number of rows synced per connection. | PowerSync’s Sync Rules and its principle of deduplication allows the system to scale to high volumes of data and users with an efficient server-side memory footprint: It stores bucket state and operation history (indexed for efficient querying) in persistent storage and stores limited data in memory. |
  

### ElectricSQL’s direct-to-Postgres CRDT architecture vs. PowerSync’s authoritative backend architecture

As mentioned above, ElectricSQL writes directly to your Postgres database, using CRDTs to merge changes deterministically. At a high level, the architecture looks like this:

![](https://powersync.com/images/blog/electricsql-vs-powersync-inline-2551c6a938.png)

There are a few implications of this architecture that developers should take into consideration when weighing whether ElectricSQL is the right fit for their needs:

**1\. Access control & validation defined by the database**

In the local-first (and offline-first) paradigm, you will typically implement much of your business logic in the client (see [here](https://powersync.com/blog/offline-first-local-first-is-a-big-deal-especially-for-the-web)), since you want the app to be fully functional regardless of network/cloud availability. However, the client-side is an untrusted environment, and therefore when writes are propagated to the server-side Postgres database, we need a way to enforce validation and authorization as a last line of defense. 

With ElectricSQL there is no custom server/backend mediating the interfacing with Postgres, and ElectricSQL uses Postgres as the exclusive “control plane” for the system. This means that the Postgres database configuration is used exclusively by ElectricSQL for defining access control / validation — in other words, the database defines the line of defense for malicious client actors. 

For example, user input validation [has to be done using Postgres check constraints](https://legacy.electric-sql.com/docs/usage/data-modelling/validation). Access control and permissions need to be defined using ElectricSQL’s [DDLX](https://legacy.electric-sql.com/docs/api/ddlx) which is executed in PostgreSQL as part of migrations. That being said, check constraints and DDLX access controls are not yet available in ElectricSQL at the time of publishing this blog post.

**2\. Server-side workflows using event sourcing**

As a result of the ElectricSQL architecture, server-side workflows cannot be triggered by your backend application. Therefore, ElectricSQL recommends triggering server-side workflows using event sourcing based off of database change events. This means adding an additional system/component to your stack for database event sourcing, and integrating your backend framework with that system.

**3\. No custom conflict resolution**

ElectricSQL applies predefined behavior to merging changes and resolving conflicts using CRDTs. For example, ElectricSQL uses the Rich-CRDT feature of ‘Compensations’ to guarantee referential integrity: If user A deletes an object while user B concurrently creates a reference to that object, the Compensation will re-create the object deleted by user A in order to preserve referential integrity. 

In cases like this, the behavior of the CRDT might not be aligned with what the developer would prefer for a particular system or a particular business requirement. ElectricSQL does [plan](https://legacy.electric-sql.com/docs/reference/integrity#long-lived-actions) on eventually allowing the developer to select between different CRDTs / conflict-resolution policies, but this will still result in limited flexibility. 

#### **PowerSync’s authoritative backend architecture**

With PowerSync, writes are sent through your own application backend [^2], allowing you to customize how they’re handled: You can apply your own business logic, fine-grained authorization, validations and server-side integrations, you can resolve conflicts using the techniques/algorithms of your choosing, you can trigger server-side workflows, and you can reject changes from clients if needed. At a high level, the architecture looks like this:

![](https://powersync.com/images/blog/electricsql-vs-powersync-inline-6d24d3caa7.png)

#### **Leveraging CRDTs’ strengths**

At PowerSync, we believe CRDTs have great strengths: For example, they are an excellent solution for collaborative document/text editing. Although ElectricSQL’s internal merge logic uses CRDTs, ElectricSQL does not provide a built-in solution for document/text collaboration using CRDTs. It would be a similar effort to implement document/text collaboration with either PowerSync or ElectricSQL. For example, you could use [Yjs](https://github.com/yjs/yjs) and store its CRDT data structure in Postgres using blob columns, with each row in the Postgres table representing a user edit/update (or each row representing a whole document). We’ve provided an [example implementation here](https://github.com/powersync-ja/powersync-web-sdk/tree/main/demos/powersync-supabase-yjs-text-collab-demo).

### Modification of your Postgres database: ElectricSQL vs. PowerSync

Another factor that developers should take into consideration when weighing whether ElectricSQL or PowerSync is the right fit for them, is the degree to which they require any changes to the Postgres database.

It should be noted that ElectricSQL makes various changes to your Postgres database:

  * Adds additional “shadow tables” to your schema, which store CRDT data which are used to merge changes. This increases the data storage used by your database. At the very least it will double the size of the data accessed by ElectricSQL, and as the change history grows, it will gradually increase from there.
  * Adds triggers, for example to perform merge logic.
  * Typically subscribes to a logical replication stream from the ElectricSQL sync service — this is typically how changes are written into your database. ElectricSQL subsequently also added a [‘direct writes’ mode](https://legacy.electric-sql.com/docs/api/service#write-to-pg-mode) as an alternative to the logical replication subscription.

It is also worth noting that Electric requires [.inline-code-snipper]SUPERUSER[.inline-code-snipper] privileges/permissions to your Postgres database, unless you are using the ‘direct writes’ mode.

**PowerSync does not modify your Postgres:**

  * Requires no modifications to your Postgres database except for enabling logical replication [^3]
  * Requires read-only permissions to your database (only the [.inline-code-snipper]SELECT[.inline-code-snipper] and replication privileges) 

### ElectricSQL’s tight coupling to Postgres vs. PowerSync’s loose coupling

Developers should also consider that ElectricSQL’s architecture makes it tightly-coupled to your Postgres schema and configuration:

  * ElectricSQL places restrictions on what you can have in your Postgres schema. For example, Check and Unique constraints are not supported by ElectricSQL and need to be removed from a table’s schema before “electrifying” that table.
  * Data transformations between Postgres and SQLite are not possible with ElectricSQL — the client-side schema will match the server-side schema (although it is possible to do basic filtering of columns).
  * Only specific Postgres types are supported. If you are using custom types in your Postgres database (e.g. for PostGIS), you would need to look into whether this can be supported (refer to “[Local migrations](https://legacy.electric-sql.com/docs/api/ddlx#sqlite)” in the ElectricSQL docs).
  * The database configuration is exclusively used for defining validation and access controls e.g. using Check constraints and DDLX (as mentioned above)
  * ElectricSQL performs automatic client-side migrations to keep the client-side schema in sync with the server-side Postgres schema. This may cause complications if your schema changes and users are still running older client versions.
  * All Postgres migrations need to run through the ElectricSQL migrations proxy (which allows ElectricSQL to enforce its restrictions and make its required modifications to the Postgres schema/configuration). If you make changes to your Postgres schema without using the ElectricSQL proxy, ElectricSQL will malfunction [^4]. This means that your migrations tooling must be configured to always use this ElectricSQL proxy. If you use a backend framework, you need to set it up to run its migrations (but not all database traffic) through the proxy.

**PowerSync: Loose coupling to Postgres**

By contrast, PowerSync is loosely coupled to Postgres, creating a layer of flexibility between your Postgres schema and configuration and the client-side SQLite schema.

  * When defining [Sync Rules](https://docs.powersync.com/usage/sync-rules), you can write custom SQL queries that can (optionally) perform transformations on the Postgres data/schema.
  * You have control over defining the client-side schema. You can automatically generate a default schema based off of your Postgres schema, and/or you can customize it based on your needs. The Postgres and SQLite schemas can be relatively independent of each other. In fact, PowerSync does not actually enforce a hard schema on the SQLite database: PowerSync syncs “schemaless” data, and then applies your client-side schema on top of that using SQLite views.

### ElectricSQL vs. PowerSync functionality and limitations

Something else to take into consideration is that ElectricSQL is currently in “open alpha”. The team has said that they do not currently recommend production use, and there are features missing that may be needed for production deployment.  
  
Here’s a quick rundown of some differences in features and limitations, accurate as of the time of publishing this blog post:

| **ElectricSQL functionality** | **PowerSync functionality** |
| --- | --- |
| **Dynamic partial replication is experimental** (controlling what data syncs to which users). Shapes are available in experimental form, and DDLX-defined permissions have not yet been integrated with Shapes. | **Dynamic partial replication is available** and production-ready. See PowerSync [Sync Rules](https://docs.powersync.co/usage/sync-rules). |
| **Permissions / access control not yet available.** The system cannot currently place restrictions on user writes applied to the Postgres database. | **Permissions / access control available:** • Read path: [Sync Rules](https://docs.powersync.co/usage/sync-rules) provide server-side control of which data syncs to which users. • Write path: Writes are sent through your existing backend application, allowing you to apply your own permissions / access control. |
| **Built-in ORM.** ElectricSQL comes with a strong built-in Prisma-inspired ORM for the client-side SQLite database, and also allows raw SQL access. | **Limited ORM integrations.** PowerSync currently provides a limited set of ORM integrations for the client-side SQLite database — see [here](https://powersync.com/blog/using-orms-with-powersync) for details. |
| **Open-source, self-hosted:** ElectricSQL is an open-source project and the sync service needs to be self-hosted. | **Open-source & source-available, managed/hosted or self-hosted:** PowerSync is currently [offered](https://powersync.com/pricing) as both a managed/hosted cloud service and self-hosted. Client SDKs are open-source (Apache 2.0 license) and a source-available version of the PowerSync Service [is available](https://powersync.com/open-source) as of May 31, 2024 (PowerSync Open Edition). |
| **Conflict resolution cannot be customized.** Pre-defined CRDTs are used for conflict resolution, which may result in conflict resolution policies that do not necessarily suit a developer's needs for a particular system. Some configuration of CRDTs will be supported in the future (see [here](https://legacy.electric-sql.com/docs/reference/integrity#long-lived-actions)) but note that this by itself does not mean deeper customization will be possible. | **Custom conflict resolution strategies** can be implemented since the developer is in control of the write process to the database. The developer can apply custom logic to conflict detection and resolution, including using CRDTs as data types (stored in Postgres as blob data) for e.g. text/documents. |
| **Only JavaScript-based environments are officially supported.** ElectricSQL currently only officially supports JavaScript-based client-side environments. This means that official support for native environments such as Kotlin, Swift and Flutter is not available. There was an unofficial community port for Dart/Flutter which was deprecated when 'electric-next' was announced. | **Cross-platform environments supported.** PowerSync currently has support for a mix of native and JavaScript-based environments, including Flutter, React Native and a plain JavaScript SDK for web browsers, with a Kotlin SDK in public alpha and Swift (iOS) in private alpha. |
| **Additive migrations only.** ElectricSQL only supports additive migrations on the database schema. | **Various migration scenarios are supported** , [as documented here](https://docs.powersync.com/usage/lifecycle-maintenance/implementing-schema-changes). |
| **Postgres 'public' schema only.** Only tables in the 'public' schema in Postgres can be accessed/synced by ElectricSQL. | **Any Postgres schema.** [Any schema](https://docs.powersync.com/usage/sync-rules/schemas-and-connections#postgres-schemas) in your Postgres database can be accessed/synced by PowerSync. |
| **Web browsers: Separate database per tab.** ElectricSQL currently provides a separate SQLite database per browser tab when used on the web. | **Web browsers: Multiple tabs concurrency.** Where supported, PowerSync allows the same SQLite database to be accessed and updated across multiple tabs in the user's web browser. |

[^1]: Support for additional databases is planned for PowerSync, including MySQL and Microsoft SQL Server / Azure SQL.
[^2]: Note: PowerSync is different from systems like WatermelonDB where you have to build your backend functionality for the _read path_ , which can put a heavier burden on the developer in terms of scope and complexity. PowerSync provides the [PowerSync Service](https://docs.powersync.com/architecture/powersync-service) which handles the **_read path_** of syncing to users, including the complexities of dynamic partial replication. PowerSync only relies on your backend for handling writes. On the client-side, PowerSync handles the complexity of queueing writes so that they can be retried if connectivity / the backend is not immediately available.
[^3]: In some cases denormalization is required to effectively partition the data to sync to different users.
[^4]: There are workarounds to do migrations without the proxy, but it requires more effort.

---

# Introducing Our Enterprise Self-Hosted Edition

> The Enterprise Self-Hosted Edition of PowerSync is available for companies that want the benefits of local-first but also want control over hosting, advanced capabilities, and dedicated support from our team.

- Published: 2024-05-16
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/introducing-our-enterprise-self-hosted-edition

---

As of today the Enterprise Self-Hosted Edition of PowerSync is available for companies that want the benefits of local-first but also want control over hosting, advanced capabilities, and dedicated support from our team.   

## PowerSync for Enterprise Local-First

PowerSync provides the benefits of local-first architecture while requiring minimal changes to database environments (no schema additions or restrictions are required — only a logical replication publication). PowerSync is compatible with corporate IdP solutions and also re-uses existing backend APIs to sync mutations, thereby preserving existing business logic, authorization rules and validations.  

Here at [JourneyApps](https://powersync.com/company) (PowerSync’s parent company), we have over a decade of experience in deploying enterprise-grade software solutions at some of the world’s largest companies in mission-critical and challenging environments such as offshore oil rigs, underground & open-air mines and medical care facilities. Our experienced team enjoy the unique challenges that each enterprise customer presents, and we are excited to leverage this expertise with PowerSync and work closely with customers to meet their needs.  

## Advanced Enterprise-Focused Capabilities

Our Enterprise Self-Hosted Edition shares a common core with our upcoming Open Edition, but during build we inject additional modules only available to Enterprise customers. These modules will provide additional capabilities around observability & metrics, scaling, security and additional ingestion options. Customers can deploy all of this on their own cloud or on-premise environment for ultimate control over their infrastructure.   

We also plan to release Enterprise client SDKs with additional features around client-side data security such as data leases which provide an additional layer of app-level data protection over and above that provided by MDM solutions, as well as end-to-end encryption support.   

We look forward to working closely with customers to expand our Enterprise capabilities and roadmap over time.

## Enterprise Plans: Pricing, Compliance & Support

In addition to advanced features, Enterprise customers also get:

  * Custom pricing
  * SOC2 Type 2 audit reports
  * Pentest summary reports
  * White-glove installation assistance from our team of senior customer experience engineers
  * A dedicated assigned Support Manager
  * A support SLA
  * A private Slack channel
  * A clearly defined release schedule with long-term support

[Contact us](https://powersync.com/contact) today if you have questions.

---

# Postgres Logical Replication Challenges & Solutions

> The flexibility of Postgres logical replication has paved the way for a variety of third party tools to do useful things with Postgres. For example, ETL tools such as PeerDB, change data capture tools such as Debezium, and local-first sync engines such as PowerSync.

- Published: 2024-05-08
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/postgres-logical-replication-challenges-solutions

---

[Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) is a valuable feature in Postgres that was [introduced](https://www.pgedge.com/blog/logical-replication-evolution-in-chronological-order-clustering-solution-built-around-logical-replication) in Postgres version 10 in 2017. It was originally meant to be used for Postgres-to-Postgres data replication in a way that is compatible over different Postgres versions and databases, by replicating row data in a configurable way (as opposed to physical replication, which does byte-by-byte replication of the exact Postgres data on disk).

The flexibility of logical replication has paved the way for a variety of third party tools to emerge that do useful things with Postgres: for example, [ETL](https://en.wikipedia.org/wiki/Extract,_transform,_load) tools such as [PeerDB](https://www.peerdb.io/), change data capture tools such as [Debezium](https://debezium.io/), and local-first sync engines such as [PowerSync](https://powersync.com/).

When we built PowerSync using Postgres logical replication, we ran into some challenges related to making the PowerSync architecture compatible with logical replication assumptions. In this post, we will explore some of those challenges and how we solved them. In no specific order, here are the 4 challenges we will examine:

  1. Handling schema/DDL changes
  2. LSNs that overlap between transactions
  3. Accessing TOASTed values 
  4. Handling different row identifier permutations

Let’s dive in:

## 1\. Handling schema/DDL changes

An important aspect of Postgres logical replication is that [Data Definition Language](https://en.wikipedia.org/wiki/Data_definition_language) (DDL) statements are not published in the stream of logical replication messages, so if you are a subscriber to a logical replication publication, you do not receive messages indicating changes made to the source database’s schema. 

Unless you are manually applying schema changes on both the publisher and subscriber databases, you would need to inspect the  published logical replication messages to try to deduce that the schema has changed. Logical replication messages do include type identifiers that can be used to identify columns and their types.

One of our primary [design objectives](https://docs.powersync.com/overview/powersync-philosophy) for PowerSync was to make the system as low-maintenance as possible, and schema evolution was one the areas where we didn’t want to put an undue maintenance burden on the developer. 

We did a number of things in pursuit of this design objective:

  * **Schemaless replication:** We made the PowerSync protocol and client-side database storage [_schemaless_](https://docs.powersync.com/architecture/powersync-protocol#protocol) _._ PowerSync replicates data from Postgres as schemaless JSON, and on the client-side, it applies SQLite views on top of the schemaless data. Therefore, the developer can work with the SQLite database as if it has a regular structured schema, while the underlying data is actually schemaless. This reduces the surface area of the system affected by schema changes: we do not need to perform schema migrations on the client-side SQLite database.
  * **Allow basic schema transformations:** PowerSync’s [Sync Rules](https://docs.powersync.com/usage/sync-rules) can apply some basic [transformations](https://docs.powersync.com/usage/sync-rules/data-queries#examples) to Postgres data during replication. The developer can use this for some backwards-compatibility, allowing clients to keep using an older SQLite “schema” even if the Postgres schema has changed.
  * **Detect and handle Postgres schema changes automatically where possible.** Lastly, we wanted the system to automatically detect and handle schema changes on the Postgres side as far as possible, and in scenarios where the schema change cannot be detected or handled automatically, minimal developer action should be required (and this should be well-documented). Here is a quick rundown of the some of these scenarios: 

| Schema change scenario | Automatic or manual? | Notes on behavior |
| --- | --- | --- |
| DROP table | Developer action required | |
| CREATE table | Automatic | |
| DROP and re-CREATE table | Automatic | |
| RENAME table | Automatic | Entire table is re-synced |
| REPLICA IDENTITY changes | Automatic | Entire table is re-synced |
| Column changes | Developer action required | |
| Publication changes | Developer action required | |
  
More details on the various scenarios can be found [here](https://docs.powersync.com/usage/lifecycle-maintenance/implementing-schema-changes) in the PowerSync documentation.

It should be noted that there are some fundamental limitations to what is possible with Postgres logical replication when it comes to the schema. For example, `GENERATED STORED` values are not published in the logical replication stream. 

## 2\. LSNs that overlap between transactions

Postgres creates logical replication messages by applying _logical decoding_ to entries in its [Write-Ahead Log](https://www.postgresql.org/docs/current/wal-intro.html) (the primary purpose of the WAL is database recovery e.g. in case of a crash). WAL messages are identified by means of [Log Sequence Numbers](https://www.crunchydata.com/blog/postgres-wal-files-and-sequuence-numbers) (LSNs).

One thing to note is that you cannot rely on LSNs that appear in the logical replication stream to be a strictly monotonically increasing sequence: Transaction commits are always in sequence in the WAL, but operations inside each transaction can have LSN ranges overlapping with other transactions. Specifically, the "begin" LSN of a transaction may be less than the "commit" of the previous transaction. This typically happens when the transactions were running concurrently on the source server.

Because PowerSync uses a [server-authoritative architecture](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer#server-authority-instead-of-distributedcrdt-architecture) that maintains a global ordered list of operations, we needed a  monotonically increasing “operation ID” (##op_id##) sequence to keep track of operations in the Postgres database. 

Initially, we used the Postgres LSNs to derive our `op_id` sequence. However, we moved away from that architecture to using our own auto-incrementing integer sequence. One reason for this was the aforementioned issue that LSNs in the WAL are not guaranteed to be monotonically increasing, but there were also other architectural reasons:

  * We want to architecturally support sharded databases where each Postgres instance has its own LSN sequence that has to be merged into a singular `op_id` sequence
  * When we reprocess sync data, we need to continue with the same `op_id` sequence, while the LSN sequence does not get reset.

PowerSync stores operation history using pluggable storage in the [PowerSync Service](https://docs.powersync.com/architecture/powersync-service), which is where we maintain this auto-incrementing integer `op_id` sequence.

## 3\. Accessing TOASTed values

You may be familiar with [TOAST](https://www.postgresql.org/docs/current/storage-toast.html), which is the “The Oversized Attribute Storage Technique” in Postgres: If a value exceeds the page size (8 kB by default), Postgres compresses the value, and if still remains larger than the page size, it is stored in a separate TOAST table, and a pointer to the TOAST value is placed in the original table. 

TOAST affects logical replication, in that a “TOASTed value” is only published in the logical replication stream if the value has changed. Otherwise, the field has an [‘unchanged’ flag](https://www.postgresql.org/docs/current/protocol-logicalrep-message-formats.html#PROTOCOL-LOGICALREP-MESSAGE-FORMATS-TUPLEDATA). For a system like PowerSync, it is useful to be able to know the current state of any row that is published in the logical replication stream. But because of TOAST, we cannot guarantee that all column values will be represented in the logical replication messages. [^1]

In order to be able to access current field values regardless of TOAST, PowerSync stores an additional copy of the current value of any field that we replicate. This is a form of stateful stream processing — [this useful write-up](https://debezium.io/blog/2019/10/08/handling-unchanged-postgres-toast-values/) by Debezium has some more details.

## 4\. Handling different row identifier permutations

The last challenge relates to [`REPLICA IDENTITY`](https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-REPLICA-IDENTITY) . The Postgres `REPLICA IDENTITY` configuration controls which row identifier information is recorded in the logical replication stream. Having some kind of row identifier information in the subscriber database is essential to be able to know which row to mutate in the replica when a change to an existing row is received from the publisher database. But tables in Postgres do not necessarily have to have a primary key, hence the additional `REPLICA IDENTITY` options available (for a practical analysis, see [this blog post](https://mydbanotebook.org/posts/replica-identity-for-logical-replication/)).

We wanted PowerSync to support all the different permutations of `REPLICA IDENTITY` for developer convenience. What this means is that if the `DEFAULT` (i.e. using the primary key as row identifier) is not being used, we need to generate some kind of ID to track changes to rows in the PowerSync replica of the Postgres data. This table summarizes how we derive row IDs depending on the `REPLICA IDENTITY` configuration in use.   

| Replica Identity | Postgres Treatment | PowerSync Treatment |
| --- | --- | --- |
| `DEFAULT` | Records primary key. | Use the primary key as ID. |
| `FULL` | Records all columns. | Generate ID from all columns. |
| `USING INDEX` | Records columns referenced by named index. | Generate ID from columns referenced by named index. |
| `NOTHING` | No information recorded. | Generate a random ID. (Postgres blocks updating or deleting rows.) |
  
As you can see above, if `REPLICA IDENTITY NOTHING` is in use with logical replication enabled, Postgres will block updating or deleting rows in that table — if this was not the case, logical replication subscribers would have no way of knowing which rows are being updated or deleted! However, for the purposes of PowerSync, we still generate a random ID in this scenario, so that we can correctly process `TRUNCATE` operations: when a table is truncated, we need to remove all rows in that table from the PowerSync replica of the data.

## PostgresConf 2024 talk

I spoke about these logical replication challenges and solutions in a talk I gave at PostgresConf 2024 in San Jose, California. I started the talk by going over how PowerSync works, and then ended with the logical replication items. You can see the video of the talk here: (you can also find the slides [here](https://postgresconf.org/conferences/2024/program/proposals/local-first-application-architecture-using-postgres-logical-replication))

[Video: Local-first application architecture using Postgres logical replication — PostgresConf 2024](https://www.youtube.com/watch?v=mPrM6lnd5wU)

[^1]: There is an exception to this: When `REPLICA IDENTITY FULL` is set for a table, the full value of any TOASTed columns will [always be present](https://xata.io/blog/replica-identity-full-performance) in the ‘keys’ field of logical replication messages. However, we want PowerSync to be able to support any `REPLICA IDENTITY` configuration, and using `REPLICA IDENTITY FULL` does [come with a cost](https://xata.io/blog/replica-identity-full-performance).

---

# PowerSync Update: April 2024

> Our update for April 2024: Postgres Conf USA, a new Vue composables package, the power of Full-Text Search unlocked and more.

- Published: 2024-05-02
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-april-2024

---

In April we published a Vue composables package, added full-text-search to our Web SDK and presented at Postgres Conf USA. We also saw community releases of a TinyBase PowerSync persister and an Ignite Cookbook recipe for implementing Supabase and PowerSync. Let’s get into it.

## **Conrad at Postgres Conf USA**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-5534883663.png)

Postgres Conference USA is _the marquee Postgres event in North America_ and organized by the US Postgres community. Conrad took the stage to present **Local-first apps using Postgres logical replication**.

We'll publish a video of the presentation on our YouTube channel soon. 

[Check out the PowerSync YouTube channel](https://cncnr04.na1.hubspotlinks.com/Ctc/ZT+113/cNCnR04/VVQvvp5WBXX9N1p__qFbfl5gW861hN75dC0d1N3cFw6g3qn9gW7Y8-PT6lZ3kDW40V19z7ySnzPW878Cwx8fQSz8W2NnfSh2Ksyp7W6_Ndt_1k83knW4_NpPL6bv8Q1N2JYbQSkwvL9W97Xz-F4bMl-0N8n67V6jmDQdW7zF1v995P58DW9ft_xk2cW03RW7Jc0Cx3F5CNjW7X_QQw4zgM9HW7j69G_6J8fKDW4zBy9m7C05TQW4D9Th-6q4HzfW4tmJvt1YpqdZW7mGG-f5cdfyqW3SQsY91HjzCvW708Ms-1wCvqdW8yG9LZ3-jTTXV7lDpf4DPjdCW41pM_78yW1Z0N3n_9GdZnfFpW3Bgdd03ZQRpSW3xd_7V8qKph-W5r7x1v6Tsg_bf7RNN8n04)

## **Vue Composables Package**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-d9ba8f1dc4.png)

Vue developers can now use PowerSync. We released the alpha version of a Vue Composables package that introduces reactivity/live queries for PowerSync functionality. We also added a demo project that shows how this package can be used with Supabase.

Shout out to **Mow** for prompting some of our work here.

[Read our engineering notes](https://powersync.com/blog/engineering-notes-integrating-with-vue-for-local-first-spas)

## **JavaScript and React Native SDK Updates**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-d3db4de261.png)

We’ve done a lot of work to make our JS Web and React Native SDKs more capable and user-friendly. Here are some highlights:

  * Added `hasSynced` property on `SyncStatus`. This value is managed in `AbstractPowerSyncDatabase`, and becomes true after the first sync has completed.
  * Added `waitForFirstSync` method to allow users to await on the state change of `hasSynced` to true.
  * Added `executeBatch` method. This allows a SQL statement with multiple parameters to be executed in a single transaction, improving performance and consistency.

Thanks to **Roman** , **Oleksii** , **AMayer** and **Mow** for your discussions and feedback.

[See the full changelog](https://releases.powersync.com/announcements/powersync-js-web-client-sdk)

## **Ignite CookBook: PowerSync Recipe**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-6d68d446bf.png)

The Ignite Cookbook was created to be an easy way for developers to browse and share React Native code snippets (or “recipes”) that actually work. In April, the **PowerSync and Supabase for Local-First Data Management** recipe was added.

Kudos to **Trevor Coleman** for creating a masterful guide.

[Read the PowerSync recipe](https://ignitecookbook.com/docs/recipes/LocalFirstDataWithPowerSync)

## **TinyBase Persister Released**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-d155b304c5.png)

TinyBase is a reactive data store for local-first apps that can make use of various persisters. In April, TinyBase released v4.8 which added the `persister-powersync` module to allow TinyBase to rely on PowerSync as the underlying persistent storage.

Community member **Benedikt Müller** drove this initiative and wrote about the reasons why:

[Read Benedikt’s blog post](https://bndkt.com/blog/2024/the-easiest-way-to-build-reactive-local-first-apps-with-tinybase-and-powersync)

## **Full-Text Search for Web**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-bf00f61eec.png)

We added full-text search (FTS) functionality to our fork of the `wa-sqlite` package, which means FTS can now be implemented alongside the PowerSync Web SDK.

Our React Todo List Demo app was updated to include FTS, which can be referenced when implementing FTS in your project. We share a few more details and a guide through our implementation in the docs.

Thanks to **Moe A** for spurring us on here!

[Read the docs](https://docs.powersync.com/usage/use-case-examples/full-text-search)

## **Coming Up: Local-First Conf in Berlin**

![](https://powersync.com/images/blog/powersync-update-april-2024-inline-055e88186f.png)

The inaugural Local-First Conf will be held in Berlin on May 30 and 31, and we’re proud to be a sponsor of this event. If you were lucky enough to get tickets, reach out to **Ralf** on our Discord who will be there to represent PowerSync. 

That's it for the April update, happy coding!

---

# Local-First State Management With SQLite

> Using a local SQLite database for state management is a quickly-evolving new approach, and over time we will see it become viable for more and more use cases.

- Published: 2024-04-18
- Author: Ralf Kistner
- Category: Engineering
- Source: https://powersync.com/blog/local-first-state-management-with-sqlite

---

Using a local SQLite database for state management is a quickly-evolving new approach, and over time we will see it become viable for more and more use cases. In this post, we look at the basics of using a synced SQLite database as a state management system.

## **Typical state management in React**

With React[^1], regardless of which state management framework is used, you typically have one-way data flow between state, actions and the view:

![](https://powersync.com/images/blog/local-first-state-management-with-sqlite-inline-00d0b23cca.png)

The view (the page or components) is rendered from the current state, and re-rendered whenever the state is updated. It can trigger actions (such as a button on-click), which update the state.

State management frameworks differ in how state is stored, how actions update the state, and how changes to state are detected and propagated back to the view.

Some frameworks like [Redux](https://redux.js.org/) require you to use immutable state, and each action creates a new “copy” of the app state.   
  
Other frameworks like [MobX](https://mobx.js.org/) let you work with plain JavaScript objects, and detect changes made to the properties directly.

## **Using a SQLite database to manage state**

Here we describe a different approach: Using a SQLite database to manage state:

![](https://powersync.com/images/blog/local-first-state-management-with-sqlite-inline-6c69308df8.png)

We store the application state in a SQLite database.

Actions become SQL queries — simple INSERT, UPDATE or DELETE statements, or more complex transactions.

Reading the state is done using a reactive `useQuery` hook[^2], which automatically updates the results whenever the underlying data changes.

Now, we have the full power of SQLite available for our state management:

  1. State is automatically persisted across page reloads.
  2. The database handles change detection for us (more on this later).
  3. We can use plain SQL queries and views to filter and transform the state as we like.
  4. We can use fast local queries to load any data from any component.  

## **Example: To-do list / task list app**

As an example, let’s consider a “To-Do List” app that manages lists of tasks. We’re showing lists on the left, and tasks in the selected list on the right. The lists on the left include a counter of pending and completed tasks for each list, which should be updated as soon as any task is toggled.

![](https://powersync.com/images/blog/local-first-state-management-with-sqlite-inline-54b3beaa3f.png)

To create, delete or toggle tasks, we use simple SQL statements:

```javascript
// Create
await db.execute('INSERT INTO tasks(id, name) VALUES(uuid(), ?)', [name]);
// Delete 
await db.execute('DELETE FROM tasks WHERE id = ?', [task_id]);
// Update
await db.execute('UPDATE tasks SET completed = NOT completed WHERE id = ?', [task.id]);
```
Our tasks query uses a simple `SELECT` statement with a `WHERE` clause, using the reactive `useQuery` hook mentioned above, which automatically updates the results whenever the underlying data changes. 

```typescript
const results = usePowerSyncWatchedQuery(`SELECT name, completed FROM tasks WHERE list_id = ?`, [list_id]);
```
Our lists query looks like this: (because we have the power of SQL, we can do things like subqueries and aggregations such as counting)

```typescript
const results = usePowerSyncWatchedQuery(`SELECT name,
        (SELECT count() FROM tasks WHERE list_id = lists.id AND completed = TRUE) as completed_count,
        (SELECT count() FROM tasks WHERE list_id = lists.id AND completed = FALSE) as pending_count
      FROM lists`);
```
That’s all there is to it! Whenever a task is added, removed or toggled, the tasks and lists components are automatically re-rendered with the latest state.

## **useQuery hook**

The `usePowerSyncWatchedQuery` hook[^3] in the examples above is at the core of what makes this possible. Without it, we’d need to keep track of when queries are stale and need to be rerun, which could increase the state management complexity quickly. While it’s not directly part of SQLite, it is built on top of functionality that SQLite already includes:

  1. SQLite [update hook](https://www.sqlite.org/c3ref/update_hook.html): This fires a notification whenever a row is inserted, updated or deleted. While it provides the affected row ID, we only keep track of changed tables in our implementation.
  2. [`EXPLAIN`](https://www.sqlite.org/lang_explain.html): Given a query, this tells us which tables are read to produce the results. Unlike custom query parsing, this works with anything from a simple `SELECT` statement to complex joins, subqueries, views or common table expressions.

Combining those two, we rerun a query whenever data in one or more of the underlying tables have changed, and it works with practically _any_ SQLite query.

It’s worth noting that this implementation does more work than is strictly required. In our example above, the tasks query will be rerun even if only tasks in a different list are modified. In practice, SQLite is so fast that it doesn’t matter for most use cases, and we get large benefits from the simplicity and flexibility of this approach.

## **Typed queries using Kysely**

In the above examples we used plain SQL, which should work for developers already familiar with it. However, one disadvantage is that it doesn’t give us any type info for auto-complete or build-time error checking. To handle that, we can use the [Kysely](https://kysely.dev/) query builder to get typed queries and results: [^4]

```typescript
// Insert/delete/update:
await db.insertInto('tasks').values({ id: uuid(), name: name }).execute();
await db.deleteFrom('tasks').where('id', '=', task_id).execute();
await db.updateTable('tasks').where('id', '=', task_id).set('completed', task.completed ? 0 : 1).execute();

// Tasks:
const results = usePowerSyncWatchedQuery(db.selectFrom('tasks').select(['name', 'completed']).where('list_id', '=', list_id));

// Lists:
const query = db.selectFrom('lists').select(['name']).select(({selectFrom}) => [
    // Select a correlated subquery
    selectFrom('tasks')
      .select(db.fn.countAll().as('count'))
      .whereRef('tasks.list_id', '=', 'lists.id')
      .where('completed', '=', 1)
      .as('completed_count'),
    selectFrom('tasks')
      .select(db.fn.countAll().as('count'))
      .whereRef('tasks.list_id', '=', 'lists.id')
      .where('completed', '=', 0)
      .as('pending_count')
  ]);
const results = usePowerSyncWatchedQuery(query);
```
This is slightly more verbose in some cases, but gives us full TypeScript type checking for the query parameters and results.

## **Where to use queries for state**

We generally recommend using queries higher up in the component hierarchy, and passing down the results as properties to components lower down. This allows us to efficiently load data for multiple components in a single query. In our example of task lists above, we use a single query to load all lists and their associated task counts, instead of an individual query for each list.

For transient local component state, such as the name of a new task as the user is typing it, React’s `useState` is typically more applicable. Once the user “saves” the task, we can save it to the database.

For navigation state, such as the current page or the currently-selected list, route properties (for example in the browser URL) are more applicable.

For transient global state, we could use a temporary database. Alternatively, React’s [`useContext`](https://react.dev/reference/react/useContext) or minimal usage of state management frameworks would also work for this. We can expect this to be a very small part of typical applications, once all persisted state is in the database.

## **Synchronizing with server-side state**

So far in the examples above, we’ve worked with only a client-side database: There was no consideration of server-side state. 

Writing a custom solution to keep the database in sync with a server is possible, but we would not recommend it. However, you don’t need to — there are multiple off-the-shelf solutions available to keep the SQLite database on the client in sync with a database on your server.

Using a sync layer such as PowerSync helps keep the client and server in sync automatically, and this has great advantages:

  1. No individual API requests needed to read data.
  2. No worrying about caching and cache invalidation — data is updated automatically.
  3. The app/site works fully offline.  

## **Loading states and waterfalls**

Due to the asynchronous nature of database queries, there can be a “flicker” on the first render of a component — it renders once before the results are available, then again after loading the results. 

Moreover, when multiple components in a hierarchy each load their state, it can lead to a “waterfall” in rendering, which can introduce significant latency in apps that fetch data from an API over the network. See [this post](https://blog.sentry.io/fetch-waterfall-in-react/) for a more in-depth discussion of the problem. Generally, this is called “fetch on render”, and is not recommended for loading data from a server. 

When loading data from a local database, individual queries typically take less than a millisecond to complete, and we can run dozens of queries sequentially between two rendering frames. This significantly reduces the waterfall problem, since the delays introduced by queries are almost insignificant. However, there can still be “flicker”.

The React [Suspense](https://react.dev/reference/react/Suspense) component offers a nice solution — with very minor code changes, we can render a fallback component such as a loader spinner while the queries are still loading. Adding React [`startTransition`](https://react.dev/reference/react/startTransition) or [`useTransition`](https://react.dev/reference/react/useTransition) will instead let React keep the current components until the queries have loaded, before rendering the new components. This is often just for a single frame, giving the appearance of the state loading instantly.

A future post will further dive into the details of Suspense. Implementing Suspense support for `usePowerSyncWatchedQuery` is currently in progress, and we already have a [pull request](https://github.com/powersync-ja/powersync-js/pull/100) open with a proof of concept.

## **Conclusion**

Using SQLite for state management is a new approach and there is more work required to cover more use cases, higher data volumes, low-latency rendering and performance in general. But even so, it already works quite well for a large share of use cases, and several developers have started observing that it’s a nice benefit to a local-first architecture. 

We are going to see a lot of new tooling around using a local-first paradigm for state management in the coming months, and over time, local-first state management may gradually start displacing use of existing state management frameworks.

## **Talk at LoFi Community**

This blog post was also the topic of a talk given by Conrad (co-founder of PowerSync) at the [Local-First (“LoFi”) Web Development](https://localfirstweb.dev/) community meetup #13. You can see the talk here:

[Video: Local-First State Management with SQLite - Conrad Hofmeyr at LoFi Web Dev Meetup](https://www.youtube.com/watch?v=Dn1u477sIVs)

[^1]: In this post we focus on React, but the same principles will apply to most other frameworks.
[^2]: In other frameworks than React, you would use the equivalent to this hook, for example `useQuery` might be a watch/subscribe API instead.
[^3]: The example code in this post is written for PowerSync, but the same concepts apply to other solutions. ElectricSQL has `useLiveQuery`. It parses the query in JavaScript to get the underlying tables, which imposes some limitations (e.g. it cannot handle views), but will cater for the majority of queries. CR-SQLite/Vulcan has `useQuery`. It uses the SQLite [tables_used](https://www.sqlite.org/bytecodevtab.html) function to get the underlying tables for the query. This is similar to `EXPLAIN` with a more stable API, but is not available in many SQLite builds by default (has to be enabled using a compiler flag).
[^4]: We are currently working on enabling `usePowerSyncWatchedQuery` to work with Kysely. We previously [released an initial Kysely integration](https://releases.powersync.com/announcements/kysely-orm-integration-for-react-native-and-js-web-beta-release).

---

# Engineering Notes: Integrating With Vue For Local-First SPAs

> An overview of the JavaScripyt Single Page Application (SPA) ecosystem and notes on how we engineered the PowerSync Vue Composables package.

- Published: 2024-04-17
- Author: Christiaan Landman
- Category: Engineering
- Source: https://powersync.com/blog/engineering-notes-integrating-with-vue-for-local-first-spas

---

## **The JavaScript SPA ecosystem**

In the ever-evolving JavaScript (Web) ecosystem, a select group of Single Page Application (SPA) frameworks claim the majority of developer mindshare and shape the trajectory of modern web development. Meanwhile, emerging contenders aim to challenge existing paradigms or introduce unique features, often focused on enhancing performance or developer experience. Some noteworthy ones include:

  1. [React](https://react.dev/): a library (not a framework) developed by Facebook. It utilizes a component-based architecture, enabling developers to create reusable UI elements.
  2. [Vue](https://vuejs.org/): a framework that provides a reactive and component-based structure similar to React. It also allows developers to incrementally adopt its features into existing JavaScript projects.
  3. [Angular](https://angular.io/): a framework maintained by Google.
  4. [Svelte](https://svelte.dev/): a novel approach to building user interfaces by shifting much of the work to compile time. Instead of shipping a framework to the browser, Svelte compiles components into highly optimized JavaScript during the build process.
  5. [Solid](https://www.solidjs.com/): a framework that feels similar to React when you compare its syntax to Functional Components and Hooks from React. Component functions are called only once at component construction and reactivity is facilitated by [signals](https://www.solidjs.com/tutorial/introduction_signals).

![](https://powersync.com/images/blog/engineering-notes-integrating-with-vue-for-local-first-spas-inline-55242098b8.png "JavaScript web frameworks.||portrait")

Two things that are common across these frameworks are that they are all manipulating HTML and have some sort of reactivity model (change HTML when something happens/changes). It’s common in building modern applications with SPAs to make sets of elements and units of logic reusable. This is often done by breaking code into components (leaning to separation by presentation) or somehow breaking logic out (reactivity logic included) into an importable module. Most SPA frameworks support some sort of component structure and something akin to [React Hooks](https://react.dev/reference/react/hooks) for sharing logic.

Additionally, there are meta frameworks that provide features and capabilities beyond what an SPA framework does out of the box. This can range from full-stack functionality (front to back) and server-side rendering (SSR) to other advanced features like data caching, routing, authentication, and authorization. Meta-frameworks tend to be built on top of an existing SPA framework. Some popular meta frameworks include:

  1. [Next.js](https://nextjs.org/): a React framework. 
  2. [Nuxt.js](https://nuxt.com/): a Vue.js framework.
  3. [SvelteKit](https://kit.svelte.dev/): a Svelte framework. 
  4. [SolidStart](https://start.solidjs.com/getting-started/what-is-solidstart): a framework for Solid that is currently in beta.
  5. [Astro](https://astro.build/): a framework for content-driven websites. Astro is UI-agnostic, meaning you can bring your own framework. React, Vue, Angular, Svelte, and Solid are all officially supported in Astro.

![](https://powersync.com/images/blog/engineering-notes-integrating-with-vue-for-local-first-spas-inline-6f3a957d91.png "JavaScript web meta frameworks.||portrait")

## **Reducing friction of using PowerSync for SPAs**

Of the above-mentioned SPA frameworks, PowerSync previously only had a wrapper package for [React](https://github.com/powersync-ja/powersync-js/tree/main/packages/react). It uses React Hooks around the [PS common SDK](https://github.com/powersync-ja/powersync-js/tree/main/packages/common) package to support reactivity/live query integration for PowerSync functionality — making it easy for developers using React in their project to leverage PowerSync. This didn’t mean that non-React based web projects could not use PowerSync, but that the barrier to entry was a bit higher than if they were to use React.

Today, we [announced](https://releases.powersync.com/announcements/powersync-vue) the alpha release of a Vue Composables package for PowerSync. In this post, we will provide some background on its development.

## **Where we started: Porting React implementation to Vue**

For adding the Vue reactivity wrapper, our first stab was to take the React wrapper and convert the React-specific code directly. The plan was to implement the wrapper co

```tsx
import { SQLWatchOptions } from '@journeyapps/powersync-sdk-common';
import React from 'react';
import { usePowerSync } from './PowerSyncContext';
/**
 * A hook to access the results of a watched query.
 */
export const usePowerSyncWatchedQuery = <T = any>(
  sqlStatement: string,
  parameters: any[] = [],
  options: Omit<SQLWatchOptions, 'signal'> = {}
): T[] => {
  const powerSync = usePowerSync();
  if (!powerSync) {
    return [];
  }
  const memoizedParams = React.useMemo(() => parameters, [...parameters]);
  const memoizedOptions = React.useMemo(() => options, [JSON.stringify(options)]);
  const [data, setData] = React.useState<T[]>([]);
  const abortController = React.useRef(new AbortController());
  React.useEffect(() => {
    // Abort any previous watches
    abortController.current?.abort();
    abortController.current = new AbortController();
    (async () => {
      for await (const result of powerSync.watch(sqlStatement, parameters, {
        ...options,
        signal: abortController.current.signal
      })) {
        setData(result.rows?._array ?? []);
      }
    })();
    return () => {
      abortController.current?.abort();
    };
  }, [powerSync, sqlStatement, memoizedParams, memoizedOptions]);
  return data;
};
```
de 

```typescript
// Note that with Vue's reactivity model - the 3 parameters for the composable aren't reactive and will need to be changed/wrapped to accommodate that.

import { SQLWatchOptions } from '@journeyapps/powersync-sdk-common';
import { usePowerSync } from './PowerSyncContext';
import { onBeforeUnmount, ref, watchEffect } from 'vue';

/**
 * A composable to access the results of a watched query.
 */
export const usePowerSyncWatchedQuery = <T = any>(
  sqlStatement: string,
  parameters: any[] = [],
  options: Omit<SQLWatchOptions, 'signal'> = {}
) => {
  const powerSync = usePowerSync();
  const data = ref([]);
  if (!powerSync) {
    return data.value;
  }
  let abortController = new AbortController();
  watchEffect(() => {
    // Abort any previous watches
    abortController.abort();
    abortController = new AbortController();
    (async () => {
      try {
        for await (const result of powerSync.value.watch(sqlStatement, parameters, {
          ...options,
          signal: abortController.signal
        })) {
          data.value = result.rows?._array ?? [];
        }
      } catch (error) {
        console.error('Error while watching query:', error);
      }
    })();
    onBeforeUnmount(() => {
      abortController.abort();
    });
  });
  return data;
};
```
as [composables](https://vuejs.org/guide/reusability/composables) which work similar to Hooks. Consider a quick and dirty port of one of the React Hooks:

React: `usePowerSyncWatchedQuery.ts`

Vue: `usePowerSyncWatchedQuery.ts`

We also identified the possibility to improve on the signatures of the `usePowerSyncQuery` and `usePowerSyncWatchedQuery` composables to return a reactive error and loading state which developers can hook onto.

```typescript
// An example drawn from Nuxt’s documentation:
const { data, error, execute, refresh } = await useFetch('/api/users')

// Could allow us to enrich the dev experience - just illustrative examples
const { data: customers, loading, error } = usePowerSyncWatchedQuery('SELECT id, name FROM customers');

// Current React usage
const customers = usePowerSyncWatchedQuery('SELECT id, name FROM customers');
```
After the reactivity was proven to work with a demo project (a Vue demo project derived from our [react-supabase-todolist](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-todolist) example), the next step was to include the Vue wrapper and demo project in the [powersync-js](https://github.com/powersync-ja/powersync-js/) repo. 

## **Unknowns at the time of initial design**

  1. How to map the React context/provider mechanism to Vue such that the same configuration is possible. With the React wrapper and React example project, context/providers are used to configure children of a top-level component such that all children are configured with a certain configuration.   
  
[Vuetify](https://vuetifyjs.com/en/getting-started/installation/#using-nuxt-3), [Pinia](https://pinia.vuejs.org/getting-started.html), and [Vue Router](https://router.vuejs.org/installation.html) (well-known Vue libraries) use Vue’s [plugin mechanism](https://vuejs.org/guide/reusability/plugins) which allows a library to have app-wide configuration installed on the Vue instance during instantiation — often propagating the configuration with [provide/inject](https://vuejs.org/guide/components/provide-inject).

  2. For the quick port above, parameters of the composable weren’t reactive. To do that in Vue you would need to wrap them with some help from Vue. For context, a Vue composable/component only executes once, whereas a React function/component executes multiple times — which is where we saw that parameter reactivity breaking in the Vue version.  
  
A first attempt was to make the composables take in both primitives and wrapped versions of the parameters. See the Vue [MaybeRef&lt;T&gt;](https://vuejs.org/api/utility-types#mayberef) utility type.

## **Update post-POC: Alpha implementation for Vue composables**

This is what we came up with after some experimentation: The parameters to the composable can either be normal JavaScript variables or refs, which on change will cause the query to refresh automatically. This is using the 

```typescript
import { SQLWatchOptions } from '@journeyapps/powersync-sdk-common';
import { MaybeRef, Ref, ref, toValue, watchEffect } from 'vue';
import { usePowerSync } from './powerSync';

export type WatchedQueryResult<T> = {
  data: Ref<T[]>;
  /**
   * Indicates the initial loading state (hard loading). Loading becomes false once the first set of results from the watched query is available or an error occurs.
   */
  loading: Ref<boolean>;
  error: Ref<Error>;
};

/**
 * A composable to access the results of a watched query.
 */
export const usePowerSyncWatchedQuery = <T = any>(
  sqlStatement: MaybeRef<string>,
  parameters: MaybeRef<any[]> = [],
  options: Omit<SQLWatchOptions, 'signal'> = {}
): WatchedQueryResult<T> => {
  const data = ref([]);
  const error = ref<Error>(undefined);
  const loading = ref(true);

  const powerSync = usePowerSync();

  let abortController = new AbortController();
  watchEffect((onCleanup) => {
    // Abort any previous watches when the effect triggers again, or when the component is unmounted
    onCleanup(() => abortController.abort());
    abortController = new AbortController();

    if (!powerSync) {
      error.value = new Error('PowerSync not configured.');
      return;
    }

    powerSync.value.watch(
      toValue(sqlStatement),
      toValue(parameters),
      {
        onResult: (result) => {
          loading.value = false;
          data.value = result.rows?._array ?? [];
          error.value = undefined;
        },
        onError: (e: Error) => {
          loading.value = false;
          data.value = [];

          const wrappedError = new Error('PowerSync failed to fetch data: ' + e.message);
          wrappedError.cause = e; // Include the original error as the cause
          error.value = wrappedError;
        }
      },
      {
        ...options,
        signal: abortController.signal
      }
    );
  });

  return { data, loading, error };
};
```
[newly added](https://github.com/powersync-ja/powersync-js/pull/105) `watch` with callback approach instead of `AsyncIterator`. Note that the implementation below might differ a bit from the released version.

`usePowerSyncWatchedQuery.ts`

See below for an example of this new composable in action. The query will refresh as the user changes the SQL in the input field, and any errors generated while typing will be shown.  

`TodoListDisplayWatchedQuery.vue

```vue
<script setup lang="ts">
import { usePowerSync, usePowerSyncWatchedQuery } from '@journeyapps/powersync-vue';
import { ref } from 'vue';

const query = ref('SELECT * from lists');
const { data: list, loading, error} = usePowerSyncWatchedQuery(query);

const powersync = usePowerSync();
const addList = () => {
    powersync.value.execute('INSERT INTO lists (id, name) VALUES (?, ?)', [Math.round(Math.random() * 1000), 'list name']);
}
</script>

<template>
    <input v-model="query" />
    
    <div v-if="loading">Loading...</div>
    <div v-else-if="error">{{ error }}</div>
    <ul v-else>
        <li v-for="l in list" :key="l.id">{{ l.name }}</li>
    </ul>
    <button @click="addList">Add list</button>
</template>
```
`

### **Bonus: for those unfamiliar with all the popular JavaScript options**

[Video: Engineering Notes: Integrating with Vue for Local-First SPAs](https://www.youtube.com/watch?v=WJRf7dh5Zws)

Careful, this guy has opinions.

---

# Using Kotlin Multiplatform With KMMBridge and SKIE To Publish A Native Swift SDK

> How we built a Swift SDK from Kotlin Multiplatform using SKIE and KMMBridge.

- Published: 2024-04-11
- Author: Manrich van Greunen
- Category: Engineering
- Source: https://powersync.com/blog/using-kotlin-multiplatform-with-kmmbridge-and-skie-to-publish-a-native-swift-sdk

---

> **Warning**
>
> After this article was written, we've replaced KMMBridge in favor of a custom publishing method.
> And in version 1.14.0 of the Swift SDK, we've replaced SKIE with a [pure Swift implementation](https://releases.powersync.com/announcements/swift-sdk-1-14-0-now-pure-swift).
> This article no longer describes the current architecture of the PowerSync Swift SDK, but it's a good overview on using SKIE and KMMBridge.

Our vision at PowerSync is to provide developers with a platform-agnostic sync layer for building local-first apps. We’re starting by expanding our client SDK to a range of frameworks, but in the near future we’ll also be adding additional database adapters (starting with MySQL). 

We recently released our Kotlin Multiplatform (KMP) SDK, adding to our growing list of PowerSync SDKs, see [here](https://github.com/powersync-ja#client-sdks). 

Some customers have been requesting support for PowerSync in native Swift, but as a small team implementing and shipping a Swift SDK would take some time. In the KMP community, many have faced a similar challenge and have developed a host of tools and approaches we could investigate. 

## KMP Summary 

_(Feel free to skip this section if you’re already familiar with KMP)_

  * KMP provides a framework and set of tools to write and maintain code for different platforms, with the flexibility and reliability of native programming.
  * Kotlin supports compiling to native targets. For iOS, the Kotlin compiler compiles shared- and native-specific code into Objective-C. This gets bundled into an Xcode framework which can then be included when building an iOS app.
  * A typical KMP developer will most likely not have to write much Swift code, apart from implementing Swift UI. Using UI frameworks like Kotlin Compose, the typical KMP developer might not even need to write _any_ Swift code.

## Enter SKIE

 _(pronounced as 'sky')_

In teams where iOS developers need to implement iOS- or Swift-specific parts of a KMP mobile app, they might find it difficult to use the Objective-C code and headers.

The difficulties might be because of the fact that the code is generated from Kotlin, which has differences in how `objects`, `classes`, `enums`, `function` parameters, etc. are declared. Or the KMP implementation might be using software concepts that are not supported (or maybe not widely supported) in Swift. Concepts like `flows`, `sealed classes`, `async callbacks`, etc.

[SKIE](https://skie.touchlab.co/) is a Gradle plugin developed and maintained by [Touchlab](https://touchlab.co/), headed by KMP expert [Kevin Galligan](https://github.com/kpgalligan). SKIE hooks into the KMP build pipeline to add and modify the generated Objective-C code that is included in the Xcode Framework. The aim is to improve the Developer Experience (DX) in Swift while preserving core Kotlin code features. It does this using a variety of approaches, which includes creating `completionHandler` wrappers, transpiling `sealed classes` into equivalent structures in Swift, renaming methods and parameters for better IntelliSense, and many more improvements. 

In summary, SKIE promises to provide better DX for Swift developers.

## Publishing with KMMBridge

Since the PowerSync SDK can be added to existing projects to enable local-first capabilities, we needed a way to build and publish the Xcode framework produced by KMP. Luckily the team at Touchlab also built a toolset called [KMMBridge](https://kmmbridge.touchlab.co/docs/) to enable this. They’ve also written various guides and provided a template project that was very helpful to get us set up.

Apart from a few issues with needing GitHub Personal Access Tokens and flushing Swift caches that needed to be cleared, we got everything working and could use the PowerSync framework in a standalone Swift app.

## Implementation

Using SKIE is as simple as applying the Gradle plugin to the module where the `framework` block for native compilations is declared.

For setting up KMMBridge, we followed [this guide](https://touchlab.co/kmmbridge-quick-start) which has an [accompanying GitHub template](https://github.com/touchlab/KMMBridgeSKIETemplate).

The basic approach is as follows:

  1. Create a dedicated Gradle module to use the KMP tooling to declare the iOS targets and configure a static `framework` that exports our `core` SDK module.
  2. Configure KMMBridge to use Swift Package Manager (instead of CocoaPods) and publish to our Maven repo hosted on GitHub.
  3. Set up a GitHub action with the relevant environment variables that calls Touchlab’s KMMBridge action. Given that our PowerSync Kotlin repo uses a custom Gradle plugin to publish to Sonatype Portal, we needed to iron out some issues with the multiple publishing config.
  4. After publishing, the framework can be added as a Package Dependency in Xcode, then imported in Swift files as any other framework, giving you access to exported code from KMP.

## Learnings

At the end of implementation, we had a decent sense of the pros and cons of this approach.

### Pros

  1. Write a Kotlin SDK and get Swift support, i.e. less code maintenance.
  2. Touchlabs are pushing to make SKIE + KMMBridge great (performant and good DX).
  3. Our team has more experience on the Kotlin/Java side of things, versus Swift.

### Cons

  1. Requires jumping through some config hoops, both for deploying the Swift Package and actually getting it installed in an app. [^1]
  2. Not the best Swift DX out of the box (lots of generated code, less _Swifty_ code patterns, and APIs), although these can be improved by using SKIE annotations and guidelines.
  3. The total bundle size does increase, because the Kotlin standard library is included in the generated library.

## Summary

Weighing up all the above and in light of positive early feedback from customers, we have decided to continue pursuing using SKIE + KMMBridge for publishing our Swift SDK.

Our Swift SDK is currently in closed alpha with select customers — please get in touch on [our Discord](https://discord.gg/powersync) if you’d like to test it!

[^1]: We found that installing the SDK as an end-user required these steps:

    1. You’ll need a GitHub Personal Access Token (PAT) with `read:packages` permissions. If you don't have one, create one at [https://github.com/settings/tokens](https://github.com/settings/tokens).

       ![](https://powersync.com/images/blog/using-kotlin-multiplatform-with-kmmbridge-and-skie-to-publish-a-native-swift-sdk-inline-7c38791100.png)

    2. Create a `~/.netrc` file with the following contents (this is the recommended approach by [KMMBridge](https://touchlab.co/quick-start-with-kmmbridge-1-hour-tutorial#configure-xcode-clients)):

       ```text
       machine maven.pkg.github.com
         login [your GitHub username]
         password [your PAT from step 1]
       ```

    3. Clear Swift caches (typically needed after there were issues while adding our Package Dependency, including PAT with incorrect permission, incorrect version or tag, etc.):

       ```bash
       rm -rf ~/Library/Caches/org.swift.swiftpm
       rm -rf ~/Library/org.swift.swiftpm
       ```

    4. Reset Packages in Xcode: `File -> Packages -> Reset Packages`

    5. Clean and rebuild the project.

---

# PowerSync Update: March 2024

> Our latest updates from March 2024, including a fresh website update, open alpha release of Kotlin Multiplatform support, CLI beta release and an update on self-hosting.

- Published: 2024-04-02
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/product-update-march-2024

---

The alpha release of our Kotlin Multiplatform Client SDK is one of our big announcements for March. We kept things moving with multiple updates to our JavaScript web and React Native SDKs as well as our attachments helper library for React Native. We’ve also been making progress on a few major upcoming features, like self-hosting.

It’s also been great to connect with the broader local-first community. We were invited to present at the Local-First (“LoFi”) Web Development community’s March meetup (more on that below) and are sponsoring [Local-First Conf](https://www.localfirstconf.com/) happening in Berlin in a couple of months. More exciting developments ahead!

## **Freshly-Baked Website Update**

![](https://powersync.com/images/blog/product-update-march-2024-inline-b81f7b28bd.png)

We’ve redesigned our home page with one goal in mind: help developers quickly construct a mental model of how PowerSync works.

We’d love to hear your thoughts. Drop a comment on Discord with any feedback.

[See the new home page](https://powersync.com/)

## **Kotlin Multiplatform Support: Open Alpha Release**

![](https://powersync.com/images/blog/product-update-march-2024-inline-a908982445.png)

One of our key objectives is to be a stack-agnostic sync layer, so the alpha release of our Kotlin Multiplatform client SDK is a big milestone for us.

This initial release includes support for Android and iOS targets. It also includes a demo app that integrates with Supabase and allows you to easily test the SDK.

Thanks to **Sami D** , **Cameron G** , **Sam H** and **Salomon B** for your discussions and feedback.

[Read the announcement](https://releases.powersync.com/announcements/powersync-kotlin-multiplatform-client-sdk-open-alpha)

## **CLI Beta Release**

![](https://powersync.com/images/blog/product-update-march-2024-inline-fa861e0ae3.png)

Our CLI is now in beta! Anyone can now control their PowerSync instances directly from the command line.

Thanks to **Husain B** , **Patrik W** , **Ben M** and **Josh S** for your help with testing.

[Read the announcement](https://releases.powersync.com/announcements/powersync-cli-beta)

## **LoFi Meetup Talk**

![](https://powersync.com/images/blog/product-update-march-2024-inline-a77a922255.png)

Local-First (“LoFi”) Web Development is a rapidly-growing community focused on local-first software development. We were invited to participate in their 13th monthly meetup where Conrad presented on using a synced SQLite database for state management in a local-first architecture.

Thanks to **Yonz** for the invite!

[Watch the talk](https://www.youtube.com/watch?v=oMYCsUo7iVA&t=1427s)

## **Self-Hosting**

![](https://powersync.com/images/blog/product-update-march-2024-inline-43dc07fea6.png)

We’re in the final stretch of work required to release self-hosting. Once available, a Docker image will allow developers to self-host the PowerSync Service, and will initially be available to our enterprise customers.

This version paves the way for our free source-available self-hosted version that will then be next on our list.

That's it for the March update!

---

# PowerSync Update: February 2024

> Our latest updates from February 2024, including our open alpha release of Flutter Web support, ORM integrations with Drift and Kysely, and highlights from our February Community Call.

- Published: 2024-03-05
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-february-2024

---

Our Flutter Web support and ORM support are top of the bill this month. We’re also welcoming two new team members joining us on our mission to make local-first the easiest architecture for app development — welcome **Mugi K** and **Christiaan L**!

We saw a record number of new users sign up for PowerSync in February, in line with growing interest in local-first software development. **Carl K** wrote about how the [local-first DX benefits from simpler state management](https://intuitably.com/epiphanies/2024/02/23/flutter) while **Simon Grimm** says that _local-first is the future_ ; check out his video below:

## **Flutter Web Support: Open Alpha Release**

![](https://powersync.com/images/blog/powersync-update-february-2024-inline-adfa130ebd.png)

Our goal is to be a stack-agnostic sync layer, so incorporating web support for Flutter apps is a major milestone for us. Now Flutter developers can use the same Dart codebase to build local-first web and mobile apps. As with our JavaScript Web SDK, the Flutter Web implementation utilizes a virtual file system (VFS) interface to persist SQLite data in the browser storage (IndexedDB by default).

Thanks to **Giorgio G** and **Ben C** for spurring us on and providing valuable feedback on our first release.

[Read the announcement](https://powersync.com/blog/announcing-powersync-flutter-web-support)

## **ORM Integrations: Drift and Kysely**

![](https://powersync.com/images/blog/powersync-update-february-2024-inline-a9e11fc505.png)

We plan to add ORM support to each of our client SDKs, starting with Flutter and JavaScript. For Flutter, we have alpha support for using the popular **Drift persistence library (ORM)** with the PowerSync Flutter SDK. For JavaScript apps, our React Native and Web SDKs can now be used with **Kysely Query Builder**. 

Thanks to **Simon B** , **Rody D** , **Josh S** and **Steven B** for their help, thoughts and guidance.

[Read more](https://powersync.com/blog/using-orms-with-powersync)

## **Dashboard Update: Granular Deploy Statuses**

![](https://powersync.com/images/blog/powersync-update-february-2024-inline-becc40fec5.png)

This small but mighty UX update brings more granular deploy statuses to the deploy logs in your PowerSync dashboard. Logs now show one of four explicit statuses:

  * “No replication errors”
  * “Processing sync rules”
  * “Warning: No connection configured”
  * “Warning: No sync rules deployed”

[Go to your dashboard](https://accounts.powersync.com)

## **Temporary Development Tokens**

![](https://powersync.com/images/blog/powersync-update-february-2024-inline-4308b12f55.png)

Support for temporary developer tokens allows you to get up and running with PowerSync quickly, without implementing a full auth solution. This is particularly relevant for non-Supabase projects.

Thanks to **Carl K** for helping us think through this.

[Read the docs](https://docs.powersync.com/usage/installation/authentication-setup/development-tokens)

## **February Community Call**

![](https://powersync.com/images/blog/powersync-update-february-2024-inline-5a4efd4575.png)

We held our first community call of 2024, with **Dom B** demoing the new PowerSync CLI, **Conrad** walking us through a CRDT implementation on PowerSync, and **Husain B** and **Matt W** showing off **Jetpack Travel,** a cross-platform travel management app built with PowerSync. We also covered our current roadmap priorities.

[Watch the presentations](https://youtube.com/playlist?list=PL7kUAxrC7PyRULUC_5w9PMD5wlT6aVm2g&si=twe5zniPIraqCmmz)

[Video: PowerSync update — February 2024](https://www.youtube.com/watch?v=SnhNHjqIbNw)

---

# Build Local-First Kotlin Multiplatform Apps With PowerSync

> The PowerSync Kotlin Multiplatform SDK is now in open alpha. Use it with a Postgres backend database to instantly make your KMP app local-first with PowerSync as the sync layer.

- Published: 2024-03-04
- Author: Benita Volkmann
- Category: Announcement
- Source: https://powersync.com/blog/build-local-first-kotlin-multiplatform-apps-with-powersync

---

The PowerSync Kotlin Multiplatform SDK is now in open alpha. Use it with a Postgres backend database to instantly make your KMP app local-first with PowerSync as a sync layer. Supported targets: Android and iOS. Supabase integration available.

## Kotlin Multiplatform SDK

Today we are announcing the alpha release of the [PowerSync Kotlin Multiplatform SDK](https://github.com/powersync-ja/powersync-kotlin/tree/main).

With this release, Kotlin Multiplatform (KMP) developers can easily build local-first apps to achieve simplified state management and real-time reactivity. This release includes support for Android and iOS targets, with additional targets (JVM, Wasm) being considered for a future release.

### SDK Features

  * Provides real-time streaming of database changes, using Kotlin Coroutines and Flows.
  * Offers direct access to the SQLite database, enabling the use of SQL on both client and server sides.
  * Operations are asynchronous, ensuring the user interface remains unblocked.
  * Supports concurrent database operations, allowing one write and multiple reads simultaneously.
  * Enables subscription to queries for receiving live updates.
  * Eliminates the need for client-side database migrations as these are managed automatically.

### Engineering Notes

Our initial plan was to build a Kotlin Native library targeting Android and iOS but we changed gears to build a Kotlin Multiplatform library, given its popularity and [benefits](https://kotlinlang.org/docs/multiplatform.html). 

We are using [SQLDelight](https://github.com/cashapp/sqldelight)’s API and drivers to connect to and execute queries in SQLite since it provides asynchronous database queries and flows — forming part of PowerSync’s core features. In the future, we plan to integrate with the SQLDelight compiler providing ORM-like capabilities.

The PowerSync library loads a SQLite extension and sets up SQLite native bindings on each platform. On iOS, we use CocoaPods to add a pod dependency and [cinterop](https://kotlinlang.org/docs/native-c-interop.html) compilations to build an iOS framework. On Android, we use a custom database open factory to load our extension and call JNI bindings.

### Current Limitations

Debugging via configurable logging is not yet implemented. The above-mentioned integration with SQLDelight’s compiler for ORM-like capabilities is also planned. This SDK currently supports only a single SQLite database file.

### Native Development

PowerSync support for Kotlin Native and native Swift development is in active development. 

## Demo App

The easiest way to test the SDK is to run the **hello-powersync** demo app. Instructions for this can be found [here](https://github.com/powersync-ja/powersync-kotlin/tree/main/demos/hello-powersync). This app uses Compose Multiplatform and demonstrates real-time streaming of Postgres data and offline CRUD operation queuing & syncing. The demo app also showcases our integration with Supabase.

We would love to hear your feedback. Reach out to us on [Discord](https://discord.gg/powersync) if you have any feedback, need help or have any questions.

---

# Announcing PowerSync Flutter Web Support

> We are excited to announce the alpha release of web support for the existing PowerSync Flutter SDK. Now, Flutter developers can use the same Dart codebase to build local-first web and mobile apps.

- Published: 2024-02-15
- Author: Benita Volkmann
- Category: Announcement
- Source: https://powersync.com/blog/announcing-powersync-flutter-web-support

---

## Flutter Web SDK

Today we are announcing the alpha release of web support for our existing [Flutter SDK](https://pub.dev/packages/powersync/versions/1.3.0-alpha.2).

With this release, Flutter developers can use the same Dart codebase to build local-first web and mobile apps with simplified state management and real-time reactivity. This release extends the PowerSync Flutter SDK to support web applications, allowing them access to the benefits of local-first architecture, including simplified state management. As with our [JavaScript Web SDK](https://www.npmjs.com/package/@powersync/web), the Flutter web implementation utilizes a virtual file system (VFS) interface to persist SQLite data in the browser storage (IndexedDB by default.)

### SDK Features

  * Connects to PowerSync service to sync data with any backend Postgres database.
  * Instantly-reactive UI interactions for the user.
  * Real-time streaming of changes.
  * Operations are asynchronous by default — they do not block UI interactions.
  * Supports one write and many reads concurrently.
  * No need for client-side database migrations — these are handled automatically.

### Engineering Notes

At PowerSync, [our goal](https://docs.powersync.com/overview/powersync-philosophy) is to be stack-agnostic, which is why incorporating web support for Flutter apps was a major milestone for us. 

The engineering work involved in supporting Flutter web was substantial because the web paradigm differs fundamentally from native platforms. Addressing tasks like storage and asynchronous database operations on web adds layers of complexity. 

To accommodate these differences, we had to restructure our existing codebase significantly. In our implementation, we introduced abstraction layers for core functionality in the [**sqlite_async.dart**](https://github.com/powersync-ja/sqlite_async.dart) and [**powersync.dart**](https://github.com/powersync-ja/powersync.dart) libraries. 

This separation enabled us to have distinct implementations for web and native platforms on aspects such as database connections. This all happens under the hood — the developer still calls the same API, which uses `common` typings that are available on both native and web.

### Limitations

Note that multiple tab support is not yet available. Using a web application in multiple tabs will cause database connection conflicts. We plan to implement support for this soon.

## Demo App

The easiest way to test out the alpha version is to run the existing Supabase Todo-List demo app in your browser. Instructions for this can be found in the [SDK’s README](https://github.com/powersync-ja/powersync.dart/tree/alpha-release/packages/powersync). Make sure you checkout the `alpha-release` branch when you follow these instructions.

We would love to hear your feedback. Reach out to us on [Discord](https://discord.gg/powersync) if you have any feedback, need help or have any questions.

---

# How Local-First Simplifies Flutter State Management

> State management can be complicated, but it is possible to eliminate most of the complexities with a local-first architecture.

- Published: 2024-02-12
- Author: Phillip van der Merwe
- Category: Engineering
- Source: https://powersync.com/blog/how-local-first-simplifies-flutter-state-management

---

Click-to-deploy backends like [Supabase](https://supabase.com/) have made it much easier to get a Flutter project off the ground quickly. 

However, state management remains complicated. In Flutter, built-in widgets have limitations and the many different third-party packages (**flutter_bloc** , **Provider** , **Riverpod** , etc.) make it hard to decide which one to use. And implementing caching, invalidation and optimistic updates can be challenging even with a great state management framework.

But it is actually possible to eliminate most of the complexities of state management, with local-first architecture.

## What is local-first?

Local-first is a development paradigm where your app code works directly with a client-side (local) database which syncs with a backend database in the background. This is in contrast to cloud-first apps which primarily use a cloud datastore via APIs.

Local-first simplifies state management because your local database is the primary data source for your app. The diagram below shows the difference in how data would travel from source to the UI:

> Note: on the _local-first_ side, the local database will typically be kept in sync with a backend database through a separate, asynchronous process.

![](https://powersync.com/images/blog/how-local-first-simplifies-flutter-state-management-inline-8bf2383c11.png)

In local-first apps, the global state is simply stored in the local database. This substantially simplifies application code since queries can be done synchronously (without a roundtrip to the backend) and the developer does not have to handle loading states or network failure states.

The app will be fast and responsive since there’s no need to wait for network requests.

## What about sync?

Unless you’re building a _local-only_ app (which is a valid way to get your project off the ground quickly), a way to sync data between the local database and the backend database will be necessary. 

Once you have a local database that is always in sync, state management becomes much easier:

  * No need for custom caching logic, whether in-memory or persisted.
  * No need for maintaining in-memory state across the application.

All state is in the local database. Queries are reactive — updating whenever the underlying data changes.

Local-first provides a simpler paradigm for app development, allowing you to keep your logic simple and functional. As the [Project Lightspeed team](https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/) at Meta said about the benefits of a SQLite-driven architecture: _“We leveraged the SQLite database as a universal system to support all the features. [...]_**_The UI merely reflects the tables in the [local] database_** _.”_  

## How to build local-first

Developing local-first is simple in theory:

  1. Implement a local database as part of your app.
  2. Implement a way to transfer data updates between the local database and the backend database (a sync system).

In reality this is not so easy. For one thing, there are a few local datastore options available for Flutter, and choosing one can be just as challenging as choosing a state management solution. For another, implementing a sync system usually becomes a rabbit hole for anything but the most simple apps.

![](https://powersync.com/images/blog/how-local-first-simplifies-flutter-state-management-inline-4efa300c45.png)

[@EvHaus on X / Twitter](https://x.com/EvHaus/status/1756765416439902453?s=20)

We built PowerSync to solve these issues:

  * Our [Flutter SDK](https://pub.dev/packages/powersync) includes a high-performance SQLite database: a proven relational database (SQLite is the [most deployed database in the world](https://www.sqlite.org/mostdeployed.html)). 
  * The PowerSync service is a click-to-deploy sync system that can handle even the most complex sync requirements through a system called [sync rules](https://docs.powersync.com/usage/sync-rules). 

The PowerSync service is**non-invasive** to your backend: it can easily be added or removed from your stack. 

## Supabase setup

Using PowerSync with Supabase is probably the easiest way to go from zero to full local-first app with sync. We've written a [Flutter tutorial](https://powersync.com/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync) as a step-by-step guide that takes around 40min to complete.

Trying local-first is easy with our [**free plan**](https://powersync.com/pricing)(sign up [here](https://accounts.powersync.com/portal/powersync-signup)), or see what others are building on our [community Discord](https://discord.gg/powersync).

Happy coding!

---

# PowerSync Update: January 2024

> Our latest updates from January 2024, including JS Web, Flutter and React Native Client SDK updates, as well as a tutorial on building collaborative apps with CRDTs and PowerSync.

- Published: 2024-02-01
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-january-2024

---

A CRDT demo app, updated client SDKs and another app built with PowerSync getting approved into the App Store were some of the highlights of a January that has flown by! Here’s the skinny:

## **Building Collaborative Apps with CRDTs and PowerSync**

![](https://powersync.com/images/blog/powersync-update-january-2024-inline-ba4604c14e.gif)

There’s been a lot of interest in CRDTs lately so we’ve been itching to show how well they work with PowerSync. We released an initial **Yjs** \+ PowerSync collaborative text editing demo app which uses the **Tiptap** rich text editor. It stores the CRDT data structure in Postgres and keeps it in sync between clients in real-time.

Thanks to **Andric** for spurring us on here!

[Read the post](https://powersync.com/blog/postgres-and-yjs-crdt-collaborative-text-editing-using-powersync)

## **JS Web Client SDK v0.2.0**

![](https://powersync.com/images/blog/powersync-update-january-2024-inline-8219f8a94f.png)

Our web SDK now supports a `viewName` override which improves support for **local-only tables**. We also shipped enhanced support for multiple tabs. All tabs share a common SQLite database and are watched reactively.

[Try our live web demo app](https://powersync.com/demo)

## **Flutter Client SDK v1.2.1**

![](https://powersync.com/images/blog/powersync-update-january-2024-inline-ebb4743e9f.png)

The updated Flutter client SDK improves the default log output and errors to better assist in debugging. Note some breaking changes were introduced in V1.2.0 — see our full release notes for more details. This SDK also supports **local-only tables**.

Thanks to **Josh S** and **Carl K** for their help!

[See the changelog](https://releases.powersync.com/announcements/flutter-client-sdk)

## **React Native Client SDK v1.2.0**

![](https://powersync.com/images/blog/powersync-update-january-2024-inline-e05683a007.png)

We shipped two minor versions of our React Native SDK in January. Updates include global locks for syncing connections, a warning when creating multiple PowerSync instances and improved ability to receive batched table updates from DB adapters. This SDK also now supports the `viewName` override which improves support for **local-only tables**.

Thanks to **David B** , **Husain B** and **Matt W** for reaching out about this!

[See the changelog](https://releases.powersync.com/announcements/react-native-client-sdk)

## **Built with PowerSync — Jetpack**

![](https://powersync.com/images/blog/powersync-update-january-2024-inline-0839027a3c.png)

Congrats to our friends over at **Jetpack Travel** for releasing their PowerSync-powered app to the app store! Their stack consists of **Next.js** and **React** (through **Solito**), **PowerSync** and **Supabase**. 

Good luck to **David B** , **Husain B** and **Matt W**!

[Check out their landing page](https://www.usejetpack.com/) and [their app](https://apps.apple.com/us/app/jetpack-travel/id6463268442)

## **Coming Soon**

![](https://powersync.com/images/blog/powersync-update-january-2024-inline-47eeabe4c3.png)

Client SDKs for **Kotlin Multiplatform** and **Flutter Web** are around the corner, stay tuned!

[Bookmark our roadmap](https://roadmap.powersync.com/tabs/5-roadmap)

Have any questions? [Book a zoom call with us](https://calendly.com/powersync-product/powersync-chat?month=2024-02) to chat!

---

# Postgres And Yjs CRDT Collaborative Text Editing, Using PowerSync

> One use case for CRDTs is collaborative text editing: a popular example of this is Yjs. This post covers how CRDTs can be implemented on top of PowerSync.

- Published: 2024-01-16
- Updated: 2025-11-17
- Author: Conrad Hofmeyr
- Category: Showcase
- Source: https://powersync.com/blog/postgres-and-yjs-crdt-collaborative-text-editing-using-powersync

---

One of the strengths of CRDTs is that they are very well-suited to collaborative text editing. A popular example of this is [Yjs](https://github.com/yjs/yjs), a CRDT implementation that has been integrated with a variety of rich text editors.

We’ve [previously mentioned](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer#server-authority-instead-of-distributedcrdt-architecture) that CRDTs can be implemented on top of PowerSync for exactly such use cases. 

So we’ve been planning to show how Yjs can be used with PowerSync to store the Yjs CRDT data structure in the backend database, and keep it in sync between clients in real-time. Some members of the PowerSync community also asked about this recently (thank you to [Andric](https://twitter.com/astralwave) in particular!).

In response to this interest, today we’re excited to release an initial [Yjs + PowerSync demo](https://github.com/powersync-ja/powersync-js/tree/main/demos/yjs-react-supabase-text-collab) which uses the [Tiptap](https://tiptap.dev/) rich text editor. We built the demo as a React app with the [PowerSync Web SDK](https://docs.powersync.com/client-sdk-references/js-web), and used Supabase as our Postgres backend for simplicity.

![](https://powersync.com/images/blog/postgres-and-yjs-crdt-collaborative-text-editing-using-powersync-inline-25a4bcebb8.gif)

## Storing CRDT Data in the Backend Database

CRDT data structures can be stored in SQL databases as binary/blob data. In Postgres, we use the [BYTEA column type](https://www.postgresql.org/docs/current/datatype-binary.html).

Depending on your data storage, it may be more efficient to have the CRDT data structure be split up to some extent. For example, it’s typically not very efficient to update a 1MB blob in-place in a database row. 

Therefore, for our demo we elected to store a separate database row for each update to the Yjs document. Since CRDTs are [commutative](https://en.wikipedia.org/wiki/Commutative_property), a Yjs document can be constructed from scratch by applying all the individual updates in any order, so this storage approach works well, and it also makes it easy to sync incremental updates between users.

Accordingly, here is the simplified [Postgres schema](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/database.sql) that we used for our demo app:

![](https://powersync.com/images/blog/postgres-and-yjs-crdt-collaborative-text-editing-using-powersync-inline-aed651c96a.png)

To prevent an ever-growing list of updates, updates may be merged periodically. This reduces the storage overhead — both in number of updates, and in update size

```sql
SELECT id, document_id, base64(update_data) as update_b64 FROM document_updates
```
.

## PowerSync Sync Rules

PowerSync cannot [currently](https://docs.powersync.com/usage/sync-rules/types) sync BYTEA columns directly from Postgres, so we need to convert the BYTEA column to Base64 in the PowerSync [Sync Rules](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/sync-rules.yaml) configuration:

## Client-Side Yjs + PowerSync Implementation

Yjs has a concept of [Providers](https://github.com/yjs/yjs?tab=readme-ov-file#providers), and more specifically _Connection Providers_ (which handle communication between clients) and _Persistence Providers_ (which handle data storage). Unless there are providers already available that suit your needs, implementing and maintaining providers can potentially require a non-trivial engineering effort for a developer wanting to use Yjs.

When PowerSync is used to store Yjs documents and sync document updates between users, it basically combines the Connection Provider and Persistence Provider in one: PowerSync stores all the document data in e.g. Postgres on the server-side and in SQLite on the client-side, and syncs it automatically between users (keeping the local SQLite database up to date on each client). This reduces Yjs implementation effort quite a bit.

On the client side, a Yjs document is [instantiated in memory](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/src/app/editor/page.tsx) and populated by applying document updates that are queried from the local SQLite database. 

We can use PowerSync _live queries_ to continuously watch the local database for document updates, and then apply those to the in-memory Yjs document, as seen in [PowerSyncYjsProvider.ts](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/src/library/powersync/PowerSyncYjsProvider.ts): (therefore, this query takes care of both the initial loading of the document from the local database, as well as receiving real-time updates from other users)

```typescript
const seenDocUpdates = new Set<string>();

const updates = db.watch('SELECT * FROM document_updates WHERE document_id = ?', [documentId])

for await (let results of updates) {
  // New data detected in the database
  for (let update of results.rows!._array) {
    // Ignore any updates we've already seen
    if (!this.seenDocUpdates.has(update.id)) {
      this.seenDocUpdates.add(update.id);      
      // apply the update from the database to the doc
      const origin = this;
      Y.applyUpdateV2(doc, b64ToUint8Array(update.update_b64), origin);    
    }
  }
}
```

A few notes on the above:

  * Yjs uses `Uint8Array` to represent binary data in JavaScript, so we convert the Base64 data from the database to `Uint8Array`.
  * Yjs allows a custom `origin` property to be associated with document updates. We use this to keep track of which updates were loaded from the local database vs. updates that originated from the Tiptap text editor as the user makes edits to the document.

The remaining part of the client-side implementation is to watch for new edits to the Yjs document (made by the user via the Tiptap text editor) and then to persist those document updates to the local SQLite databas

```typescript
doc.on('updateV2', async (update: Uint8Array, origin: any) => {
    if (origin === this) {
      // update originated from the database / PowerSync - ignore
      return;
    }
    // update originated from elsewhere - save to the database
    const docUpdateId = uuidv4();
    this.seenDocUpdates.add(docUpdateId);
    await this.db.execute('INSERT INTO document_updates(id, document_id, update_b64) VALUES(?, ?, ?)', [
      docUpdateId,
      this.documentId,
      Uint8ArrayTob64(update)
    ]);
  }
);
```
e, from where PowerSync will sync them to Postgres and to other clients: (here, we are doing the inverse conversion of `Uint8Array` to Base64)

## Writing to the Backend Database

As you may know, PowerSync allows the developer to define their own backend connector — i.e. the developer controls how writes are made to the backend source database, e.g. Postgres. 

In the [SupabaseConnector.ts](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/src/library/powersync/SupabaseConnector.ts) in our demo app, you will see that for efficiency reasons we [batch together](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/src/library/powersync/SupabaseConnector.ts#L75) the insertion of document updates into the database, using an `insert_document_updates` Postgres function defined in [database.sql](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/database.sql).

## Merging Updates

The more edits are made to a document, the longer the Yjs CRDT update history becomes. We mentioned above that updates can be merged to compact the history. We’ve included a very basic [Supabase edge function](https://github.com/powersync-ja/powersync-js/blob/main/demos/yjs-react-supabase-text-collab/supabase/functions/merge-document-updates/index.ts) to show how updates can be merged using Yjs. 

## Running the Demo

For a short demo video and for full instructions on how to run the demo, refer to the repo [README](https://github.com/powersync-ja/powersync-js/tree/main/demos/yjs-react-supabase-text-collab#readme).

## Roadmap

This is currently a fairly simple demo with various opportunities for improvement. We have listed some specific planned improvements under the [roadmap section](https://github.com/powersync-ja/powersync-js/tree/main/demos/yjs-react-supabase-text-collab#demo-app-roadmap) of the README. Feel free to open a PR if there’s anything you’d like to contribute!

---

# PowerSync Update: December 2023

> Our latest updates from December 2023, including a new attachments package for Flutter, Neon support, Railway support, and a Supabase integration update.

- Published: 2024-01-08
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-december-2023

---

Here’s a summary of some delightful things we shipped in the last month of 2023:

## **Attachments library for React Native**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-e449d453ba.png)

We’ve released this library to make it easy to manage syncing attachments/files in React Native apps using PowerSync. The package includes an example that covers capturing photos while offline as part of an inspection workflow.

[Go to the package](https://www.npmjs.com/package/@powersync/attachments)

## **Attachments package for Flutter**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-5639092211.png)

Following multiple requests, we released a similar package for Flutter that handles syncing creates, updates and deletes of files between local and remote attachment storage.

Thanks to **T Drummond** for spurring us on here!

[Go to the package](https://pub.dev/packages/powersync_attachments_helper)

## **Neon (serverless Postgres) support**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-cb5b5f8f0e.png)

Neon is a serverless Postgres environment with an innovative pricing model that separates storage and compute. They’ve recently added support for CDC, so we updated the PowerSync service to be fully compatible with Neon.

[See the installation docs](https://docs.powersync.com/usage/installation/database-setup/neon)

## **Railway support**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-df2ac19f97.png)

We've had some developers ask whether we integrate with Railway, so we published an integration guide on our docs site and a Railway Template which pre-configures Postgres for logical replication. The template also includes a barebones starter Node.js project showing off how PowerSync can integrate with existing backends.

Thanks to **poolnoodle93** for getting us on this!

[![](https://powersync.com/images/blog/powersync-update-december-2023-inline-ba929c33f0.png)](https://railway.app/template/RfZi6y)

## **Step-by-step Flutter chat app tutorial**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-4d64a899c4.png)

For those who like learning by doing, we created a complete tutorial for building an offline-first Flutter chat app with real-time sync and data streaming. The tutorial complements an existing video tutorial and uses **Supabase’s** excellent chat app tutorial as a starting point.

[Start the tutorial](https://powersync.com/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync)

## **Supabase integration update**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-68fe234bea.png)

Our Supabase integration has grown from strength to strength and seen a lot of use, so we put together a summary of all updates we’ve shipped for it. We’ve focused on extending PowerSync’s functionality as well as providing guides and resources for Supabase users and we’ve already seen some impressive implementations

[Read the full update post](https://powersync.com/blog/supabase-integration-update-december-2023)

## **JS Web client SDK v0.1.1**

![](https://powersync.com/images/blog/powersync-update-december-2023-inline-386743a3dd.png)

This update to the PowerSync web SDK introduces additional support for bundling. It includes two example projects: one for bundling with **Webpack** and one for bundling with **Vite**.

Thanks to **sg5184** for bringing this into focus!

[See the full changelog](https://releases.powersync.com/announcements/powersync-js-web-client-sdk)

---

# Flutter Tutorial: Building An Offline-First Chat App With Supabase And PowerSync

> This tutorial walks through building an offline-first chat app, using the Supabase Flutter chat app tutorial as a starting point and then integrating PowerSync. It should take ~30-45min to complete.

- Published: 2023-12-14
- Updated: 2025-09-30
- Author: Kobie Botha
- Category: Tutorial
- Source: https://powersync.com/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync

---

Offline-first apps feel instant to use because they work with a local in-app database, are functional even if the user’s network connection is interrupted, and provide multi-user real-time collaboration. If you're new to PowerSync, [start at this post](https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer) for an introduction to the technology.

This tutorial walks through building an offline-first chat app, using the [Supabase Flutter chat app tutorial](https://supabase.com/blog/flutter-tutorial-building-a-chat-app) as a starting point and then integrating PowerSync. It should take ~30-45min to complete.

Before proceeding, you should have accounts with both Supabase and PowerSync. If you don't have accounts yet, don't worry — you can get started for free with PowerSync [here](https://accounts.powersync.com/portal/powersync-signup), and with Supabase [here](https://supabase.com/dashboard/sign-in?). You should also have Flutter set up.

For a video version of this tutorial, watch the full walkthrough below:

[Video: Build an offline-first chat app with Flutter, Supabase and PowerSync](https://www.youtube.com/watch?v=EmtOfiELasY)

## Tutorial Overview

  1. Set up Supabase project and publication to PowerSync
  2. Clone Supabase Flutter chat app
  3. Run the app in its online-only form
  4. Set up PowerSync service
  5. Integrate PowerSync's Flutter SDK to make the app offline-first

## 1\. Set up Supabase project and publication to PowerSync

Complete only the following two steps in the [Supabase Flutter chat app tutorial](https://supabase.com/blog/flutter-tutorial-building-a-chat-app). This should take less than 2 minutes.

  1. [Creating a new Supbase project](https://supabase.com/blog/flutter-tutorial-building-a-chat-app#creating-a-new-supabase-project)
  2. [Setting up tables in Supabase](https://supabase.com/blog/flutter-tutorial-building-a-chat-app#setting-up-tables-in-supabase)

You should now have two tables in your Supabase project: `messages` and `profiles` You can now exit the Supabase Flutter chat app tutorial.

Allow Supabase to publish data changes to PowerSync by running the below SQL statement in your **Supabase SQL Editor** :

```sql
CREATE PUBLICATION powersync FOR TABLE public.messages, public.profiles;
```

## 2\. Clone Supabase Flutter chat app

Clone the Supabase Flutter chat app code from [this template](https://github.com/powersync-ja/powersync-supabase-flutter-simple-chat-demo-template) with this command:

```shell
git clone https://github.com/powersync-ja/powersync-supabase-flutter-simple-chat-demo-template
```

Make sure you're in the newly cloned directory:

```shell
cd powersync-supabase-flutter-simple-chat-demo-template
```

Install dependencies by running this command:

```shell
flutter pub get
```

Open the project in VSCode — a quick way to do this is with the `code .` command.

You don't want to commit your secrets into GitHub so copy and rename the `.env.template` file to `.env`.

Replace the placeholder values in that file:

  1. Find your **project URL** in Supabase, go to **Settings > API > Copy Project URL** and replace the placeholder URL value at `SUPABASE_URL=`.
  2. Find your **anon key** just below that at `anon` `public` and replace the placeholder value at `SUPABASE_ANON_KEY=`.

Save that file. 

Because of the way signups are handled in the Supabase Flutter chat app, we need to set up a Postgres function and trigger to copy usernames into the `profiles` table (see [this section](https://supabase.com/blog/flutter-tutorial-building-a-chat-app#step-5-create-register-page-with-email-password-and-username) in their tutorial if you want to learn more). To do this, run the following SQL in the Supabase **SQL Editor**.

```sql
-- Function to create a new row in profiles table upon signup
-- Also copies the username value from metadata
create or replace function handle_new_user() returns trigger as $$
    begin
        insert into public.profiles(id, username)
        values(new.id, new.raw_user_meta_data->>'username');

        return new;
    end;
$$ language plpgsql security definer;

-- Trigger to call `handle_new_user` when new user signs up
create trigger on_auth_user_created
    after insert on auth.users
    for each row
    execute function handle_new_user();
```

Back in VSCode, go to the **lib** folder and take a look at the code in the `main.dart` file:

```dart
Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await dotenv.load(fileName: '.env');

  await Supabase.initialize(
    url: dotenv.env['SUPABASE_URL']!,
    anonKey: dotenv.env['SUPABASE_ANON_KEY']!,
  );
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'My Chat App',
      theme: appTheme,
      home: const SplashPage(),
    );
  }
}
```

This code first loads that `.env` file that we just created and then initializes Supabase using the **project URL** and the **anon key** in that file. It then runs the app.

The app itself has four pages:

**1\. Splash page** `splash_page.dart`

The splash page checks if the user is currently logged in or not. If not, it takes the user to the register page, otherwise it takes the users straight to the chat page.

**2\. Register page** `register_page.dart`

The register page lets users sign up with email and password. It also allows users to skip this step if they already have an account, with a button which takes them to the login page.

**3\. Login page** `login_page.dart`

The login page lets users log in with their email and password.

**4\. Chat page** `chat_page.dart`

The chat page opens up a message stream from Supabase which binds to a `List` widget that streams messages. There's also a send button which calls a `_submitMessage()` function that inserts a row into the `messages` table with `profile_Id` and `content`.

## 3\. Run the app in its online-only form

In VSCode, click on `main.dart` and then select a target device (e.g. an Android emulator) in the bottom right to start debugging by clicking **Run > Start Debugging** from the main IDE window, or by pressing **F5**. See [Flutter docs](https://docs.flutter.dev/tools/vs-code#running-and-debugging) for more detailed instructions.

Run the app on a second device through the same process or from the command line:

```shell
//To run the app on a specific simulator device
flutter run -d "device name or id"
```

For easier testing, in your Supabase dashboard, go to **Authentication > Providers > Email > Toggle Confirm Email**. This will remove the need to verify test user email addresses.

![](https://powersync.com/images/blog/vue-tutorial-offline-first-todo-app-with-supabase-and-powersync-inline-3610c2e1a5.png)

Remember to hit save in the bottom right:

![](https://powersync.com/images/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync-inline-30d3be7bc5.png)

On each different device, create a unique user through the register page and log in with that user. Once logged in, each user should be at the chat page in a live chat with the other user.

At this point you'll be able to see certain limitations in the online-only app. For example, users cannot load the app or use it while offline. 

Let's change that by making the app offline-first.

## 4\. Set up PowerSync service

If you don't have a PowerSync account yet, don't worry, you can [get started for free](https://accounts.powersync.com/portal/powersync-signup).

Create a new instance of the PowerSync service and connect it to your Supabase project by following these steps:

  1. Log in to the [PowerSync Dashboard](https://accounts.powersync.com/).
  2. Create a new PowerSync instance and give it a name. The **Edit Instance** modal will then open (to open it any other time, right-click on the instance in the left sidebar).
  3. Go to the **DB Connections** tab. Now navigate to your [Supabase dashboard](https://supabase.com/dashboard/projects) to find your database URI. In the relevant Supabase project go to**Settings > Database  **and uncheck **"Use connection pooling"** both under the **Connection string** and**Connection parameters   **headings. Now copy the **URI** under the **Connection string** heading. Back in your PowerSync dashboard, paste that Supabase URI value in the **URI** field on the **Edit Instance** modal. This should autofill most fields in this tab. 
  4. Next paste your Supabase database password in the **Password** field and toggle **Allow querying data**. Click **Test connection** to validate everything works. 
  5. Now go to the **Client Auth** tab and and check the **Use Supabase Auth** checkbox. Click **Save**.

See [this chapter in the Supabase integration video](https://www.youtube.com/watch?v=80mnzGkeNgw&t=66s) for a visual walkthrough of the steps above.

You should now see the `public.messages` and `public.profiles` tables from Supabase listed under the PowerSync instance you created (other schemas and tables that PowerSync detects in your database will also be listed).

### Configure Sync Rules

> **Note**
>
> Sync Rules control which data gets synced to which users. They allow you to define how data should be partitioned into data buckets that get downloaded to user devices. If you want to learn more about sync rules, see [the documentation](https://docs.powersync.com/usage/sync-rules).

On the [PowerSync Dashboard](https://accounts.powersync.com/), open the `sync-rules.yaml` file in the left sidebar and delete all existing code.

For this tutorial, we'll simply sync all profiles and all messages to all users. To do that, paste the following into that file:

```yaml
# Sync rule definitions
bucket_definitions:
    global:
        data:
            - SELECT * FROM profiles
            - SELECT * FROM messages
```

Click **Validate** in the top right of that panel and select your instance as the source to validate against. You should see a response of _No issues detected,_ like this:

![](https://powersync.com/images/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync-inline-01537bfcd2.png)

Click **Deploy sync rules** and select the instance you created to deploy against, e.g.:

![](https://powersync.com/images/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync-inline-a20db82856.png)

Wait a few moments for the deployment to complete. Now that we have an instance of the PowerSync service set up, we need to wire it up to the app through the PowerSync SDK to get an offline-first architecture.

## 5\. Integrate PowerSync's Flutter SDK to make the app offline-first

### Install the SDK

Ensure you’re in the correct directory, then add the PowerSync SDK:

```javascript
flutter pub add powersync
```

Navigate to your project in VSCode. In the **lib** folder, create a new file called `powersync.dart` where we'll add some PowerSync-specific code.

Import the **PowerSync SDK** and **Supabase SDK** : 

You'll also want to import some packages to make managing paths easier, as well as the **dotenv** package:

```dart
import 'package:path/path.dart';
import 'package:path_provider/path_provider.dart';
import 'package:flutter_dotenv/flutter_dotenv.dart';
```

Under that, add a global handle to the PowerSync database, like this:

```dart
late final PowerSyncDatabase db;
```

### Instantiate the PowerSync in-app database

You need to instantiate the PowerSync database — this is the core managed database. Its primary functions are to record all changes in the local database, whether online or offline. In addition, it automatically uploads changes to your app backend when connected.

In the same `powersync.dart` file, we'll use the `openDatabase()` method ([docs](https://docs.powersync.com/usage/installation/client-side-setup/instantiate-powersync-database)) to instantiate the local SQLite database.

```dart
Future<void> openDatabase() async {
  db = PowerSyncDatabase(schema: schema, path: path);
  }
```

The constructor above requires a client-side **schema** and a **path** to the actual database file in the app. We'll create the client-side schema in the next section below. 

#### Configure the path value

For the **path** , it works well to abstract path logic. Do this with a `getDatabasePath()` method, which you can paste above the `openDatabase()` code:

```dart
Future<String> getDatabasePath() async {
  final dir = await getApplicationSupportDirectory();
  return join(dir.path, 'powersync-demo.db');
}
```

`getDatabasePath()` returns a string which appends the current application directory with the filename of the database, in the case of this example, that is "powersync-demo.db". It uses the uses the **path_provider** package.

```dart
Future<void> openDatabase() async {
  db = PowerSyncDatabase(schema: schema, path: await getDatabasePath());
  }
```

Now set the value of the **path** in the `openDatabase()` constructor to call the `getDatabasePath()` method like so:

#### Configure the schema

Now for the **schema**. Complete the steps in the [Implement client-side schema](https://powersync.com/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync#implement-client-side-schema) section below. Once you've done that, continue by importing the `schema.dart` file into the `powersync.dart` file like so:

```dart
import './models/schema.dart';
```

Your `openDatabase()` constructor is now ready to initialize the database, call `db.initialize()` to do that:

```dart
Future<void> openDatabase() async {
  db = PowerSyncDatabase(schema: schema, path: await getDatabasePath());
  await db.initialize();
  }
```

#### Integrate with Supabase client SDK

A few steps are required to make sure the PowerSync and Supabase SDKs work well together. The first thing to do is move the Supabase initialization code into the `openDatabase()` constructor. Navigate to the `main.dart` file, and find this:

```dart
  await dotenv.load(fileName: '.env');

  await Supabase.initialiize(
    url: dotenv.env['SUPABASE_URL']!,
    anonKey: dotenv.env['SUPABASE_ANON_KEY']!,
  );
```

Cut that code, go back to the `openDatabase()` constructor in the `powersync.dart` file, and paste it there so that it looks like this:

```dart
Future<void> openDatabase() async {
  db = PowerSyncDatabase(schema: schema, path: await getDatabasePath());
  await db.initialize();

  await dotenv.load(fileName: '.env');

  await Supabase.initialize(
    url: dotenv.env['SUPABASE_URL']!,
    anonKey: dotenv.env['SUPABASE_ANON_KEY']!,
  );
}
```

Now go back to the `main.dart` file and remove the **Supabase** and **dotenv** packages by deleting these two lines in the import section:

```dart
import 'package:flutter_dotenv/flutter_dotenv.dart';
import 'package:supabase_flutter/supabase_flutter.dart'
```

Import the `powersync.dart` file and add a call to `openDatabase()` in the `main()` function like so:

```dart
import 'package:powersync/powersync.dart';
import 'package:supabase_flutter/supabase_flutter.dart';
```

We're not quite done here, but the last few steps require some helper auth methods that we'll get to later in this tutorial.

### Connect the in-app database to Supabase and the PowerSync service

Back in the `powersync.dart` file, below the `openDatabase()` constructor, we'll create an instance of the `PowerSyncBackendConnector` ([docs](https://pub.dev/documentation/powersync/latest/powersync/PowerSyncBackendConnector-class.html)) which does two things:

```dart
import './powersync.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
 
  openDatabase();
  
  runApp(const MyApp());
}
```

  1. Uploads changes made on the local database to Supabase with the `uploadData()` method.
  2. Gets credentials to connect to the PowerSync service with the `fetchCredentials()` method.

After implementing these two methods, the SDK will take care of uploading local data changes to Supabase, and then connecting to the PowerSync service to download any data updates from Supabase as specified in your sync rules. It will automatically handle retrying if the network fails. 

Before getting to the methods, we need to specify that this connector takes `db` as a parameter, like so:

```dart
Future<void> class SupabaseConnector extends PowerSyncBackendConnector {
  PowerSyncDatabase db;
  SupabaseConnector(this.db);
}
```

#### The uploadData() method

> **Note**
>
> To better understand this section, complete the [Wire up in-app database calls to UI](https://powersync.com/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync#wire-up-in-app-database-calls-to-ui) section before continuing.

The `uploadData()` method gets called by the SDK whenever there's data to upload, whether the device is online or offline. If the call throws an error, it will be retried periodically until it succeeds.

In the `uploadData()` method we'll use the `getNextCrudTransaction()` method ([docs](https://pub.dev/documentation/powersync/latest/powersync/PowerSyncDatabase/getNextCrudTransaction.html)) to check whether there are any transactions to process. If there are, we'll upload them to the Supabase RESTful API, PostgREST.

We'll iterate through every operation in the `transaction.crud` object, which is a list of all client-side changes ([docs](https://pub.dev/documentation/powersync/latest/powersync/CrudTransaction/crud.html)). We'll have to map the operations to what Supabase will accept like so:

  * put –> upsert
  * patch –> update
  * delete –> delete

For every operation, we'll evaluate what type it is and then perform the relevant update. Once we've iterated through all operations, we can complete the transaction which means that all operations were successfully applied against Supabase.

We also need to monitor whether there are any errors returned from Postgrest. We're specifically interested in whether the response codes correspond to codes we know are fatal (i.e. we cannot recover from them by retrying). Instead of blocking the rest of the upload queue, we'll simply mark a specific transaction as completed (note that errors are typically the result of bugs in your code and in a production environment you'll want to save failing records somewhere else in order to prevent data loss and allow debugging).

Here is the code that will do all that:

```dart
Future<void>  @override
  Future<void> uploadData(PowerSyncDatabase database) async {
    final transaction = await database.getNextCrudTransaction();
    if (transaction == null) {
      return;
    }

    final rest = Supabase.instance.client.rest;

    try {
      for (var op in transaction.crud) {
        final table = rest.from(op.table);
        if (op.op == UpdateType.put) {
          var data = Map <String, dynamic>.of(op.opData!);
          data['id'] = op.id;
          await table.upsert(data);
        } else if (op.op == UpdateType.patch) {
          await table.update(op.opData!).eq('id', op.id);
        } else if (op.op == UpdateType.delete) {
          await table.delete().eq('id', op.id);
        }
      }

      await transaction.complete();
    } on PostgrestException catch (e) {
      if (e.code != null &&
          fatalResponseCodes.any((re) => re.hasMatch(e.code!))) {
        await transaction.complete();
      } else {
        rethrow;
      }
    }
  }
```

We also need to list the fatal response codes that we're referencing, do that by pasting the following code snippet below your import section:

```dart
/// Postgres Response codes that we cannot recover from by retrying.
final List<RegEx> fatalResponseCodes = [
  // Class 22 — Data Exception
  // Examples include data type mismatch.
  RegExp(r'^22...$'),
  // Class 23 — Integrity Constraint Violation.
  // Examples include NOT NULL, FOREIGN KEY and UNIQUE violations.
  RegExp(r'^23...$'),
  // INSUFFICIENT PRIVILEGE - typically a row-level security violation
  RegExp(r'^42501$'),
];
```

#### The fetchCredentials() method

Now for the `fetchCredentials()` method. Paste this below the `uploadData()` code snippet:

```dart
  @override
  Future<PowerSyncCredentials?> fetchCredentials() async {
  	return PowerSyncCredentials(endpoint: endpoint, token: token)
    }
  }
```

This `fetchCredentials()` method will return `PowerSyncCredentials` ([docs](https://pub.dev/documentation/powersync/latest/powersync/PowerSyncBackendConnector-class.html)). You'll need to pass two parameters: 

  1. the **endpoint** that the PowerSync service will connect to, and 
  2. a **token** to authenticate the user.

You can find the relevant endpoint on your [PowerSync Dashboard](https://accounts.powersync.com/) by right-clicking on  **[Instance Name] > Edit instance > Copy Instance URL**, e.g:

![](https://powersync.com/images/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync-inline-b69ed91b59.png)

Copy your **Instance URL** and set it as your **endpoint** value, pasting it in single quotes.

We'll use the Supabase `user access token` as the **token** parameter. We'll first do a null check on the session to see if the user is actually logged in and if they are, we'll extract the token, like so:

```dart
  @override
  Future<PowerSyncCredentials?> fetchCredentials() async {
    final session = Supabase.instance.client.auth.currentSession;

    if (session == null) {
      // not logged in
      return null;
    }

    final token = session.accessToken;

    return PowerSyncCredentials(
        endpoint: 'https://65130c9db6679a3682ba380a.powersync.journeyapps.com',
        token: token);
  }
```

### Implement client-side schema

The schema is the application-level view onto the underlying SQLite data. We'll define our client-side schema by going to **lib > models** and creating a new file called `schema.dart`. Import the `powersync` package, set `schema` as a constant but don't assign a value to it just yet:

```dart
import 'package:powersync/powersync.dart';

const schema = ;
```

Go to your PowerSync dashboard, right-click on the name of your instance in the left sidebar and select **Generate client-side schema**. Select **Dart** as the language.

![](https://powersync.com/images/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync-inline-31cec0800d.png)

> **Note**
>
> You'll notice that the generated schema does not include the `id` column for either table. This is because the `id` column is automatically available on the client and does not need to be defined in the schema file.

Copy the generated schema into your `schema.dart` file so that it looks like this:

```dart
import 'package:powersync/powersync.dart';

const schema = Schema([
  Table('messages', [
    Column.text('profile_id'),
    Column.text('content'),
    Column.text('created_at')
  ]),
  Table('profiles',[
    Column.text('username'), 
    Column.text('created_at')
  ])
]);
```

Now you can complete [the steps for instantiating your in-app database](https://powersync.com/blog/flutter-tutorial-building-an-offline-first-chat-app-with-supabase-and-powersync#instantiate-the-powersync-in-app-database).

### Implement auth methods

#### Check if a user is logged in

We'll connect the in-app database to the PowerSync service with the `db.connect()` method. However,  we only want to call this method if users are logged in. To check if users are logged in, we'll  implement a helper method called `isLoggedIn`. 

Do this above the `openDatabase()` constructor in the `powersync.dart` file, with this code that checks whether a user has an access token, and is therefore logged in:

```dart
bool isLoggedIn() {
  return Supabase.instance.client.auth.currentSession?.accessToken != null;
}
```

Now we'll add logic that relies on this helper method and calls `db.connect()` if a user is logged in:

```dart
if (isLoggedIn()) {
    db.connect(connector: connector);
  }
```

`db.connect` takes a **connector** as an input. We want that to be the `SupabaseConnector` but we'll define that outside of this logic because we'll re-use it later, like so:

```dart
 SupabaseConnector? currentConnector;

  if (isLoggedIn()) {
    currentConnector = SupabaseConnector(db);
    db.connect(connector: currentConnector);
  }
```

#### Listen for user auth state changes

Since a user's authentication state can change over the course of their use of the app (they can sign in or sign out, their JWT can expire, etc.), we want our `openDatabase()` constructor to be aware of that.

Add the following below the `if (isLoggedIn())` snippet:

```dart
Supabase.instance.client.auth.onAuthStateChange.listen((data) async {
    final AuthChangeEvent event = data.event;
    if (event == AuthChangeEvent.signedIn) {
      currentConnector = SupabaseConnector(db);
      db.connect(connector: currentConnector!);
    } else if (event == AuthChangeEvent.signedOut) {
      currentConnector = null;
      await db.disconnect();
    } else if (event == AuthChangeEvent.tokenRefreshed) {
      currentConnector?.prefetchCredentials();
    }
  });
```

This uses the `onAuthStageChange.listen()` to check a user's authentication state and disconnects the database if they are signed out or fetches new credentials if their token has been refreshed.

You've now completed implementation of the `openDatabase()` method 🎉

### Wire up in-app database calls to UI

#### Create data objects from in-app database

**In the messages model**

In `messages.dart`, import the global db object that we defined in the `powersync.dart` file as well some SQLite helpers from the **PowerSync** package, which we'll give the name `sqlite`:

```dart
import '../powersync.dart';
import 'package:powersync/sqlite3.dart' as sqlite;
```

Because we want to instantiate a message object from a database row, we'll need to add a factory constructor we'll name `Message.fromRow()` which will take a SQLite row and a user ID as parameters:

```dart
  factory Message.fromRow(sqlite.Row row, String myUserId) {
    return Message(
        id: row['id'],
        profileId: row['profile_id'],
        content: row['content'],
        createdAt: DateTime.parse(row['created_at']),
        isMine: myUserId == row['profile_id']);
  }
```

Now create a method we'll name `watchMessage()`. Here we'll use the `watch()` method ([docs](https://pub.dev/documentation/powersync/latest/sqlite_async/SqliteQueries/watch.html)) which executes a read query every time the source tables are modified. The `watchMessage()` method takes a User ID as a parameter and returns the `db.watch()` method which will execute a SQL statement to get the relevant messages for the user, ordered by their created date. We'll use the `fromRow` method to map results and cast them as a list with growable set to false:

```dart
  static Stream<List>Message>> watchMessages(String myUserId) {
    return db
        .watch('SELECT * FROM messages ORDER BY created_at DESC')
        .map((results) {
      return results
          .map((row) => Message.fromRow(row, myUserId))
          .toList(growable: false);
    });
  }
```

Lastly, create a static method that we'll name `create()` which takes `profileId` and `content` as parameters and uses the `execute()` method ([docs](https://pub.dev/documentation/powersync/latest/sqlite_async/SqliteQueries/execute.html)) to insert new messages into the messages table, like this:

```dart
  static Future<void> create(String profileId, String content) async {
    await db.execute(
        'INSERT INTO messages(id, created_at, profile_id, content) VALUES(uuid(), datetime(), ?, ?)',
        [profileId, content]);
  }
```

**In the profile model**

Go to `profile.dart` and import the global db object and SQLite helper package as above.

Now implement a similar factory constructor for the profile object. The main thing to remember here is that it must match the schema you defined:

```dart
  factory Profile.fromRow(sqlite.Row row) {
    return Profile(
        id: row['id'],
        username: row['username'],
        createdAt: DateTime.parse(row['created_at']));
  }
```

Create a method `findProfileByID()` that returns a Profile using the `get()` method ([docs](https://pub.dev/documentation/powersync/latest/sqlite_async/SqliteQueries/get.html)):

```javascript
  static Future<Profile> findProfileById(String id) async {
    final result = await db.get('SELECT * FROM profiles where id = ?', [id]);
    return Profile.fromRow(result);
  }
```

#### Wire up chat page to in-app database

**Stream messages**

In `chat_page.dart`, find the `_messageStream` snippet and replace the code from the Supabase demo with a call to the static method we defined above so that it looks like this:

```dart
  @override
  void initState() {
    final myUserId = supabase.auth.currentUser!.id;
    _messagesStream = Message.watchMessages(myUserId);
    super.initState();
  }
```

**Set profile**

Instead of extracting the profile from data, we can now set it directly. To do this, update the `_loadProfileCache` snippet to call the `findProfileById()` method, like this:

```dart
  Future<void> _loadProfileCache(String profileId) async {
    if (_profileCache[profileId] != null) {
      return;
    }
    final profile = await Profile.findProfileById(profileId);
    setState(() {
      _profileCache[profileId] = profile;
    });
  }
```

**Create message**

Find the `_submitMessage()` snippet and update it to use the static `create()` method that we defined above, like this:

```dart
  void _submitMessage() async {
    final text = _textController.text;
    final myUserId = supabase.auth.currentUser!.id;
    if (text.isEmpty) {
      return;
    }
    _textController.clear();
    await Message.create(myUserId, text);
  }
```

### Implement Logging

It's recommended to implement logging for your app but we won't go through the steps to implement that here. Refer to the complete example implementation below to see how.

### Complete Implementation Available

An example with everything above implemented (including logging) is available [here](https://github.com/powersync-ja/powersync.dart/tree/master/demos/supabase-simple-chat).

🎉🎉 That's it! You've completed the offline-first chat app tutorial 🎉🎉

---

# Supabase Integration Update — December 2023

> To celebrate Supabase Launch Week X, we’ve put together a summary of the latest functionality of our Supabase integration, including web app examples that work with Supabase.

- Published: 2023-12-12
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/supabase-integration-update-december-2023

---

We’ve seen many Supabase users implement PowerSync since we released our [integration to enable offline-first for Supabase apps](https://docs.powersync.com/integration-guides/supabase-+-powersync) on August 10th. To celebrate Supabase Launch Week X, we’ve put together a summary of the latest functionality of our Supabase integration.

We’ve focused on extending PowerSync’s functionality as well as providing guides and resources for Supabase users and we’ve already seen some impressive implementations. For a recap of our initial announcement, watch our [showcase event with Supabase’s Tyler Shukert](https://www.youtube.com/watch?v=O41BgDFRFMA).

Here are the main things we’ve added to our Supabase integration:

## JS Web SDK: Offline-first for web apps

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-a8935e3e09.png)

You can now add PowerSync to any web framework for instant offline-first web apps with Supabase as your backend. Our [JS Web SDK](https://docs.powersync.com/client-sdk-references/js-web) is [currently in beta](https://powersync.com/blog/announcing-web-support) and provides these features:

  * Direct access to the SQLite database — use SQL on the client and server.
  * Operations are asynchronous by default — does not block the UI.
  * No need for client-side database migrations — these are handled automatically.
  * Real-time streaming of changes.
  * Subscribe to queries for live updates.

## New implementation guides

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-812b4345fa.png)

We’ve created guides for frequent use cases: see all available guides [here](https://docs.powersync.com/usage/use-case-examples) or jump to a specific guide below:

  * [Full-text search](https://docs.powersync.com/usage/use-case-examples/full-text-search) (using SQLite FTS5)
  * [Syncing attachments / files](https://docs.powersync.com/usage/use-case-examples/attachments-files)
  * [Using custom types, arrays and JSON](https://docs.powersync.com/usage/use-case-examples/custom-types-arrays-and-json)

## Web app examples that work with Supabase

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-37451293d6.png)

We’ve released two example implementations of our Web SDK + Supabase so far:

  * [React To-Do List App](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-todolist)
  * [Angular To-Do List App](https://github.com/powersync-ja/powersync-js/tree/main/demos/angular-supabase-todolist) (installable as a PWA)

## Video tutorial: How to build an offline-first chat app [Flutter]

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-d62a74d7bd.png)

We’ve released a full step-by-step [video tutorial](https://youtu.be/EmtOfiELasY) on how to go from zero to offline-first using [Supabase’s Flutter chat app](https://supabase.com/blog/flutter-tutorial-building-a-chat-app) as a starting point. The finished chat app:

  * Integrates the PowerSync and Supabase client SDK
  * Syncs messages between users in real-time
  * Supports reading and creating messages, even when offline

 _A written tutorial is coming soon._

## React Native offline-first group chat app

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-7924d9ae33.png)

With help from **Benedikt M** , we’ve made a [fully functional group chat demo app available](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-native-supabase-group-chat). This offline-first group chat app is more advanced than our simple chat app example, with contacts, the ability to create new group chats, and even a typing indicator! [Watch our interview with Benedikt](https://youtu.be/Ygvdri7o6Fc?si=fD7xfu8ZgELvhRiW) about his experience using PowerSync for this and read his [blog post](https://bndkt.com/blog/2023/building-an-offline-first-chat-app-using-powersync-and-supabase).

## Flutter offline-first Trello clone

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-9bdce89807.png)

Kanban boards like Trello typically require some sync and offline functionality. For example, you would want to see in real-time if someone moves a card to a different list. Or create a new card immediately when you think about a new task, even if you might be offline. With help from **Herman L** , we’ve made a [fully functional offline-first Trello clone](https://github.com/powersync-ja/powersync-supabase-flutter-trello-demo) available. You’re free to clone the repo, make your own updates or simply scroll through the repo to see how it works.

## Rumors surrounding Launch Week X

![](https://powersync.com/images/blog/supabase-integration-update-december-2023-inline-da6b4af83d.png)

Supabase put some wild rumors to rest by providing (much needed) clarity on why there's no Launch Week 9. [Their tweet thread](https://x.com/supabase/status/1734147850085257282?s=20) exposing the [**REDACTED**].

That's it for now! Look out for new updates as we explore a deeper integration between PowerSync and Supabase, and [join our Discord server](https://discord.gg/powersync) if you have any questions.

---

# PowerSync Update: November 2023

> Our latest updates from November 2023, including the v1.0 stable release of PowerSync, the JS Web SDK release and updates to our docs.

- Published: 2023-12-01
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-november-2023

---

Last month we covered substantial ground to get PowerSync out of beta. That included implementing usage metric tracking, stability and scalability testing as well as releasing our Web SDK and updating existing Flutter and React Native SDKs. If you want a deeper look under the hood, our repos are now available under a single PowerSync GitHub org, [here](https://github.com/powersync-ja).

Here are some major things we shipped during November…

## **PowerSync v1.0 stable release**

![](https://powersync.com/images/blog/powersync-update-november-2023-inline-df33777814.png)

Excited to announce that as of yesterday, PowerSync is officially out of beta! A big thank you to all our beta testers and early adopters. Stay tuned for more insights on our journey, system capabilities, and future plans!

Thanks need to go to more than can be mentioned but **Tobie K** , **Bojan T** , **Benedikt M** , **Herman L** and **Francois vdM** all deserve special acknowledgement.

[Read the announcement post](https://cncnr04.na1.hubspotlinks.com/Ctc/ZT+113/cNCnR04/VXhkcx1514xfW6Msz8Q1mkJhNW5tZZwQ56xg7BN7zrx1j3qn9gW7Y8-PT6lZ3p5W1BxGls61v7ryVLzdzw4jN0F7W81pYjf35Ht_-W3Xcp_928NqClVMYqD08WL3SYW45llGR8b41FqW5CkxJP1YFcLDW2w_MGP8398zZW9bYshC11f0M3W4vYVF38YDrz0W47lJPH3TH37NW3j8n9b7NTsmFW79GyQJ2T_MNLW7VyT3l5DNNs1W6jDSdy149kqjW6G1Vlr18w9bKW3XlThH3dbf99W3RWBk56-Rd7fW8yPtK41zlHGkN59CF1qrSXWjW8pT5Ns4B4rNsVQ1FrN8KJlQdW3km6Pq3gRW5CMKXdzFhK_tbW1_Jz-B2vDGZ6W6hLJ1V8-5v_Kf92K5D604)

## **Web SDK release**

![](https://powersync.com/images/blog/powersync-update-november-2023-inline-8d3d8127db.png)

Our JavaScript web SDK is now in Beta. The vanilla JavaScript SDK can be wired up to any web development framework. React Hooks are available with similar ease of use enhancements planned for Angular, Vue, Svelte, and Solid.

Thanks to **David B** (aka Boozedog), **Bodok** , **Anders H** , **David A** , and **Francois vdM**.

[Read the web SDK docs](https://docs.powersync.com/client-sdk-references/js-web)

## **Usage metrics now available**

![](https://powersync.com/images/blog/powersync-update-november-2023-inline-ad472d4fe9.png)

The dashboard now has a metrics tab showing storage size, sync operations, peak concurrent connections and other usage data. Metrics are displayed per instance and support filtering by period and can be exported to CSV. Thanks to **Sebastian R** for some early feedback here.

[See your usage metrics](https://accounts.powersync.com)

## **More example implementations**

![](https://powersync.com/images/blog/powersync-update-november-2023-inline-c89055eb10.png)

We’ve released more example implementations including:

Backend implementations

  * Django (h/t **Savana Tech**)
  * Node.js (h/t **Alex M**)
  * Node.js with Firebase auth

Other

  * Attachment helpers for React Native

[See all examples](https://docs.powersync.com/resources/demo-apps-examples)

## **Docs updates**

![](https://powersync.com/images/blog/powersync-update-november-2023-inline-35100bacfd.png)

We’ve made multiple updates to our documentation, including:

  * A new page on our philosophy at PowerSync.
  * An explanation of the PowerSync protocol.
  * A reworked and more thorough explanation of how PowerSync guarantees causal+ consistency.
  * A page on performance and limits.

[Explore the docs](https://docs.powersync.com/powersync-philosophy)

## **Flutter SDK now v1.0**

![](https://powersync.com/images/blog/powersync-update-november-2023-inline-7cc59d912a.png)

Our Flutter SDK v1.0 stable has also been released. The v1.0 release includes updates that allow support for local-only tables, full-text search (FTS) and more. A full-text search reference example will be released soon.

[Pub.dev listing](https://pub.dev/packages/powersync)

---

# Introducing PowerSync v1.0: Postgres<>SQLite Sync Layer

> The goal of PowerSync is to give developers significant leverage in implementing an local-first (or offline-first) architecture, where app code works directly with a client-side embedded database which automatically syncs with a backend database in the background.

- Published: 2023-11-30
- Updated: 2025-11-17
- Author: Conrad Hofmeyr
- Category: Announcement
- Source: https://powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer

---

We are excited to announce the [v1.0 stable release](https://powersync.com/blog/powersync-v1-0-stable-release) of PowerSync, a Postgres–SQLite bi-directional sync layer. 

In this post, we’d like to give some background on the product as well as the philosophy underpinning its architecture and design.

## The goal: accelerating local-first app architecture

The goal of PowerSync is to give developers significant leverage in implementing an **local-first (or offline-first**[^1]**) architecture** , where app code works directly with a client-side embedded database which automatically syncs with a backend database in the background. 

[We believe](https://powersync.com/blog/offline-first-local-first-is-a-big-deal-especially-for-the-web) that local-first is poised to become the default architecture for the majority of apps: Local-first apps feel instant to use because of the near-zero latency of working with a local in-app database, are functional even if the user’s network connection is unreliable or unavailable, and provide built-in multi-user real-time collaboration. Local-first also has substantial benefits for developers: Simplifying state management (all state is in the local database), reducing the need for backend API development, and reducing backend dependency/load.

## What does PowerSync provide, and how is it used?

Here’s a quick rundown of how PowerSync works and the key features it provides:

  * The [PowerSync Service](https://docs.powersync.com/architecture/powersync-service) connects to standard open-source Postgres database (read-only) to perform _dynamic partial replication_ of data to users. This is controlled through [Sync Rules](https://docs.powersync.com/usage/sync-rules) which contain [SQL queries](https://docs.powersync.com/usage/sync-rules/organize-data-into-buckets) that can make use of dynamic parameters.
  * When Sync Rules are created, the PowerSync Service pre-processes and caches data and operation history from the Postgres database to efficiently and scalably sync to users. The PowerSync Service initially takes a snapshot of data defined in the sync rules, and then incrementally updates its cache whenever the data changes, using standard Postgres [logical replication](https://www.postgresql.org/docs/current/logical-replication.html).
  * On the client side, the developer includes a PowerSync SDK in the app project. SDKs are available for [Flutter](https://docs.powersync.com/client-sdk-references/flutter), [React Native](https://docs.powersync.com/client-sdk-references/react-native-and-expo) and [web (JavaScript)](https://docs.powersync.com/client-sdk-references/js-web) [^2] which [uses Wasm SQLite](https://powersync.com/blog/announcing-web-support) to run in browsers. The developer wires up the SDK to fetch a JWT from their application backend, which is then used for authentication between the PowerSync Service and the client SDK.
  * The client SDK keeps a local SQLite database in sync with Postgres in real-time, based on the Sync Rules configuration. The SDK allows for live queries from SQLite (which re-run whenever underlying data changes), allowing the developer to enable real-time reactivity in their app UI. It generally eliminates the need for a state management library.
  * Whenever the app performs writes to the local SQLite database, the write transactions are also placed in an upload queue [^3]. The developer defines a function used by the client SDK to upload the writes to their backend application, where custom business logic can be applied before committing the changes to the Postgres database. If the user is offline or network connectivity is unreliable, the client SDK will automatically retry uploading the changes in the queue.

With relatively low effort, the developer gets robust two-way syncing between Postgres and SQLite, and with it, the benefits of a local-first architecture.

## Why we built PowerSync: A need for a SQL-focused sync engine

The team behind PowerSync has been building and refining our sync technology since 2009. PowerSync [is a spin-off](https://powersync.com/company) from a full-stack app platform product where the same core sync technology has been in production for more than a decade, and is in daily use around the world by tens of thousands of enterprise users at Fortune 500 companies in industries such as energy, manufacturing and mining. The technology has been proven to provide high performance and reliability in real-world production use cases with large database volumes, in remote and disconnected environments, and there have been zero incidents of data loss since the original release.

Over the years, many folks have asked us to consider spinning off the PowerSync engine into a standalone product. In 2022, we started seriously considering this possibility, especially since there weren’t really any good sync systems available for SQL databases despite databases such as Postgres and SQLite being the most widely used in the world. There has been some innovation in the NoSQL space, the prime example being MongoDB Realm / Atlas Device Sync [^4]. 

We are big proponents of SQL database technology: Even though there has been significant convergence between the maturity of SQL and NoSQL databases over the last decade, SQL as a language remains more universal and well-known, and is very effective for advanced queries such as aggregations. As for embedded databases, SQLite is hard to beat when it comes to [performance](https://powersync.com/blog/sqlite-optimizations-for-ultra-high-performance), flexibility & advanced functionality (such as aggregations, joins, advanced indexing and JSON support), and how battle-tested it is (the SQLite team [estimates](https://www.sqlite.org/mostdeployed.html) that there are a trillion SQLite databases in active use). 

The more developers we spoke to, the more we realized that a big need exists for a SQL-focused sync engine for local-first apps. Many developers don’t want to switch to a new niche database in order to get access to syncing functionality. We decided to focus on Postgres first given its popularity.

### Design goals for PowerSync

With the SQL-focused need in mind, we identified some important design goals for the system:

  * It should be easy to adopt for either new or existing systems (greenfields and brownfields). Importantly, it should not be invasive to the developer’s stack, especially the database: it should not require substantial reconfiguration or additions to the Postgres database. The system should solve the hard problems of syncing data, and then stay out of the way of the developer.
  * Dynamic partial replication is a key capability, and it should be possible to adapt the sync controls at any time without complexity.
  * Don’t bypass the developer’s existing business logic, authorization and validation. Don’t write directly to their database — the database is sacrosanct.
  * Low maintenance. In particular, schema and data migrations should be as painless as possible.
  * A simple, robust and proven architecture, not over-engineered. It should be like a Toyota — a workhorse product that will be reliable for years with minimal intervention.
  * Provide strong consistency guarantees.

## Architectural decisions and engineering challenges

We relied on years of learnings and battle-testing in order to create the standalone PowerSync product. Let’s look into some of the important architectural decisions and engineering challenges:

### A scalable dynamic partial replication system

 _“Partial replication is a problem I haven't seen many people solving but it is definitely the next frontier in this space.”_ — [tantaman on HN](https://news.ycombinator.com/item?id=37500395)

Dynamic partial replication is a tricky problem to solve: Given a large backend database, we want to selectively sync different parts of it to different users’ local databases, keep them up to date incrementally, and keep everything consistent — in a performant and scalable way.

Let’s say you want to replicate completely arbitrary database queries to users. Consider the challenge of efficiently incrementally updating that replicated dataset. Let’s imagine a scenario where a user didn’t use our app for a week, and comes back online and does a sync. We run a query on a large table and the filtered results are a few hundred thousand rows. But we only need to sync the data in that result set that has changed since that user’s last sync, so the delta needs to be computed for that specific user for that specific time range. Now multiply this by thousands of concurrent users and it becomes clear how the efficiency is challenging.

Accordingly, we designed PowerSync to allow for partitioning data in a way where partitions can be shared between users where possible, and where we can track changes to partitions efficiently. PowerSync pre-processes data against queries in the [Sync Rules](https://docs.powersync.com/usage/sync-rules), and indexes the data by an ‘operation ID’, resulting in an ordered list of operations which we can efficiently query to get a specific series of changes in a specific time range, for any user. We also compact this operation history automatically so that it doesn’t grow indefinitely.

PowerSync does all of this outside of the Postgres database (in the [PowerSync Service](https://docs.powersync.com/architecture/powersync-service)) so that we don’t pollute Postgres. This architecture scales well, and is straightforward to use: Define sync rules and a client-side schema, and the data is automatically kept in sync. It’s also adaptable: If you change the sync rules, the entire new set of data is applied on the client as an [atomic](https://en.wikipedia.org/wiki/Atomicity_\(database_systems\)) operation. 

### Server authority instead of distributed/CRDT architecture

One of the (perhaps surprising) key decisions about the PowerSync architecture was not to use CRDTs to merge changes. 

A quick primer just in case: CRDTs are data structures where all operations are [commutative](https://en.wikipedia.org/wiki/Commutative_property), meaning they can be applied in any order on different replicas of the data, and each replica converges to the same state. This is useful for syncing data peer-to-peer, but the downside is that CRDTs come with significant overhead and more complexity. [^5]

Broadly speaking, an alternative to CRDTs is to keep a global ordered list of operations/events [^6]. By applying operations in the same order on each replica, they converge to the same state. Importantly, having an authoritative server in a system architecture means that a global ordering of operations can be enforced, typically without adding much complexity to the system.

While decentralized systems are an interesting area of innovation, we recognized that the vast majority of apps built around Postgres have some kind of centralized server architecture. Therefore, we decided to embrace this and design our system around the concept of server authority and a global order of operations. This has the advantage of keeping the architecture simple and robust, and offers developers the ability to control and customize how data gets written into their Postgres database. PowerSync makes use of an event sourcing pattern, whereby events/operations are sourced from Postgres via the logical replication stream.

With PowerSync, writes are sent through the developers’ own application backend, allowing them to apply their own business logic, fine-grained authorization, validations and server-side integrations. They can resolve conflicts using the techniques/algorithms of their choosing, trigger server-side workflows, and reject changes from clients if needed (and since the backend is authoritative, the new state will correctly and consistently replicate to clients).

While PowerSync does not use CRDTs for its internal protocol, it _can_ leverage another important strength of CRDTs: very fine-grained collaboration like document/text editing. CRDTs can actually be implemented _on top of_ PowerSync + Postgres for collaborative document editing: For example, using [Yjs](https://github.com/yjs/yjs) and storing its CRDT data structure in Postgres using blobs, and keeping it in sync between clients in real-time. See an [example here](https://github.com/powersync-ja/powersync-web-sdk/tree/main/demos/powersync-supabase-yjs-text-collab-demo).

### Consistency & integrity

We designed PowerSync to have [causal+ consistency](https://docs.powersync.com/architecture/consistency). We used the concept of "checkpoints'' for consistency. A checkpoint is a single point-in-time on the server with a consistent state — only fully committed transactions are part of the state. The client only updates its local state when it has all the data matching a checkpoint, and then it updates the state to exactly match that of the checkpoint. This works in line with the server authority mentioned above: The server can decide how to merge changes, and the server state will propagate to all clients.

Changes to the local SQLite database are applied on top of the last checkpoint received from the server, as well as being persisted into an upload queue. While changes are present in the upload queue, the client does not advance to a new checkpoint from the server. This means the client never has to resolve conflicts locally. Only once all the local changes have been acknowledged by the server, and the data for that new checkpoint is downloaded by the client, does the client advance to the next checkpoint. This ensures that operations are always ordered correctly on the client.

### Client-side schema architecture

We decided to create a degree of flexibility between the Postgres schema and the client-side SQLite schema. The Sync Rules configuration in PowerSync can optionally perform transformations on the Postgres data/schema, and the client-side SQLite schema can diverge from the Postgres schema if the developer prefers.

Another key decision was that the PowerSync protocol syncs “schemaless” data, and then applies the client-side schema on top of the schemaless data using SQLite views. One of the advantages of this approach is that there’s no need for client-side database migrations — these are handled automatically in almost all cases. The Sync Rules configuration can also be changed on-the-fly and the client-side database is automatically maintained accordingly. We have also put [processes in place](https://docs.powersync.com/usage/lifecycle-maintenance/implementing-schema-changes) for handling Postgres schema changes while still supporting older client versions.

## From beta to v1.0 stable

We launched a beta version in mid-2023, and have just reached our v1.0 stable release milestone. We are grateful for all the feedback we received from developers during the beta program. This has helped us to prioritize our roadmap. For example, a key short-term priority is to release a self-hostable version of the PowerSync Service. 

## Open-source / source-availability

Making our source-code open is also a cornerstone of our philosophy. Our client SDKs are open-source (Apache 2.0 license) and a source-available edition of the PowerSync Service will be released in 2024.  Update May 31, 2024: [our Open Edition has been released](https://powersync.com/blog/powersync-open-edition-release) (a free, source-available, self-hosted version of PowerSync).

## The future of PowerSync

A major focus is making PowerSync more stack-agnostic: We will add more SDKs (e.g. Kotlin, Swift, Electron, Capacitor, and more [^2]) as well as support for more backend databases (Initially MySQL and Microsoft SQL Server, however, this could extend to NoSQL databases in the future). 

There are a ton of interesting innovations going on in the database world and [around SQL in particular](https://powersync.com/blog/sqlite-persistence-on-the-web). This dynamic environment is unveiling a wealth of innovative applications for PowerSync, guiding the evolution of our feature set. Stay tuned.

[^1]: We see “local-first” as the logical successor to “offline-first” app architecture. Local-first builds on the idea of offline-first with additional ideals. The industrial research lab Ink & Switch [defined local-first](https://www.inkandswitch.com/local-first/) in 2019 as a software application architecture where the cloud/server is merely a peer and not on the critical path to supporting client applications. Their vision is that local-first client applications should have “ultimate ownership and control” over their own data. Not all software that is described as local-first today adhere to all of the ideals espoused by Ink & Switch, but many developers aspire to get closer and closer to those ideals over time, instead of merely providing equivalent capabilities to what would be considered “offline-first”.
[^2]: Update: Following the original publication of this blog post, client SDKs for Kotlin Multiplatform, Swift, Node.js and .NET have also been released.
[^3]: With PowerSync, you can do local transactions in SQLite and then place the whole transaction into the upload queue as a batch, which your backend can then either reject or accept.
[^4]: Interestingly, Realm Sync was [working on](https://docs.realm.io/sync/backend-integration/postgres-connector) a Postgres connector before Realm was acquired by MongoDB and distribution of the Postgres connector was paused.
[^5]: Figma’s CTO Evan Wallace [summarized this eloquently](https://www.figma.com/blog/how-figmas-multiplayer-technology-works/): _“Figma isn't using true CRDTs […]. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation.”_
[^6]: Some systems don’t keep track of operation history at all. If you don’t store history, you sacrifice some transactional guarantees — you can’t accept or reject individual transactions.

---

# PowerSync V1.0 Stable Release

> We are happy to announce that as of November 30, 2023, PowerSync is officially out of beta, and production use cases are now fully supported.

- Published: 2023-11-30
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-v1-0-stable-release

---

We are happy to announce that as of November 30, 2023, PowerSync is officially out of beta. Production use cases are fully supported. Huge thanks to all of our beta testers and early adopters for helping us get to this point. 

In this blog post we’ll provide some insight into what this journey meant for us, detail exactly which parts of the system are out of beta, touch on what the performance limits of the system currently are, and provide a peek into our longer term roadmap.

## Why has PowerSync been in beta?

Our guiding principle for keeping PowerSync in beta has been:

> “Can we take a customer to production without running into any issues?”

For any builders out there, this is harder than it sounds. Recently, though, we’ve been seeing a number of successful deployments of PowerSync with zero issues, which has made us super happy of course! 

Apart from this guiding principle, there were some specific projects we cared about that we wanted to ship in order to take PowerSync out of beta. These are detailed in the next section.

## Critical path out of beta

Our internal priorities for getting out of beta were: 

  1. releasing a web SDK,
  2. implementing usage metrics and 
  3. ensure the system scales and is stable 

### Web SDK

There is a [rising interest in local-first architectures for web apps](https://powersync.com/blog/offline-first-local-first-is-a-big-deal-especially-for-the-web), and we felt that PowerSync wasn’t a “whole product” without support for web. 

We are really excited about the architecture of [our Web SDK](https://powersync.com/blog/announcing-web-support): we extended wa-sqlite in order to compile it with our Rust-based common SDK core that is used across all platforms. We then implemented a common JS SDK package that uses this modified wa-sqlite to open the database.

We currently have demo apps built using React and Angular, with more framework examples on their way. We also dogfooded our web SDK to build our [web demo widget](https://powersync.com/demo) using Webflow Devlink.

### Usage metrics

Budgeting for SaaS products is notoriously difficult. Just take a look at our [pricing example](https://docs.powersync.com/resources/pricing-example). We realize that for some cases, a more empirical approach to budgeting would be preferred: run some tests, view the actual system usage metrics, and compare those to [our plan limits](https://powersync.com/pricing). 

This was important to us because budgeting is a key component of deciding whether to use a product with a free tier and a paid tier, and we wanted to provide developers with additional options on that front.

A nice side effect of this is that it’s also trivial for users to monitor their app’s adoption without installing invasive analytics packages — “Peak Concurrent Connections” provides some insight into the number of users using your app. 

![A screenshot showing usage monitoring dashboards on the PowerSync system](https://powersync.com/images/blog/powersync-v1-0-stable-release-inline-483b0e1c01.png)

### Scalability and stability

Keep it stable, make it scale, zero data loss. This was conceptually pretty simple, but we spent a lot of time caring about the details here to ensure solid performance in production at scale.

## Product version matrix

Not everything in our stack is out of beta just yet. See below for details as of time of writing.

| Subsystem | Version |
| --- | --- |
| [PowerSync Service](https://docs.powersync.com/architecture/powersync-service) | V1.0 |
| [Dashboard](https://accounts.powersync.com/) | V1.0 |
| [Flutter SDK](https://docs.powersync.com/client-sdk-references/flutter) | V1.0 |
| [React Native SDK](https://docs.powersync.com/client-sdk-references/react-native-and-expo) | V1.0 |
| [JS Web SDK](https://docs.powersync.com/client-sdk-references/js-web) | Beta |
  
## Current performance limits

See [Performance and Limits](https://docs.powersync.com/resources/performance-and-limits) in our docs for details.

## Customer support plans

 _Updated 9/19/2024_

Our goal with customer support is to provide customers with the best support experience that they’ve ever received.

More concretely, our various plans offer the following support:

  * **Free plan** \- community support via our [Discord](https://discord.gg/powersync) server
  * **Pro plan** \- community support + email support (tickets with reference numbers, secure channel, CC your team members on support tickets, easily attach files, etc)
  * **Team plan** \- community support + priority email support, [backed by an SLA](https://powersync.com/legal/commercial-license-and-services-agreement#support-response-time)**.** Includes access to security certifications like SOC2.
  * **Enterprise plan** \- same as Team plan + assigned Forward-Deployed Engineer, help with architecture approval diagrams, security questionnaires, etc.

## Roadmap

 _Updated 9/19/2024_

Some highlights for our medium-term roadmap:

  * Automated billing via Stripe, with plans for budgeting features – _shipped_
  * Tools and resources to streamline authentication setup – _shipped_
  * Self-hosting of the PowerSync Service - _shipped_
  * Additional SDKs (Flutter Web, Kotlin, Swift) - _shipped_
  * Additional backend databases (MySQL) - _in progress_
  * A CLI interface for managing your instances - _shipped_
  * Incremental sync-rule reprocessing to speed up sync rule deploys - _in progress_

You can see our full roadmap [here](https://roadmap.powersync.com/tabs/5-roadmap). We take new ideas and votes very seriously — so please go ahead and interact with it.

---

# Local-First Software Is A Big Deal, Especially For The Web

> Local-first architecture will increasingly be a game-changer for both developers and end-users and by making this architecture easier to implement for web apps, its total potential impact is expanded enormously.

- Published: 2023-11-22
- Author: Conrad Hofmeyr
- Category: Engineering
- Source: https://powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web

---

**Developers are**[**increasingly getting excited**](https://twitter.com/zxch3n/status/1722192660176490515)**about local-first as the app architecture of the future.**[^1] [^2]** **

In the local-first paradigm, app code works directly with a client-side embedded database, which optionally automatically syncs with a backend database in the background. This is in contrast to cloud-first apps which primarily use a cloud datastore via APIs.

Working with a local database (e.g. SQLite) means that apps feel instant to use because of low latency, and are functional even if the user’s network connection is unreliable or offline. In addition, local-first typically offers built-in multi-user real-time collaboration by automatically syncing data in the background bi-directionally.

## The application architecture of the future

While some apps will always necessarily have to rely only on synchronous network communication with a server (e.g. banking/payments, video streaming, etc.), it is likely that local-first will **become the default architecture for the majority of apps in the future** , because of its substantial benefits for developers (simplifying distributed state management) and end-users (a delightful user experience).

Local-first has gradually been gaining popularity for mobile apps, but with [SQLite in the browser using Wasm](https://powersync.com/blog/sqlite-persistence-on-the-web) becoming more robust (combined with using service workers to pre-cache assets/resources so that web apps can load offline), it’s something that will**increasingly revolutionize web apps** too. Once local-first architecture becomes mainstream on the web, the impact of this architectural shift will be much bigger. 

## From differentiator to table stakes

Apps like [Figma](https://www.figma.com/blog/how-figmas-multiplayer-technology-works/), [Linear](https://linear.app/blog/scaling-the-linear-sync-engine) and [Superhuman](https://blog.superhuman.com/superhuman-is-built-for-speed/) are widely admired for their stellar user experience powered by a local-first or similar architecture under the hood. Importantly, they’ve used it as a differentiator to disrupt their respective markets and wrest customers from incumbent competitors.

As local-first gains more momentum, the features/benefits that it provides to users (instant responsiveness, network resilience, offline use and real-time collaboration) could easily become “table stakes” rather than differentiators.

## Here be dragons?

Many developers may instinctively shy away from local-first (and previously offline-first [^1]) and stick to cloud-first apps, because it’s pretty complex and painful to build a robust active-active sync engine (challenges are numerous and include dynamic partial replication, conflict resolution, consistency guarantees, and more. Add in the need to support web apps and the complexity escalates further). 

That is not to say that cloud-first apps are without complexity traps either: In an API-powered app front-end, caching and application state management can quickly get hairy too.

Fortunately, drop-in sync engines like [PowerSync](https://powersync.com/) are now starting to make local-first architecture even simpler to build than cloud-first apps. We’re excited to be part of this movement and our aim is to help accelerate the adoption of this architecture, especially since [announcing support for web](https://powersync.com/blog/announcing-web-support).

## Deeper dive: Why local-first matters

### Lower backend compute load, dependency and cost

  * In a typical cloud-first app, clients are constantly hitting the backend with API requests to read or write data. The backend becomes a performance bottleneck. 
  * Local-first apps move the vast majority of read operations to the client-side, using the local embedded database. Because all the relevant data is right there in the local database, many computations can also be done locally. This reduces backend complexity, load and scale-out needs — thereby reducing cloud computing costs. [^3] In addition, because these apps are not reliant on the network and backend at all times, backend uptime and performance is much less of a factor in app performance.

### Simplified backend development: Reduced API burden

  * In a typical cloud-first app, every added feature results in a need for new or expanded backend APIs. Developers often have to invest significant effort in implementing and maintaining API functions.
  * An offline-first architecture drastically reduces the API development burden: By replicating the backend database to the client-side proactively, we already have all the data we need right there in the client without having to consult a backend API. Quoting [Tuomas Artman of Linear](https://www.youtube.com/watch?v=WxK11RsLqp4&t=2175s):_“We don’t have to make REST calls, we don’t have to make GraphQL calls. We modify the data, we save it, and everything always updates.”_[Dynamic partial replication](https://docs.powersync.com/usage/sync-rules) is a key piece of functionality here, since we only want to replicate the part of the backend database that is relevant to the specific user. 

### Simplified state management, simplified app codebase

  * Many developers have learned the hard way that distributed state management can be very complex and painful. As mentioned above, this is no less true for cloud-first apps, where developers typically respond to app performance issues by implementing some variation of caching and optimistic updates. This can very quickly lead to spiralling complexity around cache invalidation and inconsistent states.
  * In local-first apps, the global state is simply stored in the local database. This substantially simplifies application code since queries can be done synchronously and the developer does not have to handle loading states or network failure states. On the web, the benefits go even further: State can be shared across multiple browser tabs on the same user’s device, all accessing the same local database. By utilizing an active-active replication sync engine working in the background, the developer also doesn’t have to think about _state transfer._ 

At Meta, once the [Project Lightspeed team](https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/) migrated their Messenger app to a SQLite-centric architecture, the benefits were clear: _“We leveraged the SQLite database as a universal system to support all the features. [...] The UI merely reflects the tables in the database.”_

[Ink & Switch](https://www.inkandswitch.com/local-first/) says about the benefits of local-first: _“[It] allows app developers to focus on their application rather than the challenges of data distribution”_. This is [echoed by Tuomas Artman of Linear](https://www.youtube.com/watch?v=WxK11RsLqp4&t=2175s): _“Once we’ve put in the effort on putting the synchronization engine in, our task of developing this application became a lot easier and a lot faster.”_

### To the user, everything feels instant. No loading spinners.

  * In a cloud-first app that relies on APIs (REST, GraphQL), most data operations require a round-trip to a server. This always results in some latency — typically requiring the user to stare at a loading spinner.
  * By contrast, a local-first app that uses a local embedded database in the application front-end (with a sync engine working in the background) dramatically cuts down on the latency of reading and writing data, which means that the app is much faster for users — the UI can react near-instantaneously to user input. [^4]

### Offline use / network resilience / high availability

  * In a cloud-first app, the user is at the mercy of the network — even a momentary loss of mobile network coverage can result in the app failing to load or save data.
  * In a local-first app, the network is no longer on the critical path for user interactions —  meaning that the app is resilient to any interruptions in network service quality, or even complete downtime of the network connection or backend. Users can use the app while offline for brief periods of time (e.g. passing through a tunnel) or for extended periods of time (in the subway, in the mountains, in the basement of a building, etc). [^5] With conflict resolution and consistency guarantees, the intricacies of combining offline usage with multi-user collaboration can also be managed.

### Real-time collaboration and reactivity

  * With a typical cloud-first app architecture, the developer has to invest significant effort into building real-time streaming functionality in order to enable collaboration between different users. This may require building or otherwise bringing in a whole new system.
  * On the other hand, sync engines such as PowerSync used for local-first apps come built-in with key components that naturally enable real-time multi-user collaboration, since they are fundamentally designed to monitor for data updates and keep users in sync. [^6]

## Designing for local-first

A local-first architecture will result in **much of your app functionality living on the client-side** rather than on the backend. [^7] Much of your business logic, querying, filtering and computation will happen client-side. 

That being said, for security reasons you still want to enforce certain business logic, authorization and validation on the backend. In this sense, [PowerSync’s architecture](https://docs.powersync.com/overview/readme-1) is beneficial because it sends writes through your backend, putting you as the developer in control of the write process. This protects your backend database as the source of truth / system of record. And because PowerSync uses server reconciliation for consistency, your backend has the ability to reject writes based on your business logic / authorization / validation, and this will be kept consistent across clients.

## What about Firebase offline support?

A common misconception is that Google Firebase’s Cloud Firestore provides a local-first or offline-first architecture. It’s more accurate to describe Cloud Firestore as a **cloud-first system** : By default, queries run against the cloud (online) datastore and the results of those specific queries are cached on the local device (and may be removed from the cache later). Cloud Firestore does not preemptively sync a database to the local user device for offline-by-default access. 

In addition, by default Cloud Firestore will try to reach the server first before falling back to the local cache, which can result in frustration and significant latency for the user if their network connection is patchy.

## Ushering in the local-first future 

Hopefully it’s clear from the above that local-first architecture will increasingly be a game-changer for both developers and end-users. And by making this architecture easier to implement for web apps, the total potential impact on the software world is expanded enormously.

## Questions? Comments? Join us on Discord

If you have any thoughts to share or questions, please [join us on our Discord server](https://discord.gg/powersync).

[^1]: We see “local-first” as __ the logical successor to “offline-first” app architecture. Local-first builds on the idea of offline-first with additional ideals. The industrial research lab [Ink & Switch defined local-first](https://www.inkandswitch.com/local-first/) in 2019 as a software application architecture where the cloud/server is merely a peer and not on the critical path to supporting client applications. Their vision is that local-first applications should have “ultimate ownership and control” over their own data. Not all software that is described as local-first today adhere to all of the ideals espoused by Ink & Switch, but many developers aspire to get closer and closer to those ideals over time, instead of merely providing equivalent capabilities to what would be considered “offline-first”.
[^2]: Often when this topic comes up, there are folks who comment “what was old is new again” or “we’ve come full circle”. Indeed, there was a time when most software applications were [thick clients](https://en.wikipedia.org/wiki/Rich_client) running locally, utilizing a local datastore and allowing you to work offline. The rise of the web has meant that we’ve sacrificed that instant reactivity and offline use for the benefits of the cloud (collaboration, accessible from anywhere in the world, always up-to-date). The good news is that we now can have the best of both worlds: The benefits of the web/cloud while working local-first, even in web apps.
[^3]: In the case of PowerSync, the backend compute is further reduced by the [PowerSync service](https://docs.powersync.co/architecture/powersync-service), which handles read operations related to syncing. The PowerSync service pre-processes and indexes data to be synced for different users — enabling high-performance _dynamic partial replication_.
[^4]: Typically, the only instance where a local-first app may be slower than its online counterpart is on first start-up, since the app may need to perform an initial sync to download data into the local database. As the bandwidth of internet connections improves over time, this will become less and less of a factor. Once the initial sync is done, data updates can be synced incrementally in the background and subsequent startup time is typically instantaneous. This is a net benefit to users since they will typically save far more time while using the app than they spent waiting for the initial sync to complete.
[^5]: This is valuable given how users’ goalposts have shifted in recent years: Now that a significant share of the population have smartphones filled with useful apps, they expect to do a wide and rich range of things on their smartphones, no matter where they are, 24/7. They don’t want to be left hanging due to a lapse in network connectivity. As Ink & Switch [put it](https://www.inkandswitch.com/local-first/), _“while other applications […] threw up errors (‘offline! warning!’) and blocked the user from working, local-first [applications] function normally regardless of network status. [...] There is never any anxiety about whether the application will work or the data will be there when the user needs it.”_
[^6]: In the case of PowerSync, the sync engine hooks into a change log on the backend database, and streams data to keep the local client-side database in sync in real-time. In addition, data flows from the client to server in real-time whenever connectivity is available: Writes to the local client-side database are also placed in an upload queue which are immediately written to the backend database (unless connectivity is unavailable or interrupted, in which case it is retried later). Lastly, the client-side allows for “live queries'' which can immediately update the UI whenever data in the local database changes (whether from syncing remote changes, or from any local changes anywhere in your code).
[^7]: It is easier to implement a local-first architecture using a sync engine during the upfront development phase, than retrofitting it into a “brownfield” application. Putting logic on the client-side and working with the syncing data flow might not easily fit into your original architecture. It can certainly still be done, but requires a bit more work.

---

# Announcing PowerSync Web Support

> With our web SDK, we enable web developers to add instant offline-first capability to their apps without a heavy engineering lift or requiring invasive changes to their existing Postgres backends.

- Published: 2023-11-17
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/announcing-web-support

---

## Web SDK

Today we’re announcing the alpha release of our **JavaScript client SDK** [^1].

With this release we enable web developers to add instant offline-first capability to their apps without a heavy engineering lift or requiring invasive changes to their existing Postgres backends.

As a vanilla JS Web SDK, it can be used within a variety of frameworks including React, NextJS, Vue.js, Angular and others.

The SDK is built on top of our abstracted common TS/JS implementation of a PowerSyncDatabase client. The client is extended with locks, network request handlers and a SQLite database handler. The SDK is bundled with embedded SQLite pre-loaded with our Rust-based SQLite extension — all running in the browser using **Wasm**.

### React hooks

React hooks [^2] can be used to automatically re-render React components when query results update.  

### PWAs

Our Web SDK can be used in conjunction with PWA technologies to cache pages and bring a truly offline-first experience to your web apps.

## Demo App

We have released a React demo app which demonstrates real-time streaming of Postgres data and offline CRUD operation queuing & syncing [^3]. The demo app also showcases our integration with Supabase.

We’re available on our [Discord](https://discord.gg/powersync) if you need any help or have any questions.

[^1]: https://www.npmjs.com/package/@powersync/web
[^2]: available in a separate package: https://www.npmjs.com/package/@powersync/react
[^3]: https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-todolist

---

# PowerSync Update: October 2023

> Our latest updates from October 2023. We’ve taken big strides since our Beta release August. Highlights include React Native support, Dashboard enhancements and more

- Published: 2023-11-03
- Author: Kobie Botha
- Category: Product Update
- Source: https://powersync.com/blog/powersync-update-october-2023

---

We’ve taken big strides since our Beta release on August 10th. We’ve answered the [call from Supabase developers](https://github.com/orgs/supabase/discussions/357) to enable offline-first for [Flutter](https://pub.dev/packages/powersync) and [React Native](https://www.npmjs.com/package/@powersync/react-native) apps. We’ve since [open-sourced](https://www.powersync.co/open-source) both of those SDKs. Here are some things we shipped during October…

### **React Native SDK in Beta**

![](https://powersync.com/images/blog/powersync-update-october-2023-inline-b8fe115bbd.png)

After our alpha release earlier this month, we’ve made it to beta with our React Native client SDK. Works well with Expo.

[React Native docs](https://docs.powersync.co/client-sdk-references/react-native-and-expo)

### **Use Firebase or Auth0 as authentication providers**

![](https://powersync.com/images/blog/powersync-update-october-2023-inline-7958401ea9.png)

In addition to Supabase Auth, Firebase and Auth0 are now supported as authentication providers. Custom auth is also supported. Thanks to **Andy G** for getting us on this.

[Authentication setup docs](https://docs.powersync.co/usage/installation/authentication-setup)

### **Multiple PowerSync Dashboard enhancements**

![](https://powersync.com/images/blog/powersync-update-october-2023-inline-7a16309c31.png)

The Dashboard is under constant improvement, here is what’s new:

  * Auto-generating client-side schema from sync rules [h/t **Jon H**]
  * Support for detecting schema changes and automatically re-replicating tables [h/t **Emil Z** , **Benedikt M**]
  * Improved inline validation for sync rules
  * Sync rule validation now rejects SQL syntax PowerSync does not support [h/t **Alex M**]
  * The Dashboard now lists tables from all schemas, not only public schemas [h/t **Andy G**]

[Try them out](https://accounts.powersync.com/users/sign_in)

### **Join the community**

![](https://powersync.com/images/blog/powersync-update-october-2023-inline-c2e7462dc7.png)

Join the PowerSync Discord server to keep updated on the latest releases and discuss topics related to sync.

[Join Discord](https://discord.gg/powersync)

### **PowerChat (React Native) and Trello clone (Flutter) now available**

![](https://powersync.com/images/blog/powersync-update-october-2023-inline-d02dd39d6a.png)

Thanks to **Benedikt Müller** who released [PowerChat](https://github.com/journeyapps/powersync-supabase-react-native-group-chat-demo) — a group chat app built with React Native. Thanks to **Herman Lintvelt** who released a [Trello clone app](https://github.com/journeyapps/powersync-supabase-flutter-trello-demo) built with Flutter.

[See all example apps](https://docs.powersync.co/resources/examples-demo-apps)

### **Made with PowerSync**

![](https://powersync.com/images/blog/powersync-update-october-2023-inline-43c5ddf12d.png)

[Read about our interview](https://www.powersync.co/blog/insights-from-production-use-trashblitz) with **Praful M** on how he used PowerSync to make [TrashBlitz](https://apps.apple.com/us/app/trashblitz/id6447145347) offline-first. TrashBlitz was built with [FlutterFlow](https://flutterflow.io/) and is used in production to track trash collection efforts happening around the world.

[Watch the interview](https://youtu.be/dZY4JOV7ArA)

---

# Showcase: PowerSync For Supabase And Flutter

> We were recently joined by Tyler Shukert from Supabase and PowerSync community member Herman Lintvelt to see examples of using PowerSync as a data layer for Flutter development with Supabase.

- Published: 2023-10-16
- Author: Phillip van der Merwe
- Category: Showcase
- Source: https://powersync.com/blog/showcase-powersync-for-supabase-and-flutter

---

On the call, Tyler shared his experience using PowerSync with Supabase, Kobie from PowerSync demonstrated how to build an offline-first chat app and Herman showcased an offline-first Trello clone app that he built using Flutter and PowerSync.

Full video of the call available here:

## Using PowerSync with Supabase

Tyler (Flutter DevRel at Supabase) maintains the Supabase Flutter/Dart SDK. Supabase is an open-source Firebase alternative, but does not currently have turnkey offline caching capabilities. Offline support is actually the [top requested feature](https://github.com/orgs/supabase/discussions/357) on their GitHub discussion page, but this is a hard problem to solve.

They have previously recommended third-party integrations for offline capabilities, but these were mostly focused on JavaScript projects and were not ideal for Flutter. PowerSync has the potential to provide a reliable offline experience for Flutter developers using Supabase:

> Personally I am super excited that with PowerSync, we [Supabase] will be able to fully, truly, provide the offline experience for our Flutter developers. – Tyler Shukert

## Setting up a Flutter App with Supabase and PowerSync

Kobie from the PowerSync team demonstrated how it would be possible to use PowerSync to enable offline mode for a chat app built using Flutter with Supabase. 

His starting point was Supabase’s simple [chat app tutorial](https://supabase.com/blog/flutter-tutorial-building-a-chat-app), which has a straightforward schema consisting of two tables. The app isn’t designed to support offline but that’s easy enough to add with PowerSync.

Implementing PowerSync consists of two steps: 

**1\. Implement a PowerSync service instance**

  1. Connect to Supabase
  2. Define and deploy sync rules

**2\. Set up the Flutter app**

  1. Install the SDK
  2. Implement local schema
  3. Extend models (optional but recommended)
  4. Implement/import SupabaseConnector
  5. Call db.connect()
  6. Wire up UI to use PowerSync SDK.

Full tutorial available below:

Kobie went on to explain how [sync rules and role level security (RLS)](https://docs.powersync.co/integration-guides/supabase-+-powersync/rls-and-sync-rules) work together in PowerSync, and that he created a [template](https://github.com/journeyapps/powersync-supabase-flutter-chat-demo-template) of the chat app for all to use.

### Support for real-time data changes

Tyler and Kobie discussed that PowerSync has automatic support for real-time data. Not just REST API calls but real-time database changes and subscriptions.

### No schema migrations necessary

Tyler asked about database structure changes and Kobie showed that additive changes are not a problem and that even more destructive schema changes are supported. Kobie recommended using demo apps to learn how to use the PowerSync SDK.

### Transactions supported

Tyler asked about whether the **execute** method in PowerSync supports transactions, for example when inserting two related data into the database. Kobie explained that it is supported.

> I can see that PowerSync is really bulletproof — every single kind of interaction that you might have with the data, it's got covered. And real-time is baked in which is really, really amazing. – Tyler Shukert

## Demo: Offline-first Trello (Kanban) Clone

Herman joined us to showcase his offline-first Trello clone. He made the point that Flutter is used by developers who prioritize productivity and that PowerSync seems to be aligned with that. He previously used Firebase and Firestore at his startup but found that to be deficient in offline support — its offline capabilities are based on caching, not a full offline-first approach.

Herman built a Trello clone with workspaces which have boards, which have lists. These can all be moved around using drag-and-drop. Boards and lists can be added, as well as members. Information is then shared between these.

Herman’s app approach was based on a Trello clone open-source project and includes a separate library for data sync and authentication using PowerSync and Supabase. He also mentioned his use of repository classes for data access patterns and transactions for archiving cards. 

Herman then connected his phone to his screen share to be able to demo the offline functionality of the app. While offline he showed a shared workspace where different users have access based on the sync rules. He then completed a number of actions (creating a board, moving cards) and showed how these actions synced in real-time to the view of the other user. 

![](https://powersync.com/images/blog/showcase-powersync-for-supabase-and-flutter-inline-6a09b88ef5.png "Screenshots of the offline-first Trello clone built with PowerSync, Supabase and Flutter.||portrait")

The Trello clone app is available as an [example app.](https://github.com/journeyapps/powersync-supabase-flutter-trello-demo)

[Video: Showcase: PowerSync for Supabase and Flutter](https://www.youtube.com/watch?v=O41BgDFRFMA)

---

# Insights From PowerSync Production Use: TrashBlitz

> TrashBlitz creator Praful Mathur recently shared his experience integrating PowerSync into his FlutterFlow app with a Supabase backend.

- Published: 2023-10-11
- Author: Phillip van der Merwe
- Category: Showcase
- Source: https://powersync.com/blog/insights-from-production-use-trashblitz

---

## App use case

[TrashBlitz](https://apps.apple.com/us/app/trashblitz/id6447145347) is part of [an initiative by 5Gyres](https://www.5gyres.org/trashblitz). It is used to document trash collected on cleanup operations around the world. This data is rolled up into an annual report used to advocate for responsible environmental policy.

![](https://powersync.com/images/blog/insights-from-production-use-trashblitz-inline-9ddd53bbda.png "_Screenshots of the TrashBlitz app._")

## Engineering challenges

### 1\. Adding offline-first to an already-existing app

Trash collection sites are often in remote areas where connectivity is very slow or intermittent. Caching approaches fail in these situations so the TrashBlitz team knew they needed to adapt their existing app to use an offline-first architecture. Their challenge was finding a way to do so without a heavy engineering lift or requiring invasive changes to their existing backend database: they needed the app published on the App Store for the next cleanup operation — less than two weeks away.

### 2\. Working with FlutterFlow, not yet officially supported by PowerSync

The existing app had been built with [FlutterFlow](https://flutterflow.io/), a visual app builder that generates Flutter code. FlutterFlow allows for quick iteration but getting generated code to work with the [PowerSync Flutter SDK](https://pub.dev/packages/powersync) hadn’t been done before.

### 3\. Understanding the cost of poor offline sync

Before implementing PowerSync they had some struggles: users lost entries during an earlier event due to no way to sync data back to the server. This was all the more painful as users had online connectivity but did not have enough bandwidth to complete sync operations. 

## Developer experience: Working with FlutterFlow and PowerSync

Praful came across PowerSync through reading about recommended services for Supabase and joined the community on [Discord](https://discord.gg/powersync) shortly thereafter. He was open to working with the PowerSync team to get his app shipped in time for the cleanup event in Yosemite National Park, only a few weeks away.

Since the app was built using FlutterFlow, the PowerSync team needed to figure out how to support this development process. Thankfully, FlutterFlow, unlike many other no-code app builders, allows access to generated code and supports linking app code to a GitHub repository for deployment. 

This allowed for a solution:

  * The PowerSync team added a PowerSync branch to the TrashBlitz repository. The app can be deployed from this branch.
  * UI/app changes can be made on the FlutterFlow GUI. The generated code can then be pulled into the PowerSync branch.
  * The app can be deployed to the App Store from that branch.

Praful highlighted the remarkable speed at which the PowerSync team was able to address and rectify bugs (even coordinating a bugfix with Supabase in their Flutter SDK in this crunch period), and the efficiency of securing App Store approval.

> _“Yeah, it was incredible. I mean, to work with PowerSync was probably the easiest thing that we had to do, right? Because it was fairly straightforward with what we know of how to do Flutter development.“_

We asked Praful about whether he would recommend this solution to other FlutterFlow users and he had some practical advice: PowerSync is a “no-brainer” for developers familiar with Flutter.

Praful intends to open-source the TrashBlitz codebase, enabling others to gain insights from their implementation. This will allow developers to compare the core FlutterFlow branch with the PowerSync branch and gain a comprehensive understanding of the enhancements they introduced.

## Real-world use

Despite being relatively new, their app was used by a cleanup crew in Yosemite National Park consisting of a few thousand volunteers.

TrashBlitz is now available to anyone interested in participating in annual trash cleanups. They also organize special events like "trashblitzes", where volunteers collaborate on cleaning efforts. 

![](https://powersync.com/images/blog/insights-from-production-use-trashblitz-inline-7ed77448fe.png "TrashBlitz being used at a cleanup in Yosemite National Park. With permission from @jsepulvedaphoto.||landscape")

## The case for offline-first as a default app architecture

What is the significance of the app being offline-first? Praful shared that even areas in San Francisco experience frequent connectivity issues. Offline-first has proven to be a game-changer, allowing users to use the app without the risk of losing entries. The app is more resilient – every data mutation is persistently stored on the device's storage, ensuring that even in the event of an app crash, the data remains intact. This eliminates the frustration and expense of losing all data when an app crashes.

It's worth noting that TrashBlitz had explored other alternatives, such as Replicache, but these solutions did not provide them with what they needed.

## Use PowerSync with Flutter and Supabase

To get started with PowerSync and Supabase, check out our [Supabase Integration Guide](https://docs.powersync.co/integration-guides/supabase-+-powersync). If you’d like to use PowerSync with FlutterFlow, give us a shout on our [Discord](https://discord.gg/powersync).

This post was summarized from a live event, video recording below:

[Video: PowerSync used in Production: Interview with TrashBlitz](https://www.youtube.com/watch?v=dZY4JOV7ArA)

---

# Announcing The PowerSync React Native Client SDK

> The PowerSync React Native SDK is in open alpha. Use it with a Postgres backend database to instantly make your React Native app offline-first. Supabase integration available.

- Published: 2023-10-04
- Author: Kobie Botha
- Category: Announcement
- Source: https://powersync.com/blog/announcing-the-powersync-react-native-client-sdk

---

## React Native Support

Today we’re announcing the alpha release of our React Native SDK [^1]. 

This release makes it trivial for React Native developers to add instant offline-first capability to their apps without a heavy engineering lift or requiring invasive changes to their existing Postgres backends.

Our React Native SDK is built using our common Rust core for client SDKs that we previously presented to our community [^2], and lays the foundation for future SDKs including Flutter web.

The SDK is built using an abstracted common TypeScript/JavaScript implementation of a PowerSyncDatabase client. This client is then extended with React Native specific implementations of locks, network request handlers and a SQLite database adapter. We use a forked react-native-quick-sqlite to link the client to our Rust SQLite extension for performant JSI [^3] based DB operations [^4].

## Demo app

**We've also released a demo app created with Expo** [^5] which demonstrates real-time streaming of Postgres data and offline CRUD operation queuing & syncing. The demo app also showcases our integration with Supabase.

We’re available on our [Discord](https://discord.gg/powersync) if you need any help or have any questions.

[^1]: https://docs.powersync.co/resources/api-reference#react-native-and-expo
[^2]: https://www.youtube.com/watch?v=GpfW1r24r8c
[^3]: https://reactnative.dev/architecture/glossary#javascript-interfaces-jsi
[^4]: https://github.com/powersync-ja/react-native-quick-sqlite
[^5]: https://github.com/powersync-ja/powersync-js/tree/main/demos/react-native-supabase-todolist

---

# Why We Built PowerSync

> PowerSync provides a shortcut to building and maintaining a robust data sync and real-time streaming system. PowerSync can connect to existing SQL databases to automatically sync data to SQLite client databases with a strong consistency model.

- Published: 2023-08-17
- Updated: 2025-09-30
- Author: Phillip van der Merwe
- Category: Announcement
- Source: https://powersync.com/blog/why-we-built-powersync

---

_Updated 2024-09-11_

## The Problem

A key bottleneck in database-centric mobile and desktop app development is making data accessible. 

Backend engineers often spend a lot of time on APIs and backend functionality that enables apps to access data.

![](https://powersync.com/images/blog/why-we-built-powersync-inline-f707cf497e.png)

App developers may then be held back as they wait for required API functionality before they can ship app functionality.

![](https://powersync.com/images/blog/why-we-built-powersync-inline-7b181dfcab.png)

While there are an increasing number of ways to solve this bottleneck, user expectations have evolved in ways that present a new challenge for app development:

  1. Users expect apps that are **always available**.
  2. Users expect apps that **feel instant to use**.

This leads to two additional major requirements:

  1. Always available → data must be available even when users are offline or have poor network connectivity.
  2. Feels instant to use → data updates must be streamed to users in real-time when they’re online, and the user’s own local data updates should be applied optimistically.

This necessitates increasing the scope and complexity of the APIs, the backend app and app code of modern apps:

![](https://powersync.com/images/blog/why-we-built-powersync-inline-c58b5fa59d.png)

All this leads to a complex system design that takes a lot of care to build (to ensure reliable data integrity and correct handling of edge cases) and becomes difficult to maintain and update.

## PowerSync: Plug-and-play offline-first and real-time data

By providing a plug-and-play sync system for apps with SQL backends, PowerSync reduces the scope, cost and complexity of building offline-first apps with real-time data:

![](https://powersync.com/images/blog/why-we-built-powersync-inline-5cd22c2776.png)

For a more detailed overview of the architecture of PowerSync and how it accomplishes this, refer to the PowerSync [architecture overview here](https://docs.powersync.com/).

## What does PowerSync mean for app developers and backend engineers?

### **For app developers:**

PowerSync simplifies data management: Developers can work directly with the local in-app database provided by the PowerSync SDK, and the SDK takes care of automatically syncing with the backend database even if network connectivity is not immediately available. When users are online, the SDK streams data updates in real-time.

Example of how developers would update data in using PowerSync:

```dart
await db.execute('UPDATE users SET name=? WHERE id=?', ['My name', user_id]);
```

The PowerSync SDK takes care of keeping the local database in sync with the backend.

### **For backend engineers** :

PowerSync provides a shortcut to building and maintaining a robust data sync and real-time streaming system. PowerSync can connect to existing SQL databases to automatically sync data to SQLite client databases with a strong consistency model.

This allows developers to move extremely fast with app development, enabling them to deliver modern apps in record time and with record predictability.

## Try it free

PowerSync is **free for all new users** while we're in beta, and our planned pricing plans are available [here](https://www.powersync.co/pricing). We also intend to release a version that can be self-hosted in the near future. Update May 31, 2024: [our Open Edition has been released](https://powersync.com/blog/powersync-open-edition-release) (a free, source-available, self-hosted version of PowerSync).

PowerSync is designed to be framework agnostic, with current support for Web, React Native, Flutter, Kotlin Multiplatform, Swift, Node.js and .NET.

We'd love to get your feedback! [Join our Discord](https://discord.gg/powersync) to chat about PowerSync and Supabase.

---

# PowerSync: Bringing Offline-First To Supabase, The Right Way

> Until now, there has been no easy way to enable offline-first architectures for apps using Supabase. PowerSync changes all this by providing a batteries included sync system that integrates with Supabase.

- Published: 2023-08-10
- Author: Phillip van der Merwe
- Category: Announcement
- Source: https://powersync.com/blog/bringing-offline-first-to-supabase

---

_Updated 2024-09-11_

[Create a free PowerSync account](https://accounts.powersync.com/portal/powersync-signup) or [read our Supabase integration guide](https://docs.powersync.co/integration-guides/supabase) to get started.

## Offline has been a Supabase deal-breaker for many

Supabase launched in January 2020. Later that same year, users [asked for offline support](https://github.com/orgs/supabase/discussions/357) in what has become not only the most upvoted but also the most commented on [GitHub discussion](https://github.com/orgs/supabase/discussions?discussions_q=is%3Aopen+sort%3Atop) in the Supabase org.

For many developers exploring Supabase as an alternative to Firebase, offline support felt like it should be a solved problem. Firebase’s _Cloud Firestore_ was released [just over a year earlier](https://cloud.google.com/firestore/docs/release-notes#January_31_2019) and seemed to handle the basics of offline support with its automatic caching capabilities. The comments left by some developers illustrate the point:

![](https://powersync.com/images/blog/bringing-offline-first-to-supabase-inline-be470949c9.png)

The challenge is that a true offline-first architecture is a hard problem to solve and without a easy to use solution for Supabase, many developers have had to stick with Firebase and it’s automatic caching (which only solves part of the offline problem — more on that later).

## Why is offline so important?

Why are developers clamoring for offline when internet connectivity is abundant? In short, our hyper-connected world has led users to expect apps that are **always available** and **feel instant to use**.

### Users want apps that are always available

Cloud software is the modern default. Users are now so used to being connected they can be forgiven for not anticipating they might be offline. But we haven’t arrived at guaranteed connectivity yet.

Take a few examples:

  * A candidate waiting for an interview wants to revise notes while in a cafe with spotty Wi-Fi.
  * A construction manager wants to update their project plan at an on-site office with an ISP outage.
  * A mom wants to double check her son’s medication regimen on an overnight flight.

We can expect these users to instinctually open an app on their phone or laptop and attempt to view or update data, only to run into spinners and error messages. Instead of being frustrated with the limits of internet infrastructure, in reality they often blame the app itself.

The good news is that offline-first architectures can give users the behavior they want even when they are offline. These scenarios may seem like edge cases, but as your user base grows, so will the number of users that find themselves trying to access your app while unexpectedly offline.

That’s not to say that _everything_ needs to work offline — users have learnt that some things require an internet connection. But in many cases, the expectation is that important data and functionality in an app should always be available without forethought (requiring the user to select and download certain data before going offline is not sufficiently user-friendly)

### Users want apps that feel instant to use

Fiber optic cables and the growth of technologies such as CDNs have all but eliminated delays in accessing data over the internet. That’s not the only thing: users also want to know that they’re looking at the latest data. This emergent expectation that apps should feel instant to use results in three requirements for developers:

  1. When online, the UI should always reflect the latest data.
  2. The most important data should be immediately available (zero latency).
  3. When offline, data updates made by the user should be applied optimistically, so their UI shows their update even if that update must still be reconciled with the central database when the user goes online again.

Point 1 can be solved by real-time streaming of data changes. An up-to-date local database can solve point 2, practically eliminating latency since the data is available on device. Point 3 would be solved if that database keeps local data updates in a queue that can be rolled back if the server rejects a user update.

## Why true offline-first and not just caching?

Many Firebase users are satisfied with how the caching functionality of Cloud Firestore caters for basic offline scenarios. So, is an offline-first approach really necessary? Yes. Some fundamental limitations of caching make it unable to provide the **always available** experience of true offline-first.

### Reads and mutations are limited to cached data

For data to be read while a user is offline, it needs to be available on the user device. This means it must have been downloaded into the local cache back when the user was online. Data is typically downloaded and cached as users navigate through app pages, query data, or, in some cases, explicitly select data they want to have access to offline. If a user didn’t download the data, it would not be available in the cache.

How about forcing a download of all data when a user initially accesses the app? While this is a possibility, caches are typically not indexed and generally don’t perform as well as a local database (Google also [advises against this](https://youtu.be/oDvdAFP6OhQ?t=796)). Caching is simply not designed for this.

As with reads, you can only perform updates to data already in the cache. A user who, say, wants to update all team member schedules but only accessed team members from one region while online, will not be able to access the schedules of team members outside of that region while offline.

With offline-first, all data relevant to a specific user is persisted on their device in a local database. This means that users have full CRUD capabilities even on data that they’ve never tried to access before.

### Caches may include stale data even if users were recently online

Because data stored in the cache typically needs to be _redownloaded_ to be updated with the latest data from the server, different cached data can reflect different states. For example: a physician wants to update a patient’s chart on their app while offline. If they last accessed that chart a week ago, and since then an assistant updated chart data from a different device, that physician will not see the updated data but rather the stale data that is still stored in their cache — even if they recently accessed their app but didn’t redownload that specific patient’s chart.

Offline-first with server reconciliation and automatic sync keeps the full local database consistent with the server up to the point where the user goes offline. This means the physician in the example above will see the changes made by their assistant, even if they didn’t access that specific patient’s chart since their assistant updated it.

### Caches are constantly cleared

Data previously downloaded may no longer be in the cache. Caching keeps a local copy of data that has been viewed or otherwise downloaded by the user. Since the user could theoretically view or download an infinite amount of data, the cache needs to make sure it always has space available for new data.

It does this by purging data, typically through a Least Recently Used (LRU) strategy. However, this strategy could undermine offline capability: say a health inspector visits restaurants monthly, and one of those restaurants is in an area without network connectivity. If their cache generally fills up after about a month’s use of their app, data from their previous inspection would be purged just as they are making their follow-up trip and would be unavailable.

Offline-first with data scoping (or “Sync Streams”) allows developers to define what data should be stored on a user’s device. That data is then persisted indefinitely. Local databases can also typically store a lot more data while remaining performant when compared to caches.

### Caches create a secondary source of data which can get complicated

Since apps with caches are designed to work “**online-first** ”, they typically first attempt to get new data from the server and only fall back on cache data after that call fails.  

Some single-use callbacks (like `get()` callbacks when working with Firebase), may require first trying to retrieve the server version of data and return the cached version only after that request times out. This becomes especially tricky with intermittent connectivity, where the server eventually responds but takes a long time – making the app feel slow to use.

With offline-first, the local database is treated as the primary data source for the app. Queries and updates can happen instantly against the local database. The sync system takes care of the rest.

### The bottom line: Caching is not good enough

These limitations are well-known — precisely because caching approaches have been designed to work in an _online-first_ paradigm, as a fallback for the edge case that users are offline.

Our view is different: while being offline may be an edge case for an individual user, the typical user now expects apps that are **always available**. Apps should be designed with this in mind.

## Where existing solutions for Supabase fall short

We reached out to developers using Supabase to hear why they don’t use currently available solutions. Two reasons stand out:

### Too much backend development required

For many developers, the key value of Supabase is that it eliminates the complexity of building a backend. Supabase frees up mental bandwidth for developers to focus on app development. Supabase users don’t want to spend time on backend plumbing.

It figures that those developers prefer approaches that do not require significant backend work. Client-side offline database frameworks like **RxDB** and **WatermelonDB** provide impressive client SDKs, but require developers to build non-trivial backend functionality to support their particular way of syncing data.

![](https://powersync.com/images/blog/bringing-offline-first-to-supabase-inline-998830ea90.png)

To their credit, both have great documentation on what needs to be done. Unfortunately, the fact remains that developers are responsible for building and maintaining the backend side of the equation.

### Flutter support

No existing solution supports Flutter. Replicache, for example, focusses on web apps. Since mobile users are most likely to experience spotty connectivity, and Flutter seems to be the most used mobile framework with Supabase, lack of Flutter support is an obvious gap.

### Comparison Table

![](https://powersync.com/images/blog/bringing-offline-first-to-supabase-inline-2d362b6571.png)

## What PowerSync provides

PowerSync provides a **plug-and-play client SDK _and_ an integrated sync service that plugs into Supabase**. This means you get a complete offline-first architecture for Supabase (with robust consistency properties) out of the box.

![](https://powersync.com/images/blog/bringing-offline-first-to-supabase-inline-8a0f1873b9.png)

### What does this sync service do?

Supabase CEO Paul Copplestone described what he sees as **the right way** for Supabase to support offline:

> “...the right way to do offline would be to have a full, timestamped history of every single event that happened in your database. That way, when a client goes offline we can have the client say "give me every update between XX and YY timestamps". This is similar to how Watermelon works, but Watermelon requires you to implement an "updated_at" column in every table.”

> “How can we achieve this without you needing to add this column to every table? We'd need to store the Write Ahead Log for your database, and then expose it via an endpoint. As you can imagine, this is a lot of data and there are no good off-the-shelf tools to do this. We also need to figure out how this approach works with RLS which adds some complexity.”

[ _kiwicopple on Github, June 2023_](https://github.com/orgs/supabase/discussions/357#discussioncomment-235364)

PowerSync does exactly what Paul describes in the quote above:

The PowerSync service reads the Write Ahead Log (WAL) of your Supabase Postgres database and stores a version of it. It exposes that via an endpoint that the PowerSync SDK communicates with to sync data between server and client (we also figured out how to make this work with RLS).

And we went even further, by building:

  1. A robust consistency model with automatic integrity checks so the client can guarantee it’s working with a consistent set of data.
  2. A data scoping system so that the developer can define which users should sync which subset of the overall Postgres data based on declarative rules.

### How PowerSync works

Used in conjunction with Supabase, PowerSync enables developers to build apps that are resilient to poor network conditions and have highly responsive frontends. 

  1. The PowerSync service reads from a Publication of your Postgres WAL according to [**Sync Streams**](https://docs.powersync.com/sync/streams/overview): declarative rules that, together with [RLS](https://supabase.com/docs/guides/auth/row-level-security), determine which data gets synced to which users.
  2. The PowerSync service maintains a set of live data views based on your Sync Streams – allowing the PowerSync SDK to sync a real-time stream of scoped data updates to a local database, ensuring users have access to the latest data when they’re online.
  3. App reads and writes happen directly against the local database: an embedded SQLite database managed by the PowerSync SDK. 
  4. Local writes are additionally held in an upload queue until they’re sent to the Supabase database via the Supabase client library, through the PowerSync [uploadData() callback function](https://docs.powersync.co/installation/client-side-setup/integrating-with-your-backend).
  5. Any online network calls can happen as they normally would through the Supabase client library.

![](https://powersync.com/images/blog/bringing-offline-first-to-supabase-inline-97355dbf88.png)

### Features

  * offline-first architecture (app developers can work with the local database instead of an API).
  * real-time data streaming to keep the local database up-to-date when the user is online.
  * data scoping through Sync Streams (set rules defining which data should sync to which users).
  * strong consistency (the strongest consistency possible in a distributed system: [causal+ consistency](https://jepsen.io/consistency/models/causal)).

### Flutter support

PowerSync has a Flutter SDK.

### Comparison Table

![](https://powersync.com/images/blog/bringing-offline-first-to-supabase-inline-b7e8f44025.png)

## Now available

Our [Supabase integration](https://supabase.com/partners/integrations/powersync) is now available! The best place to get started is with our [integration guide](https://docs.powersync.co/integration-guides/supabase-+-powersync).

PowerSync is free for all new users while we're in beta, and our planned pricing plans are available [here](https://www.powersync.co/pricing). We also intend to release an open source version that can be self-hosted in the near future.

PowerSync is designed to be framework agnostic, with current support for Web, React Native, Flutter, Kotlin Multiplatform, Swift, Node.js and .NET.

We’d love to get your feedback! [Join our Discord](https://discord.gg/powersync) to chat about PowerSync and Supabase.

---

# Exploring SQLite Implementations For the Web In 2023

> NOTE: This post has been superseded by the newer post: The Current State of SQLite Persistence on the Web

- Published: 2023-06-06
- Author: Ralf Kistner
- Category: Engineering
- Source: https://powersync.com/blog/exploring-sqlite-implementations-for-web

---

NOTE: This post has been superseded by the newer post: [The Current State of SQLite Persistence on the Web](https://www.powersync.co/blog/sqlite-persistence-on-the-web)

## Can SQLite be used for the web?

Yes, however, SQLite web support has many caveats and there are many issues without good solutions at the moment.

Some implementations of SQLite for web are:

  * [Official SQLite WASM build](https://webassembly.org/) — first official SQLite subproject using WebAssembly (aka WASM).
  * [wa-sqlite](https://github.com/rhashimoto/wa-sqlite) — first public project to use OPFS as the storage layer for sqlite3 (see _Option 2_ below). It also demonstrated how to use OPFS APIs.
  * [absurd-sql](https://github.com/jlongster/absurd-sql) — older project that demonstrates persistent browser-side sqlite3 by storing the databases in IndexedDB storage (see _Option 1_ below).

## What are the caveats for using SQLite for the web?

The SQLite for web caveats are primarily related to the storage layer. There are a couple of options, and each of them has different caveats.

### Storage Layer Caveats

Depending on the implementation, one of two storage layer options could be used:

#### Option 1: IndexedDB

[IndexedDB](https://www.w3.org/TR/IndexedDB/) has fairly good cross-browser support, but using it for SQLite is essentially a big hack. You're basically storing a database (SQLite) in a database (IndexedDB) implemented on another database (SQLite or LevelDB, depending on the browser). This is not necessarily a relevant concern in practice, but it's arguably a convoluted architecture.

#### Option 2: OPFS (Origin Private File System)

[OPFS (Origin Private File System)](https://fs.spec.whatwg.org/#sandboxed-filesystem) is a very new API (only recently supported in [Firefox](https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API#origin_private_file_system) and [Safari](https://webkit.org/blog/12257/the-file-system-access-api-with-origin-private-file-system/)) that was designed to allow web apps to get the benefits of working with files, but without the restrictions and performance costs of traditional web-based file processing [[1](https://developer.chrome.com/articles/origin-private-file-system/#files-as-the-foundation-of-processing)]. It is still rapidly evolving, and actually doesn't yet contain all the APIs to implement SQLite storage properly.

Both of these storage layer options have the additional issue of synchronous vs asynchronous APIs. SQLite needs synchronous filesystem access, while traditional web APIs like IndexedDB only offer asynchronous access. 

### Workarounds for achieving synchronous filesystem access

There are broadly three options here:

#### (A) Use Asyncify

[Asyncify](https://emscripten.org/docs/porting/asyncify.html) is a tool that transforms the entire built SQLite library into one that works with asynchronous methods. This works for both IndexedDB and OPFS. That solves the problem, but (a) adds significant overhead, both in download size and in performance and (b) fundamentally transforms the code in a way that makes it less predictable (i.e. it could introduce bugs in some edge cases).

#### (B) Web worker sequencing

A combination of web workers, [SharedArrayBuffer](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer) and [Atomics APIs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics) can be used to allow one web worker to wait for another — effectively converting an asynchronous API into a synchronous one. This is also a massive hack, and may add significant performance overhead.

#### (C) Use synchronous APIs offered by OPFS

Unfortunately, this option doesn't cover all the APIs, and on Firefox and Safari even fewer APIs are supported in this way. This means that workaround (A) or (B) above is still needed. Some of these APIs also lock the entire file, which means only a single tab can access the database at a time.

## Current approaches used in practice

The following approaches are currently used in practice:

  1. **Official SQLite WASM build** uses **(C)** combined with **(B)** above i.e. OPFS synchronous APIs together with SharedArrayBuffer/Atomics. It means it works decently on Chrome, but no concurrent access to the database works (not even reading from multiple tabs at the same time).
  2. **wa-sqlite** primarily uses **(A)** above, supporting either IndexedDB or OPFS. Concurrency is not a well-explored topic here, and may or may not work.

In addition to the concerns mentioned above, another caveat is that [Write-Ahead Logging (**WAL**)](https://www.sqlite.org/wal.html)**is not supported by any implementation yet**. This also limits concurrency, even if the other issues are solved.

## Summary

In the current landscape, there is no implementation of SQLite for web that can be used without important caveats. However, progress is being made and the official WebAssembly SQLite project using OPFS could be the future of offline-first web app development.

---

# Demystifying Flutter's Local Database Options: A Comprehensive Summary

> A summary of key features of SQLite libraries (sqflite, sqlite3, sqlite_async), SQLite wrappers (Floor, Drift), made-for-Flutter NoSQL databases (Isar, Sembast) and other NoSQL databases (Realm, ObjectBox) that can be used for Flutter apps.

- Published: 2023-05-25
- Author: Phillip van der Merwe
- Category: Engineering
- Source: https://powersync.com/blog/flutter-local-database-options

---

Since we couldn’t find any easy to understand and up-to-date summary of local database options for Flutter, we created one ourselves. The table below shows the main options available with key features that should help you decide which local database will work best for you. Feedback and suggestions welcome!

## Notes

#### **Full database functionality**

This summary includes only local database options that provide full database functionality (persistent, consistent and queryable data stores). We’ve ignored overly simplistic databases or caches. For example, we haven’t included [shared_preferences](https://pub.dev/packages/shared_preferences) or [hive](https://pub.dev/packages/hive) because they’re built for basic key-value storage.

#### **Standalone**

We’ve also only included local databases that can be implemented standalone. For example, since Firebase’s local data store can only be used in conjunction with the Firebase backend-as-a-service offering, it has not been included. 

#### **Open source**

All listed databases are open source.

#### **Cross-platform**

All listed databases can support iOS, Android, MacOS, Windows and Linux. Web support is noted separately in the table.

## Summary Table of Flutter Local Databases

| Database / Package | Description | Type | Performance Category | Asynchronous by Default? | Concurrency | Encryption Support | Web Support | Query Method | Plug-in Cloud Sync Support? | Backend Database Type |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| SQLite – [sqflite](https://pub.dev/packages/sqflite) | The original SQLite integration for Flutter, using a plugin package. | SQLite | Limited optimization possibilities | Yes | Single transaction at a time | Yes (via SQLCipher) | [Experimental](https://pub.dev/packages/sqflite_common_ffi_web) | SQL | No | - |
| SQLite – [sqlite3](https://pub.dev/packages/sqlite3) | Low-level library exposing SQLite C APIs to Dart code using an FFI plugin package. | SQLite | Requires manual optimization | No - requires additional work to run in background Isolates | No built-in support, but can run operations on background isolates with extra work | Yes (via SQLCipher) | [Experimental](https://pub.dev/packages/sqlite3#wasm-web-support) | SQL | No | - |
| SQLite – [sqlite_async](https://pub.dev/packages/sqlite_async) | Modified sqlite3 to add performance optimizations and asynchronous calls by default. | SQLite | High-performance | Yes | Built-in support for one write transaction and multiple read transactions concurrently | Yes (via SQLCipher) | No (experimental support can be added similar to sqlite3) | SQL | Yes, when used as part of [PowerSync](https://www.powersync.co/) | SQL |
| [Floor](https://pub.dev/packages/floor) | SQLite ORM built on top of the sqflite library and inspired by Android’s Room persistence library. | SQLite | Limited optimization possibilities | Yes | Single transaction at a time | Yes (via SQLCipher) | [No](https://pinchbv.github.io/floor/platform-support/) | SQL | No | - |
| [Drift](https://pub.dev/packages/drift) | SQLite ORM built on top of the sqlite3 library (by the same author). | SQLite | High-performance | Yes | Connection pool can be used for one write transaction and multiple read transactions concurrently | Yes (via SQLCipher) | [Experimental](https://drift.simonbinder.eu/web/) | ORM but with “SQL parsing” capabilities | No | - |
| [Isar](https://pub.dev/packages/isar) | NoSQL database made for Flutter (written by [hive](https://pub.dev/packages/hive) author with the intention to supersede hive). | NoSQL | High-performance | Yes (has equivalent synchronous and asynchronous APIs for most operations) | Built-in support for one write transaction and multiple read transactions concurrently | Yes | Full support seems to be in the works. See [open issue](https://github.com/isar/isar/issues/686) and documented [limitations](https://isar.dev/limitations.html). | Domain-specific | No | - |
| [Sembast](https://pub.dev/packages/sembast) | NoSQL database made for Flutter “for single process io applications”. | NoSQL | Unknown | Yes | Unknown | Yes | Yes, through a [separate package](https://pub.dev/packages/sembast_web) | Domain-specific | No | - |
| [Mimir](https://pub.dev/packages/mimir) | NoSQL database made for Flutter with heavy-weight full-text search capabilities thanks to [Meilisearch](https://www.meilisearch.com/). | NoSQL | Unknown | Yes | Unknown | Yes | [No](https://github.com/GregoryConrad/mimir/issues/10) | Domain-specific | No | - |
| [Realm](https://pub.dev/packages/realm) | NoSQL “mobile database” acquired by MongoDB. | NoSQL | High-performance | No, but has partial async support | Support for concurrent transactions when using separate Isolates | Yes | No | Domain-specific | Yes through MongoDB Atlas Device Sync | Hosted MongoDB Atlas (NoSQL) |
| [ObjectBox](https://pub.dev/packages/objectbox) | NoSQL “edge database” seemingly built with IoT use cases in mind including sync to self-hosted sync server. | NoSQL | High-performance | No, but makes asynchronous operations easy from version 2.0 | Built-in support for one write transaction and multiple read transactions concurrently | [No](https://github.com/objectbox/objectbox-java/issues/8) | No | Domain-specific | Yes, to self-hosted [ObjectBox Sync Server](https://sync.objectbox.io/objectbox-sync-server) | Self-hosted ObjectBox Sync Server (NoSQL) |
| Moor | [Renamed to Drift](https://pub.dev/documentation/moor/latest/) | | | | | | | | | |

## Notes On Table Columns

#### **Type**

Indicates whether the database is SQLite or NoSQL.

#### **Performance Category**

Once a database has been optimized for performance, it will generally meet high performance standards (see our separate [post on comparing database performance](https://www.powersync.co/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar) that partly led us to this conclusion). For this reason, databases have been grouped into one of three performance categories:

  1. **Limited optimization possibilities** (for example sqflite which cannot provide access to low-level high-performance SQLite APIs because it is not an FFI package).
  2. **Requires manual optimization** (where optimization is possible but must be done manually by the developer themselves).
  3. **High-performance** (where the database is set up to be highly performant by default).

#### **Asynchronous by Default**

This indicates whether the database supports asynchronous operations; in other words, whether there is multi-isolate support that prevents the main isolate from being blocked.

#### **Concurrency**

Here we list the database’s ability to support multiple concurrent transactions.

#### **Web Support**

Here most SQLite are listed as experimental as their web support is based on [SQLite’s WebAssembly implementation](https://sqlite.org/wasm/doc/trunk/index.md) which is not yet broadly supported by web browsers.

#### **Query Method**

Here the query methods are "SQL" or "ORM" for SQLite-based databases and "domain-specific" for NoSQL databases since they each have their own query flavor.

#### **Plug-In Cloud Sync Support**

This refers to the database’s ability to plug into an existing sync system that keeps data in sync with a primary cloud database and across devices.

#### **Backend Database Type**

This indicates the cloud database type that the cloud sync solution supports.

## Feedback

If you have feedback on this summary or have a suggestion for a feature to include, please let us know on twitter [@powersync_](https://twitter.com/powersync_) .

---

# SQLite Optimizations For Ultra High-Performance

> SQLite works great as an in-app database but can require some configuration to achieve optimal performance. This post covers 10 SQLite optimizations that can help maintain blazingly fast performance.

- Published: 2023-05-25
- Author: Ralf Kistner
- Category: Engineering
- Source: https://powersync.com/blog/sqlite-optimizations-for-ultra-high-performance

---

[SQLite](https://www.sqlite.org/) is small, fast, has a lot of built-in functionality, and works great as an in-app database. However, SQLite is designed for many different use cases, and requires some configuration for optimal performance as an in-app database. And being a C library designed to run on practically any platform, it leaves a lot up to higher-level libraries to implement.

### Benchmarking Baseline Performance/Throughput

To start with, it helps to have a good idea of expected baseline performance. If an app's performance is far from this, there is likely room for optimization.

![Graph showing baseline SQLite performance](https://powersync.com/images/blog/sqlite-optimizations-for-ultra-high-performance-inline-c97060bfb1.png "This is for a single table, with small rows (around 30 bytes each), and no secondary indexes. Reads are lookups by primary key. For tables with secondary indexes, expect up to 5x reduction in insert performance. Update and delete throughout should be similar to insert.")

## Key SQLite Performance Optimizations To Consider

Here are 10 optimizations that could collectively potentially result in significant SQLite performance gains in your application:

### **#** 1: Enable Write-Ahead Logging (WAL) And Disable Synchronous Mode

**_Effect: Can reduce per-transaction overhead from 30ms+ to < 1ms._**

The default in SQLite is to use a rollback journal. This involves at least two disk writes for every transaction, and waiting for a filesystem sync.  

WAL mode instead writes changes to a sequential write-ahead log, and then later synchronizes it back to the main database. Additionally, it allows safely using `synchronous = normal`, which avoids having to wait for an filesystem sync (fsync) operation in most transactions.  

These settings are good for most applications:

```sql
pragma journal_mode = WAL;
pragma synchronous = normal;
pragma journal_size_limit = 6144000;
```

The only durability caveat is that on a system crash (not application crash), the last transaction(s) may be rolled back. This is fine for most applications — if durability is that important, you should probably rely on more than just a phone's flash storage.

### **#** 2: Reduce Binding Overhead

**_Effect: Using different bindings can reduce per-transaction and per-statement overhead by 2-10x._**

SQLite itself is _fast,_ and can execute millions of individual statements per second _._ The [official documentation](https://www.sqlite.org/np1queryprob.html) mentions there is no problem with using lots of individual queries, unlike with typical client/server databases.  

However, very often the higher-level library / SQLite bindings does add a lot of overhead to each statement, that could be an order of magnitude or two more than the underlying SQLite operation. This is especially true for (1) higher-level languages, (2) when the bindings provide asynchronous operations, or (3) when the operation passes through multiple layers of bindings. For example, if the call goes from React Native -> Java -> JNI → SQLite and back, that adds a lot of overhead.  

The only options here are:

  1. Choose a library that has as little as possible overhead.
  2. Combine multiple operations into a single statement wherever possible. Use JOIN statements or JSON1 for this (see below).

**Android**

Avoid the built-in Android SQLite implementation — it has severe limitations:

  1. The SQLite version is different based on the Android version, and outdated even on the latest Android version.
  2. No JSON1 support.
  3. The bindings only support String arguments for queries.  

If you use bindings on another platform (e.g. Flutter or React Native), make sure that it doesn't use the built-in Android SQLite under the hood. Most libraries provide an option to bundle SQLite instead of using the built-in one, if it isn't the default.

### **#** 3: Wrap Writes Into Transactions

**_Effect: Can increase write throughput by 2-20x._**

By default, every write to the database is effectively its own transaction. The overhead per transaction is reduced in WAL mode, but not eliminated. For high throughput of writes, wrap multiple writes in the same transaction.

Even read performance can be improved with transactions, since it reduces the number of lock operations required. However, when WAL mode is used, this effect is small.

### **#** 4: Run Database Operations In A Background Thread

**_Effect: Avoid blocking of the UI thread._**

Running operations in the background is important to avoid the application UI stuttering. For many operations, SQLite is fast enough that this is not a problem, even when running on the main thread. However, there may be an occasional query that takes longer, especially when working with large sets of data.  

For this reason it's usually best to run operations on a background thread. The SQLite bindings may do this automatically (e.g. ones that provide `async` methods for Dart), or may require manual work for this. This does often add some overhead to each operation, but it is still usually fast enough to not be an issue, and is worth the trade-off of not blocking the UI.

### **#** 5: Optimize Concurrency

**_Effect: Allow running large read or write queries in the background, without blocking time-sensitive read queries._**

Even when running operations in the background, operations may still block each other. If the bindings run in single-threaded mode, one large transaction (e.g. downloading data in the background) would block all other queries.  

SQLite natively supports concurrent transactions. However, each separate "connection" is effectively single-threaded. So to run multiple concurrent transactions, separate connections are needed on different threads.  

In the default rollback journal mode, SQLite can run any number of concurrent read transactions, but when a transaction writes to the database, it locks it in exclusive mode (no other readers or writers can run at that point).

In WAL mode, readers can continue reading from the database while writing. The only limit is that only a single transaction can write at any point.  

If multiple transactions attempt to write at the same time, it will fail with `SQLITE_BUSY`, and need to be retried. When only a single process uses the database at a time, it is often better to use an application-level write queue, rather than relying on `SQLITE_BUSY`. This could provide more fair writes, avoiding issues such as writer starvation.  

SQLite also has an experimental mode called [begin concurrent](https://www.sqlite.org/cgi/src/doc/begin-concurrent/doc/begin_concurrent.md), allowing concurrent write transactions, as long as they don't read or write the same pages of data. This is not part of the main build yet, and requires a custom build from a separate branch.

### **#** 6: Use Prepared Statements

**_Effect: Can increase per-statement throughput by up to 1.5x._**

When running the same small statement many times over, the overhead of parsing the SQL could add up.  

For example, instead of executing the statement each time like this:

```sql
for (var entry in entries) { 
	db.execute("INSERT INTO data(id, value) VALUES (?, ?)", entry);
```

Prepare the statement once, and run it multiple times:

```sql
var stmt = db.prepare("INSERT INTO data VALUES (?, ?)");
for (var entry in entries) {  
	stmt.execute(entry);
}
```

Bindings often do not expose the low-level `prepare()` call directly. When the bindings are asynchronous, the overhead of the bindings would be more than the gain of the prepared statement.

However, the bindings could:

  1. Implicitly use prepared statements for batch calls, e.g. `db.executeBatch("INSERT INTO data VALUES (?, ?)", entries)`.
  2. Cache prepared statements for recently-used queries.

### **#** 7: Use JSON1 Functions

**_Effect: Throughput of 1-2x of prepared statements, depending on binding overhead. If the bindings do not provide efficient alternatives for batching, this could increase throughput much more._**

In recent SQLite versions, the JSON1 extension is enabled by default. Even when not storing JSON data, this makes it easy to pass in large sets of data to a query.  

This is one great way to avoid per-statement overhead, regardless of the bindings used.

**Example 1: Lookup multiple rows in a single statement**

Typical example for a single row lookup:

```javascript
db.select('SELECT * FROM users WHERE id = ?', [id]);
```

To query multiple rows in a single statement, use the `IN` operator:

```javascript
db.select('SELECT * FROM users WHERE id IN (?, ?, ?)', [id1, id2, id3]);
```

However, the above typically involves generating SQL programmatically, which is error-prone, and could run into the limit on the maximum number of parameters per statement (999 or 32766 by default, depending on the SQLite version used).  

Using JSON1 functions avoids that complexity, in addition to typically being faster:

```javascript
db.select('SELECT * FROM users WHERE id IN (SELECT e.value FROM json_each(?) e)', [jsonEncode(ids)]);
```

**Bulk insert**

JSON1 can also be used to bulk insert data:

```javascript
var data = users.map(u => u.toMap());
db.execute("INSERT INTO users(name, email) SELECT e ->> 'name', e ->> 'email' FROM json_each(?) e)", [jsonEncode(data)]);
```

When the query gets large, use a CTE (Common Table Expressions) (`WITH` statement) to split it out from the rest of the query:

```javascript
db.execute("""
WITH data AS (SELECT e ->> 'name' as name, e ->> 'email' as email FROM json_each(?) e)
INSERT INTO users(name, email) SELECT data.name, data.email FROM data
""", [jsonEncode(data)]);
```

**Bulk update**

Bulk update using `UPDATE FROM`:

```javascript
var data = users.map(u => u.toMap());
db.execute("""
WITH data AS (SELECT e ->> 'id' as id, e ->> 'name' as name, e ->> 'email' as email FROM json_each(?) e)
UPDATE users   
	SET email = data.email, name = data.name  
  FROM data 
  WHERE users.id = data.id
""", [jsonEncode(data)]);
```

**Bulk delete**

Bulk delete using `IN`:

```javascript
db.execute("""
	DELETE FROM users WHERE users.id IN (SELECT e.value FROM json_each(?) e)
""", [jsonEncode(ids)]);
```

### **#** 8: Use Indexes Optimally

**_Effect: Read queries can be orders of magnitude faster._**

Indexes can increase the performance of read queries by orders of magnitude. There are many great guides on indexing, and won't be repeated here.

SQLite has a great guide on all the different optimizations the query planner can perform using indexes: https://www.sqlite.org/optoverview.html

Some tips:

  1. Make sure that the correct indexes are being used, by using `EXPLAIN QUERY PLAN`. In most cases the query planner is quite good, but it does pick a suboptimal index in some cases.
  2. If a suboptimal index is used, see this guide: https://www.sqlite.org/queryplanner-ng.html#howtofix  

Note that by default, SQLite does not know how many unique values are in each column, which may cause it to choose a suboptimal index. The default recommendation is to use `ANALYZE` (or `OPTIMIZE`) to analyze tables, but this may cause different indexes to be used for different users, resulting in difficult-to-debug performance issues.  

Instead, use one of the other options:

  1. Use `likely()` and `unlikely()` functions to provide hints on conditions that are likely to be true or false.
  2. Use the unary "+" operators to prevent certain terms from begin used for an index.
  3. Pre-populate the `sqlite_stat1` table.  

SQLite has support for [indexes on expressions](https://www.sqlite.org/expridx.html) and [partial indexes](https://www.sqlite.org/partialindex.html), which may be very useful in some cases. For example, an index can be created on a field inside a JSON document using:

```sql
CREATE INDEX myindex ON mytable(json_document ->> 'subfield');
```

### **#** 9: Use Background WAL Checkpoints

**_Effect: Remove the occasional fsync overhead on a transaction, typically 30-100ms._**

WAL checkpoints are where data is moved from the write-ahead log to the main database. This is one place that does wait synchronously for the filesystem to sync.  

By default, this occurs once the WAL is greater than 1,000 pages, as part of a `COMMIT` statement. This means that every now and then, a transaction may be slightly slower to complete.  

To avoid this overhead, the WAL checkpoint can be run in a separate thread on a separate database connection. This requires some low-level operations, described [here](https://www.sqlite.org/c3ref/wal_autocheckpoint.html).

### **#** 10: Free Up Space When Appropriate

By default, the database does not decrease in size after deleting data. There are two files that could grow indefinitely, and does not free space automatically:

  * The main database file. Space is freed using a manual `VACUUM` command, or auto `VACUUM`.
  * The WAL file. This can grow large if there are large transactions, or many concurrent transactions. Space is freed using `pragma journal_size_limit` or `pragma wal_checkpoint(truncate)`.  

While SQLite does support an incremental vacuum mode for the main database, it can increase fragmentation and decrease performance. Instead, manually run `VACUUM` to reclaim space after a lot of data has been deleted.  

To estimate the amount of space that can be freed, use this query:

```sql
SELECT page_count * page_size as total_size, freelist_count * page_size as freelist_size FROM pragma_freelist_count(), pragma_page_size();
```

The actual space that can be freed may be more when many pages are only partially filled.

The WAL size is mostly managed automatically by the `pragma journal_size_limit` setting. It could still be useful to directly truncate the WAL after a `VACUUM` command. There is currently no built-in SQLite method to get the WAL size, but this can be done by checking the size of the `-wal` file using standard filesystem methods.  

If there are many free pages (e.g. more than 10MB), run the following to reclaim the space:

```sql
vacuum;
pragma wal_checkpoint(truncate);
```

Note that even though this will free up space, it actually requires more storage while running. This means it can't be used to free up space when the device storage is already full.

Both these statements require a write lock, and may block writing to the database for a long time if the database is large. It is best to run this while the device is idle, to avoid slowing down or blocking other operations.  

On iOS, schedule a background processing task:

  * [Background tasks](https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/using_background_tasks_to_update_your_app) in general
  * [BGProcessingTask](https://developer.apple.com/documentation/backgroundtasks/bgprocessingtask)  

On Android, use WorkManager to schedule the operation when the device is idle:

  * [Define work requests](https://developer.android.com/guide/background/persistent/getting-started/define-work)
  * Use BatteryNotLow, DeviceIdle and StorageNotLow constraints.

## Optimized SQLite Library For Flutter

Application developers should not have to care about most of this complexity. To assist with this in Flutter applications, [we’ve created a library](https://pub.dev/packages/sqlite_async) (sqlite_async) that contains many of the above optimizations built-in, including:

  1. Using WAL mode by default.
  2. Transactions are asynchronous and concurrent by default, by using a pool of connections, each running in a separate Isolate.
  3. As an escape for complex performance-sensitive operations, synchronous database operations can be run directly on the underlying database connection in the database Isolate.
  4. List, Map and custom Object arguments are automatically encoded as JSON to simplify JSON1 operations.
  5. Use SQL queries directly — no code generation required.  

Additional support is planned for:

  1. Automatic background WAL checkpoints.
  2. Helper libraries for automatic `VACUUM` support when the device is idle (Flutter applications).  

If you prefer using an ORM and typed queries, look at the great `drift` library instead. While it doesn’t have all the same optimizations out of the box, most of it can be enabled with some configuration.

---

# Flutter Database Comparison: sqlite_async, sqflite, ObjectBox and Isar

> Local databases often claim to have relatively better performance than others. We tested four local databases to benchmark their performance both with and without batched operations.

- Published: 2023-05-18
- Author: Ralf Kistner
- Category: Engineering
- Source: https://powersync.com/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar

---

After publishing [sqlite_async](https://pub.dev/packages/sqlite_async), a [high-performance](https://powersync.com/blog/sqlite-optimizations-for-ultra-high-performance) asynchronous interface for SQLite on Dart & Flutter, we wanted to compare its performance to other in-app databases for Flutter: sqflite, ObjectBox and Isar.

## Summary

  1. With some exceptions, all the evaluated databases give similar performance.
  2. Using transactions & batching makes a much bigger difference in performance than which database is used.
  3. WAL mode in SQLite is great for performance of many smaller write transactions.

## Methodology

  * Benchmark tests were loosely based on old [SQLite benchmarks](https://www.sqlite.org/speed.html) that include 16 separate tests, of which 15 were used.
  * Where available, two implementations of each database engine were tested:
  * ~A **“default” implementation** where the focus is on ease of implementation rather than performance. Only very simple performance optimizations are applied here, for example: combining writes into a single operation.
  * ~A **"batched" implementation** that aims to minimize the performance overhead of individual async operations. This may introduce some additional complexity to batch operations, but increases performance. Only performance optimizations readily available in the library's documentation or examples are considered. This is done by either using a batch API provided by the library, or running synchronous operations in a separate Isolate.
  * Benchmark tests were run on iOS, Android and Linux.
  * Benchmark tests were run 3 times on each platform and for each database engine implementation.

##### **List of all benchmark tests used:**

  * Test 1: 1000 INSERTs
  * Test 2: 25000 INSERTs in a transaction
  * Test 3: 25000 INSERTs into an indexed table
  * Test 4: 100 SELECTs without an index
  * Test 5: 100 SELECTs on a string comparison
  * Test 7: 5000 SELECTs with an index
  * Test 8: 1000 UPDATEs without an index
  * Test 9: 25000 UPDATEs with an index
  * Test 10: 25000 text UPDATEs with an index
  * Test 11: INSERTs from a SELECT
  * Test 12: DELETE without an index
  * Test 13: DELETE with an index
  * Test 14: A big INSERT after a big DELETE
  * Test 15: A big DELETE followed by many small INSERTs
  * Test 16: Clear table

#### Notes

  1. Since the tests are based on those from SQLite, the operations used may favor SQLite in some cases. For example, copying data from one table to another (Test 11) is a native operation using a single query in SQLite, while this requires separately querying and inserting data in Isar and ObjectBox.

  2. Some differences from the SQLite benchmarks:

  * ~Tables and indexes are pre-created, to better match typical usage, and to allow fair comparison with databases that don't support dynamic tables and indexes.
  * ~Tables have an explicit integer primary key "id", auto-populated by the respective databases. This is not directly used in the tests.
  * ~Clear instead of drop tables.
  * ~The exact queries may be different, but the outcome should be roughly the same.

  3. On specific tests:

  * ~Test 1: This does individual inserts — no batching or transactions. This is not recommended for large volumes, but does demonstrate the overhead per transaction. The WAL journal mode on SQLite gives it an advantage on this test.
  * ~Test 6: Not present, since it only creates indexes, which are avoided in these benchmarks.
  * ~Test 7: This tests a "between" operation on an indexed column (WHERE b >= ? AND b < ?). This is one test where ObjectBox does not perform as well as the others — it's possible that this operation does not currently use indexes in ObjectBox.

  4. Only asynchronous/non-blocking APIs are used, unless the code runs in a background Isolate. Synchronous calls have the ability to block the UI / introduce stutter, so we believe it best to avoid them completely.

  5. Benchmark limitations:

  * ~The benchmark implementation does not measure UI performance during database operations yet. Despite the database operations being async, it may still block the UI Isolate in some cases.
  * ~No UI yet — all results are logged to the console.
  * ~The benchmark implementation does not test concurrent operations.

## Database-specific Notes

#### sqlite_async

  * [sqlite_async](https://pub.dev/packages/sqlite_async) is a performance-optimized modification of the [sqlite3 package](https://pub.dev/packages/sqlite3).
  * Only async operations are directly supported.
  * Uses WAL journal mode (library default). `PRAGMA wal_checkpoint(RESTART)` is run at the end of every test, to better allocate write time to the relevant test.
  * Batched mode: Uses prepared statements internally.

#### sqflite

  * Uses DELETE journal mode (library default).
  * [sqflite_ffi](https://github.com/tekartik/sqflite/blob/master/sqflite_common_ffi/doc/using_ffi_instead_of_sqflite.md) is used for all tests. This has much better performance than the default implementation, and is a simple change.

#### Isar

  * Uses async operations.

#### ObjectBox

  * ObjectBox does support async operations from version 2.0, but not in a transaction.
  * For async transactions, everything in the transaction must run in a separate isolate. It doesn't cause any issues in these benchmarks, but would potentially complicate code in real-world applications.
  * Since there is no way to run an async transaction without running in a separate Isolate, only one implementation is provided.

### Comparing Flutter Database Performance On iOS

**Test device** : iPhone 7, iOS 15

The table below shows the average test results across 3 test runs for each database engine implementation. Cells show time taken to complete the test in milliseconds and are shaded dark green (best) to amber to dark red (worst) to show relative performance for each test.

![](https://powersync.com/images/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar-inline-6b89bd5f12.png)

The graph below shows the sum of average test results for each database engine, ignoring tests 1 and 7 for their potential to skew the data: (As you can see, using transactions & batching makes a much bigger difference in performance than which database is used.)

![](https://powersync.com/images/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar-inline-4b5fd69829.png)

### Comparing Flutter Database Performance On Android

**Test device:** OnePlus Nord N10, Android 11

Here is a table showing average test results for different Flutter databases running on Android, set up as above:

![](https://powersync.com/images/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar-inline-e92e7c1df4.png)

Here is a similar graph as above, showing the sum of average test results, ignoring tests 1 and 7:

![](https://powersync.com/images/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar-inline-6187ea5ac8.png)

### Comparing Flutter Database Performance On Linux

**Test device:** Dell XPS 13, Ubuntu 22.04

Here is a table showing average test results for different Flutter databases running on Linux, set up as above:

![](https://powersync.com/images/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar-inline-1e836d5a4a.png)

And here is the graph of the sum of average test results for Linux, also ignoring tests 1 and 7:

![](https://powersync.com/images/blog/flutter-database-comparison-sqlite-async-sqflite-objectbox-isar-inline-f916676e73.png)

### Benchmark GitHub Project

The benchmark project with full details including database files and acknowledgements is available [here](https://github.com/journeyapps/flutter-database-benchmarks/tree/main).

---

# Acceptable Use Policy

> Acceptable use policy — PowerSync

- Source: https://powersync.com/legal/acceptable-use-policy

---

###### 1\. **INTRODUCTION**.

1.1. This page sets forth the principles, guidelines and requirements of Journey Mobile, Inc.’s (“**Company**”) Acceptable Use Policy for its PowerSync technology platform, including the software application development tools and source code therein, and any enhancements and modifications thereto (“**PowerSync**”), governing your use of PowerSync. The Acceptable Use Policy has been created to promote the integrity, security, reliability and privacy of PowerSync and any data, information, and other materials contained and accessible therein.  
  
1.2. If you have elected to access PowerSync as hosted by Company (“**PowerSync Cloud**”), the additional provisions set forth in the attached [Appendix](#appendix-powersync-cloud-terms) shall apply to you.

###### 2\. **PROHIBITED USES**.

In addition to the other requirements of this Acceptable Use Policy, you may only use PowerSync in a manner that, in the sole judgment of Company, is consistent with the purposes of PowerSync. If you are unsure of whether any contemplated use or action is permitted, you should contact Company. By way of example, and not limitation, uses of PowerSync described below are expressly prohibited: (i) the resale of PowerSync without Company's explicit written consent pursuant to a resale or other agreement executed between you and Company; and (ii) violations or infringements of any rights of any third party, including without limitation, copyright, trade secret, patent or other intellectual property or proprietary rights.

###### 3\. **ENFORCEMENT**.

Company reserves the right to interpret the guidelines and take (or refrain from taking), any action in its discretion. Without affecting any other remedies available to Company, Company may immediately permanently or temporarily remove or disable access to any content, or suspend and/or terminate your access to PowerSync if Company reasonably believes that you have violated or intend to violate any provision of this Acceptable Use Policy. Company may, but is not required to, provide you with written notice of such suspension and/or termination, which may be provided by email. Company will, in its discretion, attempt to work with you to cure violations of this Acceptable Use Policy and to ensure that there is no recurrence of violations prior to suspension and/or termination. If Company suspends your access to PowerSync due to a violation of this Acceptable Use Policy, such suspension does not relieve you from any obligations to pay amounts due, and to continue to pay for any applicable PowerSync subscriptions or fees while you are subject to such suspension.

###### 4\. **ADDITIONAL DISCLOSURES**.

4.1. Any waiver of any provision of the Acceptable Use Policy will be effective only if in writing and signed by an executive officer or director of Company.  
  
4.2. No waiver by Company of any breach or default or failure to exercise any right allowed under this Acceptable Use Policy is a waiver of any preceding or subsequent breach or default or a waiver or forfeiture of any similar or future rights under this Acceptable Use Policy.  
  
4.3. The section headings used herein are for convenience only and shall be of no legal force or effect.  
  
4.4. If a court of competent jurisdiction holds any provision of this Acceptable Use Policy invalid, such invalidity shall not affect the enforceability of any other provisions contained in this Acceptable Use Policy, and the remaining portions of the Acceptable Use Policy shall continue in full force and effect.

### **APPENDIX: PowerSync Cloud Terms**

The following provisions apply when you have purchased access to **PowerSync Cloud**.

###### 1\. **COMPLIANCE.**

You shall not post, transmit, re-transmit or store any information, data or other materials on PowerSync Cloud that, in the sole judgment of Company, (a) is in violation of any local, state, federal or foreign law, rule or judicial or administrative order or regulation, (b) is threatening, obscene, indecent, libelous or that otherwise could adversely affect any individual, group or entity (each, a “**Person**”), or (c) violates the rights of any Person, including rights protected by copyright, trade secret, patent or other intellectual property or similar laws or regulations. You shall be responsible for determining what laws or regulations are applicable to your use of PowerSync Cloud.

###### 2\. **PROHIBITED USES.**

a. By way of example, and not limitation, uses of PowerSync Cloud described below are expressly prohibited: (i) the introduction of malicious programs into PowerSync Cloud (e.g. viruses and worms); (ii) effecting security breaches or disruptions of internet communication (security breaches include, but are not limited to, accessing data of which you are not an intended recipient or logging into an account that you are not expressly authorized to access); (iii) executing any form of network monitoring which will intercept data not intended for you; (iv) circumventing passwords, user authentication or security of any account; (v) interfering with, denying or causing degraded service to any other Company customer in any way; and (vi) using any code, program/script/command, or messages of any kind to submit excessively high volumes of Application Programming Interface (API) requests to PowerSync Cloud, that interfere with or are designed to disable another Company customer’s access to PowerSync Cloud.  
  
b. Company will not be liable for any loss or damage caused by a distributed denial-of-service attack, viruses or other technologically harmful material that may infect your device, including hardware and/or software, data or other proprietary material due to your use of PowerSync Cloud.

###### 3\. **COPYRIGHT POLICY AND DIGITAL MILLENNIUM COPYRIGHT ACT (DMCA) PROCEDURES.**

a. Company reserves the right to terminate your or any third-party’s right to use PowerSync Cloud if such use infringes the copyrights of another. Company may, under appropriate circumstances and at its discretion, terminate your or any third-party’s right to access PowerSync Cloud if Company determines that you or a third-party are/is a repeat infringer. If you believe that any material has been posted via PowerSync Cloud by any third-party in a way that constitutes copyright infringement, and you would like to bring it to Company's attention, you must provide Company's DMCA agent identified below with the following information: (i) an electronic or physical signature of the person authorized to act on behalf of the owner of the copyrighted work, (ii) an identification of the copyrighted work and the location on PowerSync Cloud of the allegedly infringing work, (iii) a written statement that you have a good faith belief that the disputed use is not authorized by the owner, its agent or the law, (iv) your name and contact information, including telephone number and email address, and (v) a statement by you that the above information in your notice is accurate and, under penalty of perjury, that you are the copyright owner or are authorized to act on the copyright owner’s behalf.  
  
b. The contact information for Company's DMCA Agent for notice of claims of copyright infringement is: DMCA Agent, Journey Mobile, Inc., 3700 Quebec St, Ste 100 PMB 132, Denver, Colorado, 80207, United States.

---

# Contributor license agreement

> Contributor license agreement — PowerSync

- Source: https://powersync.com/legal/cla

---

In order to clarify the intellectual property license granted with Contributions (as defined below) from any person or entity, Journey Mobile, Inc. ("**Company**") must have a Contributor License Agreement ("**CLA**") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for Your protection as a Contributor as well as the protection of the Company and its users; it does not change Your rights to use Your own Contributions for any other purpose.  
  
You accept and agree to the following terms and conditions for Your present and future Contributions submitted to Company. Except for the license granted herein to Company and recipients of software distributed by Company, You reserve all right, title, and interest in and to Your Contributions.

###### 1\. **Definitions**.

"**You**" (or "**Your**") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this CLA with Company. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "**control**" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.  
  
"**Contribution**" shall mean any original work of authorship, including any modifications or additions to an existing work, that is or previously has been intentionally submitted by You to Company for inclusion in, or documentation of, any of the products owned or managed by Company (the "**Work**"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to Company or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, Company for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."

###### 2\. **Grant of Copyright License.**

Subject to the terms and conditions of this CLA, You hereby grant to Company and to recipients of software distributed by Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.

###### 3\. **Grant of Patent License.**

Subject to the terms and conditions of this CLA, You hereby grant to Company and to recipients of software distributed by Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that Your Contribution, or the Work to which You have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this CLA for that Contribution or Work shall terminate as of the date such litigation is filed.

###### 4.

You represent that You are legally entitled to grant the above license. If Your employer(s) has rights to intellectual property that you create that includes Your Contributions, You represent that You have received permission to make Contributions on behalf of that employer, that You will have received permission from Your current and future employers for all future Contributions, that Your applicable employer has waived such rights for all of your current and future Contributions to Company, or that Your employer has executed a separate CLA with Company.

###### 5.

You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.

###### 6.

You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.

###### 7.

Should You wish to submit work that is not Your original creation, You may submit it to Company separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: \[named here\]".

###### 8.

You agree to notify Company of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.

---

# Commercial license and services agreement

> Commercial license and services agreement — PowerSync

- Source: https://powersync.com/legal/commercial-license-and-services-agreement

---

This PowerSync Commercial License and Services Agreement (this “Agreement”) is by and between Journey Mobile, Inc. DBA PowerSync, with mailing address 3700 Quebec St, Ste 100 PMB 132, Denver, CO 80207, United States, and principal place of business at 2679 W Main St, 3rd Floor, Littleton, CO 80120 (“**Company**”) and the Customer (also referred to herein as “**you**”), identified on the applicable Order Form (as defined below).  This Agreement is effective as of the date the Customer clicks the “I Accept” or similar checkbox or button associated with this Agreement, or the date set forth on the Order Form, if applicable (the “**Effective Date**”). Company and Customer may be referred to individually as a “**Party**” or together as the “**Parties**”.  
  
Customer’s use of the Services (as defined below) is subject to and governed by this Agreement. Company may, at its discretion, update this Agreement at any time. Customer can access and review the most current version of this Agreement at the URL for this page or by clicking on the “Commercial License and Services Agreement” link on the PowerSync website, or as otherwise made available by Company.  
  
PLEASE REVIEW THIS AGREEMENT CAREFULLY. BY ACCESSING OR USING THE SERVICES, CUSTOMER AGREES TO BE BOUND BY THIS AGREEMENT, INCLUDING ANY UPDATES OR REVISIONS POSTED HERE OR OTHERWISE COMMUNICATED TO CUSTOMER. IF CUSTOMER DOES NOT AGREE WITH THE TERMS AND CONDITIONS OF THIS AGREEMENT, CUSTOMER MAY NOT ACCESS OR USE THE SERVICES.  
  
**THIS AGREEMENT REQUIRES FINAL AND BINDING ARBITRATION TO RESOLVE ANY DISPUTE OR CLAIM ARISING OUT OF OR RELATING IN ANY WAY TO THIS AGREEMENT, OR YOUR ACCESS TO OR USE OF THE SERVICES**, INCLUDING THE VALIDITY, APPLICABILITY OR INTERPRETATION OF THIS AGREEMENT, AND YOU AGREE THAT ANY SUCH CLAIM WILL BE RESOLVED ONLY ON AN INDIVIDUAL BASIS AND NOT IN A CLASS, CONSOLIDATED OR REPRESENTATIVE ACTION, ARBITRATION OR OTHER SIMILAR PROCESS. PLEASE REVIEW SECTION 13(i) CAREFULLY TO UNDERSTAND YOUR RIGHTS AND OBLIGATIONS WITH RESPECT TO THE RESOLUTION OF ANY CLAIM.  
  
If you are entering into this Agreement as an individual, you represent and warrant that you: (a) are of legal age to form a binding contract; (b) have the right, authority, and capacity to agree to and abide by this Agreement; and (c) are not a person barred from using the Services under the laws of any applicable jurisdiction. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT AND WARRANT THAT YOU ARE AUTHORIZED AND LAWFULLY ABLE TO BIND SUCH ENTITY TO THIS AGREEMENT, IN WHICH CASE THE TERM “YOU” SHALL REFER TO SUCH ENTITY. IF YOU DO NOT HAVE SUCH AUTHORITY, YOU MAY NOT ACCESS OR USE THE SERVICES.  
  
If Customer elects to deploy and host PowerSync using Customer’s own computing infrastructure, as indicated on an Order Form, the additional provisions set forth in [Appendix A](#appendix-a-self-hosting-terms) (Self-Hosting Terms) shall apply to Customer. If Customer elects to access PowerSync as hosted by Company (“**PowerSync Cloud**”), the additional provisions set forth in [Appendix B](#appendix-b-powersync-cloud-terms) (PowerSync Cloud Terms) shall apply to Customer.  
  
The Parties hereby agree as follows:

###### 1\. DEFINITIONS.

a. “**Acceptable Use Policy**” means the policy that sets forth the principles, guidelines and requirements governing the use by Customer of PowerSync, available at [https://www.powersync.com/acceptable-use-policy](https://powersync.com/legal/acceptable-use-policy).  
  
b. “**Credentials**” means any User accounts, passwords and other authentication credentials or keys associated with use of PowerSync by Customer or Users.  
  
c. “**Customer Data**” means all Data that any User submits, uploads, emails, transmits or otherwise makes available through the Services or to Company.  
  
d. “**Customer Facilities**” means Credentials and any account, database, hardware, server, system or other facility within Customer’s custody or control.  
  
e. “**Data**” means all information, data, and other materials accessible through the Services.  
  
f. “**Documentation**” means the contents provided under the documentation section of the PowerSync website, or other URL as notified to the Customer in writing from time to time.  
  
g. “**Unauthorized Usage Issue**” means any use of the Services by Customer or Users in violation of the terms and conditions of this Agreement or any Policy.  
  
h. “**Intellectual Property**” means all rights associated with patents and inventions; copyrights, and other works of authorship (including moral rights); trademarks, service marks, trade dress, trade names, logos and other source identifiers; trade secrets; software, databases and data; and all other intellectual property and industrial designs.  
  
i. “**Order Form**” means a written ordering document or online order for the procurement of the Services.  
  
j. “**PowerSync**” means Company's PowerSync technology platform, including the PowerSync Core Offerings and the PowerSync Premium Offering, together with the format, content, look and feel, sequence and functionality thereof, and the software application development tools and source code therein, including the Updates, enhancements and modifications thereto.  
  
k. “**PowerSync Core Offerings**” means PowerSync software development kits (SDKs) and other software which constitute the core features of the PowerSync technology platform, and which are made available by Company under open-source or source-available licenses.  
  
l. “**PowerSync Premium Offering**” means the PowerSync subscription service for Premium PowerSync Features, consisting of (i) a license to access and use the Premium PowerSync Features and the Documentation relating thereto, and (ii) any other services as Company may decide, at its sole discretion, to incorporate into the PowerSync Premium Offering and provide to its customers from time to time.  
  
m. “**Premium PowerSync Features**” means optional PowerSync features that are not part of the PowerSync Core Offerings, or are otherwise designated by the Company as “Premium Features” from time to time.  
  
n. “**Professional Service**s” means (i) consulting services related to the use of PowerSync, and (ii) any other services agreed to between the Parties from time to time.  
  
o. “**Services**” means the PowerSync Premium Offering, Support and Professional Services.  
  
p. “**Support**” means the technical support for PowerSync provided to Customer’s Developer Users by Company, according to the service levels set forth in [Appendix C](#appendix-c-service-level-agreement).  
  
q. “**Third Party Offerings**” means services delivered or performed by third parties independently of the Services, or other online, web-based or other business application subscription services, and any associated products provided by third parties that interoperate with the Services.  
  
r. “**Update**” means one or more minor enhancements and bug fixes (patches) to PowerSync, made generally available to customers of the Company at no charge. Updates shall be deemed to be a part of PowerSync upon release.  
  
s. “**User**” means any user authorized by Customer to access and use PowerSync for the purpose of either (i) integrating software applications with PowerSync as a software developer (“**Developer User**”), or (ii) operating a software application as an end-user, where the applicable software application utilizes the PowerSync as an underlying technology.
  
t. “**Term**” has the meaning set forth in Section 7(a).  

###### **2\. GRANT OF RIGHTS AND RESTRICTIONS.**

a. **Grant of Rights.** Subject to and conditioned upon Customer’s and its Users’ compliance with the terms and conditions of this Agreement (including those in an applicable Order Form and any Acceptable Use Policy), Company hereby grants Customer a limited, non-exclusive, non-sublicensable, non-transferable, revocable right under each Order Form to access and use the PowerSync Premium Offering as specified in each applicable Order Form or otherwise by Company (including any limitations set forth by Company on the PowerSync website with respect to any free access to the PowerSync Premium Offering), only during the Term, in the form and through the means made available by Company under such Order Form. The Services are licensed and not sold even if for convenience Company refers to words such as sale or purchase. The PowerSync Core Offerings are separately available from Company under open-source or source-available licenses, however, the license granted by Company to Customer under this Agreement supersedes the terms of such licenses with respect to the PowerSync Premium Offering and other Services provided hereunder. Customer hereby grants Company and its service providers a royalty-free, non-exclusive license to use, process, store, transmit and reproduce Customer Data (including Usage Data) as necessary for Company to provide the Services to Customer and Users.  
  
b. **Restrictions.** Except as expressly permitted under this Agreement, Customer shall not itself, nor shall it permit any other party (including Users) to: (i) reproduce, modify, translate, adapt or create derivative works based upon the PowerSync Premium Offering; (ii) reverse engineer, decode, decompile, disassemble or otherwise attempt to access or derive the source code or architectural framework of any part of the PowerSync Premium Offering; (iii) access the PowerSync Premium Offering for purposes of benchmarking or developing, marketing, selling or distributing any product or service that competes with or includes features substantially similar to the PowerSync Premium Offering; (iv) use spiders, crawlers, robots, scrapers or other similar means to access the PowerSync Premium Offering, or otherwise substantially download, reproduce or archive any portion of the PowerSync Premium Offering; (v) rent, lease, lend, sell or sublicense the PowerSync Premium Offering, or otherwise provide access to the PowerSync Premium Offering to anyone who is not a User or as part of a service bureau or similar fee-for-service purpose; (vi) use the PowerSync Premium Offering to transmit code, files, scripts, agents or programs intended to do harm, including without limitation viruses, worms, time bombs and trojan horses; or (vii) access or use the PowerSync Premium Offering in any manner that does not comply with all applicable laws and regulations.  
  
c. **Changes.** Customer acknowledges and agrees that Company may improve, modify, add or remove functions or features to or from the PowerSync Premium Offering from time to time, with or without notice to Customer.  
  
d. **Third Party Offerings.** Company may make Third Party Offerings available to Customer for use in connection with the Services. Customer acknowledges and agrees that any use by Customer or any User of any Third Party Offerings may be subject to a separate agreement with such third party provider, which will govern Customer’s and each User’s use of such Third Party Offerings. Company makes no warranties of any kind and assumes no liability whatsoever for Customer’s or any User’s use of (or inability to use) Third Party Offerings, which are made available by Company “AS IS,” “AS AVAILABLE” and “WITH ALL FAULTS.”

###### **3\. PROFESSIONAL SERVICES AND SUPPORT.**

Subject to payment of the applicable fees and as set forth in applicable Order Forms, Company agrees to use commercially reasonable efforts to (i) provide the Professional Services, as further set forth and described on each applicable Order Form, and (ii) provide Support for PowerSync to Developer Users, as described in [Appendix C](#appendix-c-service-level-agreement). Professional Services shall not include the creation or development of any Intellectual Property for Customer by Company.

###### **4\. CUSTOMER OBLIGATIONS.**

a. **Technical Requirements.** Customer and End Users shall be solely responsible for obtaining, configuring and maintaining any hardware, network connectivity and third-party software required to access the Services, including computers, operating systems, web browsers and storage devices.  
  
b. **Integrations.** Customer acknowledges and agrees that enabling certain Integrations in the Services will require Customer to register and create accounts with various Third Party Offerings, or to link and enable such Integrations with existing Third Party Offerings with respect to which Customer may already have an account. Customer acknowledges and agrees that it shall remain solely responsible for its and its End Users’ conduct with respect to such Integrations and any credentials, authorizations, permissions, Customer Data, or other information or actions required or permitted in connection therewith.  
  
c. **Protection.** Customer shall be solely responsible for protecting the confidentiality of Credentials and all activities undertaken using Customer Facilities. In the event that Customer becomes aware of any unauthorized access to or use of the Services through use of Customer Facilities, Customer shall promptly give written notice to Company of such breach and make reasonable efforts to eliminate it. Customer shall at all times implement appropriate security policies and procedures and access control methodologies to safeguard access to and use of the Services through Customer Facilities. All such measures shall comply with prevailing industry standards but in no case consist of less than reasonable care.  
  
d. **Policies.** Customer must comply with and ensure its Users comply with all privacy policies, end user license agreement and other guidelines instituted by Company or its licensors or service providers, including without limitation, the Acceptable Use Policy (each, a “**Policy**”). In addition to this Agreement, the PowerSync Privacy Policy at [https://www.powersync.com/privacy-policy](https://powersync.com/legal/privacy-policy) (“**Privacy Policy**”) applies to how the Company may process information obtained as part of providing the Services. Customer acknowledges and agrees that by accessing or using the Services, Company may receive certain information about Customer and its Users, including personal data, as set forth in the Privacy Policy, and Company may collect, use, disclose, store, share, and process such personal data in accordance with such Privacy Policy.  
  
e. **Cooperation.** In connection with Company's provision of the Professional Services, Customer shall perform those tasks and fulfill those responsibilities as may be specified in this Agreement, an applicable Order Form and as reasonably requested from time to time by Company (“**Customer Responsibilities**”). Company's performance of the Professional Services is dependent upon Customer’s timely and effective performance of Customer Responsibilities and timely decisions and approvals by Customer. Company shall be entitled to rely on all decisions and approvals of Customer in connection with the Professional Services. Customer shall retain responsibility for its compliance with all applicable federal, state and local laws and regulations. Customer shall obtain all consents necessary from third parties required for Company to perform its obligations under this Agreement or in any Order Form issued hereunder.

###### **5\. FEES AND TAXES.**

a. **Fees.** Customer shall pay Company the applicable fees set forth in the Order Form pursuant to the payment terms therein. Customer shall provide Company with complete and accurate billing contact information including a valid email address. Company may invoice parts of an Order Form separately or all in one invoice.  
  
b. **Payment Terms and Third Party Providers.** All payments to Company are non-refundable except as otherwise expressly provided in the applicable Order Form. Customer hereby (i) acknowledges and agrees that Company uses or may use a third party payment provider in connection with its collection of fees, (ii) acknowledges and agrees that Company will not be responsible for any payments or charges as a result of Customer’s failure to provide up-to-date and accurate information to any such third party payment provider, and (iii) acknowledges and authorizes Company and its third-party payment processors to charge all fees to Customer’s chosen payment method.  
  
c. **Late Payments.** Any payment not received from Customer when due shall incur interest at the rate of one and a half percent (1.5%) per month or the maximum rate permitted by law, whichever is less.  
  
d. **Taxes.** Any and all amounts payable hereunder by Customer are exclusive of any value added, sales, use, excise or other similar taxes (collectively, “**Taxes**”). Customer shall be solely responsible for paying all applicable Taxes. If Company has the legal obligation to collect any Taxes, Customer shall reimburse Company upon invoice by Company. If Customer is required by law to withhold any taxes from its payments to Company, Customer shall provide Company with an official tax receipt or other appropriate documentation to support such payments and take reasonable steps to minimize such payments.  
  
e. **Subscriptions.** If Customer is accessing the Services pursuant to a monthly, annual or other subscription (each, a “**Subscription**”), Customer may cancel the Subscription at any time; however, except as otherwise set forth in an Order Form, any such cancellation prior to the end of the then-current Subscription Term does not relieve Customer of its obligation to pay all fees due for the entirety of that Subscription Term. Such cancellation will only serve to prevent the automatic renewal of the Subscription at the end of that Term. Unless otherwise set forth in an Order Form, Customer must cancel its Subscription prior to 11:59 p.m. UTC on the day before the end of the current Subscription Term in order to avoid being charged for the next Subscription Term. If Customer does not timely cancel the Subscription, the Subscription shall be automatically renewed at the price in effect at the time of renewal, or as otherwise set forth in an Order Form, without any additional action by Customer, and Customer authorizes Company to charge Customer’s payment method for such amounts. To cancel a Subscription, Customer may navigate to its account and follow the instructions provided therein, or reach out to Company at [support@powersync.com](mailto:support@powersync.com).

###### **6\. INTELLECTUAL PROPERTY.**

a. **Responsibility for Data.** All Data is the sole responsibility of the party from whom such materials originated. Customer acknowledges and agrees that: (i) the Services may provide access to or rely on Data from third parties (including without limitation, via Third Party Offerings), and such third parties, and Company, are entirely responsible for such Data (including without limitation, for the nature, quality and accuracy of such Data); (ii) Customer and Users, and not Company, are entirely responsible for all Customer Data (including without limitation, for the nature, quality and accuracy of such Customer Data); and (iii) Customer and Users are solely responsible for giving all required notices and obtaining all necessary consents (including all required permissions from Intellectual Property holders) before submitting Customer Data (if any) through or to the Services or Company. Company has no liability to Customer or any third party as a result of: (i) any unauthorized disclosure or access to Customer Facilities or Customer Data as a result of Customer’s or a User’s misuse of the Services or loss or theft of any Credentials; (ii) any deletion, destruction, damage or loss of Customer Data caused by or at the direction of Customer or a User; or (iii) Customer’s failure to maintain adequate security or virus controls in any devices used to access the Services.  
  
b. **Usage and Aggregated Data.** “**Aggregated Data**” means Customer Data that has been aggregated in a manner that does not reveal any personally identifiable information and cannot reasonably be used to identify Customer or any User as the source of such data. Customer hereby agrees that Company may collect or generate Aggregated Data in connection with providing Customer and Users with access to the Services.  
  
c. **Company Ownership.** Customer acknowledges and agrees that, as between Company and Customer, Company owns all right, title and interest (including all Intellectual Property) in and to PowerSync, Aggregated Data and the Services. Furthermore, Company owns the statistical usage data derived from the operation of PowerSync (“**Usage Data**”). Nothing herein will be construed as prohibiting Company from utilizing the Usage Data to optimize and improve the Services or otherwise operate Company's business. If Company provides Usage Data to third parties, such Usage Data shall be anonymized and presented in the aggregate so that it will not disclose the identity of Customer to any third party. Nothing in this Agreement or an Order Form shall be construed to transfer to Customer, any User or any other person any ownership interest in any of the foregoing. Company reserves all rights to the foregoing that are not specifically granted to Customer in this Agreement.  
  
d. **Customer Ownership.** Company acknowledges and agrees that, as between Customer and Company, Customer owns all right, title and interest (including all Intellectual Property) in and to Customer Data and any results therefrom.  
  
e. **Feedback.** In addition to any contributions made pursuant to any contributor license agreements applicable to any contributions by Customer or Users with respect to any PowerSync Core Offerings, if Customer or Users elect to provide or make available to Company any suggestions, comments, opinions, code, input, ideas, reports, information, know-how or other feedback (whether in oral, electronic or written form) related to PowerSync or the Services (“**Feedback**”), Customer hereby assigns, at no charge, all rights, title and interests in Feedback to Company, and agrees that Company is free to use, reproduce, modify, adapt, create derivative works from, publicly perform, publicly display, distribute, make, have made, assign, pledge, transfer or otherwise grant rights in the Feedback in any form and any medium (whether now known or later developed), without credit or compensation to Customer. Customer warrants that the Feedback does not infringe any copyright or trade secret of any third party, and that Customer has no knowledge of any patent of any third party that may be infringed by the Feedback (including any implementation thereof recommended by Customer). Customer further warrants that its Feedback is not subject to any license terms that would purport to require Company to comply with any additional obligations with respect to any Services that incorporates Customer’s Feedback.  
  
f. **Intellectual Property Notices.** Customer shall not remove, obscure or modify in any way any copyright or trademark notices or other notices or disclaimers that appear within the Services.  
  
g. **Reservation of Rights.** Each of the Parties reserves all rights not expressly granted under this Agreement.

###### **7\. TERM, SUSPENSION AND TERMINATION.**

a. **Term.** The term for this Agreement shall commence on the Effective Date and continue in effect until the conclusion of all Order Forms (the “**Term**”); _provided, however,_ that all Subscriptions shall automatically renew for successive terms, unless otherwise set forth in an applicable Order Form.  
  
b. **Suspension.** Company reserves the right to suspend Customer or any User’s access to the Services in the event of an Unauthorized Usage Issue. Company will make commercially reasonable efforts to limit suspension to the minimum extent and duration necessary to eliminate the Unauthorized Usage Issue. Company further reserves the right to suspend or revoke access to the Services by any User who violates any Policy.  
  
c. **Termination.** Notwithstanding anything to the contrary, either Party may terminate this Agreement or any Order Form, as applicable: (i) upon the terms set forth in the applicable Order Form; (ii) unless otherwise set forth in an Order Form, at any time upon written notice to the other Party solely with respect to any Subscription and subject to Section 5(e); (iii) upon written notice to the other Party of a material breach of this Agreement or any Order Form, as applicable, by the other Party, which breach the other Party does not cure within thirty (30) days after receipt of written notice of the breach; provided that, where the breach affects only a particular Order Form, termination will be limited to that Order Form; or (iv) in the event the other Party becomes insolvent or bankrupt; becomes the subject of any proceedings under bankruptcy, insolvency or debtor’s relief law; has a receiver or manager appointed; makes an assignment for the benefit of creditors; or takes the benefit of any applicable law or statute in force for the winding up or liquidation of such Party’s business. Notwithstanding the termination of this Agreement or any Order Form for any reason, neither Party will be relieved of any duty, obligation, debt or liability that arose or accrued prior to the effective date of termination.  
  
d. **Events upon Termination of Order Form.** Upon termination of an Order Form for any reason: (i) all rights granted by the Parties under such Order Form shall immediately terminate; (ii) Customer shall immediately cease all use of the Services made available under such Order Form; and (iii) each Party shall immediately cease all use of the other party’s Confidential Information made available under such Order Form and return or destroy all copies of such Confidential Information that are within its custody or control.  
  
e. **Events upon Termination of Agreement.** Upon termination of this Agreement for any reason: (i) all rights granted by the Parties under this Agreement shall immediately terminate; (ii) Customer shall immediately cease all use of all Services; and (iii) each Party shall immediately cease all use of the other Party’s Confidential Information and return or destroy all copies of such Confidential Information that are within its custody or control.  
  
f. **Survival.** Any provision that, by its terms, is intended to survive the expiration or termination of this Agreement shall survive such expiration or termination, including Sections: 1 (Definitions); 5(c) (Late Payments); 5(e) (Subscriptions); 6 (Intellectual Property); 7(e) (Events Upon Termination of Agreement); 7(f) (Survival); 9 (Indemnification); 10 (Confidential Information); 11 (Disclaimers); 12 (Limitation of Liability); and 13 (General).

###### **8\. REPRESENTATIONS AND WARRANTIES.**

Company and Customer each represents and warrants to the other that: (a) it has the necessary power and authority to enter into this Agreement; (b) the execution and performance of this Agreement have been authorized by all necessary corporate or institutional action; (c) entry into and performance of this Agreement will not conflict with any provision of law or the certificate of incorporation, bylaws or comparable organizational documents of such Party; (d) no action by any governmental organization is necessary to make this Agreement valid and binding upon such Party; and (e) it possesses all governmental licenses and approvals necessary to perform its obligations under this Agreement. Customer further represents and warrants to Company that it will comply with all applicable foreign, federal, state, and local laws, rules and regulations, including without limitation, U.S. export laws and import and use laws of the country where the Services are delivered or used and Customer is not: (a) located in a country that is subject to a U.S. Government embargo, or designated by the U.S. Government as a “terrorist supporting” country; and (b) listed on any U.S. Government list of prohibited or restricted parties, including the Specially Designated Nationals List.

###### **9\. INDEMNIFICATION.**

a. **Company Indemnification.** Company agrees that Customer shall have no liability and Company shall indemnify, defend and hold Customer harmless against any loss, damage, cost, liability and expense (including reasonable attorneys’ fees) finally awarded by a court of competent jurisdiction or paid in settlement to the extent arising from any action or claim of a third party (collectively, “**Claim**”) asserting that Customer or Users’ use of the Services infringes the Intellectual Property of such third party; _provided, however,_ that Company shall have no obligation to indemnify Customer from any Claim to the extent it arises from: (i) use of the Services by or on behalf of Customer in any manner that does not comply with the terms and conditions of this Agreement or applicable laws or regulations; (ii) use of the Services by or on behalf of Customer in combination with any hardware or software not provided or approved by Company; (iii) modifications to the Services made by or on behalf of Customer that are not authorized by Company; or (iv) any Customer Data (the foregoing subsections (i) through (iv), collectively, “**Customer Acts**”). In the event that any part of the Services becomes the subject of a Claim or Company reasonably determines that any part of the Services is likely to become the subject of a Claim, Company may, at its sole discretion: (A) procure for Customer a license as necessary for Customer to exercise the rights granted by Company under this Agreement; (B) modify or replace the infringing portion of the Services to avoid infringement; or (C) terminate the applicable Order Form and provide a pro rata refund of the fees paid by Customer to Company for the unused portion of the Term, as applicable, under such Order Form. THE FOREGOING STATES THE ENTIRE LIABILITY AND OBLIGATIONS OF COMPANY, AND THE EXCLUSIVE REMEDY OF CUSTOMER, WITH RESPECT TO ANY ACTUAL OR ALLEGED INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS UNDER THIS AGREEMENT.  
  
b. **Customer Indemnification.** Customer agrees that Company shall have no liability and Customer shall indemnify, defend and hold Company harmless against any Claim to the extent arising from: (i) Customer Acts or Customer’s breach of confidentiality; (ii) any violation of applicable laws or regulations by Customer or Users; (iii) any breach by Customer or Users of this Agreement or any agreement governing use of Third Party Offerings; and (iv) any use by Customer or Users of Customer Data, except as permitted by this Agreement or otherwise and as separate from Customer’s or Users’ use of or access to the Services.  
  
c. **Procedure.** The indemnified Party shall: (i) give the indemnifying Party prompt written notice of any Claim; _provided, however,_ that failure of the indemnified Party to give such prompt written notice shall not relieve the indemnifying Party of any obligation to indemnify pursuant to this Section, except to the extent the indemnifying Party has been prejudiced thereby; (ii) cooperate fully with the indemnifying Party, at the indemnifying Party’s expense, in the defense or settlement of any Claim; and (iii) give the indemnifying Party sole and complete control over the defense or settlement of any Claim; _provided, however,_ that any settlement must include a complete release of the indemnified Party without requiring the indemnified Party to make any payment or bear any obligation.

###### **10\. CONFIDENTIAL INFORMATION.**

a. **Definition.** “**Confidential Information**” means information identified in good faith by either Party as being confidential or proprietary, or information that, given its nature or the circumstances of its disclosure, should reasonably be understood to be confidential or proprietary. Confidential Information shall include, with respect to Company, the terms and conditions of any applicable Order Forms, any container images (including without limitation, Docker images) relating to the Premium PowerSync Offering provided by Company, the source code (if any), Usage Data, Aggregated Data and architectural framework relating to the Premium PowerSync Offering, and, with respect to either Party, any pricing information and business plans provided by either Party.  
  
b. **Non-Disclosure.** Each Party may use the Confidential Information provided by the other Party only as necessary to exercise its rights and discharge its obligations under this Agreement and for no other purpose without the prior written consent of the disclosing Party. Neither Party may disclose to a third party Confidential Information of the other Party. The receiving Party shall protect Confidential Information of the disclosing Party using the same degree of care it uses to protect the confidentiality of its own Confidential Information of like nature, but no less than reasonable care. The foregoing obligations shall not apply to any Confidential Information that: (i) is known or becomes known to the public in general, other than as a result of a breach of this Agreement by the receiving Party; (ii) was known by or in the lawful possession of the receiving Party prior to receipt from the disclosing Party; (iii) is or has been independently developed by the receiving Party without use of or reference to Confidential Information of the disclosing Party; (iv) is or has been made known or disclosed to the receiving Party by a third party without a breach of any obligation of confidentiality to the disclosing Party; or (v) is required to be disclosed by law; _provided, however,_ that the receiving Party shall take reasonable actions to minimize such disclosure and promptly notify the disclosing Party, to the extent permitted by law, so that the disclosing Party may take lawful actions to avoid or minimize such disclosure. Notwithstanding anything to the contrary, Company shall be permitted to identify Customer as a Company customer.

###### **11\. DISCLAIMERS.**

a. **Disclaimer of Warranties.** EXCEPT AS EXPLICITLY SET FORTH IN [APPENDIX C](#appendix-c-service-level-agreement), ALL SERVICES PROVIDED UNDER THIS AGREEMENT ARE PROVIDED “AS IS,” “AS AVAILABLE” AND “WITH ALL FAULTS.” COMPANY, TO THE MAXIMUM EXTENT PERMITTED BY LAW, EXPRESSLY DISCLAIMS ALL WARRANTIES AND REPRESENTATIONS (EXCEPT AS SET FORTH IN SECTION 8), EXPRESS OR IMPLIED, INCLUDING: (A) THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE; AND (B) ANY WARRANTY WITH RESPECT TO THE QUALITY, ACCURACY, COMPLETENESS OF THE SERVICES PROVIDED UNDER THIS AGREEMENT, OR THAT USE OF SUCH SERVICES WILL BE ERROR-FREE, UNINTERRUPTED, FREE FROM OTHER FAILURES OR WILL MEET CUSTOMER OR USERS’ REQUIREMENTS.  
  
b. **No Advice or Endorsement.** Customer hereby acknowledges, understands and agrees that: (i) any content or information provided on the Services are for informational purposes only; (ii) such content and information are not intended to be, and Customer and Users should not construe such content and information as, technical or other advice; (iii) Customer alone assumes the sole responsibility of evaluating the merits and risks associated with the use of or reference to any content and information provided on the Services before making any decisions based on such content and information; (vi) Company shall not be held responsible or liable for any possible claim for damages arising from any decision Customer or its Users make based on content or information made available to Customer and/or Users.

###### **12\. LIMITATION OF LIABILITY.**

OTHER THAN WITH RESPECT TO A PARTY’S GROSS NEGLIGENCE, WILLFUL MISCONDUCT, BREACH OF ANY POLICY, INDEMNIFICATION OBLIGATIONS, OR BREACH OF CONFIDENTIALITY OBLIGATIONS: (A) IN NO EVENT SHALL EITHER PARTY BE LIABLE TO THE OTHER PARTY FOR ANY LOST PROFITS OR COST OF COVER, OR INCIDENTAL, INDIRECT, SPECIAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, INCLUDING DAMAGES ARISING FROM ANY TYPE OR MANNER OF COMMERCIAL, BUSINESS OR FINANCIAL LOSS OCCASIONED BY OR RESULTING FROM ANY USE OF OR INABILITY TO USE SERVICES PROVIDED UNDER THIS AGREEMENT, SUCH AS ANY MALFUNCTION, DEFECT OR FAILURE OF THE SERVICES OR ITS DELIVERY VIA THE INTERNET, EVEN IF SUCH PARTY HAD ACTUAL OR CONSTRUCTIVE KNOWLEDGE OF THE POSSIBILITY OF SUCH DAMAGES AND REGARDLESS OF WHETHER SUCH DAMAGES WERE FORESEEABLE; AND (B) SUBJECT TO CUSTOMER’S OBLIGATION TO PAY ALL FEES DUE UNDER THIS AGREEMENT, IN NO EVENT SHALL EITHER PARTY’S AGGREGATE LIABILITY UNDER THIS AGREEMENT EXCEED THE GREATER OF (I) THE AMOUNT OF FEES RECEIVED BY COMPANY FROM CUSTOMER UNDER THIS AGREEMENT IN THE 12-MONTH PERIOD IMMEDIATELY PRECEDING THE DATE ON WHICH THE EVENTS GIVING RISE TO LIABILITY AROSE, OR (II) TWO HUNDRED DOLLARS ($200).

###### **13\. GENERAL.**

a. **Independent Contractors.** The relationship between Company and Customer established by this Agreement is solely that of independent contractors. Neither Party is in any way the partner or agent of the other, nor is either Party authorized or empowered to create or assume any obligation of any kind, implied or expressed, on behalf of the other Party, without the express prior written consent of such other Party.  
  
b. **Notice.** All notices, demands and other communications (“**Notices**”) to be given or delivered under or by reason of the provisions of this Agreement shall be in writing and sent to the Parties according to the contact information provided below, or such other contact information as either Party shall notify the other in accordance with this Section:  
  
**To Company**  
Attn: Legal Department: Journey Mobile, Inc.
3700 Quebec St, Ste 100 PMB 132, Denver, Colorado, 80207, USA  
  
**To Customer**  
As set forth in the most-recent Order Form  
  
c. **Assignment.** Customer may not assign this Agreement, or sublicense, assign or delegate any right or obligation hereunder, by operation of law or otherwise without the prior written consent of the Company. This Agreement shall be binding upon and inure to the benefit of the Parties hereto and their respective successors and permitted assigns.  
  
d. **Interpretation.** For the purposes of this Agreement: (i) the words “such as,” “include,” “includes” and “including” shall be deemed to be followed by the words “without limitation;” (ii) the word “or” is not exclusive; and (iii) the words “herein,” “hereof,” “hereby,” “hereto” and “hereunder” refer to this Agreement as a whole. This Agreement shall be construed without regard to any presumption or rule requiring construction or interpretation against the Party drafting an instrument or causing any instrument to be drafted.  
  
e. **Entire Agreement.** This Agreement contains the entire agreement of the Parties with respect to the subject matter hereof and supersedes all previous or contemporaneous oral or written negotiations or agreements with respect to such subject matter. In the event of any conflict among this Agreement, an Order Form, and any Policy, the terms and conditions of each shall take precedence in the following order: this Agreement, an Order Form, and any Policy.  
  
f. **Amendment.** This Agreement may not be amended except in a writing executed by an authorized representative of each Party.  
  
g. **Severability.** If any provision of this Agreement shall be held to be invalid or unenforceable under applicable law, then such provision shall be construed, limited, modified or, if necessary, severed to the extent necessary to eliminate its invalidity or unenforceability, without in any way affecting the remaining parts of this Agreement.  
  
h. **Governing Law.** This Agreement shall be governed by and construed and enforced in accordance with the laws of the United States of America and the State of Delaware, without regard to conflict of laws principles. The United Nations Convention on Contracts for the International Sale of Goods is specifically excluded from application to this Agreement.  
  
i. **Jurisdiction.** This Agreement shall be deemed to have been concluded in, and shall be construed pursuant to the laws of, the State of Delaware and the United States without regard to conflict of laws provisions thereof. This Agreement will not be governed by the United Nations Convention of Contracts for the International Sale of Goods, the application of which is expressly excluded. Any controversy or claim arising out of or relating to this Agreement, or the breach thereof, will be fully and finally settled by binding arbitration in accordance with the JAMS Streamlined Arbitration Rules and Procedures of the JAMS/Endispute or any successor entity. The arbitration will be held in Denver County, Colorado.  
  
j. **No Waiver.** The failure of either Party to require strict performance by the other Party of any provision hereof shall not affect the full right to require such performance at any time thereafter, nor shall the waiver by either Party of a breach of any provision hereof be taken or held to be a waiver of the provision itself. Any waiver of the provisions of this Agreement, or of any breach or default hereunder, must be set forth in a written instrument signed by the Party against which such waiver is to be enforced.  
  
k. **Force Majeure.** Neither Party shall be liable for any failure to perform under this Agreement to the extent due to any act of God, fire, casualty, flood, war, strike, lock out, failure of public utilities, injunction or any act, exercise, assertion or requirement of any governmental authority, epidemic, destruction of production facilities, insurrection or any other cause beyond the reasonable control of the Party invoking this provision.  
  
l. **U.S. Government Entities.** This Section applies to access to or use of the Services by a branch or agency of the United States Government. The Services includes “commercial computer software” and “commercial computer software documentation” as such terms are used in 48 C.F.R. 12.212 and qualifies as “commercial items” as defined in 48 C.F.R. 2.101. Such items are provided to the United States Government: (a) for acquisition by or on behalf of civilian agencies, consistent with the policy set forth in 48 C.F.R. 12.212; or (b) for acquisition by or on behalf of units of the Department of Defense, consistent with the policies set forth in 48 C.F.R. 227.7202-1 and 227.7202-3. The United States Government shall acquire only those rights set forth in these Terms with respect to the such items, and any access to or use of the Services by the United States Government constitutes: (i) agreement by the United States Government that that such items are “commercial computer software” and “commercial computer software documentation” as defined in this section; and (ii) acceptance of the rights and obligations herein.

### **APPENDIX A: Self-Hosting Terms**

**_(Only applicable if such deployment is indicated in an applicable Order Form)_**

The following provisions apply when PowerSync is run on machines (“**Instances**”) and persistent storage devices (“**Persistent Storage**”) (Instances and Persistent Storage are jointly referred to as “**Resources**”), under Customer’s own private cloud accounts or servers, or otherwise on Customer’s Facilities (the “**Customer’s Environment**”). In the event of any conflict between this Appendix A and the main body of this Agreement, this Appendix A shall control.

###### **A1. LICENSE.**

Subject to and conditioned upon Customer’s and its Users’ compliance with the terms and conditions of this Agreement (including those in an applicable Order Form and any Acceptable Use Policy), Company hereby grants Customer a limited, non-exclusive, non-sublicensable, non-transferable, revocable right under each Order Form to download, deploy, install and host the PowerSync Premium Offering from within Customer’s Environment during the Term. All other terms concerning the Services shall apply. Customer acknowledges and agrees: (a) PowerSync may not work on all Resources or within Customer’s Environment now or in the future; (b) that Company does not provide support for Customer’s Environment (except pursuant to the Professional Services, as applicable) and Company shall have no liability to Customer for any damage caused to Customer’s Environment resulting from Customer’s election run PowerSync in Customer’s Environment; and (c) Company is not liable or responsible for the interoperability of PowerSync with Customer’s Environment.

###### **A2. USAGE AND AGGREGATED DATA.**

If Customer has elected to run PowerSync on the Customer’s Environment, Customer may elect to opt out of sharing Usage Data and allowing Company to collect or generate Aggregated Data by indicating such election to Company in accordance with Company's written instructions.

###### **A3. CUSTOMER OBLIGATIONS.**

Customer shall: (a) promptly download, install, implement or otherwise configure all Updates and non-minor enhancements to PowerSync consisting of new features, functionality and/or technology, each as provided, made available or otherwise instructed by Company (collectively, “**Upgrades**”); (b) be responsible for installing and maintaining any and all operating systems, applications, and other components necessary for the functionality, maintenance and operability of Customer’s Environment; (c) be responsible for all maintenance, security, backup and disaster recovery in connection with Customer’s Environment; and (d) be responsible for securing all necessary ownership and/or access rights to all of Customer’s Environment and for all costs and expenses in connection therewith. Customer agrees that Upgrades shall be deemed to be a part of PowerSync or the PowerSync Premium Offering, as confirmed by Company in Company's sole discretion, upon release. Customer further agrees that the foregoing obligations shall be deemed to be Customer Responsibilities under this Agreement.

###### **A4. DELIVERY.**

Company shall deliver to Customer an authentication key to download an authorized copy of the container image for the PowerSync Premium Offering. Customer agrees that it shall have responsibility for using authorized copies of the PowerSync Premium Offering only to the extent permitted by this Agreement and any applicable Order Forms. Customer further agrees that the foregoing obligations shall be deemed to be Customer Responsibilities under this Agreement.

###### **A5. ARCHIVAL AND BACKUP COPIES.**

Subject to the restrictions set forth in this Agreement, for the duration of the Term, Customer may make back-up copies of the authorized copy of the PowerSync Premium Offering as reasonably required for archival and disaster recovery purposes.

### **APPENDIX B: PowerSync Cloud Terms**

**_(Only applicable if such deployment is indicated in an applicable Order Form)_**

The following provisions apply when the Customer has purchased access to **PowerSync Cloud**. In the event of any conflict between this Appendix B and the main body of this Agreement, this Appendix B shall control.

###### **B1. UNAUTHORIZED USAGE ISSUES.**

With respect to any Customer to whom this Appendix B applies, the definition of “Unauthorized Usage Issue” shall, in addition to the definition set forth in Section 1.g of this Agreement, also include any: (i) use of the Services by Customer or Users that disrupts or is reasonably likely to disrupt the availability of the Services to other users; and (ii) access to the Services by any unauthorized third party through use of any Customer Facilities.

###### **B2. RESTRICTIONS.**

In addition to the restrictions set forth in Section 2.a of this Agreement, Customer shall not itself, nor shall it permit any other party (including Users) to take any action that imposes an unreasonable or disproportionately heavy load on the PowerSync Premium Offering or related infrastructure or that negatively affects the ability of others to access or use the PowerSync Premium Offering.

###### **B3. DATA SUB-PROCESSING AND TRANSFER.**

Customer authorizes Company to use one or more internationally-recognized and reputable cloud storage and processing providers, including Amazon Web Services, Inc. (each a “**Sub-Processor**”) to store and process Customer Data on its behalf for the sole purpose of providing the Hosted Services to Customer. If Customer is subject to the California Consumer Privacy Act, the European Union’s General Data Protection Regulation (GDPR) (EU) 2016/679 or another applicable data privacy law which requires Customer and Company to enter into separate data processing terms, Customer must request such data processing terms from Company in writing. Customer agrees that Company shall have no liability and Customer shall indemnify, defend and hold Company harmless against any Claim to the extent arising from Customer’s failure to make such request.

### **APPENDIX C: Service Level Agreement**

###### **C1. SUPPORT.** 

C1.1. **Support Service Levels.** Company will use commercially reasonable efforts to ensure that Support is provided to Customer as part of the Services in accordance with the Service Levels defined in the table below. The Service Level applicable to Customer will be indicated on the relevant Order Form or otherwise indicated by Company to Customer.

| **Service Level** | **Free** | **Pro** | **Team** | **Enterprise** |
| --- | --- | --- | --- | --- |
| **Email-Based Support Case Management**, as defined in Section C1.2 | Not Available | Available | Available | Available |
| **Assigned Forward-Deployed Engineer**, as defined in Section C1.3 | Not Available | Not Available | Not Available | Available |
| **Support Case Response Time Guarantee.** Company will respond to Support Cases reported by Customer (as per Email-Based Support Case Management) within the time period indicated, based on the Severity Levels defined in Section C1.4 | No Guarantee | No Guarantee | Severity Level 1 Support Cases: Within 4 hours. Severity Level 2 Support Cases: Within 8 hours. Severity Level 3 Support Cases: Within 2 U.S. Business Days. Severity Level 4 Support Case: No Guarantee. | Severity Level 1 Support Cases: Within 2 hours. Severity Level 2 Support Cases: Within 4 hours. Severity Level 3 Support Cases: Within 8 U.S. Business Hours. Severity Level 4 Support Case: Within 1 U.S. Business Day. |
| **Security Reports. **Availability of Security Reports as defined in Section C1.5 | Not Available | Not Available | Available | Available |

For purposes of this Appendix C: (i) “**Business Hours**” means the eight (8) hour period between 9 a.m. and 5 p.m. Central Time, Monday through Friday; (ii) “**Business Day**” means Monday through Friday and excluding United States federal holidays; and (iii) “**Support Case**” means an inquiry or incident reported by Customer in accordance with the process set forth in C1.2.

C1.2. **Email-Based Support Case Management.** Customers must report Support Cases by electronic mail to [support@powersync.com](mailto:support@powersync.com), or through other approved methods communicated by Company to Customer from time to time. Customer’s Developer Users are required to carefully document the support issue or incident and answer all of Company's questions so Company can efficiently serve the Customer’s Developer User(s). Company, in its sole discretion, has the right to approve or reject whether a Support Case is a valid request for support.  
  
C1.3. **Assigned Forward-Deployed Engineer**. Customer will be provided with access to assigned Company staff for advice on questions relating to Customer’s use of PowerSync and the Services.  
  
C1.4. **Severity Levels**. Each Support Case reported to Company by Customer will be assigned a Severity Level by Company, in its sole discretion. Severity Levels are defined as follows:

| **Severity Level** | **Description** |
| --- | --- |
| **1** | **Critical.** Major production issue severely affecting all Users. |
| **2** | **High.** Persistent issue affecting many production Users; Major functionality is impacted; Significant performance degradation; Data integrity issues. |
| **3** | **Medium.** Performance issue affecting some but not all Users. |
| **4** | **Low.** Inquiries about routine technical issues; Information requests on PowerSync capabilities, installation or configuration. |

C1.5. **Security Report.** Company will maintain a security report in connection with PowerSync and the Services, describing security measures in use in PowerSync (“**Security Report**”). Subject to mutually agreed-upon usage terms at the time of written request by the Customer, Company may, in its reasonable discretion, provide Customer with the then-current Security Report for PowerSync and the Services. During the term of the Agreement, Company will maintain such security measures identified in the then current Security Report or, if Company determines that more effective measures should be implemented, apply such replacement security measures.  

###### **C2. POWERSYNC CLOUD.**

**_(Only applicable if PowerSync Cloud deployment is indicated in an applicable Order Form)_**

C2.1. **Availability & Unavailability**. The PowerSync Cloud shall be deemed to be “**Unavailable**” if Customer’s reasonably up-to-date hardware, software, operating systems and network connections are functioning properly, but Customer Users cannot achieve access to the PowerSync Cloud. Unavailability shall not be deemed to occur as a result of Company scheduled maintenance activities; acts of omission by Customer, failure of Customer hardware or software or network connection, vicious attacks such as hacks, denial of service attacks and malicious introduction of viruses and disabling devices, or events beyond Company's reasonable control, including Unavailability due to third party service provider and data center issues, network connectivity and/or device hardware failure.  
  
C2.2. **Availability Service Levels.** Company will use commercially reasonable efforts to ensure the Availability of the PowerSync Cloud to Customer as part of the Services in accordance with the Service Levels defined in the table below. The Service Level applicable to Customer will be indicated on the relevant Order Form or otherwise indicated by Company to Customer.  

| **Service Level** | **Free** | **Pro** | **Team** | **Enterprise** |
| --- | --- | --- | --- | --- |
| **PowerSync Cloud Availability. **Availability measured as a percentage of time in each calendar month. | No Guarantee | No Guarantee | 99.9% | 99.95% |

C2.3. **Credits.** Credit to Customer’s account shall be Customer’s sole and exclusive remedy for Unavailability in respect of the PowerSync Cloud. Credits shall be calculated as the daily equivalent of the subscription Fee in the applicable Order Form, applied for each 24-hour period of Unavailability and any portion of such a 24-hour period. Credits shall be suspended if Customer is in payment default. Credits shall not be provided to Customer in the event that Customer experiences Unavailability resulting from (i) scheduled maintenance, (ii) Customer’s misuse of the Services or the performance or failure of Customer’s equipment, facilities or applications, (iii) Customer’s (or its Users’) violation of an Order Form or the Acceptable Use Policy or (iv) circumstances beyond Company's reasonable control, including, without limitation, acts of any governmental body, war, insurrection, terrorism, sabotage, embargo, fire, flood, earthquake or other acts of God, strike or other labor disturbance, interruption of or delay in transportation, unavailability or interruption or delay in telecommunications or third party services (including DNS propagation), failure of third party software or hardware or inability to obtain raw materials, supplies, or power used in or equipment needed for provision of an application.  
  
C2.4. **Support Service Levels.** With respect to customers who have purchased access to PowerSync Cloud, the following Support Service Levels will apply, in addition to the Support Service Levels in Section C1.1 of this Appendix C. The Service Level applicable to Customer will be indicated on the relevant Order Form or otherwise indicated in writing by Company to Customer.  

| **Service Level** | **Free** | **Pro** | **Team** | **Enterprise** |
| --- | --- | --- | --- | --- |
| **Support Case Resolution Time Guarantee. **Company will resolve Support Cases reported by Customer (as per Email-Based Support Case Management) within the time period indicated, based on the Severity Levels defined in Section C1.4 | No Guarantee | No Guarantee | No Guarantee | Severity Level 1 Support Cases: Within 24 hours. Severity Level 2 Support Cases: Within 72 hours. Severity Level 3 & 4 Support Cases: No Guarantee. |

C2.5. **Security Testing.** Customer may perform security testing with respect to PowerSync Cloud, but only with Company's prior written consent, not to be unreasonably withheld.  
  
C2.6. **Logical Segregation of Customer Data.** Customer Data residing in PowerSync Cloud (if any) will be logically separated from the Data of other customers of the Company.  
  
C2.7. **Chronic Outages.** If Company determines in its reasonable discretion that Customer is experiencing chronic outages, then Company may, in its discretion and at its expense, investigate the nature of the recurring problem. Within ten (10) Business Days of the conclusion of Company's investigation, Company and Customer technical representatives will discuss the results of the investigation. If Company, in its reasonable discretion, determines that Customer’s equipment, network or infrastructure requires upgrades or additions to prevent chronic outages, then Customer shall not be eligible for future credits if Customer does not repair, upgrade or otherwise make required changes.  

###### **C3. LIMITED WARRANTY.**

C3.1. Company warrants that the Premium PowerSync Features and Support, as applicable, will conform substantially in accordance to the Service Levels set forth in this Appendix C. The foregoing warranty is only for the benefit of Customer, and will only apply if (i) the Premium PowerSync Features have been used at all times in accordance with the terms of the Agreement, the Acceptable Use Policy and other Policies for use provided by Company; and (ii) no modification, alteration or addition has been made to PowerSync by persons other than Company or Company's authorized representatives.  
  
C3.2. Company does not warrant the results obtained through use of the Services. Additionally, Company is not responsible for problems caused by changes in, or modifications to, the operating characteristics of any computer hardware or operating system of Customer, a User or any third party, nor is Company responsible for problems that occur as a result of the use of the Services in conjunction with software of third parties or with hardware that is incompatible with the operating systems, computer hardware, software frameworks, user devices, or web browsers (if applicable) with which the Services are intended to be used.  
  
C3.3. As Company's entire liability and Customer’s exclusive remedy for the breach of the foregoing warranty, Company shall, at its sole option, use reasonable efforts to repair or replace the nonconforming elements of the Premium PowerSync Features. If neither of the foregoing options is commercially practical, Company will terminate the Agreement and provide a pro-rata refund to Customer for periods following the date of termination.  
  
C3.4. In addition to the Support information and terms included in this Service Level Agreement, Company may provide Customer and Developer Users with additional guidance and materials in order to ensure the optimal functioning of PowerSync and the Services. Where a conflict exists between the support levels specified in this SLA and any additional guidance and materials provided to Customer and its Developer Users, the terms of this SLA shall prevail.

---

# Community code of conduct

> Community code of conduct — PowerSync

- Source: https://powersync.com/legal/community-code-of-conduct

---

##### Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.  
  
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

##### Our Standards

Examples of behavior that contributes to a positive environment for our community include:  

-   Demonstrating empathy and kindness toward other people
-   Being respectful of differing opinions, viewpoints, and experiences
-   Giving and gracefully accepting constructive feedback
-   Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
-   Focusing on what is best not just for us as individuals, but for the overall community

  
Examples of unacceptable behavior include:

-   The use of sexualized language or imagery, and sexual attention or advances of any kind
-   Trolling, insulting or derogatory comments, and personal or political attacks
-   Public or private harassment
-   Publishing others' private information, such as a physical or email address, without their explicit permission
-   Other conduct which could reasonably be considered inappropriate in a professional setting

##### Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.  
  
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate

##### Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

##### Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [report-abuse@powersync.com](mailto:report-abuse@powersync.com). All complaints will be reviewed and investigated promptly and fairly.  
  
All community leaders are obligated to respect the privacy and security of the reporter of any incident.

##### Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

###### 1\. Correction

**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.  
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

###### 2\. Warning

**Community Impact**: A violation through a single incident or series of actions.  
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

###### 3\. Temporary Ban

**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.  
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

###### 4\. Permanent Ban

**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.  
**Consequence**: A permanent ban from any sort of public interaction within the community.

##### Attribution

This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 2.0, available at [https://www.contributor-covenant.org/version/2/0/code\_of\_conduct.html](https://www.contributor-covenant.org/version/2/0/code_of_conduct.html).  
  
Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).  
  
For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are available at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations).

---

# Functional Source License

> Functional Source License — PowerSync

- Source: https://powersync.com/legal/fsl

---

###### **Abbreviation**

FSL-1.1-ALv2

###### **Notice**

Copyright 2023-2026 Journey Mobile, Inc.

### **Terms and Conditions**

###### **Licensor ("We")**

The party offering the Software under these Terms and Conditions.

###### **The Software**

The "Software" is each version of the software that we make available under these Terms and Conditions, as indicated by our inclusion of these Terms and Conditions with the Software.

###### **License Grant**

Subject to your compliance with this License Grant and the Patents, Redistribution and Trademark clauses below, we hereby grant you the right to use, copy, modify, create derivative works, publicly perform, publicly display and redistribute the Software for any Permitted Purpose identified below.

###### **Permitted Purpose**

A Permitted Purpose is any purpose other than a Competing Use. A Competing Use means making the Software available to others in a commercial product or service that:

1.  substitutes for the Software;
2.  substitutes for any other product or service we offer using the Software that exists as of the date we make the Software available; or
3.  offers the same or substantially similar functionality as the Software.

Permitted Purposes specifically include using the Software:

1.  for your internal use and access;
2.  for non-commercial education;
3.  for non-commercial research; and
4.  in connection with professional services that you provide to a licensee using the Software in accordance with these Terms and Conditions.

###### **Patents**

To the extent your use for a Permitted Purpose would necessarily infringe our patents, the license grant above includes a license under our patents. If you make a claim against any party that the Software infringes or contributes to the infringement of any patent, then your patent license to the Software ends immediately.

###### **Redistribution**

The Terms and Conditions apply to all copies, modifications and derivatives of the Software.  
  
If you redistribute any copies, modifications or derivatives of the Software, you must include a copy of or a link to these Terms and Conditions and not remove any copyright notices provided in or with the Software.

###### **Disclaimer**

THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, TITLE OR NON-INFRINGEMENT.  
  
IN NO EVENT WILL WE HAVE ANY LIABILITY TO YOU ARISING OUT OF OR RELATED TO THE SOFTWARE, INCLUDING INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF WE HAVE BEEN INFORMED OF THEIR POSSIBILITY IN ADVANCE.

###### **Trademarks**

Except for displaying the License Details and identifying us as the origin of the Software, you have no right under these Terms and Conditions to use our trademarks, trade names, service marks or product names.

### **Grant of Future License**

We hereby irrevocably grant you an additional license to use the Software under the Apache License, Version 2.0 that is effective on the second anniversary of the date we make the Software available. On or after that date, you may use the Software under the Apache License, Version 2.0, in which case the following will apply:  
  
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.  
  
You may obtain a copy of the License at  
  
[http://www.apache.org/licenses/LICENSE-2.0  
](http://www.apache.org/licenses/LICENSE-2.0)

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.[  
](http://www.apache.org/licenses/LICENSE-2.0)

---

# Licensing terms

> PowerSync licensing and terms overview — PowerSync

- Source: https://powersync.com/legal/licensing-terms

---

_This page is a comparison grid that has no markdown source. Read it at https://powersync.com/legal/licensing-terms, or see https://powersync.com/pricing.md for the editions it compares._

---

# Privacy policy

> Privacy policy — PowerSync

- Source: https://powersync.com/legal/privacy-policy

---

Last updated: January 22, 2025

###### **INTRODUCTION**

This Privacy Policy relates to Journey Mobile, Inc. and its affiliates (“Company” or “us” or “we” or “our”). It describes how we treat the personal information we collect and process when:

-   someone (a “Visitor”) visits our one of our website properties (www.powersync.com or www.journeyapps.com) (“Website”);
-   one of our customers (a “Customer”) or one of our business partners, suppliers, subcontractors or independent contractors (a “Supplier”) enters into a written agreement with us; or
-   a Customer, or a Customer’s authorized users (a “User”) uses our hosted PowerSync product (“PowerSync Cloud”) and its ancillary components and services (collectively, our “Product”), or uses any application developed by a Customer that utilizes PowerSync Cloud (an “Application”, and collectively with the Website and Product, the “Services”) or otherwise uses a product or service provided by us.
-   a Supplier provides a product or service to us.

Where another written agreement between us and a Visitor, Customer, Supplier or a User exists, and the terms of that other agreement conflict with the terms of this Privacy Policy, the terms of that other agreement shall prevail, unless applicable laws require otherwise. If you are a User using the Application of a Customer, please consult the applicable agreement between you and our Customer (such as an end-user license agreement) to ensure you understand your rights and obligations.

###### **The purpose and scope of this policy**

We respect data privacy rights and take the protection of data seriously. The purpose of this Privacy Policy is to be transparent about the way we collect, store, use, and protect personal information of Visitors, Customers, Suppliers and Users, collectively referred to as “data subjects”. We implement business practices that comply with applicable data protection laws, including the General Data Protection Regulation ((EU) 2016/679) ("GDPR") (collectively "Applicable Law"). This Policy applies to all processing of personal information of data subjects.  
  
In general, we receive and collect all information you provide via the Services, including through website input fields (including advertisements), phone, email (including email campaigns), web chat, or other such ways.

| **Category of Personal Information** | **Examples of Personal Information We Collect** | **Categories of Sources from which such Personal Information is Collected** | **Categories of Third Parties or Services Providers with whom we share such Personal Information** |
| --- | --- | --- | --- |
| Profile or Contact Data | Examples may include: • First and last name • Postal address • Telephone number • Email address • Unique identifiers, such as usernames and passwords • Other similar identifiers | • You • Service providers | • Data analytics providers • Service providers / third-party vendors • Partners you authorize, access, or authenticate |
| Demographic Data | Examples may include: • ZIP code | • You • Service providers • Company’s affiliated entities, partners, etc. • Other independent third-party sources | • Data analytics providers • Service providers / third-party vendors • Partners you authorize, access, or authenticate |
| Commercial Data | Examples may include: • Records of products or services sold, used, or purchased | • You • Service providers | • Data analytics providers • Service providers / third-party vendors |
| Device/IP Data | Examples may include: • IP address • Device ID • Browser type • Type of device • Information regarding your interaction with the Services or any advertisement • Information collected automatically through cookies and similar technology, device type, domain names, and access time/logs | • You • Service providers | • Data analytics providers • Advertising networks • Service providers / third-party vendors |
| Geolocation Data | Examples may include: • IP address-based location information | • You • Service providers | • Data analytics providers • Service providers / third-party vendors |
| Web Analytics | Examples may include: • Web page interactions • Referring web page / source through which you accessed the Services • Statistics associated with the interaction between device or browser and the Services | • You • Service providers | • Data analytics providers • Advertising networks • Service providers / third-party vendors |
| Professional or Employment-Related Data | Examples may include: • Employer • Job title | • You • Service providers | • Data analytics providers • Service providers / third-party vendors • Partners you authorize, access, or authenticate |
| Financial and Payment Data | Examples may include: • Payment card type • Last 4 digits of payment card and expiration date • Billing address | • You • Service providers | • Data analytics providers • Service providers / third-party vendors • Partners you authorize, access, or authenticate |
| Social Network Data | Examples may include: • Publicly displayed contact information and social media username / ID associated with your social media accounts • Data, information, or materials accessible through your social media | • You • Service providers • Other independent third-party sources | • Data analytics providers • Service providers / third-party vendors |
| Inferences Drawn from Other Personal Information Collected | Examples may include: • Profiles reflecting user attributes • Profiles reflecting user behavior | • You • Service providers • Other independent third-party sources | • Data analytics providers • Service providers / third-party vendors |
| Other Identifying Information that You Voluntarily Decide to Provide | Examples may include: • Identifying information in emails, texts, letters, or other communications you send us • Identifying information you post to blogs, competitions, live chats, forums, or message boards | • You • Service providers • Other independent third-party sources | • Data analytics providers • Service providers / third-party vendors |

You have the choice on what information to share. You can choose not to provide information to us, but in general, some information about you is required in order for you to access certain functionalities of the Services.  
  
We also may periodically obtain information about you from affiliated entities, partners and other independent third-party sources and will add it to our database of information, including any information that you provide to third parties that are associated or whose products and/or services are integrated with the Services. For one example, we may receive information about your interaction with advertisements on third party websites and use this information to update demographic information.

###### **How we collect your personal information**

We collect data, which may include personal information of individuals, in one of four ways:

-   Through our Website, when a Visitor, Customer or User enquires about our products and services by providing their details and requesting that we contact them;
-   Through our Product, when Customers sign up to use the Product, request support from our support desk or otherwise use our or other third-party software to interact with us in terms of the agreement between us and a Customer;
-   Through Applications developed by our Customers that utilize our hosted Product (PowerSync Cloud), when Users use an Application to capture personal information in terms of an agreement between us and a Customer; or
-   Through other means, including email and electronic signature software, when we collect the personal information of Customers and Suppliers as part of the execution and administration of the terms under which we provide our products and services (in the case of Customers) or under which we procure products and services (in the case of Suppliers).

Data collected through our Websites

When an individual clicks on “Contact Us” or otherwise completes a form which requests that they provide personal information, we collect certain personal information such as their full name, phone number, email address, company name (if applicable) and online identifier information.

Data collected through our Product and customer support and interaction channels

When an individual signs up to use our Product, we collect certain personal information, including their name, email address and online identifier.

We use a number of channels to provide professional services and technical support to Customers and to contact Customers with important information regarding the Product and Customers’ Applications.

Data collected through Customers’ Application

Our Product is used by Customers in the development and operation of custom software applications. The personal information collected using the Application through PowerSync Cloud (if applicable for Customer’s deployment of the Services) varies depending on the Application’s purpose and the Customer’s specific implementation.

Data collected through cookies

We may use cookies, log files, device identifiers, advertising identifiers, and similar tracking technologies, including those from third-party service providers like Google Ads, Google Analytics, Google Tag Manager, HubSpot, and other cloud-based tools, to automatically collect your preferences, performance data, and information about your web usage when you visit the Services. For example, we may collect your IP address, device and Internet service provider information, Web browser details and the address of any referring website. We may also collect information about your online activity, such as pages viewed and interactions with other users. This may include collecting geolocation signals from your IP address or device settings to determine your location. By collecting and using this information, we may operate and personalize the Services for you, including to provide more relevant ads and search results.  For more information on how we use cookies, please see the “Cookies” section below.

The Services are not designed to recognize or respond to “do not track” signals received from browsers. You can control the information collected by such tracking technologies or be alerted when cookies are sent by adjusting the settings on your Internet browser or devices, but such adjustments may affect or disable certain functionality of the Services. You can learn more about Google Analytics and your options for opting out of interest-based Google ads at [https://adssettings.google.com](https://adssettings.google.com). You can learn more about targeted ads and your ability to opt out of receiving interest-based ads at [optout.aboutads.info](https://optout.aboutads.info) and [www.networkadvertising.org/choices](https://www.networkadvertising.org/choices).

Data collected by other means to execute and administer Customer and Supplier agreements

When a Customer enters into an agreement for the use of our Product and the provision of related services, we collect information such as the Customer name, place of incorporation and physical and postal address, which are required in order to properly execute a legally binding agreement between us and the Customer. We also collect billing and shipping information, such as the email address of invoice recipients and the shipping address where our Product and services will be used, which we need to collect services fees and comply with sales tax legislation.  
  
When a Supplier enters into an agreement with us to provide us with products and/or services, we may collect information about the Supplier required to administer our agreement with the Supplier, including but not limited to the Supplier’s name, place of incorporation, physical and postal address, tax information and banking information.

###### **How we use your personal information**

We process your personal information with your consent or as needed to provide you the Services. We may also use your personal information to comply with legal obligations, operate our business, protect the vital interests of you, our customers, or the public, or for other legitimate interests of Company as described in this Privacy Policy.  
  
More specifically, we may use your personal information to:

-   optimize and improve the Services and the content and functionalities with respect thereto;
-   measure engagement with the Services to understand how you and other users interact with and use the Services and other resources Company provides;
-   respond to support needs, inquiries and communications;
-   service and comply with the contractual relationships with our Customers, including responding to pre-contractual queries, registration for our technology products and related services, administering our contract with our Customers, billing and collections, ongoing Customer relationship management and direct marketing;
-   generate business analysis, statistics, product development, internal operational requirements, testing, legal requirements and compliance;
-   administer our agreement with the Supplier, pay the Supplier’s fees and comply with tax legislation and other regulatory reporting requirements;
-   process transactions and fulfill requests (financial or payment information, such as credit card information or bank details are not shared with third parties except to the extent necessary to process such transactions and provide the Services);
-   collect statistics about the behavior of Visitors to the Website and Users’ use of our Product and Customers’ Applications. We may display this information, in aggregate, publicly or provide it to others;
-   send periodic communications; and
-   carry out other legitimate business purposes, as well as other lawful purposes.

The personal information of Users that we process on behalf of our Customers who use PowerSync Cloud will depend on our Customers’ requirements and we do not control these requirements.  
  
We have no obligation to maintain or monitor any data entered by a User using an Application on PowerSync Cloud or the Customer’s account on our Product.  
  
Like most software companies, we collect non-personally-identifying data of the sort that web browsers, platforms and software applications and servers typically make available, such as the browser type, language preference, referring website or application, and the date and time of each visitor request. Our purpose in collecting non-personally identifying data is to better understand how our Visitors, Customers and Users use our Website, our Product and Applications and to tailor the information provided to Visitors and Customers based on their location, in order to make that information more relevant. From time to time, we may release non-personally-identifying data in the aggregate, e.g., by publishing a report on trends in the usage of our products and services.  
  
We also collect potentially personally-identifying data like Internet Protocol (IP) addresses. We do not use such information to identify Visitors or Users, and we do not disclose such information, other than under the same circumstances that we use and disclose personal information as described in this Privacy Policy.  
  
Certain Visitors to our Website and Users using our support and interaction channels choose to interact with us in ways that require us to gather personal information. The amount and type of data that we gather depend on the nature of the interaction. For example, we ask Users who sign up to use our Product to provide data such as their name, email address, Customer name and contact details. In each case, we collect such data only insofar as is necessary or appropriate to fulfill the purpose of the User’s interaction with us, as determined by an agreement between us and a Customer. We do not disclose personally-identifying information other than as described in this Privacy Policy. Users can refuse to provide certain personally-identifying data, and although we make every attempt to accommodate such a request, such a refusal may prevent them from being able to use our Product or an Application.  
  
Note that if our Customer uses PowerSync Cloud to process personal information for their own direct marketing purposes within their Application, our Customer is obligated to ensure compliance with Applicable Laws.

###### **Legal basis for using your personal information**

Our basis for collecting and processing personal information is one of the following:

-   **Our contract with a Customer or Supplier**: for example, when we process personal information to respond to a Customer request to enter into an agreement with us, or when processing personal information for billing purposes or any other purpose relating to the technology products and related services we provide to Customers in terms of our agreement with them, or when Suppliers provide products and services to us;
-   **Our legitimate interest**: for example, when we conduct direct marketing to a Visitor, User or Customer or process personal information for our internal statistical or research purposes;
-   **Legal or compliance requirements**: for example, when we process personal information for a purpose required in law or when we liaise with authorities, or for reviewing our security practices.

When we process personal information on behalf of our Customers, such Customer is responsible for determining the legal basis for processing. This may include that the Customer may require consent from a User before processing the information or sharing it with us for purposes of processing in terms of our agreement with the Customer.

###### **Sharing your personal information with third parties**

We do not sell personal information. We disclose personal information to employees, contractors, affiliated organizations and business partners in terms of this policy. When we share personal information it is only on a need-to-know basis and subject to contract regulating the use of the personal information by the recipient. We may share personal information as follows:

-   with regulators or similar bodies if required by any governmental regulatory authorities or similar bodies in terms of applicable law. We may also share it with law enforcement agencies if required by law;
-   with employees, service providers and contractors who provide services to us under contract;
-   with external professional service providers such as auditors and attorneys for purposes relating to our business operations;
-   in response to subpoenas, court orders, or other legal processes; to establish or exercise our legal rights; to defend against legal claims; or as otherwise required by law. In such cases we reserve the right to raise or waive any legal objection or right available to us;
-   when we believe it is appropriate to investigate, prevent, or take action regarding illegal or suspected illegal activities; to protect and defend the rights, interests, or safety of our company or the Services, our Customers, or others; or in connection with our agreements;
-   with any third party in connection with and as a result of a sale, acquisition, merger, reorganization or other transfer (a “Transfer”) involving Company. Company specifically reserves the right to transfer personal information to a third party in connection with a Transfer. Should such a Transfer occur, we will request that the new combined entity follow this Privacy Policy with respect to your personal information, as and to the extent required by applicable law, and to require that you receive prior notice if your personal information could be used contrary to this Privacy Policy.

Personal Information You Post in Public Areas

When you post a message in a Company/PowerSync review, customer feedback, or public online forum, the information you post may be accessible to other users of the Services and the public. If you post personal information anywhere on the Services that is accessible to other users or the public, you are advised that such personal information can be read, collected, used, or disseminated by others and could be used to send you unsolicited information or for other purposes. Accordingly, you assume full risk and responsibility for posting such information and agree that Company is not responsible in any way for personal information you choose to post in these public areas.

Aggregated Information

We may publish, share, distribute, or disclose personal information that has been aggregated with information from other users or otherwise de-identified data in a manner that does not allow third parties, including Company partners, sponsors, and advisers, to de-aggregate the data and identify it as originating from you. Such information may help Company identify and analyze training, demographic, and psychographic trends and information, and report to third parties how many people saw, visited, or clicked on certain content, areas of the Services, ads, or other materials. We may also use such data for research purposes and optimizing the Services’ functionality.

###### **Your rights in respect of your personal information**

To the extent provided by the law of your jurisdiction, you may:

-   Have the right to access certain personal information we maintain about you and request details about how we process it;
-   Request certain information regarding our disclosure of personal information to third parties for their direct marketing purposes;
-   Request that we update or correct inaccuracies regarding your personal information;
-   Object to our use of your personal information;
-   Ask us to block or delete your personal information from our database;
-   Request to download the information you have shared on the Services; and
-   Confirm whether Company stores your data in certain locations.

You may make these requests and any other inquiries about this Privacy Policy by emailing [dpo@powersync.com](mailto:dpo@powersync.com). Any such requests are subject to the protection of other individuals’ rights and applicable law. Additionally, to help protect your privacy and maintain security, we may take steps to verify your identity before granting you access to the information. To the extent permitted by applicable law, a charge may apply before we provide you with a copy of any of your personal information that we maintain.  
  
Note that where we process personal information on behalf of our Customers, these rights must be applied against the Customer. We will reasonably cooperate with our Customer on any request relating to these rights.

###### **Retaining your personal information**

We will retain your information as long as necessary for the purposes outlined in this Privacy Policy, in a manner consistent with our internal retention policies, and for a commercially reasonable time thereafter for backup, archival, fraud prevention or detection or audit purposes. We will retain your personal information consistent with the original purpose of collection or as long as necessary to comply with our legal obligations; maintain accurate accounting, financial and other operational records; resolve disputes; and enforce our agreements. We will never retain your information for a period longer than permitted by Applicable Law.  
  
We determine the appropriate retention period for personal information on the basis of: the amount, nature, and sensitivity of the personal information being processed; the potential risk of harm from unauthorized use or disclosure of the personal information; whether we can achieve the purposes of the processing through other means; and on the basis of applicable legal requirements.  
  
After expiration of the applicable retention periods, your personal information will be deleted.  
  
We may keep personal information indefinitely in an aggregated or de-identified format for statistical purposes, which may include for example statistics of how data subjects use our services.

###### **Security of your personal information**

We are committed to take reasonable steps to keep your personal information safe and secured, and we implement appropriate technical and other security measures to protect the integrity and confidentiality of your personal information against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, unauthorized access, and other unlawful or unauthorized forms of processing, in accordance with applicable law.  
  
We employ administrative, physical, and electronic measures designed to protect the personal information we store and process.  
  
For PowerSync Cloud, we use industry-standard technological means to protect personal information while in transit through the internet and when stored on our servers. We use encryption and a comprehensive authentication protocol to provide reasonable security. However, please remember that no security system on the internet is perfect.  
  
When you access the Product using a username and password, please ensure that you always keep these safe and confidential and never share it with any third party. We will never ask you for your password. If someone contacts you, claiming to represent Company or PowerSync and requests your information, it is always best to request that you contact that person by first getting in touch with Company through a known and published communication channel such as our support desk, or email address and confirming that person’s identity.  
  
We will report any security breach in terms of Applicable Laws to the applicable regulatory authority and to the data subjects whose personal information is involved in the breach, unless you are a User. If you are a User and your personal information is affected by a security breach, we will inform our Customer about the breach.  
  
We rely on Google’s, AWS’ and HubSpot’s security programs to protect personal information while stored in their respective controlled facilities.  For more information on AWS’ security practices and processes, please see [https://aws.amazon.com/security/](https://aws.amazon.com/security/). For more information on HubSpot’s security practices and processes, please see [https://legal.hubspot.com/security](https://legal.hubspot.com/security). For more information on Google’s security practices and processes, please see [https://safety.google/security-privacy/](https://safety.google/security-privacy/).  
  
Company currently uses Stripe for payment services. Stripe collects identifying information about the devices that connect to each of their services. Stripe uses this information to operate and improve the services they provide to Company, including for fraud detection. You can learn more about Stripe and read its privacy policy at [https://stripe.com/privacy](https://stripe.com/privacy). As with all third-party providers, Company is not a party to any agreement between you and Stripe and does not control Stripe’s privacy and data security policies. Company reserves the right to change payment processors at any time.  
  
If you want to report any concerns about our privacy practices or if you suspect any breach regarding your personal information, please notify us by sending an email to [dpo@powersync.com](mailto:dpo@powersync.com).

###### **Cookies**

Cookies, also known as tracking cookies or browser cookies, and similar technologies such as web beacons, clear GIFs, pixel tags, and JavaScript (collectively, “Cookies”) are small pieces of data, usually text files, placed on a computer, tablet, phone, or similar device when you use that device to access the Services. We use the following types of Cookies:

-   **Essential Cookies**. Essential Cookies are necessary for providing you with services and features that you requested. For example, these Cookies allow you to log into and stay logged into secure areas of the Services, save language preferences, and more. These Cookies are required to make the Services available to you, so they cannot be disabled.
-   **Functional Cookies**. Functional Cookies are utilized to record your choices and settings, maintain your preferences over time, and recognize you when you return to our Services. These Cookies help us personalize our content for you, greet you by name, and remember your preferences. Some examples include your ability to comment on a blog, facilitate web chat services, update user preferences, and more.
-   **Performance/Analytical Cookies**. Performance/Analytical Cookies allow us to understand how visitors (like you) use our Services. These Cookies accomplish this by collecting information about the number of visitors to the Services, what pages visitors view the most, and how long visitors view specific pages. These Cookies also help us measure and manage the performance of our advertising campaigns in order to help us improve the campaigns and the Services’ content. For example, Google uses cookies in connection with its Google Analytics services. Google’s ability to use and share information collected by Google Analytics about your visits to the Services is subject to the Google Analytics Terms of Use and the Google Privacy Policy. You have the option to opt-out of Google’s use of Cookies by visiting the Google advertising opt-out page at [http://www.google.com/privacy\_ads.html](http://www.google.com/privacy_ads.html) or the Google Analytics Opt-out Browser Add-on at [https://tools.google.com/dlpage/gaoptout/](https://tools.google.com/dlpage/gaoptout/).

You have the option to decide through your internet browser’s settings whether or not to accept Cookies. Most browsers allow users to choose whether to turn off the Cookie feature, which will prevent your browser from accepting new Cookies, as well as (depending on the browser) allow you to toggle whether to accept each new Cookie. You can also clear all Cookies that are already on your device. If you do this, however, you may have to manually adjust some preferences every time you visit the Services and some functionalities may not work. If applicable, you can also manage your cookie settings by selecting "Cookies settings" in the cookie banner that appears when you first visit our website.  
  
To explore what Cookie settings are available to you, look in the “settings”, “preferences” or “options” section of your browser’s menu. To find out more information about Cookies, including information about how to manage and delete Cookies generally, please visit [http://www.allaboutcookies.org/](http://www.allaboutcookies.org/).

###### **Limitation of liability**

We exercise reasonable efforts to safeguard the security and confidentiality of your personal information; however, transmissions protected by industry standard technology and administered by humans cannot be guaranteed to be secure in all circumstances. We will not be liable for unauthorized disclosure of personal information that occurs through no fault of Company including, but not limited to, errors in transmission, uses of your data by a third party, and your failure to comply with your security obligations.

###### **Links to other websites and software services**

This policy addresses only the use and disclosure of information that we collect from you through the Website and your use of the Product or an Application, through our interaction with you or from interaction with our business partners. Our Website and Product may contain links to other websites and software services. The fact that we link to a website or another software service is not an endorsement, authorization or representation of our affiliation with that third party. We do not exercise control over third party websites or software services. These other websites and software services may place their own cookies or other files on your computer, collect data, or solicit personal information from you. They follow their own rules regarding the use or disclosure of the personal information you submit to them. We recommend that you read the privacy policies or statements of these other websites and software services, if applicable.

###### **Children’s and your sensitive personal information**

We do not collect personal information from children under the age of 18. If you believe that a child has provided us with personal information without the consent of his or her parent or guardian, please contact us immediately at [dpo@powersync.com](mailto:dpo@powersync.com). If we become aware that a child under age 18 has provided us with personal information, we will delete such data.  
  
We do not intentionally collect sensitive or special personal information.  
  
Where we process children’s or sensitive/special personal information on behalf of a Customer, the Customer is responsible to ensure lawful processing and to obtain consents where required.

###### **Cross-border transfers of your personal information**

As part of providing PowerSync Cloud, we make use of third party service providers as [sub-processors](https://powersync.com/legal/subprocessors) and may transfer data cross border if our service provider conducts business in another jurisdiction. We only use [reputable sub-processors](https://powersync.com/legal/subprocessors) who maintain rigorous security standards.  
  
Any personal information transferred cross border will only be transferred in terms of an agreement requiring the recipient of the data to comply with all applicable requirements in respect of data privacy, and/or the recipient is subject to a law or binding corporate rules which provide an adequate level of protection that effectively upholds principles for reasonable processing of the information and includes provisions relating to the further transfer of personal information from the recipient to third parties who are in a foreign country.

###### **Dispute resolution and complaints**

If you have any concerns or claims with respect to our Privacy Policy, please contact our Data Protection Officer/Information Officer at [dpo@powersync.com](mailto:dpo@powersync.com). We will investigate and attempt to resolve any complaints and disputes regarding our use and disclosure of personal information.  
  
In terms of applicable laws, you may have the right to formally lodge a complaint about how we handle your personal information with your relevant regulatory authority in terms of the applicable law that applies to you.  

-   If the GDPR applies to you, you may lodge a complaint with the European Commission by using the European Commission [online complaint procedure](https://commission.europa.eu/about-european-commission/contact/problems-and-complaints_en) or writing to the European Commission, Secretary-General B-1049 Brussels, BELGIUM, or sending a fax to +32 229 64 335.

**California Resident Privacy Rights**. California Civil Code Section 1798.83 permits our customers who are California residents to request certain information regarding our disclosure of personal information to third parties for their direct marketing purposes. To make such a request, please e-mail us at [dpo@powersync.com](mailto:dpo@powersync.com).

###### **Updates to this Privacy Policy**

This Privacy Policy may be updated from time to time in order to reflect changes in our practices. We will notify you of any material changes by posting the new Privacy Policy on our Website, and we will obtain the necessary consents as may be required under Applicable Laws if we seek to collect, use or disclose personal information for purposes other than those disclosed initially or for which consent has been obtained.  
  
Except as stated above, all changes will apply to the personal information that has already been collected, and to personal information that is collected after the effective date of the revised Privacy Policy. If any proposed change is unacceptable to you, you will have the right to ask for the deletion of your personal information. You are advised to consult this Privacy Policy regularly for any changes.

###### **How to contact us**

If you have any questions, comments, concerns, complaints or claims with respect to our Website or Product, if your Product account has been compromised by a hacker or scammer, if you find that certain content displayed on the Website, the Product is inappropriate or prohibited by these terms, or if you have any other concern, please contact us by email at [dpo@powersync.com](mailto:dpo@powersync.com). We will investigate and attempt to resolve the matter.

---

# Subprocessors

> PowerSync Sub-Processors

- Source: https://powersync.com/legal/subprocessors

---

As part of providing the Services for [PowerSync Cloud](https://powersync.com/pricing), we may enlist the services of third-party cloud infrastructure providers, known as Sub-Processors. This page provides the name, purpose and location for each Sub-Processor.

By consenting to the [Data Processing Addendum](https://powersync.com/legal/dpa) (DPA), you acknowledge that these Sub-Processors may be engaged to process Customer Data solely within their designated scopes outlined below.

### **1. Core Infrastructure & Data Sync Sub-Processors**

_(Entities processing customer database sync payloads)_

| **Entity Name** | **Purpose** | **Location** |
| --- | --- | --- |
| Amazon Web Services, Inc. | Cloud infrastructure | US, EU, Australia (AU), Japan (JP), Brazil (BR), India (IN) *Location depends on project deployment settings.* |
| MongoDB, Inc. | Database hosting | US, EU, Australia (AU), Japan (JP), Brazil (BR), India (IN) *Location depends on project deployment settings.* |

### **2. Supporting & Administrative Sub-Processors**

_(Entities strictly limited to account management, authentication, and system operations. These companies do not process customer database sync payloads)_

| **Entity Name** | **Purpose** | **Location** |
| --- | --- | --- |
| SendGrid, Inc. | Transactional email | US |
| Twilio, Inc. | Two-factor authentication (2FA) | US |
| HubSpot, Inc. | Product analytics | US |
| Supabase, Inc. | Product analytics | US |