I know this is a really old thread, but just wanted to offer this in case it helps someone. The complications involved in switching between the popular RDMS systems such as MySQL, PostgreSQL, Oracle, and Microsoft SQL Server would be around:Whether the app uses database-specific functions or a generic API. Differences between built-in functions.If the app uses stored functions and procedures--these use db-specific languages and constructs.In the case of osTicket, from my 5 minute review (so take it for what it's worth) I did not find any stored functions and procedures in the osticket mysql database, so good there--that's usually the big one that can make a database migration difficult.osticket uses an ORM based on the Django ORM. This is good in the sense that the actual database interaction is abstracted away from specifics of MySQL. The generic database functions are defined in include/mysqli.php, and you guessed it--they are wrapped around mysql specific methods.So, again 5 minute review, but you'd have to create your own postgresql.php that emulates all of the methods in mysqli.php. That alone may get you 99% there. So at least my initial take says it would not be a huge project.BUT, I'm not sure why I'd bother considering how easy it is to just use MySQL. I'm a huge PostgreSQL fan, but if you know how to use and administrate PostgreSQL, your skills translate quite easily to MySQL--so just install MySQL and roll with it.Of course if you are in a large organization that has a team of database admins with PostgreSQL specialized tools, backup strategies, etc., I can understand the desire for this.If I was setting up osTicket for a large organization, I'd use Amazon's Aurora database offering in their AWS RDS service. It's designed to be 100% MySQL compatible and offers about 5x performance, automatic backups, automatic growth in 10G SSD chunks, redundancy, etc. Pretty stinkin' amazing.