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.

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, and we intend on keeping it that way.

The code is available on GitHub and an image is published on Docker Hub.

The sync service (PowerSync Service) is a Node.js app that uses:

• A fork of [.inline-code-snippet]pgwire[.inline-code-snippet] 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:

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.

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.

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 and Railway
• 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, and thought I’d recap where all our components stand now:

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 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 for details.