I'm working on a startup that connects to databases. Interested in finding out what the most popular DBs are for HN users. Can't list em all so add others in comments to be voted up.
No background process like mysql or pgsql. Thus helps me run on cheap ram. _IF_ it grows and gains traction, then switch to a better db, which until now has not happened. So I haven't thought about the "better db" i mentioned above.
I had a similar idea when I built RubyFlow - http://www.rubyflow.com/ - it's a Ruby community link site. Some people thought it was an amateur hack at the time.
However, RF does about 80,000 pageviews per month, has over 1000 registered users and gets about 10 posts a day, and SQLite hasn't proven a problem whatsoever. It's hardly a big project but it's bigger than 90% of small, part-time projects that use technologies that are more advanced than they really need.
Object-relational impedance mismatch crossed SQL and other tabular engines. Bad OLTP performance for complex operations ruled out key-value stores. Dismal performance ruled out XML databases. Also built-in schema-aware compression was a major drive.
It's a proof-of-concept other people will find useful when I get around to make it presentable.
We're using Oracle much against my desires. While this was before I was there, they hit some issue with mySQL and someone in charge at the time (no longer there) pushed us to get Oracle to fix all the world's problems. Its too expensive and doesn't do enough of what we need unfortunately.
Interesting that MongoDB has, at time of writing, more than 4 times the users of CouchDB. Both are document-based and have a JavaScript query language. MongoDB came out last year and CouchDB in 2005.
to some extent, I decided to use couchdb because I trust apache with server stuff. I've slotted mongodb in for testing next time I have the luxury of time, though.
MongoDB, at least at first glance, seems easier to install than CouchDB. The Erlang dependency might be a little off-putting. That could easily explain it's apparent greater popularity.
For me that was one of the turn-offs of CouchDB, that it had been around since 2005 and still was not considered to be production-ready as late as last year.
Despite being alpha (and now beta), CouchDB's been in production at a number of installations for years without issue.
Because the #1 goal is reliability, we've hesitated to recommend production use, until the most recent release (0.11). CouchDB 1.0 ships this summer, and is definitely a safe place to put your data.
I have used both. I implemented a prototype back-end in CouchDB, and it worked well for this purpose, allowing me to get up and running quickly. But I found that I needed a couple of things that they didn't support - for example, I wanted to integrate with an existing authentication system rather than use the built-in CouchDB one. It became clear that I would have to write my own middleware layer in Python or similar. Once I had made that decision, I had lost the simplicity that is CouchDB's most compelling feature and I felt I was missing out in other ways - CouchDB's REST API is less flexible than MongoDB's programmatic API for example. So I switched to MongoDB.
I'd say both gave me exactly what I needed at different times, and so I recommend both projects highly, depending on what you need. CouchDB is an excellent tool to quickly "mock up" a live back end, and a great way to learn hands on with document stores with very little upfront effort required. MongoDB seems to integrate better as part of a larger system, and provides more flexibility.
http://wasitup.com uses Tokyo Tyrant, but I'm nearly finished with a rewrite to Redis. Tyrant was abandoned because of a nearly non-existent community, poor documentation, and some replication issues.
Redis was selected over MongoDB and Cassandra since it scales down, is lightweight (with virtual memory enabled memory is not an issue anymore), and extremely easy to install and manage.
At Mugasha we are musing MySQL and Redis. We recently started using redis to store a lot data related to our social features (activity stream, user suggestions, dashboard views). It also acts as a caching layer since data is stored in memory. I plan on developing many of our new features on top of redis as data store. We'll continue to use MYSQL as our db for persistence and manageability (backup/durability) sake.
MySQL for day to day stuff/existing software, Postgres for a new project, and Sqlite for unit testing (since it has an in memory database, which is awesome).
Playing around with the document/NoSQL databases, but nothing in production yet.
I'd love to chat sometime about SQL Server and your experience storing massive amounts of analytics data. We're king of in the same boat. We've started to play with Windows Azure to manage the load. My email is in my profile details.
I like to make predictions about things, so my completely uninformed prediction is you're building an analytics app of some kind. there's lots of timestamped data sitting around in databases these days. might be nice to visually display it better.
another cool area might be analysis of data structures to predictably suggest better schemas for faster results, or better database engines, for example.
Looked at using it for an app I've been hacking on. Getting it to market seemed faster to do on a traditional rdbms, but I may migrate later once I incorporate collaborative filtering. Just curious if anyone has significant experience with it :)
67 comments
[ 3.1 ms ] story [ 127 ms ] threadYou must mean Derby..
No background process like mysql or pgsql. Thus helps me run on cheap ram. _IF_ it grows and gains traction, then switch to a better db, which until now has not happened. So I haven't thought about the "better db" i mentioned above.
However, RF does about 80,000 pageviews per month, has over 1000 registered users and gets about 10 posts a day, and SQLite hasn't proven a problem whatsoever. It's hardly a big project but it's bigger than 90% of small, part-time projects that use technologies that are more advanced than they really need.
It's a proof-of-concept other people will find useful when I get around to make it presentable.
Because the #1 goal is reliability, we've hesitated to recommend production use, until the most recent release (0.11). CouchDB 1.0 ships this summer, and is definitely a safe place to put your data.
I'd say both gave me exactly what I needed at different times, and so I recommend both projects highly, depending on what you need. CouchDB is an excellent tool to quickly "mock up" a live back end, and a great way to learn hands on with document stores with very little upfront effort required. MongoDB seems to integrate better as part of a larger system, and provides more flexibility.
Redis was selected over MongoDB and Cassandra since it scales down, is lightweight (with virtual memory enabled memory is not an issue anymore), and extremely easy to install and manage.
Playing around with the document/NoSQL databases, but nothing in production yet.
another cool area might be analysis of data structures to predictably suggest better schemas for faster results, or better database engines, for example.
I wonder how many in the "Other" category are SQLite as well.
Looked at using it for an app I've been hacking on. Getting it to market seemed faster to do on a traditional rdbms, but I may migrate later once I incorporate collaborative filtering. Just curious if anyone has significant experience with it :)