3 ms·

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 immed

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-mapping-table-data-to-key-value-storage 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."

marknadal 9y ago
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!
- lwansbrough 9y ago
  > 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. Ahh I see, interesting. > You sound really smart! ... you should jump in on your favorite DB projects Hah, thanks. We're working on our own product at the moment. Not directly DB related, but because we're bootstrapped we're making an serious effort to address the cost, efficiency, and scalability of our choices. Being able to somewhat quickly try out a given database has some real benefits. Would be nice if more databases shared libraries - I suspect everyone would benefit from that rather substantially.

marknadal 9y ago

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!

lwansbrough 9y ago
> 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. Ahh I see, interesting. > You sound really smart! ... you should jump in on your favorite DB projects Hah, thanks. We're working on our own product at the moment. Not directly DB related, but because we're bootstrapped we're making an serious effort to address the cost, efficiency, and scalability of our choices. Being able to somewhat quickly try out a given database has some real benefits. Would be nice if more databases shared libraries - I suspect everyone would benefit from that rather substantially.