[erlang-questions] Web app back-ends

[Aaron J. Seigo]

On Wednesday, June 18, 2014 17:21:19 Lloyd R. Prentice wrote:
> postgeSQL
> - consider when: you want to use a battle-tested relational data store.

battle-tested (aka reliable), yes. there are key/value stores that are also 
pretty reliable, however. 

the real benefit (imho) of pgsql is ACID properties combined with 'advanced' 
features such as stored procedures / triggers and custom data types.

as for speed, it's a dead-heat with mysql in real-world work loads. this has 
been the case for a number of years now, and is generally acknowledged by the 
people working on the respective projects.

however, providing ACID properties makes some action unavoidably slower than 
straight-up key/value stores that do not offer those properties.

> - reject when: your data needs are more key-value oriented or free form/less
> structured.

these days, that isn't really accurate. others have pointed out that pgsql now 
has key/value storage (hstore) and this is getting better in every release. 
heck, it even has a json datatype these days. you can mix and match key/value 
data with structured data in the same table, which is pretty interesting. 

the real challenge with pgsql for larger applications imho is horizontal 
scalability. not many projects REALLY require that, but for those that do 
pgsql is not the best choice right now.

replication is still a developing feature set within pgsql and perhaps the 
most promising solution is currently a third-party semi-fork called Postgres-
XC:

	http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki

i personally haven't used Postgres-XC in any sort of production env so i can't 
vouch for its completeness or how well it meets the claims its developers 
make, but it seems to be on a good track. (esp compared to the architecture of 
other solutions in use with pgsql databases)

this is quite similar to how full text indexing ended up making its way into 
pgsql: first as third-party enhancements, then eventually (after several years) 
folded into pgsql proper. i expect horizontal scalability features to make 
their way into pgsql sometime in the next 5 years, probably based on this or 
another 3rd-party pgsql add-on. but right now these features are not part of 
pgsql itself and are still in-development.

tl;dr -> horizontal scalability is probably the most significant weak point for 
pgsql right now. 

p.s. i've written non-trivial applications (inc one or two i'd actually call 
"enterprise" apps with a relatively staight face)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140620/cf669c75/attachment.bin>