Poll: What databases does your company use?
http://news.ycombinator.com/item?id=2684620 http://news.ycombinator.com/item?id=1411937
Leave a comment for ones I forgot to mention and I'll add them.
http://news.ycombinator.com/item?id=2684620 http://news.ycombinator.com/item?id=1411937
Leave a comment for ones I forgot to mention and I'll add them.
Someone save me.
I happen to think it's a pretty good bad joke :)
Similarly, Justin Bieber is actually one of the best artists of all time.
My comment is popular amongst other HN readers. Therefore it's reasonable to assume it's a good comment.
At my current job we use PostgreSQL and MySQL in production, and H2 in development. At my previous job we used Sybase SQL Anywhere (horrible, wouldn't recommend it), Microsoft SQL server, MySQL, Amazon RDS and H2.
Currently we use PostgreSQL for all new projects, but we have a few legacy projects still using MySQL that we haven't bothered migrating.
Additionally, most developers find it a hassle if they have to configure a fullblown database just to do development on a given project. That's why we use H2 (in-memory database) for development.
At Instagram we use PostgreSQL, Redis, and Cassandra.
What about Berkeley DB? That has a similar range of functionality yet is cited as 'the most widely used database toolkit.'
Built a database to do basic inventory of instruments and calibrations.
I am trying to convert us to PostgresQL over time, but I still have to get a good guide on how to use it.
It's weird to see memcache listed as databases but is true it can be used as cache system for web frameworks
I have used it for Rails , Django and CakePhp So i guess it is worth it's place to stay in the database world
It was great during development because I would create the tables in the morning, code all day and then delete the tables at the end of the day so I would only pay for 6-8 hours of provisioned throughput!
I prefer the former as it enables me to have the dev/test env as similar as possible to the prod environment: same naming, and both env's are separated, when one gets compromised at least the other one doesn't suffer. Security rules are also easier as you don't have to create per-table rules, when you want to lock out some team-members from production tables, but not dev/test tables.
I've done tests previously, and can confirm that they aren't making the performance numbers up :). 3x $500 servers (~18 months ago: single quad-core Core2) were able to handle over 100K tx/sec with k=1 (2 copies of each record). It was pretty easy to get it up and running and the out-of-box performance required no tweaking on my part to achieve excellence (apart from making sure NTP was working well).