You can't trust much in this particular corner of the internet.
How many people are monitoring the blockchain in that way - sounds like an app idea.
Through these giant waves of expansion, they've kept their trade engine running quickly (people have described a few brief periods of slower operation, but it never affected me).
A lot of folks discount them because they're in Eastern/Central Europe, but really Slovenia's business environment shares more with Germany than it does the rest of Eastern Europe.
All in all, I think Bitstamp is doing a great job.
Checked with the team and we couldn't find any interaction matching that description. http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_...
We work with a community of security researchers who help us test these sort of things https://coinbase.com/whitehat including quite a lot on race conditions. We use a variety of datastores for different parts of the app where they are best suited.
Some people view this as a problem, personally I view this as a benefit. Because of them being a little bit sketchy, they don't ask for ID verification and offer some services, margin trading for example that other exchanges do not due to legal complications. As long as you use it as an exchange and not as storage I think it's perfectly fine.
http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_...
Why is MongoDB bad? It's not ACID compliant. It's hard to determine the state of the database with concurrent processes attempting to modify its data. Given the explanation it's fairly clear that it's Coinbase being talked about.
(Also, MongoDB is like the worst NoSQL data store out there for a task like this.)
It makes sense to use mongodb for commenting system where nobody cares if you lose a comment or certain comments are written before others.
But no competent architect would use mongodb for financial/currency transactions.
If coinbase did use mongodb, it will be inevitable they will have transactional issues. The more popular coinbase gets, the more transactions they process, the more issues they'll have. I don't envy the poor souls that have to track down these kinds of issues...
It's not particularly likely to eat your data or kill you as you get started, and the ecosystem is relatively unified which means consistent and generally good best practices documentation. Becoming a Postgres expert could take a lifetime as the database offers an astonishing depth of features, but it won't bite you if you just use the basics. Plus the source is quite good if you ever find the urge to dig deep.
A couple of gotchas might bother you. You'll need to implement your own strategy for upserts if you need those. But you do get robust native support for popular data types commonly seen in today's apps: geographic data as well as document data (via HStore or JSON).
The MySQL/MariaDB family is well-proven as well, but with tens of available storage engines, two core forks, and a bit of non-standard SQL magic sprinkled throughout it's harder for a beginner to learn the best practices IMO.
The challenge comes once you exceed what one machine can do and want to move beyond the simple client(s) <-> (possibly replicated) server model. Keep in mind that depending on your project, this might not ever happen to you. Certain types of mid-sized sites like Basecamp and Stack Exchange have gotten away with throwing bigger hardware at their database systems.
If or when you reach the point where you need a distributed database, you have to choose between consistency and availability. I'll let the experts explain some of those concepts by linking to this excellent article by Coda Hale: http://codahale.com/you-cant-sacrifice-partition-tolerance/ . That's when you'll find yourself in the NoSQL world - many NoSQL databases are useful in that they try to trade consistent for available in some way or another. While they generally fail completely to actually do so, as illustrated in Kyle Kingsbury's excellent "Call Me Maybe" series, the largest -scale systems are all based on a "NoSQL" data store in some way or another.
Having said all of that on my personal site I actually use RethinkDB because it is delightfully easy to setup and code against (I just persist my Go structs to the db and don't worry about a relational schema to maintain) and I don't really care about data integrity there, so I don't mind that RethinkDB is relatively new and untested. So one size doesn't fit all, but PostgreSQL is still, IMO, generally the "safest bet" if you do care about data integrity and don't want to spend hundreds of thousands of dollars on licensing to scale it up.
If you do want to experiment with NoSQL databases, MongoDB is probably the easiest to get going with (which is why it is so widely used). However, you seem statistically unlikely to be in the group that is happy with MongoDB in production :-)
HBase has a much brighter future for the NoSQL use cases (and is even getting SQL support!)
From the point of view of NoSQL data stores, it'll really depend on your application needs, and I can't give you a full overview, buuuut.... Amazon did a solid job with its DynamoDB database, and Apache Cassandra did a solid job cloning it. I believe I've also heard decent things about the sanity level of Redis and Hypderdex.
It is loosely based on the Dynamo paper like most modern distributed databases, but Dynamo and DynamoDB are very different things.
Riak could be another interesting option in that space. Redis is more adapted for small datasets with high workloads and low durability expectations (i.e. do not host a Bitcoin exchange purely on it unless you really know what you are doing :p).
Else you're better off with NoSQL (I found CouchDB amazingly easy).
The problem here is that developers not taking the time to understand their application and how their tools work. Yes, MongoDB gives you enough rope to hang yourself and I certainly wouldn't suggest using it for a financial ledger, but you could have a durable application based on it if you really wanted to.
However if developers of a financial system cant grasp the need for atomicity in the transaction path then they're going to be buggering things up all over the place.
Tokutek engineers are top notch.
If you are even thinking about following any of the advice on that page, you are no longer in the MongoDB use case: you plainly need transactions.
In particular, dijit asserted that "Not ACID => Not secure" (which is debatable, but that doesn't matter here) from which you can also validly deduce the contrapositive "Secure => ACID". However, you then (sarcastically) asserted that dijit is saying "ACID => Secure", whereas in fact he said nothing like that.
That being said, I don't think a schemaless database is really appropriate for carefully considered (or what should be carefully considered) financial data.
I dislike MongoDB, but if I had to try to summarize objectively:
1) It is marketed very heavily, including to use cases to which it is poorly suited
2) It can be very complicated to run in production, I think because it actually wasn't originally designed to be distributed.
3) It has a history of data loss. I think this is because it generally favors performance over reliability, combined with #1 and #2
I have run it in production, thrown over the fence by some dumb devs who believed the lies that "you don't need a DBA". Well you need a full time team and a lot of hardware, and that's comparing it to Oracle.
What about other NoSQL solutions?
MOST other NoSQL solutions actually do things like treat their index differently than their bulk data so that it isn't accidentally swapped out, ruining performance. Many also do important things like supplying durable writes. (Your data may not be consistent at any one given moment, but it'll get there.)
Trust is a slow process.
For example, they need to know where do you get your money from, and if it's from mining, they want copies of bills for the mining rigs, and so on.
But you have to have robust systems first.
There is also the huge problem that they do not have MSB licenses in the US, so it's only a matter of time until Florida or NY sues them, or demands the arrest and extradition of the owners for not complying with US laws yet still allowing American customers.
Foreign services stopped dealing with US residents because last year new FBAR and FATCA compliance rules went into effect, requiring US taxpayers to provide more information about their foreign assets, and the US signed numerous new agreements with most major nations to share data about U.S. account-holders (agreements under which either nation could demand specified information about account-holders in the other nation as if they were domestic institutions) Many European banks stopped doing business with Americans because it was a paperwork nightmare to deal with the compliance.
The Final Rule requires each foreign-located MSB to appoint a person residing in the United States as an agent for service of legal process with respect to compliance with the BSA and its implementing regulations.
Translation: Bitstamp, if they take $1 from an American customer are now required to register with FinCen, possibly apply for licenses (nobody has figured this out yet at the bitcoin foundation) and have an agent based in the US to oversee legal compliance. I haven't heard of Bitstamp doing this. Use at your own risk.
Just like you don't worry about crazy laws in Saudi Arabia or Kuwait that prohibit drinking alcohol.
They can try and press the UK, but that, at best, will only result in Bitstamp moving its headquarters to a different country, which would result in a ton of taxes leaving too.
They can and do go after banks that have subsidiaries in the US. They also can pressure those banks that don't by going after their affiliates that do.
These exchanges have to have a certain amount of capital set aside and can't simply disappear with account holder's money if they get hacked due to incompetence.