31–40 of 72 posts
Eagerly awaiting the React Native compatible version. https://zerosync.dev/ is the main alternative I'm considering.
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?
Earlier quoted context omitted.
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 rout…
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?
Earlier quoted context omitted.
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.
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?
This is really amazing as is their standalone pglite project, which is a WASM port of Postgres. One surprise for me though is that Electric is a read only replica. In particular, “Electric does read-path sync. It syncs data out-of Postgres, into local apps and services. Electric does not do write-path sync. It doesn't provide (or prescribe) a built-in solution for getting data back into Postgres from local apps and s…
We use Hasura as the read engine. That updates a graph of mobx objects that drive the ui. We apply updates directly to those objects so the ui updates immediately. The mutations are posted back to a Python api that applies them to the db.
I’ve looked at Electric because we’ve had to recreate some of what they do to interface with Hasura. At the moment it’s a non-starter because we use pg views to shape the data for the frontend.
This is really amazing as is their standalone pglite project, which is a WASM port of Postgres. One surprise for me though is that Electric is a read only replica. In particular, “Electric does read-path sync. It syncs data out-of Postgres, into local apps and services. Electric does not do write-path sync. It doesn't provide (or prescribe) a built-in solution for getting data back into Postgres from local apps and s…
We hit on exactly the same pattern for our product and it works really well. We use Hasura as the read engine. That updates a graph of mobx objects that drive the ui. We apply updates directly to those objects so the ui updates immediately. The mutations are posted back to a Python api that applies them to the db. I’ve looked at Electric because we’ve had to recreate some of what they do to interface with Hasura. At…
Earlier quoted context omitted.
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 rout…
This is interesting. Can you go into a bit more detail on why the WASM decompiling would be helpful as opposed to just using the native codebase?
It also allows us to implement a VFS layer underneath PGlite in a native mode. So things like the in-memory VFS, or a custom VFS, would be possible.
We have not committed to one route or the other yet.