pretix is a multi-tenant application: With one software installation, it can handle lots of companies and institutions selling tickets. In pretix, they are called organizers, but in the more general case, we usually speak of “tenants” in the software industry. Building pretix this way is a design choice, we could just as well have created a software that only handles one company and run the software many times on logically or physically seperate systems for every event organizer. We decided to go with multi-tenancy in the software many years ago for a number of reasons.
One of them is that we want to have the ability to provide some features across multiple tenants. Some of our power users manage a large number of events split over multiple organizers and it’s really convenient for them that we can offer global search and reporting. A second reason is the performance pattern inherent to ticket sales: Most of our clients do not cause any load 99% of the time and we want them to take up as little memory and disk space as possible, but they sometimes require a lot of resources for a short time when they have a big onsale. This performance pattern is easier to handle when running all customers on the same large instance instead of every customer in their own.
This leaves us with the challenge to isolate customers effectively to protect their data from unwanted data leaks. There are some fany approaches e.g. based on having multiple PostgreSQL schemas, but since pretix is capable to run with different database backends, this is not a solution for us.