31–40 of 43 posts
Great that nobody can track, or easily contribute to, the underlying postgres bug, because postgres has no issue tracker. Keeps the number of reported bugs nice and low. The discussion of critical bugs that lose your data is left to HN and Twitter threads instead.
Earlier quoted context omitted.
Yugabyte is Postgres compatible, not actually Postgres. It's also only compatible insofar that you can use only a subset of Postgres features, as they're only supporting the most basics things like select, views etc Triggers, notifys etc were out of scope the last time I checked (which has admittedly been a while)
You're right of course, it's not entirely compatible, but this might be interesting: > We use vanilla Postgres as-is for the query layer and replace Postgres storage with YugabyteDB’s own distributed storage engine. https://www.yugabyte.com/blog/yugabytedb-enhanced-postgres-c...
I feel like thats not actually a distinction that matters to application developers, because they know thats just a technical detail that only concerns the developers of the database. Ultimately, all the compatibility has to be implemented in the storage engine. The fact that they're using Postgres's porcelain is surely a time saver for them, but of no consequence to the consumers/users of the database
Couldn't one simply define kubernetes network policies to limit egress from CockroachDB pods?
It would be awesome if you could do the same test with Stolon!
Is there any alternative to Jepsen that does not involve writing spaghetti Clojure code?
Writing Clojure without spaghetti isn't too hard, and definitely more practical than waiting for a Jepsen alternative to come along. The Jepsen author gave a great talk on all the performance engineering work that has gone into it, Jepsen is near enough an entire DBMS in its own right https://www.youtube.com/watch?v=EUdhyAdYfpA
I just really couldn’t justify Clojure in my project and personally if I want Lisp, I know where to find it.
Is anyone here using YugabyteDB for high-availability Postgres? It seems like a compelling option: * Much closer to Postgres compatibility than CockroachDB. * A more permissive license. * Built-in connection manager [1], which should simplify deployment. * Supports both high availability and geo-distribution, which is useful if scaling globally becomes necessary later. That said, I don't see it mentioned around here…
I was under the impression that Yugabyte requires signing a CLA to contribute which leads me to avoid it for fear of them relicensing the thing when the VC's start squeezing. Also: very unique and single vendor driven. Seems like too much of a risk longer term but that is just my take. EDIT: in response to your question I did run a PoC of it but it had issues where I wasn't able to create very large indexes without t…
Is anyone here using YugabyteDB for high-availability Postgres? It seems like a compelling option: * Much closer to Postgres compatibility than CockroachDB. * A more permissive license. * Built-in connection manager [1], which should simplify deployment. * Supports both high availability and geo-distribution, which is useful if scaling globally becomes necessary later. That said, I don't see it mentioned around here…
Yugabyte is Postgres compatible, not actually Postgres. It's also only compatible insofar that you can use only a subset of Postgres features, as they're only supporting the most basics things like select, views etc Triggers, notifys etc were out of scope the last time I checked (which has admittedly been a while)
Is anyone here using YugabyteDB for high-availability Postgres? It seems like a compelling option: * Much closer to Postgres compatibility than CockroachDB. * A more permissive license. * Built-in connection manager [1], which should simplify deployment. * Supports both high availability and geo-distribution, which is useful if scaling globally becomes necessary later. That said, I don't see it mentioned around here…
I'm curious about this as well. I often see people talk about CockroachDB in production, but I don't think I've ever heard of anyone running Yugabyte. But it is definitely under active development. I found two threads discussing it from the past year: https://news.ycombinator.com/item?id=39430411 https://news.ycombinator.com/item?id=38914764 Yugabyte (as with CockroachDB and TiDB) is based on mapping relations to an…
Please see this blog https://www.yugabyte.com/blog/chaos-testing-yugabytedb/ for latest updates, as well as information on additional in-house built frameworks for resiliency and consistency testing.
Is anyone here using YugabyteDB for high-availability Postgres? It seems like a compelling option: * Much closer to Postgres compatibility than CockroachDB. * A more permissive license. * Built-in connection manager [1], which should simplify deployment. * Supports both high availability and geo-distribution, which is useful if scaling globally becomes necessary later. That said, I don't see it mentioned around here…
One thing possibly holding some folks back is the version of Postgres it's held back to. Right now YDB has PostgreSQL 12 comparability. Support for PG15 is under active development, so hopefully it's a 2025 feature. I really wanted to be able to actually use YugabyteDB for once, but our developers reportedly are using PG15+ features. https://github.com/yugabyte/yugabyte-db/issues/9797
Is anyone here using YugabyteDB for high-availability Postgres? It seems like a compelling option: * Much closer to Postgres compatibility than CockroachDB. * A more permissive license. * Built-in connection manager [1], which should simplify deployment. * Supports both high availability and geo-distribution, which is useful if scaling globally becomes necessary later. That said, I don't see it mentioned around here…
I'm curious about this as well. I often see people talk about CockroachDB in production, but I don't think I've ever heard of anyone running Yugabyte. But it is definitely under active development. I found two threads discussing it from the past year: https://news.ycombinator.com/item?id=39430411 https://news.ycombinator.com/item?id=38914764 Yugabyte (as with CockroachDB and TiDB) is based on mapping relations to an…
The first upgrade is the hardest, but after that we will have the framework in place to perform consecutive upgrades much sooner. When the pg11 to pg15 upgrade becomes available it will be in-place online without affecting the DMLs, no other pg fork offers this capability today.