Today, we are releasing MoSQL, a tool Stripe developed for live-replicating data from a MongoDB database into a PostgreSQL database. With MoSQL, you can run applications against a MongoDB database, but also maintain a live-updated mirror of your data in PostgreSQL, ready for querying with the full power of SQL.

Yesterday a Ruby on Rails SQL injection vulnerability was announced which affects all versions. This immediately received widespread attention on Hacker News. Unfortunately the announcement doesn’t clearly explain how the vulnerability exactly works, which caused a lot of confusion and unnecessary panic, especially among people who are less familiar with Ruby or Rails.

Here are the facts, along with a clear explanation for non-Rails people.

You never develop code without version control, why do you develop your database without it?

LiquiBase is an open source (LGPL), database-independent library for tracking, managing and applying database changes. It is built on a simple premise: All database changes are stored in a human readable yet trackable form and checked into source control.

Over time, though, my initially rosy feelings towards ORMs have begun to sour. I gradually realised I was spending a disproportionate amount of time trying to coax the ORM into doing my bidding - and when I succeeded, the results were often ugly, slow and needlessly opaque. Analysing the performance of some of the more complicated portions of my data access layer was often painful, and I spent cumulative hours poring over generated SQL, trying to figure out what the ORM was doing and why. Usually, improving performance involved side-stepping the ORM altogether. Recently, a particularly gnarly performance issue prompted me to ditch the ORM from a project altogether, with surprisingly pleasant results.

Unprecedented data volumes are driving businesses to look at alternatives to the traditional relational database technology that has served us well for over thirty years.

Collectively, these alternatives have become known as “NoSQL databases.”

Brief overview of non-relational databases follows.

1. CRUD is crud. The fundamental activities of Create, Read, Update and Delete are fundamentally wrong-headed. Updates to data should never be allowed, because they destroy information and Deletes should never be allowed for the same reason. When data changes the database should just add another record and note (by any mechanism that works) the previous value for that record. If the database gets too large then data should be archived from it. The right set of activities is thus CRA, Create, Read, Archive.

Of course the answer is “it depends”, but that’s not very helpful. Let me ask you a few questions to help you figure out which technology is appropriate to your particular application. Then I can give a few pointers so that you can find out more.

The movement's chief champions are Web and Java developers, many of whom learned to get by at their cash-strapped startups without Oracle by building their own data storage solutions, emulating those being built by Google Inc. and Amazon.com Inc., and which they subsequently released as open source.

Now that their open source data stores manage hundreds of terabytes or even petabytes of data for thriving Web 2.0 and cloud computing vendors, switching back is neither technically, economically or even ideologically feasible.

Like the Patriots, who rebelled against Britain's heavy taxes, NoSQLers came to share how they had overthrown the tyranny of slow, expensive relational databases in favor of more efficient and cheaper ways of managing data.

Object identity is deceptively hard to implement correctly when objects are persisted to a database. However, the problems stem entirely from allowing objects to exist without an id before they are saved. We can solve these problems by taking the responsibility of assigning object IDs away from object-relational mapping frameworks such as Hibernate. Instead, object IDs can be assigned as soon as the object is instantiated. This makes object identity simple and error-free, and reduces the amount of code needed in the domain model.