Just to put some light into the Vertica licenses
-All development,homologation or desaster sites (they are under the initial production License – no extra money)
-Raw data size based (valid to store up to some amount of raw data) -License is only applied to the RAW data loaded – once loaded it can be replicated as many times as you like.
-Term-based (valid until a specific date).
-Both term-based and data-size-based.
-Unlimited duration and data storage(perpetual).
-Community version will only allow you to create a 3 nodes cluster and a max of 1TB(no bkp available 🙁 – and others things are as well not possible)
And yes price may vary as per location and demand – i think is all bout the way you negotiate.

I am not a HP Vertica rep, so i have no intend of convincing anybody.

More recent slides mention significant price decrease to $20K/TB
http://www.slideshare.net/sasindia/future-of-analytics-is-here-15616679

Of course both of these can’t be a reliable source, so only way to know if to call Vertica sales and generate them one more lead.

Hi Henrik,
I am so happy you asked me this, well you see like i said is not compression is encoding and it comes by default if your run a Database Designer(is a Vertica built-in tuning tool- or at least i call it like that) not like Oracle where you need to specify it.
Just to make it clear i love Oracle database and i think it holds an important role on the market and Vertica is not here to replace any rdbms, here is the key of great system arch – make the best of each tech( as they serve a purpose )
I will try to apply the compress types and see the results. Just to remind you that any compression will require decompression so more cpus etc… Encoded data is read as it is !

Hi Fadi,
Just wanted to complete the previous post with a simple example:
We have the table EMPS with 46.000.000 rows (1.2G of raw data)
Example of the data content :
1,Torres,F,FR,Brainbox
2,Ortiz,F,VG,Mudo
…..
….
Once i load it into Vertica and apply all the encoding(i choose the best for my data type) the entire 46 millions rows of data will occupy only 1.1MB of space on my disk !
See table definition
CREATE PROJECTION emps_tt
(
id ENCODING RLE,
last_name ENCODING RLE,
gender ENCODING RLE,
country ENCODING RLE,
company_name ENCODING RLE
)
AS
SELECT id,
last_name,
gender,
country,
company_name
FROM public.emps
ORDER BY gender,
country,
last_name,
company_name,
id
UNSEGMENTED ALL NODES;

And used space:
dbadmin=> select row_count,cast((used_bytes/1024/1024) as float(2)) as MB from v_monitor.projection_storage;
row_count | MB
———–+——————
46000000 | 1.172

##Now let’s do this in Oracle(just as an example)- this is a an Exadata machine:##
– we loaded the data quite fast :).
select
segment_name table_name,
sum(bytes)/(1024*1024) table_size_meg
from dba_extents
where segment_type=’TABLE’
and segment_name = ‘EMPS’
group by segment_name;

TABLE_NAME TABLE_SIZE_MEG
—————– ————–
EMPS 1516

Table definition:

create table emps (
id int,
last_name varchar(30),
gender char,
country varchar(3),
company_name varchar(30)
);

So at the end of the data loading we get a 1516 MB os used space in Oracle and 1.1MB in Vertica – that is quite a space consumption difference ! don’t you think ? (and just to remember you that no indexes were created on the Oracle table!)
Again the space consumption ratio depends on your data type(of course i have used a data type that helped me make a point).
If in any ways i am wrong please fell free to correct me.

Hi Fadi,
Well that is the key to a fast result set !
Like i said we have compressed data and encoded data, the compressed data will require some extra cpu cycles while retrieved, but most of the times Vertica uses encoding as i describe in this article http://www.aodba.com/tut_output_mysql.php?tut=6&page=vertica , encoding creates a smaller footprints and by doing this data retrieval will be faster.
And maybe your concept of columnar databases is not up to date, as columnar mixed with Vertica’s technology(projections) will enable only the data that is in the predicates reach to be retrieved, not like ordinary RDBMS that unless there is an index present will need to read all the block in order to get the results.
I hope i was clear 🙂

I wonder if that highly compressed data is really an advantage. Wouldn’t that mean more load retrieving it? After all, there is no point in storing the data if you don’t intend to retrieve it at some point.

Cristian B — Do you have a source for your figure?

Foo — Infobright and InfiniDB are niche players compared to leaders such as Vertica.