Edgewall Software

Version 5 (modified by ax, 14 years ago) ( diff )

added link to mailing list discussion about using svn repository as data store

Database Backend

Currently, Trac uses SQLite as its database backend.

However, there has been several requests that other databases should be supported as well (see #126).

Existing Proposals and Implementations

  • A more recent PostgreSQL effort is here.
  • Data Model Change If SQLObject (see below) works well, this proposal may not be necessary, but I would like some feedback (brad at dsource dot org) on the following proposal: TracTicketDataModelChanges

I like its elegance in handling custom fields, allowing multiple ticket attributes per ticket (i.e. this is a problem in 0.7.1, 0.8, and 0.9, so ticket gets multiple versions marked on it), and I imagine it results in reduced code overall for the app, because of the use of metadata.

Object-Relational Mapper

provide a unified object interface to different RDBMS

  • SQLObject I think some people have been talking about using SQLObject to accomplish this goal of database independence.
  • Modeling Another, more advanced (and more complex) OR-Mapper.

Comparisions between both and more info on Python ORMs:

Store Tickets and Wiki pages directly in the Subversion repository

A compelling idea with many


(taken from Subissue, a project that aims to implement such a solution)

  • "Issues are stored directly in your Subversion repository, next to your source — right where they belong!" Ie. you have access to your Issues and project documentation (Wiki) by just checking out your source.
  • no extra RDBMS required - Subversion already has its own database
  • "logging, intelligent reporting, history, and access control straight out of the box: most everything required for issue tracking is already in place — right down to email notification."


  • no SQL
  • (from 411) revision numbers of the repository would climb like crazy because every ticket added or edited would create a new changeset
  • (from 411) trac currently does not modify the repository at all — changing it to do so might create other problems

There seem to be more cons :( - the Subissue project seems to be dead.

See also <Trac> Why does Trac use SQLite for Wiki?

Other Alternatives


Note: See TracWiki for help on using the wiki.