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:
- releasing a web SDK,
- implementing usage metrics and
- ensure the system scales and is stable
Web SDK
There is a rising interest in local-first architectures for web apps, 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: 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 using Webflow Devlink.
Usage metrics
Budgeting for SaaS products is notoriously difficult. Just take a look at our 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.
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.
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.
