This kind of comment shows how little knowledge you have about NoSQL and SQL. Is not a SQL vs NoSQL, it's about using the right technology for the job.
The question is perfectly valid. In many scenarios (not necessarily Stripe's), PostgreSQL is fast enough to do the job. Stop putting people down for legitimate engineering questions.
Try not to be condescending and your point will be better received. "Right technology" as I'm sure you're aware, has as much to do with subjectivity as appropriateness. Familiarity, workflow, ease of use (and did I mention familiarity?) cannot be overstated even when the perceived benefits are considered.
Read: religion.
Some of the people who rally against NoSQL may be deriding it from a knee jerk reaction, however others are simply frustrated with developers who, as Ted Dziuba would say, "value technological purity over gettin' shit done".
Relational databases were created in the first place to solve these very problems around transactionality and analytics for finance.
This library is a beautiful example of reinventing the wheel, and otherwise creating a patchwork of unnecessary - and ultimately brittle - infrastructure.
Where we use MongoDB, it's not because of speed. PostgreSQL is certainly capable of fast performance. MongoDB is useful for its ability to log freeform data as well as for its replication model. (We use sharded MongoDB in a few places, but mostly use straight replica sets.)
We use MySQL, MongoDB, PostgreSQL, and Impala. They're all useful in different places.
Thanks for the clarification, but this makes it even more obvious your engineering team is introducing needless complexity into your organization.
Postgres can store unstructured data just fine, so you have a 'solution' that uses 3 OLTP stores instead of one.
Making developers productive is an important aspect for choosing a database.
More important questions are how is the data stored, how is it accessible, how can you scale the system, what operational constraints are there, how fast is it, what types of data modeling can be done, what consistency/transaction guarantees does it provide, etc. These are the things that will make developers productive because they will not be putting out fires all the time.
How are you liking Impala? We just dropped 0.5 release yesterday which includes the JDBC driver :D!
Edit: Awesome job on the Ruby client, it's great!
I've been meaning to write a MoSQL equivalent for our Impala data, but at the moment we're doing a more traditional ETL.
I've passed your comment on to Colin, who wrote the Ruby client -- I'm sure he'll appreciate it!
Thanks for the kind words!
These are the same guys who built hstore, full text search, GIN and GIST indexes and I think are working on a generic regular expression index type right now.
There is absolutely no reason to make banking system on GT.M but they did.
Although: GT.M is the only(?) NoSQL that is ACID-compliant.
Yes there is. PostgreSQL doesn't support multi master replication which makes it a terrible choice if you really want to make sure every transaction gets written. I really wonder at what point people that keep recommending PostgreSQL are going to wake up and realise what is happening in the industry.
People are scaling OUT not UP. Especially startups.
Many startups would be using AWS and it is not inconceivable that you would have Multi-AZ/Multi-Region VPSs. Scaling out != Expensive.
Startups need to scale out because many of them like to deploy on mediocre EC2 instances with the slowest SAN storage ever.
People that keep recommending PostgreSQL are rightfully ignoring this industry.
No. They need to scale out because providers like AWS have outages. And so startups et al need to deploy in multiple AZ/regions in order to have as close to 100% uptime as possible. You can't do that with a well considered multi master style replication strategy which PostgreSQL frankly doesn't have.
>People that keep recommending PostgreSQL are rightfully ignoring this industry.
Sure. And soon enough they will be relegated to the dustbins of history. The trends don't lie.
Wah. And you do not even seem to be ironic. Trends always lie, there is always a next thing that will take the opposite direction, in philosophy, in science, and particularly so in computing stuff.
You could build something like that on top of SQL, but it's nice to have a tool where you don't have.
I'm imagining with this tool you start to need to be a bit more careful with the flexibility which initially drew you to mongo.
If you need the data in SQL, you can either parse the JSON somehow, or rebuild the SQL table with a MoSQL schema that knows about the new fields.
In the situations you describe, and when using most NoSQL databases, there's still a schema. It's just stored in the minds of developers, in documentation that's correct and up-to-date, in documentation that is incorrect and outdated, throughout application code, and numerous other places.
Then there's the sensible approach taken by most relational database systems, where the schema is centralized, it is described with some degree of rigor, and it can be more safely modified and managed.
A Postgres bouncer + WAL replication achieves a similar result: There is no downtime on failover, but there is a single slave.