3 ms·

So how easy is it to distribute it? I don’t have experience with it but the tutorials look terrible compared to, say, Scylla, Yuga, Cockroach, TiDB etc. Again,

So how easy is it to distribute it? I don’t have experience with it but the tutorials look terrible compared to, say, Scylla, Yuga, Cockroach, TiDB etc. Again, honest question?

rad_gruchalski 2y ago
Pongo seems to be a middleware between your app and Postgres. So it will most certainly work absolutely fine on YugabyteDB, if one’s okay with occasional latency issues. One could optimise it more for a distributed sql by implementing key partition awareness and connecting directly to a tserver storing the data one’s after.
- oskar_dudycz 2y ago
  Yes, as long as database has support to JSONB and JSON path syntax (so PG 12 >= compliant) you should be good to go :)
  - rad_gruchalski 2y ago
    It could work: https://docs.yugabyte.com/preview/explore/ysql-language-features/jsonb-ysql/ https://docs.yugabyte.com/preview/explore/ysql-language-feat....
theteapot 2y ago
Does "distributed" mean sharded or just replicated? In either case it's a bit quirky but easy enough. > Scylla, Yuga, Cockroach, TiDB etc. You have experience "distributing" all these DBs? That's impressive.
- anonzzzies 2y ago
  We evaluated these over the years for different purposes/clients. And I don’t expect the ‘quirky’ part in 2024 I guess; it gets hard of course when the loads get specific; but in general I expect things to be automatic (multi master, sharding and replication) and simple to set up. Point out other nodes and done.
Too 2y ago
It couldn’t be simpler. Just configure all clients and servers to be aware of each other and go. Say what you want about the rest of mongo. This is an area where it actually shines.
- anonzzzies 2y ago
  Alright, I'll try it. Maybe I had the wrong tutorials or maybe these were old.
tracker1 2y ago
Relatively easy... though, and I may be out of date, you have to choose replication or sharding at any given level... so if you want horizontal scale plus redundancy, you will wind up with slightly more complexity. My experience trying to recover a broken cluster after 5 hours of Azure going up/down in series was anything but fun. Would have to test, but the library for this post may well work with CockroachDB if you wanted to go that route instead of straight PostgreSQL. I think conceptually the sharding + replication of other DBs like Scylla/Cassandra and CockroachDB is a bit more elegant and easier to reason with. Just my own take though.
- karmakaze 2y ago
  I don't see any point in emulating MongoDB (NoSQL) document store on CockroachDB (NewSQL) which is already sharded and replicated.
  - redwood 2y ago
    Right if you want to use a sharded and replicated system with a document data model, might as well use the real thing rather than introduce the risk and impedance mismatch of an emulation layer. The whole point here is for folks to not have to have the cognitive and performance downsides of a tabular data model

So how easy is it to distribute it? I don’t have experience with it but the tutorials look terrible compared to, say, Scylla, Yuga, Cockroach, TiDB etc. Again, honest question?

rad_gruchalski 2y ago

Pongo seems to be a middleware between your app and Postgres. So it will most certainly work absolutely fine on YugabyteDB, if one’s okay with occasional latency issues. One could optimise it more for a distributed sql by implementing key partition awareness and connecting directly to a tserver storing the data one’s after.

oskar_dudycz 2y ago
Yes, as long as database has support to JSONB and JSON path syntax (so PG 12 >= compliant) you should be good to go :)
- rad_gruchalski 2y ago
  It could work: https://docs.yugabyte.com/preview/explore/ysql-language-features/jsonb-ysql/ https://docs.yugabyte.com/preview/explore/ysql-language-feat....

theteapot 2y ago

Does "distributed" mean sharded or just replicated? In either case it's a bit quirky but easy enough. > Scylla, Yuga, Cockroach, TiDB etc. You have experience "distributing" all these DBs? That's impressive.

anonzzzies 2y ago
We evaluated these over the years for different purposes/clients. And I don’t expect the ‘quirky’ part in 2024 I guess; it gets hard of course when the loads get specific; but in general I expect things to be automatic (multi master, sharding and replication) and simple to set up. Point out other nodes and done.

Too 2y ago

It couldn’t be simpler. Just configure all clients and servers to be aware of each other and go. Say what you want about the rest of mongo. This is an area where it actually shines.

anonzzzies 2y ago
Alright, I'll try it. Maybe I had the wrong tutorials or maybe these were old.

tracker1 2y ago

Relatively easy... though, and I may be out of date, you have to choose replication or sharding at any given level... so if you want horizontal scale plus redundancy, you will wind up with slightly more complexity. My experience trying to recover a broken cluster after 5 hours of Azure going up/down in series was anything but fun. Would have to test, but the library for this post may well work with CockroachDB if you wanted to go that route instead of straight PostgreSQL. I think conceptually the sharding + replication of other DBs like Scylla/Cassandra and CockroachDB is a bit more elegant and easier to reason with. Just my own take though.

karmakaze 2y ago
I don't see any point in emulating MongoDB (NoSQL) document store on CockroachDB (NewSQL) which is already sharded and replicated.
- redwood 2y ago
  Right if you want to use a sharded and replicated system with a document data model, might as well use the real thing rather than introduce the risk and impedance mismatch of an emulation layer. The whole point here is for folks to not have to have the cognitive and performance downsides of a tabular data model