Would there be any benefit to using redis/nosql over postgres for my bug tracking application?

I'm making a site to document browser bugs where users can submit a bug and users can submit solutions/workarounds to these bugs. I'll have stuff like:

• screenshots of bugs
• browser rendering engines
• browsers
• tags for each bug
• bug categories ( css, html, js )
• solutions per bug which include code snippets
• usual date/time, author, date modified

Since I'm just s开发者_如何学运维tarting this site, I won't really need to scale off the bat. I'm just wondering if the data is more ideal for something like redis, or should I stick with rdbms ( in my case, Postgres )?

Bug information revolves around products and users, and that data benefits from relational structure. (You can look at a host of existing bug trackers for examples). If you do find you'd need hierarchical data structures (like redis leans toward), there are several different implementations of tree structures in traditional sql, and postgres offers some additional constructs like arrays and ltree structures. Additionally, Postgres has fairly proven methods for storing binary data (like screenshots) and large text data, that depending your nosql engine might not be as stable as you'd hope. I guess there might be some benefit of learning another system (otoh, others woul argue learning your existing tools better is more beneficial), but from a technical standpoint there isn't really an advantage.

MySQL as well Postgress development teams do not recommend storing images and binary data inside the database.

Instead you can store the images in some directory, and filename can be either the ID from the database, or md5(ID + secret) if you worry people may "hack" the system and see images they must not see.

Doing this you will benefit with smaller database also faster access - you can serve the images directly with your webserver.

I am huge Redis fan, but this project looks more like RDBMS for me.