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?
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.
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.
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)
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.