There are many types of databases by the way. If you want to run all of them without messing up your machine or creating multiple virtual machines, I highly suggest running them via Docker. Google it.
Clue: Docker is like ultralightweight version of a virtual machine.
MySql or Postgres - relational db which is good for shopping cart or attendance monitoring style records. Well these two databases are really workhorses--meaning when you aren't sure, just pick any of these two
InfluxDB - time series db which is highly optimized for time series data. Think of spplications that send data as a function of time. Think of a source that sends temperature every second. This is a common use case -- like metrics coming from another system as functioj of time
MongoDB - a NoSQL db meaning it doesnt follow the usual relational.schema of MySQL or Postgres. Best thing about MongoDB is you dont need a schema to store your data. You can create one but basically just a blob of arbitray JSON can be stores directly in the db
MariaDB - similar to MySQL but highly optimized for columnar storage meaning this is better for apps that deal with analytics
Eventstore - a db that's highly optimized for event store and cqrs style of development. Google this.
Redis - a noSql db that's commonly used for caching but it's not just for cachin. You can use it for pub sub and storage
Neo4j - a graph based db. Think of storing Facebook style relationships. This is highly optimized for storing data can be represented as graphs or networks or relationships.
ElasticSearch - a db that's optimized for searching
Think of Google or Yahoo.
There's more out there but you guys get the idea.
On a similar topic, there's also messaging / message brokers. Think of these as temporary databases that can be used as placeholders between two systems. The purpose of these brokers is to decouple your services. So one service is down your other service is still up. Good examples:
Kafka (not really a message broker but can like one)
Other MQ clones
Best thing about these tools is they are all open sourcr and free to use for commercial purposes. They are non-Microsoft technologies
Just to give you and idea how you would connect these systems.
You have four microservices.
1. Frontend - the ui. It runs independently. It's job, well, to display the UI
2. Backend servicr - it's job is to handle request from the UI. They communicate via Rest API (or if you are fancier GraphQL)
3. Another backend service that processes emails
4. Another backend service that process pdf conversion.
So user makes a request on the frontend. Backend handles the request. Lets say it's account creation
Backend saves the data on a db ie MySQL. Backend returns response to the user that it's succesful.
Now user wants to send an email. He composes an email on the UI. Backend handles the requests. He forwards the request to thr message broker. Let's say RabbitMQ and backend immediately returns to the user that email request is being processed. User can proceed in doing other stuff on the UI.
Now the other backend service that handles email sees there is a message for him to process on the message broker. He takes the message and creates the email and sends it. Done.
The user doesnt neef an acknowledgement from the system. This is given when you send an email, you cannot expect an immediate response.
Now user makes a request to create a PDF. Same process for the backend and message broker. The PDF service handles the request. When the pdf is ready to be served, the pdf service sends a message to the message broker to notify the email service to send an email to the client to pickup the pdf.
So all communications are done via the message broker. The advantage is if thr backend submits a message to the broker and the pdf or email service dies, the message. will stay there until our other services becomes online again. Another advantage is I can spin up 100 more email or pdf services and all they need to do is talk to the message broker. I dont need to update my frontend or backend service.