We are using successfully  H2 1.4.x in production for almost 2 years in a 
big organization with 300 of users.  It's an embedded database behind GIS 
desktop system which is a main tool these 300 users are using daily. So, 
very business critical case :) Data (spatial data) is taken from central 
database (Postgre) and delivered to H2 where all kind of CRUD operations 
are performed.  Changes are collected and synchronized back to central 
database.

We always compile H2 from code with minor local changes optimizing the 
performance for certain SQL scenarios (probably some improvements are worth 
to contribute to master branch). PageStore mechanism is used. So far the 
biggest problem was the performance  and stability of BLOB/CLOB types. 
Since we got rid of them towards VARBINARY/VARCHAR types  the number of 
corrupted database cases dropped to almost 0. Actually it was mistake to 
use BLOB in datamodel design from the beginning, once I have learned better 
H2 internals an understanding that BLOB is not needed in our case solved 
the majority of database corruption cases from users.

There is so much to do still in H2, but it's great  Java product, thanks to 
developers! 

P.S. Our optimizations concerned nested selects like  .... WHERE FK_COLUMN 
IN (SELECT... ) . Often when index exists for FK_COLUMN, parent table 
contains 200000 records and nested SELECT retrieves thousands of values 
implementation is not optimal; I try to write soon about this case with a 
patch suggested.

-- 
You received this message because you are subscribed to the Google Groups "H2 
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Reply via email to