What nosql database is ideal to use for storing code/snippets?

Question

I want to store code similar to how jsfiddle stores code. I currently use Postgres for my main database but I'm wondering if it's more ideal to be using a NoSQL database?

Code snippets for now will have just one author, but in the future there may be multiple authors and I want the ability for reverting as well.

I know there are key/value databases and document-oriented databases. Which specific noSQL db would suite my needs? Or should I still stick with my Postgres db?

FYI:

1. I'm using django
2. The users will be permanently stored in postgres ( I'm using openID )

Answer 1

As for NoSQL databases, the only ones I'm familiar with are XML (doesn't scale well and has bad concurrency), and local databases such as Paradox, dBase, FoxProx and Access. I would not recommend any of these.

I think that the idea that it's a NoSQL database should be a smaller factor in your decision. Consider these things instead.

• Redundancy. Can you run it on two servers at the same time or does it support failover? (SQL Server, Interbase, Firebird)

• Concurrency. Will you host this app on the web? How will it handle 10 concurrent operations? (PostGres, MySql, Interbase, Firebird)

• Speed. How long is acceptable for a lookup or post?

• Embeddability. Is this a desktop application? An embedded database can make things easier. (Local databases such as Paradox, dBase, FoxPro, Access, Interbase, Firebird or SQLite)

• Portability. Desktop apps may run on Mac, Linux, Windows. (SQLite)

Answer 2

You can't choose a non-relational data strategy without defining what you want to do with your data.

Relational database design comes from rules of normalization, which you can apply once you know your data alone. But non-relational database design depends on your queries more than your data.

But without knowing anything about your application, my first recommendation would be to stick with PostgreSQL. Store your code snippets in text blobs, and meta-data about the code (authorship, date, language, project, etc.) in additional columns alongside the text blob. Also you can consider using GIST indexes to allow for flexible searching.

You might also consider Apache Solr, which is technically similar to a document-oriented DBMS, though it is usually presented as a fulltext search engine.

Answer 3

Sounds like a relatively uncomplicated application which could be implemented in a traditional relational database or a NoSQL without too many problems.

However if you're keeping the userbase info in PostgreSQL, it would seem simplest to just stick with that as a single storage method. Using both an SQL database and a NoSQL adds complexity, makes joining across the datasets hard (so eg. you couldn't make a query to do something like 'list users along with their most recent document'), and makes it impossible to ensure consistency between the two datasets.

What do you get for this trouble? You want versioning. CouchDB will give you revision control, but it's questionable whether you should be using that for UI-level versioning (eg because compacting the database will lose your old versions).