Ask HN: Which database do you use in production today and why? | Hacker News Reader

Ask HN: Which database do you use in production today and why?

12 pointsstunt6 comments

I'm fascinated by databases and I'm writing about them. I've collected so much but more input could help to see where I could put more energy.

1) Which database do you use in production? and, why did you choose it?

2) Is it self-managed or managed?

3) What is your biggest complain about it?

4) Which database do you choose if you could migrate at no cost and time?

5) How do you plan for scale? How your cluster looks like? Is your database distributed? How do you handle auto-scaling/sharding/replication/service-discovery?

6) Do you know about your current monthly cost for this database?

View on HN

1) CouchDB

2) Self-managed

3) Don't have any complaints

4) CouchDB

5) So far I've not needed, nor made any plans to scale up. But CouchDB is designed to make it easy to setup a cluster of DBs and has tools built-in to help setup and manage them.

6) The DB is running on a $20 per month DigitalOcean VPS.

Why CouchDB? - There are a lot of reasons I chose CouchDB. Here are a few:

1. CouchDB was designed from the ground up to by used as a back end for web apps and for managing "documents". My apps are document creation and management apps.

2. CouchDB stores data in the JSON format which makes it easy to use in a client side app written in Javascript.

3. PouchDB.js makes it easy to work with CouchDB.

4. CouchDB provides my users an easy way to run my apps "Offline-first" and "Local-first" and the local app's performance is near native app speeds.

5. CouchDB and PouchDB.js provide "Live Sync" functionality that insure users always have the latest version of their documents.

6. The CouchDB dev team is top notch and community support is too.

I always wanted to use pouchdb as a self-hosted firebase for small projects but I have trouble reasoning about the cost.

How much load can a cheap VPS handle in terms of concurrent live syncing users?

I really cannot say. I don't have enough users to stress the server, and my server is running on a $20 per month Digital Ocean VPS.

CouchDB is designed to process huge numbers of files.

PouchDB makes it very easy to work with CouchDB. You can use plain JS to process the data on the client side but you can also do data processing on the server side and send just the results to the client.

There are some things you have to do on the server side for security purposes, like setting up a new CouchDB database and user. You can do that with PouchDB but you have to include the CouchDB admin credentials. I don't run PouchDB on server side but that can be done as well with Node.js.

1) CouchDB, because we needed a document database and CouchDB is the cool one. The multi main replication model is also very interesting.

2) self managed, because managed couchdb are rare.

3) the indexes uses tons of ram, we have to be very careful when we index something.

4) I would migrate to a managed postgresql because transactions are something we would like to have, and the replication model wasn't that useful after all.

5) we can use bigger vms and more vms. Couchdb will scale okay as long as we have enough ram for the indexes.

6) a few VMs, 50€ with OVH or 500€ with Azure.

I am not sure if I am the target audience. I am a solopreneur working on multiple side projects.

1) Postgres. Moved from mysql to Pg and never looked back. All my projects run on pg. One of the advantages is I don't have to context switch my internal model of a database when I navigate from on project to another. Another reason is, I witnessed the rise and fall of NoSQL dbs, as an outsider. I have decided pg can do most things that I need and only reach for any other DB once I reach the limits of PG. Yet to do that.

2) Self-Managed: I run my projects through containers orchestrated by docker-compose. Adding a db to that is trivial. Moreover, the best practices I learnt in one project can be carried over to the next

3) None so far :) One of my side projects is a like a CRUD app. It serves a 1.3 million pageviews a month from a 10$ digitalocean machine.

4) Sticking to PG. I mostly use Django as frontend. Django supports all of the postgres fields including JSONB fields. So that functions is a poor man's Key-Value Database. The one of the responses to CouchDB here sounds interesting. I shall investigate.

5) _

6) Less than $5 (for the database in each project)

I'm not going to answer all the questions, as they vary from project to project.

We use some DB2 simply because it's legacy. We are holing to transition off of this for most things in the coming decade.

If we need a RDBS, we use Oracle. If performance/scale is needed, then we tend to use Exadata. We also have some replication/backup software that we use.

Most of our new stuff uses DynamoDB. We mostly plan to transition out DB2 data here.

Reply on news.ycombinator.com