I had the pleasure of chatting with Spencer the other day, great guy. We're still very opposite in database tradeoffs that we believe in, but it joys me that at least both ends of the spectrum are covered in the OSS community. As I've expressed before, I don't think Master-Slave globally strongly consistent databases are the direction the future is headed, but at least if I'm wrong ;) we'll have Spencer & Co(ckroach) to save the day for Open Source (hearing his vision and emphasis on OSS was very refreshing and affirming too, especially after the last year of database announcements/failures/crippleware).
So they have definitely won my heart over, although I'll still make critiques where appropriate. This particular article was very well done, thoughtful, and insightful. So thank you! Being Postgres wire compatible is a daunting task though, one that to me seems unnecessary (we're implementing SQL on top of our decentralized graph database, but not at the wire level). But it once again showcases our polar opposite views. Obviously, their extra effort will result in remarkably better SQL compatibility, performance, and experience. So they are the hands up winner, but I'm curious to see the extent of full SQL use (versus approximations) in the industry over the next decade.
pgwire compatibility is a huge benefit to us. Not all of us want to use this year's hottest language, so it's nice when we can use an existing library and immediately get to work. I would strongly recommend anyone who is making a database from scratch to either: write libraries for every popular language so people can use it (don't do this) or interface with one of the many existing protocols that has been thoroughly tested and has strong support across many platforms (do this.)
Maybe I'm out of my depth here, but I'm not sure your comparison of CockroachDB SQL being "wire level" whereas your SQL is "on top of a decentralized graph" makes much sense. CockroachDB is built on a key value store. More on that here: https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mappin...
I suspect your technology, too, would be built on something similar? The difference being in how you implement the "front end."
That is a really good point. There are a lot of really incredible drivers for different languages out there, and reusing them is a major selling point.
Right, the difference being is no SQL would actually be sent over the wire. The SQL parsing happens on the client (so it is front end only), then it is converted to our wire graph spec, and then sent out. So it is more SQL emulation/approximation. Even though CockroachDB is key/value underneath, they are actually running SQL on top. Which is why their system would always be better than ours.
You sound really smart! If you are interested in these things, you should jump in on your favorite DB projects, or start your own!
So they have definitely won my heart over, although I'll still make critiques where appropriate. This particular article was very well done, thoughtful, and insightful. So thank you! Being Postgres wire compatible is a daunting task though, one that to me seems unnecessary (we're implementing SQL on top of our decentralized graph database, but not at the wire level). But it once again showcases our polar opposite views. Obviously, their extra effort will result in remarkably better SQL compatibility, performance, and experience. So they are the hands up winner, but I'm curious to see the extent of full SQL use (versus approximations) in the industry over the next decade.
Congrats guys, great article.