Hacker News new | ask | show | jobs
by bozoUser 2529 days ago
One way for YB to fight off the competition from AWS would be to include a clause that any forks of the DB should always be in sync with the upstream(master developed by YB), so hypothetically speaking this would mean companies that are using the AWS YB could always have the freedom to switch to using the OSS YB and only risk loosing the features that AWS has contributed to its fork and might actually force the OSS to keep up.

So goodluck YB.
1 comments
rkarthik007 2529 days ago
(founder/cto of YugaByte)

This is a very insightful suggestion, thanks for raising that! We had considered many of these variants until finally, we concluded that fully open is the best way.

PostgreSQL (which is the database on fire right now) got to this spot by being fully open and permissive - and embracing all forms of competition. In fact, PostgreSQL got rewritten from Lisp to C (which begs an interesting question - what is a database? The code or the query language? Anyway I digress).

We felt if we want to build something as foundational as PostgreSQL for the cloud, then we need to be as open.

link
bozoUser 2529 days ago
> We felt if we want to build something as foundational as PostgreSQL for the cloud, then we need to be as open.

Good intentions here, wish you guys the very best.

link
kjeetgill 2529 days ago
I think the reason open source helps adoption is because:

A) I can conveniently install it and work with it via apt, yum, dnf, etc. for free at home.

B) I trust that the product will remain alive as long as its interest and users are, not when funding runs out.

Who wants to put time into vaporware? I don't want to pay for it until I know it's good and that it'll be around. I don't think being hostile to AWS takeover with change adoption.

link
sansnomme 2529 days ago
Can you explain more about the rewrite from Lisp?
link
sidch 2529 days ago
Postgres was first written in Lisp and had to be re-written in C because of slow performance [1]. YugaByte DB reuses the same C-based Postgres query layer but runs it on a Google Spanner-inspired distributed document store written in C++. The goal of this new “rewrite” is to add horizontal write scaling, native failover/repair and geo-distribution. As long as users love the language they interact with, the underlying software will continue to see such re-writes in order to meet the needs of the current times.

[1] https://thenewstack.io/the-slow-climb-of-postgres-and-the-va...

link