2. Self-hosted Supabase

Context

The application needs a database, authentication, and file storage. Supabase provides all three, and offers both a managed cloud service and a self-hostable stack.

This is a community project for a university alumni association, funded informally. It holds personal data about members, some of whom care where that data is stored.

Decision

Run the full Supabase stack on a single virtual server, managed through Coolify, alongside the application itself.

The reasons were cost predictability, keeping member data under the community's own control, and the fact that the server was already being run for the application.

Consequences

Operating a database is now part of the project. Upgrades, disk space, connection limits, and backups are all the team's responsibility. A managed service would have handled them.

The stack is larger than expected. Self-hosted Supabase is roughly fifteen containers, not one. Failures in supporting services produce confusing symptoms: the analytics service is a hard dependency of both the API gateway and the administrative interface, so when it fails to start, the site appears to be down for reasons unrelated to the application.

Some defaults differ from the managed service. Notably, the stack's default privileges grant broader table access than the migrations requested, silently overriding them. This was found during a security review, not during development, and means row-level security is the only protection on the older tables.

Email does not work. The hosting provider blocks outbound mail ports by default, and the mail server sits on a different Docker network from Supabase. Email verification is disabled as a result, which weakens account security in a way that is documented but not solved.

Everything shares one server's resources. The disk has filled once. There is no CDN. These constraints shape unrelated decisions, such as resizing images in the browser rather than on the server.

There are no backups yet, which would have been provided by default on a managed service. This is the most significant unpaid cost of the decision.

Would it be made again

Probably, for data control and cost. But the decision should have come with a backup plan from the first day rather than as an outstanding task, and the operational burden is real rather than theoretical.