Which database to choose for a small file service?

Question

Python

I want to make a python application (on Fastapi) that will work like this:
Users run a job that uploads a heavy report to the file system on the server, after which they receive an email notification with a unique link. When you click on the link, the file is automatically downloaded.

I need to store the following information:
1. Connection of a link to a file in the file system
2. Download history

Perhaps sometimes I will need to clean up old files (and links, respectively) in bulk (for example, older than 30 or 7 days).
I expect to upload several tens of thousands of files per month.

Advise what DB should be used for such purposes? And why her?

Answer 1

FastAPI involves working with the database through ORM in particular SQLAlchemy
Which provides an abstraction layer.
so it doesn't matter which base is used.
Start with SQLite and then, if not enough, easily migrate to muscle or postgres

Answer 2

Whichever one you know best. At such quantities, any database will work without problems.

Answer 3

Any relational: MySQL, Postgresql, Firebird. The first one can definitely be configured for low memory consumption, if necessary.
When using them, it is easy to grow without changing the DBMS.
In the long run, SQLite is not suitable.

Answer 4

Your database based on files. You do not need to install extra software with functionality that you do not need, and the described tasks can be organized in files.

Answer 5

Such a task is ideally solved using s3 or any object storage. It has the functions of restricting access, deleting old files, and, most importantly, - you do not need to pump these reports yourself through your own http server - you can link directly to the repository directly to a specific report.
The universal PostgreSQL DBMS is great for storing any application metadata

Answer 6

The question in the future draws on an expert system for choosing a database.
With this setting - you can take any document-oriented. All fit the same.
But if the main content (we take 80% according to Pareto) is files, then you can take Amazon S3, in the future with the prospect of transforming it into DynamoDb if transactions are needed or into Amazon Document Db (aka Mongo) if you need fine work with document attributes (or files).
The author must understand that there is no single correct solution in this matter. There is just some kind of comparative table where there is a set of features on the one hand and a set of DBMS on the other, and there is no such coverage that would cover ALL features.

Answer 7

And what for in general files and a database? This problem can be solved much easier. The user starts a heavy task that builds a report. The report is cached with a lifetime of 30 days (well, or as long as you need). The key in the cache is a unique value that the user receives in the link in the email. That is, the task is greatly simplified:

1. no base
   
2. No need to write logic for deleting reports, because they will be deleted automatically when the cache expires
   
3. No need to store files