Let me ask you this - how would I use citusdb in such a way that it does not become a tax on my growth?
In other words, big data usually precedes big revenue, but most data products are priced per datum not per revenue.
So to put in indelicately, who can afford this and if they could, why would they? (after all those who could afford it, eg: bloomberg have strong reasons not to)
Umur from Citus here. Our goal is to make CitusDB an enabler for your growth by making scaling out simple for you and your dev, ops and analyst teams. If we've made it a tax instead and haven't saved you significant time, effort and complexity in the process, we're not doing our job.
At a practical level, we offer several ways to accomplish this:
- We provide free, open-source extensions on standard PostgreSQL (pg_shard, cstore_fdw)
- We provide a free community edition of CitusDB for added functionality (e.g. massively parallel analytic queries, distributed joins)
- For enterprises, we provide a sitewide, unlimited license of CitusDB Enterprise. For smaller projects there, we provide support and a per-node license.
- For start-ups, we provide a flat rate of CitusDB Enterprise irrespective of your data volume.
The right approach depends on the company and the use-case. Either way, and given the quick time-to-deployment, any of the approaches should end up as a major cost saver.
One big difference seems to be that Oracle RAC uses a shared disk for each node. This means you need a fast disk. Oracle ships a lot of data between RAC nodes so you need a fast interconnect between your nodes (e.g. infiniband).
After a very cursory look, isn't the answer to download and use one of Citus' free, open source extensions to the free, open source postgres? (Depending on your use-case either pg-shard or cstore-fdw)
In other words, big data usually precedes big revenue, but most data products are priced per datum not per revenue.
So to put in indelicately, who can afford this and if they could, why would they? (after all those who could afford it, eg: bloomberg have strong reasons not to)