Poll: What database does your startup use? | Hacker News Reader

Poll: What database does your startup use?

74 pointsdaniel_levine63 comments

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.

View on HN

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.

Google AppEngine datastore?

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.

Sqlite :-)

the power of sqlite is often underrated, jetty too.

I totally agree, and just consider how many "instances" of sqlite are deployed with all the mobile applications using it.

> jetty too.

You must mean Derby..

nope I was citing jetty as an undervalued embedded library

My policy: launch apps on Sqlite.

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.

Redis

http://www.swfstats.com/ = SQL Server, planning to shift the heavy bits to MongoDB though.

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'd also like to know how you are approaching this... We're also working on a SQL Azure project but still in the beginning phase

I'm really not working with a massive dataset, the data's aggregated and not real time so I'm not actually operating on ~7b rows heh.

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.

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.

TokyoCabinet/Tyrant

how was working with tyrant, I hear english docs blow? any comparison to couchdb?

Hey Dan, We started off hosting on Heroku, which at the time defaulted to using postgres. It now supports mysql as well I believe. We never really needed to worry about the db using a framework like Rails.

In my experience, MySQL and PostgresSQL are both awesome choices, and the community support behind them is huge.

Anybody out there using neo4j?

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 :)

An alternative: http://github.com/stevedekorte/vertex.js

I just saw a 10-week software engineering class project use Neo4j. I'm not convinced that deployment is as hard as you might believe.

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 love how everyone is weighing in with which DBs are the best without actually mentioning the usage or deployment patterns. You can't discuss faults or merits without knowing what it's going to be used for!

where's Redis?

Added in comments. Vote that one up if you use redis.

Adding Redis later to the party was not fair ;)

I didn't want to list every db. But people can vote up your Redis comment as a proxy.

http://w3counter.com uses MongoDB capped collections which are aggregated into partitioned MySQL databases.

Does an in-memory scheme hashtable (backed to disk) count as a database? Does my lowly 2-hits-a-week app count me as a web startup?

MongoDB + Redis at http://bu.mp/. Some PostgreSQL for offline analytics later on.

PostgresSQL and Redis. A local SQLite database installed under "/dev/shm/" (i.e., really in RAM) is nice while programming.

You can also open a SQLite database with the filename ":memory:".

Yeah, but that is different. It will not persist past one use while I am working, it will not be usable across unix processes.

At the company I work at we are using MySQL but we are looking at moving some portions of our product to redis.

http://github.com/stevedekorte/vertex.js

We're a little company, but not really a startup so I didn't upvote above. We use DB2 and MongoDB, though.

Riak

Two stage Redis to Postgres.

The "two stage" process would make an interesting blog post, btw.

SQLite.

I wonder how many in the "Other" category are SQLite as well.

PostgreSQL in production, MongoDB and Redis in the pipeline...

A bunch, actually:

MySQL, PostgresSQL, SQLite, and SimpleDB.

Own.

Why?

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.

Which language(s) are you using for your application and db?

C and some prototyping on JavaScript for the DB. C++, C, and JavaScript/V8 for the server-side application.

Mongo is awesome.

HBase

PostgreSQL here, but full speed on our way to HBase. Why is it not on the list? It is quite big already.

Hypertable

Jetty

How so? Jetty is a servlet container, right?

Yea, you're right. Not sure how I got sidetracked into posting that.. This is what happens when I try to multitask :|

solr

Reply on news.ycombinator.com