hazaskull

I would imagine this was written by someone not from the US.

Thanks. I think that only covers the commercial bits they run themselves though:

  "The entire database with all its features (including the enterprise ones) is licensed under the Apache License 2.0


  The binaries that contain -managed in the artifact and help run a managed service are licensed under the Polyform Free Trial License 1.0.0."

EDIT: formatting

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 the statement timing out on me. Basic simple hand-benchmarking of complex joins on very large tables were very slow if they finished at all. I suppose systems like this and cockroach really need short, simple statements and high client-concurrency rather than large, complex queries.

Hi there! Thank you for the post and your work on pgzx! Though it depends on the system (cockroachdb can place leaders on specific nodes to speed up local queries, it has global tables and otherwise there's always follower-reads) those are of course valid reasons. Admittedly if you want to keep data "pinned", you're into manual placement, rather than horizontal scaling but that's nitpicking and there's pros and cons. I do enjoy the freedom of Postgres and am hopeful that its virtually prehistoric storage-design becomes a non-issue thanks to tech such as Neon and Orioledb. The option to decouple storage would provide wonderful flexibility for solutions like yours too I think.

Thank you for the correction. Indeed it is not entirely the same thing. Though I'd expect that at least the benefit of not having to read columns that aren't in the family would still help (haven't tried in earnest). I suppose compression is not an option though.

Indeed. As I commented alsewhere this is just about the general design. It is not targeting OLAP in this case (even though I do believe cockroach employs vectorization for reads)

No expert but I'd say you'd rather be looking at bigquery, Redshift, Clickhouse, Snowflake, etc.

They don't optimize for it and I suppose the data distribution is primarily aimed at parallel OLTP rather than OLAP. Just wanted to mention that design-wise it is similar but that's indeed not all there is to it. I'd be hesitant to store large volumes of data on a single PG instance; don't see how a single-writer, filesystem-based database is suitable at all for data that is large enough to warrant columnar storage

Not Postgres-based (but wire- and mostly syntax-compatible): cockroachDB using column families is much like a columnar MPP. Yugabyte is PG-based and MPP but not columnar.

...and then there is me using

  echo "75000000" | sudo tee /sys/class/powercap/intel-rapl/intel-rapl\:0/constraint_1_power_limit_uw 

to cap my i7-10700 to prevent it from overpowering the system fan by peaking to 200+ watts.

Not to say that I disagree with you in principle but I'd think there is a large difference between disagreeing with someone's opinions and disagreeing with someones values. You generally can't have a meaningful conversation in the latter case.

Personally I find the idea of a very small cartel of companies holding all the cards quite dystopian. There are certain people that I very much would not like to be in control of all that. Guess I'm not ready to accept the supposed inevitability of this end game.

The way I read it is simply a broadly applicable notion that a certain type of people will demonstrate their power and (perceived) higher status over others by openly breaking the others' rules without consequence. EDIT for better wording