Why do you think a filesystem is better for files? I see only downsides.

@Grim Well, the name "file system" should be a giveaway that it's the right system for managing files. The pros of storing the files on disk and referencing their location in the database are a number of things inclusive of: not bloating your database, faster querying, not bloating the backups of the database, faster recovery time, reduced redundancy of the file itself, easier management of the files themselves, etc.

My dbs queries does not going slower. I would not say it bloats the database, I would say it sovles the single-source-of-truth. I am happy with the fact that a backup of the database also backups the referenced files, so the backup have no broken-file-references, let me phrase it as corrupted foreign-keys. The redundancy is a db-design problem. A file forces you to solve the owner/permission-problem, it is not acid since its there (or not) indepnednendly of the commit, it forces you to have a directory, it forces you to think about vulnerability (unpack petabytes in a 1kb zip, ADS bullshit etc

You dont need a complex secure and backup plan than "just backup the db", you automatically have a network-filesystem, you have easy statictis source for the overall-storage-requirement, you can balance the datasource across nodes easier than on file-systems, you can order, index and find files by name or/and size without having os-specific find commands faster and easier. You can consistent guarantee no ambiguity in a db but never using files. A unique filename is no precondition in the same folder. Windows does not create unexpected thumbs.db files, linux does not create .trash-folders.

@Grim There's unfortunately too much subjectivity & incorrectness with what you said, that I don't have the energy to reply to it all. But an example of what you said that is incorrect is "you can order, index and find files by name or/and size without having os-specific find commands faster and easier". This is no different than if you stored the files on disk and the paths in the database, indexed accordingly. Again, backups become bloated and restore times take longer. Regardless of your personal opinion, the general professional consensus is that files are better stored in a file system.

List files in Windows is dir in linux is ls. Do you agree? Its os-specific. How do you find files in linux? find -name "t.txt" or locate t.txt. in windows find "t.txt"(without -name). You see, they differ, thats your best prime example? It does not matter what os the sql-db runs in, you always use the same SQL, it might even not matter what vendor the sql server is. A backup that include sql and the files is as fast as backup them seperatly, but less work-complex and less error-prone and you are not forced to store ownership/perm and path.

general professional consensus is a sophism (argumentum ad verecundiam). too much subjectivity & incorrectness is a sohpism (ignoring the counterevidence). what you said 2x a sophism (special pleading).

@Grim "...You see, they differ, thats your best prime example?" - you seem to be having a tough time understanding what I'm saying, so let me repeat myself once more: "This is no different than if you stored the files on disk and the paths in the database, indexed accordingly." - You'd still use SQL to manage and find the locations of the files, which in turn then gives you direct access to the files, without having to actually store the files in the database, making it no less beneficial than storing the files in the database.

"A backup that include sql and the files is as fast as backup them seperatly" - Not true. The rate at which one backups their database is typically more frequent than the rate at which they need to backup their files, especially when one needs point in time recovery in their database. The data typically changes more frequently than files do themselves. Therefore if one needs to recover from a specific point in time, they could theoretically skip having to restore the file at all, making for a faster database recovery time objective. But do what you want, I've had enough of your trolling.

Please do not compare your incremental backups with my full-backup. I can do incremental backups in postgres faster too having the same speed as your incremental backup. About find using os-specific commands, how do you differ entry #1 having filename "/a.txt" (2 bytes) from entry#2 having filename "/a.txt" (9 bytes)? You can not using file-references. You need os-specific-commands as well as a path is os-specific c:\t.txt and /t.txt differ. You can not order them, you need to use os-specific commands. Please do not be rude, I am new at dba.

"how do you differ entry #1 having filename "/a.txt" (2 bytes) from entry#2 having filename "/a.txt"' - File Names != File Paths. If you store the unique File Path, you can index it and search on it just the same. The SQL code to do so is always the same, regardless of what OS the server is running on. I am not trying to be rude, apologies if it appears that way.

hi, sorry I am late

Did you noticed the files have the same path and name? I like to be sure that this fact did catch your attention. Uniqueness, you are bound in absolute-file-paths in every os (almost every I guess).

Maybe tomorrow