Eagerly awaiting the React Native compatible version. https://zerosync.dev/ is the main alternative I'm considering.
Electric (Postgres sync engine) beta release
21–30 of 72 posts
Re: Electric (Postgres sync engine) beta release
#22Is it fair to say that if you have a high read\low write service, you could use this as a sort of local cache (with the added benefit that it also handles staleness through the sync) on the service itself, to reduce latency from not just calls to Postgres but other caches like Redis?
Right exactly — a sync engine like Electric maintains replicas of data wherever you like. So natural places are web apps, mobile apps, backend services, etc. Here's an example showing how to sync a table from PG to Redis https://github.com/electric-sql/electric/blob/main/examples/... It's dramatically faster to read from a local copy of data vs. sending the query to Postgres and can eliminate a lot of network and db…
Thanks!
Re: Electric (Postgres sync engine) beta release
#23I listened to https://www.localfirst.fm/18 recently from Electric-SQL. One of the things James mentioned was that Electric lets you use commodity CDNs for distributing sync data, which takes the load off your main Postgres and servers. This seems like a good pattern, but of lower value for a SaaS app with many customers storing private data in your service. This is because the cache hit-rate for any particular compan…
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.
Re: Electric (Postgres sync engine) beta release
#24Eagerly awaiting the React Native compatible version. https://zerosync.dev/ is the main alternative I'm considering.
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).
Re: Electric (Postgres sync engine) beta release
#25Eagerly awaiting the React Native compatible version. https://zerosync.dev/ is the main alternative I'm considering.
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).
Sorry should have mentioned that I need PGlite or SQLite support. I am very much looking forward to PGlite on Expo/RN!
Re: Electric (Postgres sync engine) beta release
#26Earlier quoted context omitted.
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).
Sorry should have mentioned that I need PGlite or SQLite support. I am very much looking forward to PGlite on Expo/RN!
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.
Re: Electric (Postgres sync engine) beta release
#27Eagerly awaiting the React Native compatible version. https://zerosync.dev/ is the main alternative I'm considering.
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).
What are you using for your WASI runtime?
Re: Electric (Postgres sync engine) beta release
#28I have followed a lot of these projects because I have clients with persistent state and synced state too, as well as realtime needs. Anyway, this passes the smell test imo. It’s solid engineering and built from first principles, reusing the right pieces. So congrats! My concern with DB startups is always the business model. There’s a massive tension between open source and a sustainable business which is much more p…
What if the DRM/license was based around offering binaries built with 8/16/32/64 bit limits in data types and max records per table, each being its own edition and priced accordingly? Eg yearly license of $8/160/3,200/640,000.
It's very creative! LOL
But in practice most my tables that are uncapped end up with IDs are 64bits and i suspect not being the only one.. 32b is in fact quite small ~ 4B rows.
Re: Electric (Postgres sync engine) beta release
#29Earlier quoted context omitted.
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).
What are you using for your WASI runtime?
A couple of things here:
- the WASI build is targeting WASI snapshot preview 1, and so should work in any compatible runtime.
- for the web, currently we use Emscripten, but we are considering moving to a single WASI build there as well. We'll be writing our own JS WASI shim if we do. Having full control of the JS code will help to solve some of the problems we've faced with Emscripten.
- we are also exploring a route to native where we take the WASI build and decompile it back to C. This seems a little mad, but it makes it possible to compile (with any tool chain) a native binary with a very minimal WASI-like api that can be linked to from any app. It essentially end up a little like the SQLite amalgamated header file as a build route. It's very experimental, and we haven't committed to it yet, but it looks like it may work.
Re: Electric (Postgres sync engine) beta release
#30Just curious. They have Google listed as user. Why would a company like that be interested given that they’ve already any world class db in-house along with the expertise?