I am considering how to implement auditing my database with Django. There are lots of auditing packages and I am decided on using something that logs changes to models in the database, rather than externally, but can anybody give me reasons why I should not try to implement this myself? I have a finite amount of time to implement this (about a week) but should I be aware of any issues or complicating factors?
I assume for each model I would need a pre-save signal and post-save signal and I would need to store the model, field, previous value and post-save value to the db
In general, it is often better to use a (popular) library, than writing your own implementation. A popular library often ships with "batteries included". It allows you to easily set it up, and configure it conveniently.
But more important, a library that is used be a (relatively) large community, is often more safe. The most common mistakes are already fixed, and often it has taken (considerable) time not to start the project, but to "scaffold" it to a better modeling, implementation, etc.
Bugs in your own implementation can cost a lot of time, or money. For example if your auditing tool is not entirely secure, a hacker could use the audit "stream" to inspect your database.
When using a library, behavior that is not entirely what one might expect is often documented, and furthermore other people, like here on StackOverflow, can help with specific issues if you use a popular library. If you implement your own, you are the only person who understand the mechanisms. If you find a bug in a software library, you can create an issue on the GitHub page of that library, or even better, make a pull request. That way, the issue you found, can be fixed for all users using the same library.
Of course by writing your own implementation, you might eventually reach the same level. But it will require solving a lot of "teething problems". Often the real cost of a project is not that much the "initial development", but the "maintenance" of the software: fixing bugs, solving performance problems and security vulnerabilities, extending the library.
For example in your specific case, using signals might not be the best options. Django's ORM has a lot of ways to circumvent signals. For example a .bulk_create(..) [Django-doc] will not trigger the signals. Therefore using signals might not be the best idea.