FAQs

We’ve collated frequently asked questions about ElectricSQL here, either with answers, or with links and signposts to more information.

 Warning – Alpha!

ElectricSQL is currently in Developer Preview mode. This is like a public alpha. There are still lots of things we need to do before we fully deliver on the development paradigm we’re aiming for.

1. Technical

1.1 What is ElectricSQL?

ElectricSQL is a set of open source software libraries and a managed software platform that helps developers make local-first apps. These apps can run on a mobile phone, in a web browser or on a server. Local-first means that the apps talk to a local database inside the device they run on, rather than talking to a backend or database over the network.

See our technical intro for more information or read this article on local-first software.

1.2 How do you compare with other solutions?

There are many different tools to make local-first software. ElectricSQL aims to simplify local-first development and avoid leaking complexity into the app domain.

Our sync layer provides realtime, low-latency, geo-distributed, multi-user, conflict-free, active-active replication with reactivity, durability, atomic transactions and causal+ consistency with CRDTs. Our system eliminates rollbacks and associated failure code and provides fully featured relational SQL with referential integrity and constraints.

As such, we differentiate by providing:

  1. real SQL with referential integrity and constraints based on Rich-CRDTs
  2. finality of writes eliminating the need to code failure paths
  3. fully open-source and integrated with standard SQLite and Postgres
  4. multi-platform with first class support for mobile, web and edge apps
  5. drop-in compatible with existing SQL drivers, ORMs and frameworks
  6. turnkey, conflict-free, active-active replication-as-a-service
  7. strongest possible consistency for a local-first system

Note that we do not target:

  • peer-to-peer (check out Concordant)
  • byzantine fault tolerance (check out Orbit)
  • filesystem integration (check out LiteFS)
  • object or document model (lots of alternaties, e.g.: Gun and Pouch)
  • analytics / timeseries / high throughout (check out DuckDB)

We list alterative tools and projects on our alternatives page.

1.3 What kind of apps or use-cases is ElectricSQL for?

ElectricSQL is great for scenarios when/where:

  • you have poor connectivity: perhaps because your app targets a market with patchy Internet or a category like farming, or an activity like trail-running
  • you’re sharing data with a bounded group of people: such as yourself, your family, your team, your collaborators, your company or your community
  • you want high availability without high cost: local-first can save you from the cost and complexity of engineering high-availability on the backend – you don’t need zero-downtime deploys or multi-region redundancy when your users don’t notice the downtime
Specific use-case / application examples:
  • personal productivity apps like note taking, recipies, fitness, etc.
  • family apps, like a shared shopping list or school-run coordinator
  • authoring tools, like a book writing app or a pre/post meeting CRM tool (for where users want to be able to cut out interruptions and keep writing/designing/creating when they’re off-grid or on a train/plane)
  • creative collaboration apps, like Trello, Miro and Figma, where data can naturally be segmented (and thus synced) by workspace, board or document
  • SaaS apps where the data is naturally segementable (and thus syncable) by tenant, group or workspace
  • business management apps like farm management and factory operation systems
  • data entry apps, like mobile point-of-delivery and on-site form entry systems – with these, downtime costs time and local-first can unblock people in the field
  • off-road activity apps like mapping, running, orienteering where you go in and out of connectivity

Take out your phone and look at the apps you have installed. How many of them could be local-first?

Some more counter-intuitive examples:
  • e-commerce: replication becomes more efficient under increased load and avoids thundering herds; combined with reservation algorithms to manage stock availability, local-first can be a low-cost solution to Black Friday spikes in demand
  • content publishing: blogs, newspapers, directories, etc are actually a great fit for local-first, because public content can be published and synced globally and interactions can be scoped to the content
  • search and social networks: local-first isn’t a good fit for web-scale search or social networks but can be brilliant for smaller scale search or networks where the data naturally fits on the device

We believe that there are a lot more apps, use-cases and categories that can be adapted to local-first SQL that you might first think. We’re keen to facilitate experimentation to discover just how far the paradigm can go and how much of the existing software landscape can be disrupted.

1.4 How do you do migrations?

ElectricSQL’s solution to DDL migrations is based on causal consistency and lenses. See the How migrations work section of our migrations documentation.

1.5 Do you have benchmarks? How can I compare your performance?

We don’t have published benchmarks yet and we’re not currently focused on data throughput. We’re still in the “make it” and “make it right” phases at the moment.

Our replication layer is based on AntidoteDB. Antidote has good benchmark tooling. There’s also some early Jepsen testing here. Our backend services are built in Elixir (so everything server-side is running on the BEAM). You can see some integration tests here, including sysbench tests with load generation.

Let us know on Discord if you’re interested in collaborating at some point on performance testing.

1.6 Where’s my data stored? What’s the source of truth?

You data is stored in either two or three places:

  1. in local embedded SQLite database instances inside your app
  2. in AntidoteDB database nodes in the ElectricSQL cloud replication mesh
  3. optionally in Postgres database instances (one per geo-distributed region in the ElectricSQL cloud)

Currently ElectricSQL is hosted in Google Cloud Platform. Data is persisted on encrypted and isolated SSD volumes that are dynamically provisioned and mounted per application. You can choose which regions are enabled for each application.

When a new node joins the network (and / or when a node re-connects), it syncs data from the cloud replication mesh. This sources the data from the nearest AntidoteDB node. I.e.: it is not pulled dynamically from peers or assembled from other SQL nodes. In this sense, Antidote is the source of truth.

See How do I control what syncs where? and Are you fully local-first? for more information.

1.7 What are your consistency guarantees?

We provide Transactional Causal+ Consistency with CRDTs, as defined in the Cure protocol. This is formally proven to be the strongest possible consistency mode for a local-first system.

See the consistency page in our reference docs for more information.

1.8 How do you provide referential integrity and constraints?

See our Introducing Rich-CRDTs post and the integrity page in our reference docs for more information.

1.9 Are there limitations on how I should model my data?

Yes. See the limitations section of our migrations docs.

1.10 Do you support p2p sync without going through the cloud?

No. Clients sync data via the cloud. Specifically, the nearest cloud region, i.e.: replication is latency efficient, via the cloud edge. See the alternatives page for p2p alternatives.

1.11 Do I need to run the backend? Can I run the backend?

ElectricSQL is a turnkey platform that provides replication-as-a-service based on open-source software.

You don’t need to run the backend system. You can just sign up for an account and create an application. We dynamically provision geo-distributed compute and storage resources for you, configure the networking and provide you with a globally load balanced connection string and credentials that just work. We then operationally manage the backend systems.

If you want to run the backend yourself, you of course can. Check out the repos on GitHub.

1.12 How do I control what syncs where?

At the moment, our developer preview is public and global only: everything syncs everywhere.

We’re working on adding authentication modes and authorisation rules, and on a system for dynamic partial replication. See the auth and replication guides for status.

2. Operational

2.1 Are you fully open source?

All of our core components are open source at github.com/electric-sql under the Apache 2.0 License. This includes our core replication layer based on AntidoteDB electric-sql/vaxine, our core replication pipeline, protocol and services electric-sql/electric and the electric-sql/typescript-client client side libraries.

You can run these components yourself to operate a fully working ElectricSQL system. There is no seperate community vs enterprise edition – all functionality goes into the open source code.

As a company, we do have additional proprietary code that supports our business operations and replication-as-a-service offering. This includes things like automated provisioning, monitoring and a management dashboard. This is not open source.

2.2 Are you fully local-first?

Local-first is defined by Ink & Switch as a set of principles for software that enables both collaboration and ownership for users:

Local-first ideals include the ability to work offline and collaborate across multiple devices, while also improving the security, privacy, long-term preservation, and user control of data.

With ElectricSQL, the database and the data are on the device. There are no loading spinners: your work is at your fingertips. Data syncs across devices. So your work is not trapped on one device. The network is optional. Apps can bundle migrations and initial data state and users can make progress immediately without ever initiating a network connection to sync data. All writes go through the local-database, which is available without any network connection. Apps naturally tolerate poor and intermitently network connectivity.

By adding cloud sync to the local database and realtime reactive queries, based on conflict-free active-active replication and rich-CRDTs, we enable seamless collaboration with your colleagues. Because the source of truth for our system is our cloud replication layer, it’s arguable whether we fully conform to the security and privacy by default principle. However, we are working to provide replication controls that put the user and developer fully in control of what syncs where.

Data is stored in standard open-source databases, including local SQLite and optionally a cloud Postgres. You retain ultimate ownership and control of the data and users can can continue accessing the data for a long time in the future, even if the ElectricSQL service disappears.

2.3 When will you be production-ready?

We don’t know yet. Maybe spring-summer 2023. Join the Discord and we’ll keep you posted.

2.4 Who are you? Who’s behind ElectricSQL?

We are a UK company called Electric DB Limited. See the team page for more information.

2.5 What do you know about database systems?

We invented CRDTs, the bounded counter, rich-CRDTs, AntidoteDB and AQL. We’ve built production grade database-as-a-serice products, including Oracle’s MySQL HeatWave, highly available payment processing systems for Klarna and contributed to projects including Apache CouchDB and Couchbase.

We’ve also won a Ted Prize, the $1,000,000 Microsoft Prize for the best startup in Europe, the Grand Prix at the prestigious Société Générale Banking CyberSecurity Innovation Awards and the CogX Award for Best Innovation In Data Protection And Privacy.

See the bios on the team page for more background information.

2.6 What’s your business model?

Replication-as-a-service.

2.7 How are you funded?

We are a Seed stage VC-backed company. See the investors section of the team page.

Yes. You can download the logo files here.

3. Community

3.1 Are you accepting contributions?

Yes. It’s probably a good idea to raise an issue to discuss before jumping in to code but we’re very much open to contributions and would welcome your help and ideas. You can see the contributing guide and agreement in the meta repo.

3.2 How can I get involved?

Join the Discord, introduce yourself and let us know what you’re interested in. We need help with development, testing, demo apps, documentation, etc.

3.3 Are you hiring?

If we are, it will be listed on the jobs page. We’ll also notify about any new roles on Discord.

More information

See the documentation, about and legal pages.