
A Guide on how to find a GPU Database that’s just right for you - pgv
http://www.brytlyt.com/resources/articles/gpu-database-guide/
======
oliwarner
68 points, no comments, on a _blatant_ advert?

It makes me feel sorry for developers around the world whose managers read
this. They're going to see that flow diagram at the end and be all like "Well
my database is big and I want speed... and JSON-OMG-WEBSCALE!", which'll
translate into an email instructing the immediate migration to Brytlyt.

Having a boss who reads HN is a dangerous thing.

~~~
arnon
You know what? It's even worse.

They took /my/ article, refashioned it, and inserted themselves in!

[https://hackernoon.com/which-gpu-database-is-right-for-
me-6c...](https://hackernoon.com/which-gpu-database-is-right-for-
me-6ceef6a17505)

Also, they flat out don't understand MapD, Kinetica or SQream if they say
Kinetica and SQream DB don't support nested queries (because they do).

~~~
pgv
Nested queries are great but I am far more interested in the other features
mentioned. I could be wrong but I as far as I am aware MapD, Kinetica and
SQream don't have all of these covered?

~~~
arnon
Some do, some don't. It's not as simplistic as that.

Saying "Do you need a large amount of Data?" and then saying not to use GPU
databases ignores SQream's experience in managing more than 1PB of data, and
Kinetica's experience in clustering multi-TB machines.

~~~
pgv
I thought the flow diagram was promoting the use of GPUs for large datasets...
Brytlyt is a GPU database right?

------
chitwan
Interesting article, I think I saw the graph on LinkedIn as well.

