Live data from Hacker News

Electric (Postgres sync engine) beta release

electric-sql.com

41–50 of 72 posts

Re: Electric (Postgres sync engine) beta release

#41

I tried using this a bit in an earlier version, when there was an option to have a real SQL client library/ORM, and you declared what part of the schema would exist client side. Is there plans to bring this back? The part where you could use drizzle client side was really what interested me, I don't want to bother learning another new query language apart from SQL.

Hey, it's possible to use PGlite on the client, along with Drizzle. Our "Linearlite" example show this (albeit without Drizzle) with a "write through the database" pattern to sync back to the server.

Live demo: http://linearlite.examples.electric-sql.com

Code: https://github.com/electric-sql/electric/tree/main/examples/...

Re: Electric (Postgres sync engine) beta release

#45

Just 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?

Yeah, I'm gonna need a citation on Google's usage of ElectricSQL, considering that the link points to Firebase Data Connect.

Re: Electric (Postgres sync engine) beta release

#46
post #19
post #14

Earlier quoted context omitted.

It doesn't always work, but I like the SQLite model: the core offering is free and open source, but enterprises can pay for things like * Professional support, including on-prem hosting when applicable * Additional features that enterprises care about (encrypted databases, SSO) * Compliance documentation/certifications

How big of a business is SQLite?

Big enough to keep the developers happy to keep working on it. That is all that matters.

Re: Electric (Postgres sync engine) beta release

#47
post #23

I 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. T…

I'm curious on how you'd configure this. Is it common (and safe) to let a cdn cache private data for authenticated users?

Say Jira used electric, would you be able to put all tickets for a project behind a cdn cache key? You'd need a cdn that is able to run auth logic such as verifying a jwt to ensure you don't leak data to unauthorized users, right?

Re: Electric (Postgres sync engine) beta release

#48
post #14
post #10

I 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…

It doesn't always work, but I like the SQLite model: the core offering is free and open source, but enterprises can pay for things like * Professional support, including on-prem hosting when applicable * Additional features that enterprises care about (encrypted databases, SSO) * Compliance documentation/certifications

This is how DuckDB is structured too:

DuckDB Labs: The core contributors. Instead of developing features that will be behind a paywall, they provide support and consulting.

DuckDB Foundation: A non-profit that ensures DuckDB remains MIT licensed.

0 - https://x.com/thisritchie/status/1797962367571239309

Re: Electric (Postgres sync engine) beta release

#49
post #23

Earlier quoted context omitted.

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. T…

I'm curious on how you'd configure this. Is it common (and safe) to let a cdn cache private data for authenticated users? Say Jira used electric, would you be able to put all tickets for a project behind a cdn cache key? You'd need a cdn that is able to run auth logic such as verifying a jwt to ensure you don't leak data to unauthorized users, right?

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).

Re: Electric (Postgres sync engine) beta release

#50
post #45

Just 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?

Yeah, I'm gonna need a citation on Google's usage of ElectricSQL, considering that the link points to Firebase Data Connect.

https://www.npmjs.com/package/firebase-tools?activeTab=depen...
Post reply on HN