Real-world apps
So far, we've seen how local-first provides instant reactivity and realtime sync. We've looked under the hood at conflict-free offline, active-active replication and dynamic sync controls.
Bringing it all together and coming back to a high level, what kind of apps does ElectricSQL really work for? Are there examples and where do you go next?
Postgres to local-first
ElectricSQL is designed to support relational applications which match a particular pattern. This pattern has a central, Postgres-based, backend application as a control plane or management system. You can then expose multiple local-first apps and interfaces on top of this, much as you would with traditional API-based architectures.
In this architecture, ElectricSQL replaces traditional APIs and state transfer protocols, like REST and GraphQL. You still define your data model using your existing web framework, like Prisma, Phoenix or Rails -- any framework that handles migrations and works with Postgres.
You replace your server-side business logic with a local-first client app and background processing triggered by database events. And you codify your imperative authorization and validation logic into declarative security and sync rules.
Example applications
You can see this pattern implemented, for example, in our LinearLite application.
LinearLite is a project management SaaS app, based on a simplified clone of Linear.app. It uses a membership-based block sync model where data is segmented by workspace. All users share the same local-first application interface.
To dive in and start coding, see the Quickstart.
For more detailed information, see the Usage and Integrations guides. If you'd like to chat anything through, join the community Discord and feel free to ask any questions there.