HN user
https://electric-sql.com
b0b935
Thanks from the Electric side to the Casco team for the responsible disclosure, comprehensive repro and great communication through the process.
This was a critical one to identify and patch: https://github.com/electric-sql/electric/security/advisories...
Just to repeat for visibility, if you're self-hosting the Electric sync service, upgrade to version >= 1.5.0 immediately.
I made a little tool for Ralphing on Sprites: https://github.com/thruflo/wisp
I’ve found the sprites just work for claude. Pull how a repo (or repos) and run dangerously.
ElectricSQL | https://electric-sql.com | Founders Associate | FT | US based, SF Bay Area preferred (working with remote team) | $140-160k + equity
Electric is a devtools startup. We solve reactive, real-time sync across client and server [1]. We have a large developer community, millions of downloads a week, high profile customers and top-tier investors. Our software is built into platforms like Firebase, Prisma and TanStack. Our cloud product is growing 7% week on week.
This is a generalist, operational role. Working directly with the founders and founding team [2] to handle company operations as we grow into and through the Series stages.
It would be ideal if you're based in the San Francisco Bay Area. If not, you need to be able to travel there every month or so. You also need to travel to Europe for team on-sites a few times a year.
More information and application details here: https://electric-sql.com/about/jobs/founders-associate
[1] https://electric-sql.com/blog/2025/07/29/local-first-sync-wi... [2] https://electric-sql.com/about/team
This is very much the point of https://pglite.dev
It's an embeddable Postgres you can run in process as a local client DB, just like SQLite but it's actually Postgres.
Dallin's building https://www.buster.so (agents for data analytics).
Just to say if you're interested in this kind of tech and are in the Bay Area, Sync Conf [0] just announced [1] its initial speaker lineup today and Arushi Bandi from Figma is one of the speakers.
[0] https://syncconf.dev [1]: https://x.com/sync_conf/status/1957818840777122293
PubSub and LiveView do go a long way. However, broadcast isn't sync and LiveView isn't appropriate for all applications.
Phoenix recently added Phoenix.Sync [0], a sync engine library explicitly designed [1] to address this. In combination with a front-end library like TanStack DB [2] it goes much further towards giving you a Figma/Linear-style sync engine out of the box [3].
[0] https://hexdocs.pm/phoenix_sync [1] https://www.youtube.com/watch?v=4IWShnVuRCg [2] https://electric-sql.com/blog/2025/07/29/local-first-sync-wi... [3] https://electric-sql.com/demos/burn
Disclaimer: Electric founder. Linking to my own talk / post / demo.
Electric’s approach is compelling given it works with existing Postgres databases. However, one gap remains to fill, how to handle mutations?
Just to note that, with TanStack DB, Electric now has first class support for local writes / write-path sync using transactional optimistic mutations:
https://electric-sql.com/blog/2025/07/29/local-first-sync-wi...
This is the VM behind Popcorn https://github.com/software-mansion/popcorn, a project aiming to run OTP and Elixir in WASM:
Popcorn is a library that allows you to run client-side Elixir in browsers, with Javascript interoperability
Recent ElixirConf keynote introducing it: https://youtu.be/ep--rQO1FRI
On your last point: https://pglite.dev
On the main point around materialisation cost, I know more work is planned on compaction specifically but generally LiveStore is a framework that’s been highly crafted to address and optimise for all aspects of performance.
There are lots of options to stream data out of Postgres, including:
- https://electric-sql.com (disclaimer: co-founder) - https://feldera.com - https://materialize.com - https://powersync.com - https://sequinstream.com - https://supabase.com/docs/guides/realtime/broadcast - https://zero.rocicorp.dev
Etc.
This looks really cool, congrats!
Just to share a couple of similar/related projects in case useful for reference:
http://strobe.audio multi-room audio in Elixir
https://www.panaudia.com multi-user spatial audio mixing in Rust
Electric is a read-path sync engine for Postgres that does partial replication [1]. It's agnostic to your choice of client -- you can sync into anything you like. It doesn't handle or mandate a pattern for syncing local writes back to Postgres. Instead, it's designed to allow you to handle concerns like writes and auth using your existing API [2].
Turso Offline Sync is an active-active replication system for distributed SQLite/Turso databases. IIUC, this release adds the capability to sync local writes back to the cloud [3].
[1] https://electric-sql.com [2] https://electric-sql.com/blog/2024/11/21/local-first-with-yo... [3] https://turso.tech/blog/turso-offline-sync-public-beta#what-...
https://zero.rocicorp.dev/docs/introduction
Hard to raise the bar on Zero. It’s a brilliant system.
Come along :)
It’s pretty remarkable what Bruin brings together into a single tool / workflow.
If you’re doing data analytics in Python it’s well worth a look.
Yup, you can put an auth proxy in front of the CDN, for example using an edge worker.
See the auth guide: https://electric-sql.com/docs/guides/auth
Some CDNs also validate JWTs, so the CDN can be the proxy part of the Gatekeeper pattern (in the guide).
As are we :) btw checkout LiveStore if you haven’t already:
https://expo.dev/blog/local-first-application-development-wi...
It’s not fully released yet but it is now open to GitHub sponsors and it’s very cool.
Electric works with Expo / RN now.
PGlite is coming — we have a new WASI build that is the basis for native mobile support. (It’s working in dev, but still needs some more polishing and bindings).
Hey, one of the things here is to define shapes that are shared. If you imagine syncing a shape that is that user’s data then it may be unique. But if you sync, say, one shape per project that that user has access to and a small shape of unique user data then you get shared cache between users who have access to each project.
It’s worth noting that Electric is still efficient on read even if you miss the CDN cache. The shape log is a sequential read off disk.
Would be nice to add support for PGlite [0] to have the same “spin up in the browser” experience with Postgres.
Let me know if we can help with it!
We've actually also implemented Phoenix sync using Electric: https://hexdocs.pm/electric_phoenix/Electric.Phoenix.html
So you can have local-first sync in a Phoenix app using Electric. And you can use Electric to sync data into a LiveView using Phoenix.Streams, which is a very natural fit.
We have a couple of example apps showing things in action:
- https://github.com/electric-sql/electric/tree/main/examples/... - https://github.com/electric-sql/electric/tree/main/examples/...
Great stuff. Voice AI is great to run locally not just for privacy / access to personal data but also because of the low latency requirement. If there's a delay in conversation caused by a network call, it just feels weird, like an old satellite phone call.
ElectricSQL | https://electric-sql.com | PGlite Engineer | Remote in Europe or eastern US | €80-100k + Equity
We're looking for a generalist web and systems engineer to join the core PGlite team, working mainly in Typescript, Rust and C++.
PGlite (https://pglite.dev) is a lightweight, embeddable WASM Postgres. It's a fast growing open source project, with 8k GitHub stars and 100k+ weekly downloads. It opens up new possibilities for local-first apps and systems built on an embedded, real-time, reactive Postgres, such as https://postgres.new
Technically, you need strong Typescript and systems programming experience, ideally in C++ and Rust. It would be great if (but is not essential that) you're familiar with some aspects of database internals, filesystems and WASM.
We're a highly technical team working remote-first on a 4-day week. More information at https://electric-sql.com/about/jobs/pglite-engineer
Congrats to the Instant team. It’s a fantastic project. The DX is great and the engineering behind the datalog engine is really impressive.
Electric does partial replication. It’s specifically a system for syncing a different subset of data onto each local device.
Hey, Electric co-founder here.
Yup, our reactivity is quite simple at the moment, as described, and works quite well because SQLite is so fast. There are other projects doing more sophisticated reactivity algorithms, like Riffle/LiveStore, which has a reactive DAG optimised to avoid re-rendering and https://github.com/vlcn-io/materialite, which is like differential dataflow for live queries.
They're quite bleeding edge at the moment, but you can expect more efficient primitives for incremental view maintenance / efficient subscriptions to land in the embedded database layer quite soon.
Just also re: above, shape filtering for partial sync landed in v0.10 https://electric-sql.com/blog/2024/04/10/electricsql-v0.10-r... :)
ElectricSQL | Remote - EU | Full-time | https://electric-sql.com
ElectricSQL is an open source platform for building local-first software. We’re a small technical team hiring for a:
- Product Advocate / Engineer
- Staff Engineer (Elixir / Typescript)
- Systems Engineer (C / WASM)
Details here: https://electric-sql.com/about/jobs