<div dir="ltr"><div><br></div>To add something to this thread that also exists but seems to be quite ignored:<div>Take a look at <a href="https://github.com/ztmr/egtm">https://github.com/ztmr/egtm</a> which uses <a href="http://www.fisglobal.com/products-technologyplatforms-gtm">http://www.fisglobal.com/products-technologyplatforms-gtm</a>.</div>
<div><br></div><div>It's an ACID Schema less store engine (with M language as a really powerful 'stored procedure' engine).</div><div><br></div><div>Extract from the website:</div><div><p style="font-size:12px;color:rgb(51,51,51);line-height:17px;max-width:686px;font-family:Arial">
The GT.M data model is a hierarchical associative memory (i.e., multi-dimensional array) that imposes no restrictions on the data types of the indexes and the content - the application logic can impose any schema, dictionary or data organization suited to its problem domain.* GT.M's compiler for the standard M (also known as MUMPS) scripting language implements full support for ACID (Atomic, Consistent, Isolated, Durable) transactions, using optimistic concurrency control and software transactional memory (STM) that resolves the common mismatch between databases and programming languages. Its unique ability to create and deploy logical multi-site configurations of applications provides unrivaled continuity of business in the face of not just unplanned events, but also planned events, including planned events that include changes to application logic and schema.</p>
<p style="font-size:12px;color:rgb(51,51,51);line-height:17px;max-width:686px;font-family:Arial">Worldwide, GT.M is used in multiple industries, including finance, health care, transportation, manufacturing and others. GT.M supplies the processing power to the FIS Profile™ enterprise banking application.</p>
<p style="font-size:12px;color:rgb(51,51,51);line-height:17px;max-width:686px;font-family:Arial"><br></p><p style="font-size:12px;color:rgb(51,51,51);line-height:17px;max-width:686px;font-family:Arial">And about the proven stability of this tool, you can look at <a href="http://www.fisglobal.com/products-technologyplatforms-gtm-historyofgtm" style="font-family:arial;font-size:small;line-height:normal">http://www.fisglobal.com/products-technologyplatforms-gtm-historyofgtm</a></p>
<p style="font-size:12px;color:rgb(51,51,51);line-height:17px;max-width:686px;font-family:Arial"><br></p></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 11:01 AM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wednesday, June 18, 2014 17:21:19 Lloyd R. Prentice wrote:<br>
> postgeSQL<br>
> - consider when: you want to use a battle-tested relational data store.<br>
<br>
</div>battle-tested (aka reliable), yes. there are key/value stores that are also<br>
pretty reliable, however.<br>
<br>
the real benefit (imho) of pgsql is ACID properties combined with 'advanced'<br>
features such as stored procedures / triggers and custom data types.<br>
<br>
as for speed, it's a dead-heat with mysql in real-world work loads. this has<br>
been the case for a number of years now, and is generally acknowledged by the<br>
people working on the respective projects.<br>
<br>
however, providing ACID properties makes some action unavoidably slower than<br>
straight-up key/value stores that do not offer those properties.<br>
<div class=""><br>
> - reject when: your data needs are more key-value oriented or free form/less<br>
> structured.<br>
<br>
</div>these days, that isn't really accurate. others have pointed out that pgsql now<br>
has key/value storage (hstore) and this is getting better in every release.<br>
heck, it even has a json datatype these days. you can mix and match key/value<br>
data with structured data in the same table, which is pretty interesting.<br>
<br>
the real challenge with pgsql for larger applications imho is horizontal<br>
scalability. not many projects REALLY require that, but for those that do<br>
pgsql is not the best choice right now.<br>
<br>
replication is still a developing feature set within pgsql and perhaps the<br>
most promising solution is currently a third-party semi-fork called Postgres-<br>
XC:<br>
<br>
        <a href="http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki" target="_blank">http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki</a><br>
<br>
i personally haven't used Postgres-XC in any sort of production env so i can't<br>
vouch for its completeness or how well it meets the claims its developers<br>
make, but it seems to be on a good track. (esp compared to the architecture of<br>
other solutions in use with pgsql databases)<br>
<br>
this is quite similar to how full text indexing ended up making its way into<br>
pgsql: first as third-party enhancements, then eventually (after several years)<br>
folded into pgsql proper. i expect horizontal scalability features to make<br>
their way into pgsql sometime in the next 5 years, probably based on this or<br>
another 3rd-party pgsql add-on. but right now these features are not part of<br>
pgsql itself and are still in-development.<br>
<br>
tl;dr -> horizontal scalability is probably the most significant weak point for<br>
pgsql right now.<br>
<br>
p.s. i've written non-trivial applications (inc one or two i'd actually call<br>
"enterprise" apps with a relatively staight face)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aaron J. Seigo</font></span><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>