31–40 of 50 posts
If you're interested in this, here are some related projects that all take slightly different approaches: - LiteSync directly competes with Marmot and supports DDL sync, but is closed source commercial (similar to SQLite EE): https://litesync.io - dqlite is Canonical's distributed SQLite that depends on c-raft and kernel-level async I/O: https://dqlite.io - cr-sqlite is a Rust-based loadable extension that adds CRDT…
I can totally see some junior dev who doesn't fully grok transactions (and not reading/understanding the "What happens when there is a race condition?" section), trying to deploy something like this and scratching their head why it falls over completely in production. The site worked fine when it was just me testing it! This is a neat proof of concept and I encourage experimentation. But, if you're developing somethi…
I completely agree with your analysis. Understanding the complexities of achieving convergence with basic auto-increment counters without advanced CRDT types is 101 IMO. Those familiar with these issues inherently comprehend the challenges involved. While it's plausible for someone to leverage a library atop Marmot to construct and synchronize such types, it's important to note that this tool isn't tailored for junio…
I posit that if you're at that scale, you're figuring out how to get distributed postgres to work and not messing with things like Marmot.
I can totally see some junior dev who doesn't fully grok transactions (and not reading/understanding the "What happens when there is a race condition?" section), trying to deploy something like this and scratching their head why it falls over completely in production. The site worked fine when it was just me testing it! This is a neat proof of concept and I encourage experimentation. But, if you're developing somethi…
There’s a reason that this is called “hacker news” and not “just use the industry standard for the last 3 decades news”. Won’t downvote you for giving pragmatic advice, but I appreciate projects like this that slap together disparate technologies for an interesting goal, even if it isn’t the best choice for your usual Fortune 500 company.
That's exactly why I said: "This is a neat proof of concept and I encourage experimentation."
Nobody pushes an application out just once.
I see a lot of projects started in this space and all of them appear to have multi-writer as a goal. I've been interested for a long time (and have started and stopped) in a solution for single-write multi-read with eventual consistency. I chatted with @benbjohnson on a LiteStream ticket about the possibility of adding a mobile client to receive the replicas to mobile devices but I think that option isn't really cons…
I can totally see some junior dev who doesn't fully grok transactions (and not reading/understanding the "What happens when there is a race condition?" section), trying to deploy something like this and scratching their head why it falls over completely in production. The site worked fine when it was just me testing it! This is a neat proof of concept and I encourage experimentation. But, if you're developing somethi…
If you absolutely need to distribute data, it means you're working at a scale where things are already complex.
Using SQLite for that will not simplify your life, it will just make it harder to tackle the complexity.
Unless you are extremely careful, eventually consistent writes are almost guaranteed to produce behaviors that are hard / impossible to anticipate during development. And a PITA to debug.
I'm using Marmot for my own website on production. Up to this date there were no problems. If I had any technical issues (i.e. questions, optimizations etc) I always asked the developer maxpert and he gave me in-depth answers that helped me personally a lot. In my case I have much love for Marmot and hopefully it grows and helps a bigger community
Earlier quoted context omitted.
If you let juniors design and deploy a DB layer to prod it's your fault not the DBs. Transaction isolation is generally complicated topic that a lot of senior devs have a pretty tenuous grasp on ime and distributed Postgres solutions don't solve this particularly well either last I checked
> If you let juniors design and deploy a DB layer to prod it's your fault not the DBs. Some companies only have juniors. 28 years ago, I was the junior at my company, and the first/only engineer. Let's also be real here, most applications don't need distributed Postgres either and those that do, will have senior engineers on staff.
i'm surprised by this.. No schema changes? Nobody pushes an application out just once.
If you're interested in this, here are some related projects that all take slightly different approaches: - LiteSync directly competes with Marmot and supports DDL sync, but is closed source commercial (similar to SQLite EE): https://litesync.io - dqlite is Canonical's distributed SQLite that depends on c-raft and kernel-level async I/O: https://dqlite.io - cr-sqlite is a Rust-based loadable extension that adds CRDT…
That plus a globally incrementing version number is what I want…