marmot VS rust-postgres

If you're willing to accept eventual consistency (a big ask, but acceptable in some scenarios) then there are options like marmot [1] that replicate cdc over nats.

[1]: https://github.com/maxpert/marmot

I've written a whole SQLite replication system that works on top of RAFT ( https://github.com/maxpert/marmot ). Best part is RAFT has a well understood and strong library ecosystem as well. I started of with libraries and when I noticed I am reimplementing distributed streams, I just took off the shelf implementation (https://docs.nats.io/nats-concepts/jetstream) and embedded it in system. I love the simplicity and reasoning that comes with RAFT. However I am playing with epaxos these days (https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf), because then I can truly decentralize the implementation for truly masterless implementation. Right now I've added sharding mechanism on various streams so that in high load cases masters can be distributed across nodes too.

Very interesting! I have question ( out of my experience in https://github.com/maxpert/marmot ) how do get around the boot time, specially when a change log of table is pretty large in Postgres? I've implemented snapshotting mechanism in Marmot as part of quickly getting up to speed. At some level I wonder if we can just feed this PG replication log into NATS cluster and Marmot can just replicate it across the board.

One of the reasons I started writing Marmot (https://maxpert.github.io/marmot/) was for replicating bunch of tables across regions that were read heavy. I even used it for cache replication (because who cares if it’s a cache miss, but a hit will save me time and money). It’s hard to make such blue prints in early days of product, and by the time you hit a true growth almost everyone builds a custom solution for multi-region IAM.

Amazing I was just looking for a good mail server to configure for my demo. Which reminds me since you folks have mentioned LiteStream, have you tried Marmot (https://github.com/maxpert/marmot); I recently configured Isso with Marmot to scale it out horizontally (https://maxpert.github.io/marmot/demo). I am super curious what kind of write workload on a sub thousand people organization will have and if Marmot can help scale it horizontally without Foundation DB. I always find the the convenience of SQLite amazing.

Great that you brought it up. I will fill in the perspective of what I am doing for solving this in Marmot (https://github.com/maxpert/marmot). Today Marmot already records changes via installing triggers to record changes of a table, hence all the offline changes (while Marmot is not running) are never lost. Today when Marmot comes up after a long offline (depending upon max_log_size configuration), it realizes that and tries to catch up changes via restoring a snapshot and then applying rest of logs from NATS (JetStream) change logs. I am working on change that will be publishing those change logs to NATS before it restores snapshots, and once it reapplies those changes after restoring snapshot everyone will have your changes + your DB will be up to date. Now in this case one of the things that bothers people is the fact that if two nodes coming up with conflicting rows the last writer wins.

For that I am also exploring on SQLite-Y-CRDT (https://github.com/maxpert/sqlite-y-crdt) which can help me treat each row as document, and then try to merge them. I personally think CRDT gets harder to reason sometimes, and might not be explainable to an entry level developers. Usually when something is hard to reason and explain, I prefer sticking to simplicity. People IMO will be much more comfortable knowing they can't use auto incrementing IDs for particular tables (because two independent nodes can increment counter to same values) vs here is a magical way to merge that will mess up your data.

For C there should be good options.

For Rust it doesn't appear that well-supported.

A very simple approach is to poll for changes using `pg_logical_slot_get_changes()` - that should work with any driver. That's what I used for my initial experimentation, before switching over to the streaming replication protocol for better performance.

The streaming replication protocol is not that complicated, but currently you'll have to handle some of the low-level protocol yourself, or work with some very experimental implementations. There's a project to help get you started at [1], and some more discussion at [2].

For the logical decoder, wal2json is quite nice to experiment with, but I've found pgoutput is not that complicated and gives you something closer to the raw data.

[1]: https://github.com/seddonm1/logicaldecoding/

[2]: https://github.com/sfackler/rust-postgres/issues/116

This is a bit of a rant so please bear with me. I wrote a small utility program a long time ago that used this version of the postgres crate

En este post aprendermos a usar Rust, Tonic y la crate gRPC, y implementaremos un CRUD con Postgresql database.

I can understand that this can be frustrating and I know that the situation there is not ideal for diesel. There are certainly things to improve there by either providing a bundling support which builds the native library as part of the normal build process or by implementing a pure rust connection implementation. Both is possible with diesel, but requires some work. At least the pure rust connection implementation is something that can be provided by a third party crate now with upcoming diesel 2.0 release. If you are interested in that checkout this and this issue. As for the bundling support: This requires changes in the mysqlclient-sys and pq-sys crates. Again help there is welcome. In the end it makes me sad that some people have repeating decided that a solution to this problem is to write just another crate instead of helping to fix these issues. This just results in everyone have more work to do, as there are now two non-perfect solutions instead of having one slightly improved solution.

We created this little library to have a fully native type for Postgres Numerics with the rust-postgres (https://github.com/sfackler/rust-postgres) library.

The problem with a crate like postgres is that you have to define the types of the query at compile-time. And if you use the simple query protocol in postgres, you just get a bunch of strings, i.e. no proper typing at all. However, for maximal flexibility arbitrary queries should work in pigeon, without knowing the database schema.

Some nifty things about usual: - It's a generic wrapper over any SQL "row" object. The first implementation that's provided is for tokio-postgres, but traits are available to implement over whatever you'd like. - It provides static typing for partial queries. That is, it supports fetching a subset of fields from a row and makes a unique type for the return value. This gives you some neat-o type safety like this:

In this post, we will learn how to use Rust Tonic gRPC crate. We will learn how to implement CRUD with Postgresql database.

(see: https://github.com/sfackler/rust-postgres/blob/e15c9b1415f69821799f1370246581c1600a6196/postgres-protocol/src/types/mod.rs#L137)