News for hackers. Stuff that matters.
Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by hazaskull on Sunday December 08, 2024 @06:37AM (#42356567)
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.

Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by fweimer on Sunday December 08, 2024 @06:44AM (#42356596)
Not sure about the CLA process, but the database is already under a restrictive, proprietary license:

    ## Free Trial
    
    Use to evaluate whether the software suits a particular
    application for less than 32 consecutive calendar days, on
    behalf of you or your company, is use for a permitted purpose.

https://github.com/yugabyte/yugabyte-db/blob/master/licenses...

It's not really clear what this means (what is a permitted purpose?), but it seems the intent is that after 32 days, you are expected to pay up. Or at least prepare for a future when the infrastructure to charge customers is in place (if it isn't there yet).

Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by hazaskull on Sunday December 08, 2024 @06:48AM (#42356606)
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
Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by senorsmile on Thursday December 19, 2024 @04:06PM (#42465691)
It also mentions: > By default, the build options generate only the Apache License 2.0 binaries.

So, it seems like the proprietary builds are for the managed services that they host themselves, which makes sense.

Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by sgarland on Sunday December 08, 2024 @11:58AM (#42358205)
> DDL timeouts

That’s normal for building indices on large tables, regardless of the RDBMS. Increase the timeout, and build them with the CONCURRENTLY option.

> Query speed

Without knowing your schema and query I can’t say with any certainty, but it shouldn’t be dramatically slower than single-node Postgres, assuming your table statistics are accurate (have you run ANALYZE <table>?), necessary indices are in place, and there aren’t some horrendously wrong parameters set.

Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by franckpachot on Monday December 09, 2024 @04:57PM (#42370987)
Index creation should not be controlled by statement timeout, but backfill_index_client_rpc_timeout_ms which defaults to 24 hours. May have been lower in old versions