Poll: What database does your company use?

697 points by daniel_levine ↗ HN
Upvote please if you think it's an interesting question so that more people will respond

Last year I asked this question (http://news.ycombinator.com/item?id=1411937) and I think it was useful to a bunch of people. Figured it's worth asking again and the diffs will be interesting.

377 comments

[ 2.3 ms ] story [ 290 ms ] thread
(comment deleted)
(comment deleted)
flat files!
My company uses actual filing cabinets that have actual physical files.
what kind of sharding scheme do you use?
Duh: Customers with a last name starting with A through E go in the drawer labelled A-E, etc. We just implemented a RAID 1+0 solution that involves a fleet of entry level workers furiously photocopying every document and putting them in boxes for Iron Mountain...
(comment deleted)
Do you work at an elementary school, by any chance?

I'm not trying to be a wise guy - it's more of a comment that elementary schools are often last to implement technologically savvy solutions (i.e. solutions that cost a lot of money), so I wouldn't be surprised if you said "yes" to my question.

In school before learning SQL I wrote my personal site's blog on engine my own flat file database hack. :) Fun times.
Likewise. Perl's DBD::CSV module was my greatest discovery - SQL queries across flat files! No joins though. :)
Me too... in Excel 95's VB for applications! fun times.
You should add the Neo4j (http://neo4j.org/) graph database to the list.

Graphs are a much more modern and elegant way of storing relational data. I've used Postgres for over 10 years, but it's not a graph database. With graph databases you don't have to mess with tables or joins -- everything is implicitly joined.

And Neo4j is ridiculously sweet -- store 32 billion nodes (http://blog.neo4j.org/2011/03/neo4j-13-abisko-lampa-m04-size...) with 2 million traversals per second (http://www.infoq.com/news/2010/02/neo4j-10), and you can use Gremlin with it (the graph traversal language), which let's you calculate PageRank in 2 lines.

Neo4j is open source, and the Community Edition is now free (https://github.com/neo4j/community).

I recommend pairing it with the TinkerPop stack (http://www.tinkerpop.com/).

(comment deleted)
We are also using Neo4j in an academic environment and we are really pleased with it. We recommend it despite of the lack of a good native binding Python, we had to build a neo4j-rest-client (https://github.com/versae/neo4j-rest-client) through REST API.
There is an open-source Python persistence framework in the works called Bulbs that connects to Neo4j through the Rexster REST server, and there are binary bindings in the works as well.

There is also a Python open-source Web development framework for graph databases called Bulbflow that is based on Bulbs and Flask.

Both frameworks should be released in the next few weeks.

> Graphs are a much more modern and elegant way of storing relational data.

Actually, storing data as graphs is older than relational approaches. It used to be called "network databases". They were not supplanted for the hell of it, relational databases have certain advantages.

For select applications, object databases are absolutely the way to go. But for most purposes relational is hard to beat.

For tabular data, relational databases rock. But the relational model doesn't align well with object-orientated programming so you have an ORM layer that adds complexity to your code. And with relational databases, the complexity of your schema grows with the complexity of the data.

The graph-database model simplifies much of this and makes working with the modern-day social graph so much cleaner.

Graphs allow you to do powerful things like find inferences inside the data in ways that would be hard to do with relational databases.

How would you calculate PageRank using a relational database? As I said, with a graph database and Gremlin, you can do it in 2 lines.

To see the types of things you can do with graphs, check out Marko's short screencast on Gremlin (http://www.youtube.com/watch?v=5wpTtEBK4-E).

And also check out Peter Neubauer's introduction to graph databases and how they compare to RDBMS' and where they stand in the NOSQL-movement (http://www.infoq.com/articles/graph-nosql-neo4j).

> But the relational model doesn't align well with object-orientated programming so you have an ORM layer that adds complexity to your code.

The mismatch comes about for a number of reasons:

    * OOP has no formal basis so it can't be reliably transformed into relational terms.
    * OOP is identity-bound -- each object is essentially
      an address in memory, not a relation in a set.
    * The biggie: OOP mixes data with behaviour.
      Relational does not.
> How would you calculate PageRank using a relational database? As I said, with a graph database and Gremlin, you can do it in 2 lines.

For something on PageRank's scale, a custom datastore based on matrices and their multiplication makes business sense. Or MapReduce over a distributed key-value store (note that these are both OLAP approaches).

Still. SQL's a bit verbose, but these days we have recursive queries. For Oracle users, I'm talking about CONNECT BY. If I find myself running the social graph every minute, I develop an ETL package that periodically moves data from my write-bound system to my read-bound system with a more query-friendly schema. Depending on how you look on it, relational systems invented "eventual consistency".

More to the point, boring old database greybeards have learnt that OLTP and OLAP are very different use cases. The 3/4/5NF of the OLTP database will be very different from the star schema of the OLAP database.

There's really not much about NoSQL that hasn't already been done, under a different name, by the relational crowd.

I still think there is a place for NoSQL. It's just not as universal a replacement for relational systems as many make it out to be, whether we're talking about document stores, distributed key-value stores, graph stores and so on.

The "NoSQL vs SQL debate" name will eventually change. Instead of isolating SQL from the other datastores, the debate will move toward discussing which database is the right tool for the job, where SQL/relational databases will have a specific role.

Putting relational databases into their own group is silly. I believe this came about because relational databases have dominated for so long, and this has caused developers to try and fit every problem into the relational database model.

In the early days of the Web, choosing a database meant choosing between relational database management systems -- Oracle was king but expensive, Microsoft SQL Server if you were on a Microsoft stack, and PostgreSQL or MySQL were the primary open-source options (with one being a real RDBMS while the other was basically just an SQL interface to the file system).

Ten years ago the RDBMS was the only good option so that's what everyone used even though many problems and programming languages didn't match up well with it -- it was like trying to fit a square peg in a round hole.

You don't have to do that anymore so relational databases can stop being the one-size-fits-all solution, and instead we can move toward using them for the specialized cases where they're the right fit.

We use MySQL mainly and also Redis a little bit. We will probably do more with Redis.

Also, we use S3 as database for some of our larger datasets where latency isn't a concern and are looking at either Mongo or HBase for large datasets that need faster performance.

Voted Oracle & Other (DB2)
(comment deleted)
What is it about Postgres that you don't like?
(comment deleted)
(comment deleted)
At TransLoc, we use MySQL and have set up a cluster of four nodes, using streaming replication across two data centers. It is something that all of us were familiar with and it almost, sort of, kind of support GIS functions, which is something we need.
I've been pleased with Postgres 9's streaming replication. We use postgres primarily for PostGIS.
+1 for PostgreSQL and PostGIS for Geospatial needs.
Legacy apps, Ingres.

All sorts of odd little things, SQL Server.

Various legacy data processing and newer data warehousing jobs, SAS.

New projects, in theory Oracle but there seems to be a degree of resistance. It'd be interesting to see how that pans out but I won't be around there much longer :)

Ingres is underrated, I find it quite ok to work with.
It might be good potentially but it certainly isn't as we're currently using it. Quite aside from the incredibly basic console apps we're having to use to browse and test against the DB server, performance isn't exactly its strong point and it has sometimes been crashed by running individual queries. I wasn't impressed.
In addition to PostgreSQL and Redis, we use Hbase.
Sybase & Oracle - in investment banking
We use KDB+ for anything speed-critical - not on the lists, so I voted 'other'
Are you guys watching the new Kona project? I'm excited about it.
SQLite all over the place – it's great having a super portable DB format for quick little hits.

There's nothing quite like sending a DB as an email attachment.

SQLite is so pervasive that I'm pretty sure everyone uses it at some point. It's in client applications, it's used by yum (the package manager found on CentOS/RHEL/Scientific Linux systems), it's part of many web applications, it's part of many spam filtering systems, it's part of Android (maybe iOS, too?), it's basically impossible to avoid it if you're a nerd.

Also, it's awesome.

SQLite is indeed built into iOS and Mac OS X as well. Core Data's store uses SQLite as an option (XML and Binary are the others), and it is accessible via third party frameworks like FMDB.
It's also built into Android.
Unfortunately, it's quite slow on Android. And make sure never to put your db on the sdcard, or else your whole phone becomes unusable while doing writes to the db.
SQLite is overall slow if you are writing item-by-item. Does not matter what platform you use. Write multiple items in single transaction. As well understand what you get and what you loose by writing all items in single transaction.
And iPhones, and BlackBerries. It is by far the most widely use relational DB in the world (despite what the MySQL people claim on their website, they're not even close)
Firefox uses it.
So does Chrome. Actually, this comes in handy: http://sqlite.org/famous.html
So good to see Sun's logo there :)
They should replace it with Oracle's logo now. Just for giggles.
Ouch, Php got a mention, but they snubbed Rails, despite the fact that it comes bundled ... DHH won't like that one bit!
At this point, it would be faster for them to just list the companies who aren't using sqlite.
Probably couldn't use the Rails logo because of stupid trademarking, so they left it off.
Rails doesn't bundle sqlite3, just lists it as a default dependency for new projects.
(comment deleted)
Also damn useful when plugged into NHibernate for bringing up test cases using in memory databases for performance.
Love SQLite when doing some Django development. Great to easily scrap the database with a quick `rm` and repopulate with good data.
I've been breaking myself of that habit: I try and use the flush command so I don't have to keep doing the superuser creation step.

https://docs.djangoproject.com/en/dev/ref/django-admin/?from...

Good point, as the superuser creation bit does tend to get annoying. But you have to admit–there's something much more fun about getting to rm your db ;)
yeah, but if you are modifying the schema and are not using south or something like that, you will still want to rm & syncdb again....
For me JSON has replaced SQLLite, with a large reduction in code and complexity. [ Admittedly I've written my own routines to access it more simply/directly on iOS ]
Yeah and like HTML5 has totally replaced our web server.
He means a flat file of JSON records. Your sarcasm is unnecessary and uncharitable.
(comment deleted)
How do you know he means that?
Because it's the only interpretation that makes sense, and charitable discussion demands that I assume my interlocutors are reasonable people who say things that make sense until I have evidence to the contrary.
The sarcasm was perhaps a little mean but he has a point. If a flat text file storing JSON could replace your database, then you probably never needed a DB in the first place.
Lots of people use full blown rdbms's when they dont need to (see blogs), its not a silly point and the sarcasm was unwarranted
If you can use SQLlite, you probably didn't need a real database. So the use cases overlap a bit with flat-files and JSON.
The JSON flat file sounds like variable length records where length is determined by parsing each record with global reader/writer locking?

It's like public storage where you have to sift through everyone else's crap to get to yours, every item is stored in a bulk cargo box and only one customer gets to store their stuff at a time.

If you're interested in db internals, here's a few algorithms that MySQL uses. Note this doesn't cover InnoDB which performs far better under high concurrency loads and offers row level locking, clustered indexes, an excellent caching algorithm, foreign key constraints with cascade, etc..etc...

http://forge.mysql.com/wiki/MySQL_Internals_Algorithms

The way I've stored things in flat files is to make use of the file system's lookup capabilities. I wouldn't suggest storing data that may be requested or written to by more than one client at once with a method such as this, either. I wouldn't try to use it like a C array or anything. One file per user or more makes sense. I've also used stuff like this for system admin scripts.

Something like

   user_id=int(request.GET['id'])
   data_type=int(request.GET['id'])
   json_file="{0}-{1}-chart_data.json".format(user_id,data_type)
   #get the file, decode, etc.
It's a quick and dirty caching method that has good persistence, of course, is relatively performant under low loads and easy to understand.

Thanks, I'll check out the MySQL thing, but I'm not actually intending to build my own database.

what's your cutoff line for something to be a "real database"? sqlite is fully acid compliant.
sqlite is single user and locks a bit too frequently to be very scalable, so while quite useful, I mean sqlite not capable of fully replacing a typical engine such as postgres or mysql.
I think you could make your point better by asking a question about the negative consequences/limitations of using JSON.

Sarcasm doesn't aid in making points online because people who don't know anything about the issue at hand make sarcastic 'points' as easily as an expert.

I left it unsaid that I assumed SQLLite was normally used in places other than the traditional back end server data store - I tend to use postgreSQL / mysql or perhaps a noSQL variant such as couchDB/Mongo for server-side data.

So I meant that instead of using SQLLite on mobile devices, pc based local fat clients or in the browser... I now use JSON now whereas I might have used SQLLite before [ I also use JSON where I might have used XML or windows config files etc ]

I did not intend to say JSON is replacing MySQL / PostgreSQL.

I can sorta see many cases where that would be useful, but personally I am happy letting SQLLite do the heavy lifting extracting things with indexes, grouping and using the where clause.

But yeah, JSON is great for small amounts of data.

It's pretty handy, and an easy upgrade to a 'real' database if the need ever arises - especially mongo/couch.
You're getting jumped on, but you have a good point. It's often easier to just stringify a dictionary and read it back as the object instead of handling the database creation/insertion/selection if all you need is to store and access a few values.
I also tend to use JSON as the main messaging format for Client/Server communications [ where I might have used sockets custom binary protocol previously ].

This means I can reuse the same REST style data 'provider' from within a Javascript web UI and within an iOS or Android client app.

So theres quite a few reasons why using JSON simplifies things for me - particularly I notice that there is a whole layer or ORM style boilerplate code that I dont need now [ whether its SQLLite <-> Object or XML <--> Object ].

I actually like the SQL Lite implementation!

Because JSON is well known for its ACID compliance.
It's also worth noting that SQLite is, for the time being, the underlying store for Membase
You mean the eventual persistance store.
In the microsoft world SQL CE 4 is pretty nice for doing the same sort of thing.
I still much prefer to use SQLite on the MS stack, given how reliable and ubiquitous it is.
In some scenarios I prefer Microsoft Excel over SQLite. Yes, Excel can be used as a database as well!
Do you mean as a database engine using the ODBC driver for Excel or as a database-like application?
Agreed. SQLite also has a great copyright notice in its headers:

  ** The author disclaims copyright to this source code.  In place of
  ** a legal notice, here is a blessing:
  **
  **    May you do good and not evil.
  **    May you find forgiveness for yourself and forgive others.
  **    May you share freely, never taking more than you give.
(http://www.sqlite.org/src/artifact?name=a8571665d43ff18f89a4...)
I'm surprised to see that Oracle even has as many mentions as it does, given how rarely you read about it here on HN. We're locked into it at my workplace, and every time I'm reminded of this PG quote I cringe a little:

"The more of an IT flavor the job descriptions had, the less dangerous was the company. The safest kind were the ones that wanted Oracle experience. You never had to worry about those."

I was wondering the same thing. Our startup currently uses it when doing research on data sets, but it's a db I don't hear about very often when talking about startups. I'm assuming a big factor is price.
Yeah, Oracle is mostly used by bigger companies.
The licensing is really an issue, especially when you get into the higher-end. They don't charge per computer, they charge per CPU. So you'll have to pay 4x as much in a dual CPU system (I'm not sure if they have a similar licensing structure for dual-core or quad-core systems)
I use to work with Oracle daily (previous job) and now I use MySQL mostly with some Postgres and SQLServer at times (lots of client work).

I would say all these databases are worthwhile as long as the DBA is competent. Given that, unless you have a reason to choose Oracle (e.g. familiarity, integration with other applications, a specific Oracle only feature, contractual obligation), I see no reason to choose Oracle. Many companies choose Oracle because Oracle built a solid database/brand early on while catering to big businesses. MySQL and Postgres made great progress in the past decade make them valid alternatives.

I suspect that it's the HNers still toiling away in large companies that are voting for Oracle. You'd probably see about as many votes for DB2 had it been an option.
You are correct in my case.

We use Oracle, MS SQL Server, and Sybase because that's what the vendorware we use requires. We do have some open-source software that uses MySQL for administrative purposes.

Having Oracle as your db doesn't mean that you are not working on interesting problems. Every company is not a startup. Some of us work on well established products used by huge customer base who use Oracle and in turn we are forced to.

Above all, are you helping a customer? solve his problems instead of compounding it - that my friend is more important than choosing Oracle or Mongodb.

    Having Oracle as your db doesn't mean that you 
    are not working on interesting problems
First, I consider consultancy for customers using Oracle to be OK, as long as you earn something from it.

But if your company chooses Oracle, it means that you're bogged down by legacy, stupid company processes and/or clueless managers.

And in most such environments, the harder you try to change it for the better, the harder it fights back, putting yourself in an awkward position in which you are considered the bad apple of the team. So you end up either adapting (not giving a shit), quitting or finding some small project with no perspective for the company (i.e. less controlled) that can bring you pleasure.

Of course, some companies, like Adobe for example, use Oracle when it doesn't impact their core competencies, as it's a safe choice for corporate types. But a company like Adobe doesn't earn money from projects that are relying on Oracle and other projects inside Adobe are also using HBase and MySql and their own distributed file-system that can be queried and so forth.

Either way that quote is correct. I'm not promoting the latest fads (personally I'm not into NoSql unless it makes absolute sense), but you can safely ignore companies that make decisions based on brochures and lap dances.

I hope you realize that a company might choose to use Oracle for a reason other than "brochures and lap dances", and that a "legacy" decision to use Oracle doesn't necessarily mean you are "bogged down" or that the decision was stupid.

I don't understand how using Oracle for your RDBMS is suddenly equated with all the things you mention.

Such as? Really, I'd like to know the reason for why a company might choose Oracle.
Because they might want to run some of the applications that Oracle sells that run on top of their database - the example that I am most familiar with being Oracle Hyperion HFM which is by far the leading financial consolidation application for large corporations. Even Google uses Hyperion:

http://www.google.com/intl/en/jobs/uslocations/mountain-view...

[If 12 dimensional hierarchical databases with complex logic are your thing then Hyperion is really rather cool in a perverse kind of way].

BTW If anyone here is interested in this kind of space I have had some interesting experiences in building extensions to HFM...

  true clustering (Oracle RAC)
  multi platform
  support
Oracle is a bear to get setup. Nearly impossible, best I can tell, but the feature set is incredible. It's like Excel 2003 -- pretty much every feature you might want is in there somewhere, just need to find out how to expose it. For example, I've seen people say that its auditing and regulatory support has no peer. I don't really know that stuff well, but the ppl who told me spent non-trivial amounts of time with other solutions to see that Oracle made the most sense.

My point, if all you ever need from a database is solved with key/value store then Oracle is not mildly interesting.

Oracle costs at least twice as much as any other databases. Yet companies still buy it. Why do people buy things that cost twice as much? Hint: it's better.

Forget price for a moment, any feelings you might have for Larry Ellison, the good/evil nature of the company, or whatever. Consider the software itself.

Many people aren't all that familiar with the basic things a database is supposed to do. The list is large. I can't possibly give it justice off the top of my head, but here are a few that come to mind: make it possible to see data in a consistent state (as of a single point in time), without being blocked, even as other people are changing it; support "transactions" -- a group of requests that either all succeed or all fail -- so that the database cannot end up in an inconsistent state; guarantee recoverability to a consistent state even when people change their minds, statements fails, power fails, hardware fails, or all of these things happen at the same time; and many, many other things like security, support for the relational model, SQL, joins, etc. Real databases aren’t simple key-value stores.

Historically, Oracle obtained a huge lead in market share because it delivered the most complete mix of these basic things long before anyone else.

Something not widely recognized, but that should be obvious to programmers, is that low-level architectural decisions have a huge impact on how well a database performs these basic duties. Oracle maintained its lead for a long time because it got many of the low-level architectural decisions right. It is really hard to catch Oracle if you are trying to polish up a bad locking model, for example. Oracle still does the basics better than most. That, in and of itself, is a reason to consider Oracle.

Oracle remains viable, even as others continue to catch up, because Oracle builds on its solid foundation by adding additional capability and features relentlessly. I challenge you to read the new features guide for any new release of Oracle and to remember just the names of 20% of the new features. The Oracle documentation, as of 6 or 8 years ago (10g), was 40,000 pages. No telling what it is now. I can tell you this. If you have something you need to do with databases, Oracle probably figured out how to do it a long time ago.

I, personally, am a huge fan of PostgreSQL (and it’s freeness), but I recognize that Postgres is never going to be able to touch Oracle in features. It’s impossible. Working with Postgres is just going to require a lot more manual labor. Some things aren’t going to be possible. Performance may just have to suffer sometimes. Let’s hope Postgres does the basics well (it does). That’s the most important thing. But when it comes to building spacial indexes on hierarchical dimensions, or whatever, Postgress just isn’t going to have a feature for that. I’ll have to figure that one out for myself.

One key point: if you need to build a large, high-performance, data-driven application that provides nearly instantaneous response for thousands of simultaneous users, Oracle is one option that can get the job done. If you need to build something huge, say billions of rows, that provides nearly instantaneous response to dozens of users, Oracle is one option that can get that job done. So no wonder that some companies consider Oracle.

The last thing I’ll mention is that it takes a lot of time to learn something like Oracle. I would be surprised if after a year of using it, for example, that you can really make it hum better than any of its top competitors. If you do use it for a while I think you’ll find that it is really good at the normal things and in a different league when it comes to the unusual things. This comes in handy when you are being paid to get things done (by a company that can afford Oracle) -- hence the reason that most startup-oriented people don't have much appreciation for Oracle.

"Oracle remains viable, even as others continue to catch up, because Oracle builds on its solid foundation by adding additional capability and features relentlessly. I challenge you to read the new features guide for any new release of Oracle and to remember just the names of 20% of the new features. The Oracle documentation, as of 6 or 8 years ago (10g), was 40,000 pages. No telling what it is now. I can tell you this. If you have something you need to do with databases, Oracle probably figured out how to do it a long time ago."

Are these good things?

We can also reverse this argument: if you're using Oracle, you will never have a use for 99% of its features.

Or - as I picked up from some long forgotten blog post:

If you need Oracle, you'll know it. If you don't know that you need Oracle, you don't need Oracle.

I run MySQL, Oracle SQL Server, hundreds of databases, a couple in the 'many thousands of queries per second' range.

There are reasons for each database platform.

> But when it comes to building spacial indexes on hierarchical dimensions, or whatever, Postgres just isn’t going to have a feature for that. I’ll have to figure that one out for myself.

In this case, yes it is, Postgres probably has the best type system and extensibility of all SQL databases. GiST and GIN are very good technologies that also exist in Informix.

If I had to choose something that is missing in Postgres and very far away for sheer want of implementation effort, it's parallel execution of queries.

Oracle RAC is also quite a crazy and neat feature, except when it has problems, in which case you get even more crazy for that crazy.

On the other hand, Oracle is also not a strict superset of the features in PostgreSQL. For example, 9.1 has the only credibly fast implementation of SERIALIZABLE level isolation that I am aware of. There are also interesting features like "index exclusion constraints" that have no equivalent in Oracle, and solve problems hard to solve otherwise (example constraint: there are no overlapping circles in this table)

Amazon uses Oracle. I think to completely disregard Amazon because of this fact would be a mistake.
(comment deleted)
As does Facebook I believe
Facebook uses MySQL as it's primary data store, with some hbase, cassandra, and other more minor usage storage solutions in various places.
Facebook uses Oracle for certain things.
I'm probably starting to sound like a broken record around here, but:

1. I build products on Oracle at a startup.

2. Oracle has many compelling features that really don't have first-class open source alternatives: OLAP, encryption (wire and at-rest), VPD, materialized views with query rewriting, object and document storage, monitoring and tracing, among others...

3. Oracle got more compelling since being offered--license included!--on Amazon RDS.

There are a ton of responses for Microsoft; why doesn't anyone question that? Actually, I'm curious now. Is there a new incentive for SQL Server? Maybe something in BizSpark that makes it attractive?

Also, do not forget or underestimate the cheek-in-tongue "Nobody got fired for buying Oracle" in this case.
We actually have our own extensions to use Perl filehandles to write directly to Oracle LOBs. I don't know if that is Oracle-specific or if it can be used elsewhere. I've never cracked open the implementation.
It is perplexing that Microsoft (presumably SQL-Server) has got so many votes. In my experience, absolutely nobody chooses to use it. They just have aggressive sales people who use it as a bargaining chip to elbow out Oracle and help win other business.
I started out with Oracle on AIX, then Sybase on Solaris, then Postgres 8.3 on Windows and Linux, and am currently using MS SQL Server. Postgress (8.3 on Linux) is currently used for an inventory db in house, and SQL Server is used for most apps that reside at customer premises.

Sybase was better than Oracle, and Postgres was just as good as Sybase at that time. But SQL Server (version 2005 on) has stood taller than all of them in my view. Excellent management tools, stable, reliable and no performance issues for our apps. Most of our apps are write light and read heavy with thousands of users hitting the db - served off one Win 2003 server (we have a warm spare).

So there is some truth to your statement about nobody choosing to use it - for us the primary motivation to not use it internally was cost. At our customer premises they picked up the tab. We have MSDN so sql server development licenses are not an issue. Have not met a Microsoft salesperson yet!

I actually did.

I've never had a bad experience with it, it needs a lot less maintenance than Oracle does (or did, at least), it performs pretty well (we're an insurance company with large datasets), is integrated in a .NET stack (while you might not want to go there, especially as a startup, it is very nice for corporate work), it came with Reporting Services which we used to replace Crystal Reports, it has lots of (admittedly non-standard) extremely useful SQL functions, data types, etc. And I love SQL Server Management Studio and the other Microsoft tools.

MySQL felt like a toy database in comparison (especially the management aspect), and the non-relational stuff is out of the question for now. We might not have done due diligence by not looking at other alternatives (notably Postgre I guess) but they seem like a poor fit given our developer's strong Microsoft-centric backgrounds. Most of us also have at least one Microsoft training course in their SQL server, and they have very strong support in my country (Uruguay) against nonexistant for most other platforms.

Oracle is all over the place. My daily bread-and-butter relies on Oracle. For some thing it is, as I like to say, more 1980s than Top Gun crossed with Duran Duran -- still no SQL boolean type after 30 years! -- but for other things it has no peer except DB2, Sybase and SQL Server.
Oracle Express actually has a free license. The Express version has most of the same functions as the expensive versions except the 5GB limit on database size. If your app doesn't require lots of data but needs all the SQL power, it's a good choice.
Hey Redis folks, if you haven't played with http://radishapp.com/ yet I'd love to hear your feedback on it.

Also, go Postgres! Woot!

I'd totally use an open source clone of that.
Agreed. Or at least a free version of it.
There's a 30 day free trial...sign up and give it a spin!
I think this same argument goes for any kind of SaaS. Hopefully with us we provide enough value over rolling your own Redis monitoring/data analysis that you won't need to.
Failure. You don't know your audience.

Fortune 500's will pay you to spit out graphs, but they don't use bleeding edge tools like Redis.

Anyone who uses Redis in any serious fashion already knows that the numbers you show on the homepage are easy to get to. Just write a script to pump them into $graphing_software.

My advice would be to give the current product away for free (yes right now), making the barrier to entry lower than doing it yourself and capturing future customers. Then focus on selling people things that are hard, like real actionable intelligence. Everything you charge for should answer a question like "what", "who", "where", "why". Free stuff should answer questions like "how many".

[Edit: Just realized you are the Hoptoad guys (of which I am a happy user), so I know you have the potential]

(comment deleted)
Interesting to see Tokyo with so few votes. On benchmarking it had the smallest memory footprint when loading ~17GB of packed binary data. Been awhile but I remember testing redis, postgres, mongo, and bdb. This let us keep all the low latency read-only data we needed available in memory and provision the smallest possible machine to do it.
I bet a lot of the proportion is down to most people writing in with what they use in their day jobs.

Also, while I love Tokyo's speed, it is just a better bdb - which is an impressive feat, but I can see why a lot of people would use something slower but more featureful.

Tokyo is my standard database for personal projects and goes great with Lua. Both are lightweight and fast, Cabinet has an excellent binding, and Tyrant has embedding.
We use Database for objects (Db4o).
Postgres and Redis for one thing and mysql for the other.
For my pet projects mySQL due to free. For business Microsoft.
MySQL
TBH, it wasn't exactly clear that upvoting was how you "voted". Thanks for the -1 whomever that was.

Next question, there's karma here?

Though I use MongoDB and sometimes PostgreSQL, I know of a lot of companies who rely on MS SQLServer as their primary database.
MySQL, with SQLite for development environments. I want to learn/migrate to Postgres though, what with MySQL being in Oracle's hands.
One of the best things you will ever do.
Agreed. I had to migrate a copy of Team City from MySQL to PostgreSQL a few days ago (due to a buggy mysql version in the Ubuntu 10.04LTS package repository). You just don't get crap like that with Postgres. It just works.
If SQLServer is going to be referred to as "Microsoft" shouldn't MySQL be lumped under the "Oracle" grouping?
MS really only has one relevant offering in this discussion, unless you want to add Exchange as a document-oriented store.
It would not surprise me if MS Access were used at more companies than MS SQL Server.

I'll leave it to you whether you call it a database :-)

I think it would be fair to say that Jet (Microsoft Access) is a least as much a database as SQLite.
I wont argue, but Jet hasn't been the default backend to Access in a long time. It is SQL Server Desktop Edition now, IIRC.
Hah! Don't discount it that quickly - MS Access can be surprisingly useful, particularly for RAD work at a large company where you need to push stuff out to a bunch of MS Office users. I've delivered a bunch of "light" Access/VBA applications to support business initiatives (cranked out in under a week or two) which probably account for over 80% of the value created by my hands on technical work (several of which provided the "chassis" for multi-million dollar performance improvement programs).

Access plays well with everyone (including Oracle, the MS Office family, and Sharepoint), can be heavily extended if you know VBA and are willing to hack a bit, and can often be handed off to a non-technical person for support. The trick is to try to use the same coding/design standards that you would use in a real langauge - the internal parts of my Access/VBA work is influenced by Python and C++.

And from a consulting perspective, it has the advantage of being aligned with what 90% of your Fortune 500 end-users are familar with (MS Office)... simpler handoffs.

That being said...not my first choice for after hours work (do a lot of MySQL, looking to step up to Postgres).

Incidently (for the other thread) - one really nice thing about oracle is their statistical analysis functions - very nice set of tools, co-located with your data, and can be accessed through SQL. Only free solution I've seen that is competitive in terms of functionality is Postgres...

A nice distinction would be SQL Server and SQL Server Express. Express being free, it would be interesting to see how many people are using SQL Server Express as a free alternative to MySQL and how many are using SQL Server as the paid alternative
Yes, sadly FoxPro died when it was acquired by Microsoft.
Microsoft has key-value database on Azure as Azure Tables. They also have Azure SQL which is different than just SQL Server (though very similar).
I have to agree, and planned to comment just to say the same. SQL Server is incredibly powerful, easy to use, and scales okay. If StackOverflow is any indication, people are seriously underestimating (and mis-representing) the Microsoft offerings.

Just to name a few:

* SQL Server

* SQL Server Express

* SQL Compact 4

* SQL Azure

It's really hard to compare results between both polls. It would be nice if pg added the percentages next to each item, or at least sort them.
Here is a graph of this poll: http://koldfront.dk/misc/hn/database2011/data.png

... and one of the 2010 poll: http://koldfront.dk/misc/hn/database2010/data.png

(Updated every ~4 hours currently; I will be fading out the update rate.)

The bars are different sizes and in different orders, this makes it much harder to compare by flipping between browser tabs.
They reflect the polls, so they also tell you that the polls didn't have the same choices.

The two sets of data ought to be shown in the same graph, really.

Edit: I have now joined the two years in one graph, and plot the percentages to make it easy to see the change: http://koldfront.dk/misc/hn/database/data.png

Very surprising thing is the upward change in Microsoft SQL Server, that too in HN.

On a lighter note, does this support the theory of HNers who complain that HN is not the same any more and it has been generalized?

Maybe more Microsoft SQL Server users follow Hacker News now than before?