That was pre AI. Nowadays lots of browsers popping up with AI guidance like Ladybird and Blitz, both of which have experienced developers leading them rather than AI slop.
Lots of people say they're building their new home, meaning it's a new construction, not that they're literally laying the bricks. Same with software now too.
ZeBridge delivers to the client the (PG) enabled tables, replicates the schema locally (SQLite, PGLite, DuckDB tables), seeds them, and handles Postgres supported migrations. Local mutations are optimistic, durably queued (locally) and on (re)connection submitted to Postgres for the authoritative decision, and then CDC are echoed back with a verdict.
ElectricSQL is a Postgres-to-client read synchronization engine. It can operate without a local SQL database: it streams selected data as shapes and the selected rows can be maintained as JS objects or maintained by the dev as materialised into a local database. The reverse flow is implemented by the application and its backend API; libraries can add optimistic updates and offline write handling. Electric then synchronizes the resulting Postgres changes back to clients.
You also have PowerSync: it synchronizes the backend data into a local SQLite database using a schema supplied by the application. By default, records are stored as JSON and exposed through SQL views. It also offers native SQLite storage: managed tables, currently in alpha, are created and migrated automatically, while raw tables require developer-managed creation and migrations. Local writes take effect immediately and enter a durable upload queue. The SDK invokes a developer-provided uploadData() function to send those writes to the application’s backend API, which validates and applies them to Postgres. Authoritative changes then return through PowerSync’s synchronization stream.
In conclusion, ZeBridge is therefore closer to PowerSync in its local database and queued-write model, but the responsibilities differ. ZeBridge delivers server-derived schemas and integrates mutation submission and verdict handling. PowerSync manages local SQLite and the upload queue while the application supplies its client schema and backend write logic. Electric focuses on distributing Postgres changes, leaving client storage and the write path to the surrounding application stack.
How do you handle syncing? Due to not many good options I resorted to putting a CRDT in my database on client and server side and then running their sync functions on every change but I wish Postgres had integrated CRDTs.
So yes, the core of that wish is built: a small CRDT that PostgreSQL itself merges, so not a general-purpose library: not for cooperative editing at the text/character level as I don't need this. Two people typing in the same text field at once still end with one winner. For collaborative text you still want Yjs or Automerge.
The sql function `zebridge_enable(register_cols => ARRAY['doc'])` installs a BEFORE INSERT OR UPDATE trigger that merges each accepted write into the stored document register by register. The client runs the same merge code. It’s “CRDTs integrated in Postgres” without running sync functions on both sides.
Reads: a client seeds, records its position in each stream (NATS) so resumes where it stopped, off-line or not.
Writes: are applied locally plus into an outbox entry in one transaction, sent when online, and a verdict per write (accepted, stale or rejected). The result reaches every client through the change stream above. There’s no client-to-client protocol: PostgreSQL is the single merge point, and clients receive the merged row.
Conflicts: 2 levels, last-writer-wins per row, and an opt-in map of last-write-wins inside a json column. Two editors changing different fields of one record both survive. Two changing the same field: the newer edit wins. It works like Cassandra’s per-cell timestamps, or Figma’s per-property multiplayer.
Each field of the document is a precise register {"v": value, "t": timestamp, "w": writer}. In PG, the trigger `zebridge_merge_registers_t` merges every accepted write, register by register. A write can only add or advance registers, so a late offline write can’t roll back fields others changed meanwhile. In the client library, `mergeRegisters`.
Thanks. Yeah there's always LWW but modern CRDT libraries are way more advanced than that including intelligent merges so wondering if there was something closer to that in Postgres. By the way all your comments are showing up as dead which I have to vouch.
The engineers wouldn't have made world changing products without his guidance. There are many books about this, even by the employees themselves such as Creative Selection and Insanely Simple, which talk about how Jobs' product vision simplified much of the UI and UX and therefore product for regular users when engineers instead wanted to add more features and complexify the product. Steve was not just a salesman handed a product and asked to sell it.
Steve Jobs said no. No to 'stupid' ideas and no to 'cannot be done'. That leads to some products being bad (eg mac cube) and other to be interesting to build on (iphone with no app SDK).
The Mooncrash DLC specifically is one of the best pieces of gaming available. It turns the base game mechanics into a Rogue-like where the world resets but some things in the world still stay persistent.
While I like that DLC, I think it loses what makes these games so great to play: the feeling of exploration and slowly uncovering a story. Moon crashes repetition and time limits don't quite do it for me (although I still really recommend it to anyone).
reply