Which database do you use? and why?

For almost all cases, I use Postgres. There's really no substitute for a lot of the nice things that a transactional SQL database gives you.

That said, I've found that Postgres + most other SQL dbs tend to break down in two cases at the small business scale.

1. You need to search documents across many, many axes. For example, you have a million products and you want to look up all the products available in Minnesota in the laundry detergent category, sorted by affinity. These types of complex queries tend to scale very poorly in Postgres. My preferred alternative is ElasticSearch, which is designed to handle these multi-faceted filters / score boosts, etc.

2. You are fetching a particular piece of data a lot in a short amount of time. For example, every time a user makes an API call, you need to check to make sure they have a valid cookie and have the right user permissions to make the API call. If users are making many, many calls per second, this can bog down Postgres. This is a good use-case for an in-memory store like Redis.

Postgres is as good as you'll likely get for a one size fits all tool, but make sure to keep the above two failure cases in mind as they happen a lot more often than you would expect.

We've been using MongoDB for metric storage since it performed best for the amount and type of data we store.

Performance has been solid since we're grown from storing a couple GB's of metrics to several TB's of metrics.

This wouldn't work for lots of sites, but I recently used an SQLite database and committed it to the repository. I'm treating it as almost a static site, but instead of generating all the pages I've hooked up a traditional ORM to a committed file.

It felt a bit wrong but works really well, and can always be swapped out later.

You will laugh, but it depends on data you want to store, relations in data, frequency of changes, amount of changes, an finally your knowledge of particular engine.
We use MariaDB Cluster, Sphinx, ElasticSearch, Redis in one project.
If you want to start fast, take some well known RDBMS like MySQL, Postgres, MsSQL - what easier to integrate in your technology stack

I still use MySQL knowing that PostgreSQL is often better. It's partially, if not mostly, because of habit. However, I have used an ORM pretty reliably for many many years so it's often easy enough to switch between the two. I've used SQLite for minor projects. Anything that gets remotely complex or has any real level of traffic will crush it, but it's still a useful tool. I've also used AWS' RDS service with basically no issues to speak of. It just worked. I have found that using an agnostic ORM (well, as agnostic as they get, anyway) has had more value than tapping any one database's specific features. But that's for my limited use cases.

I use http://fauna.com. Easy to start, provides GraphQL integration by default, and has a generous free tier.

Using cloud provider's relational or Nosql solutions are cost effective way. For example, AWS RDS Mysql version or Dynamodb are the mandatory choices at least for me.

Which one should you use depends on the data type of yours. Transactional operations need Mysql/Postgresql or high data read&write operations might need Nosql.

I use a relational database whenever there are some relations between my data (PostgreSQL is probably the best one).
Otherwise, I use NoSQL. If you want some speed, check Redis out!

And, if you don't want to administrate everything use them as a service.

It's the quickier answer I can make. Feel free to ask for more details!

It depends.

At Yomi.ai I started with CouchDB (specifically IBM Cloudant) to host read-only data in the users' browsers. Once I got validation and started to build out features, I removed that part and built a grown-up API that is connected to Postgres and Redis for different uses. Currently hosting Postgres on Heroku and Redis on Redislabs, because it has the best cost-benefit ratio for our size at the moment.

Additionally a lot of data is also stored in the server that's serving the REST API in a custom format.