PostgreSQL or MySQL? Why I choose Supabase with Nuxt for large management systems

I have been working a lot with Nuxt lately, as I described in React or Vue: why I choose Nuxt, and more and more often on complex projects: management systems, private areas, platforms with a lot of data. On those projects I don't use Nuxt Content, Netlify Blobs or an external service to store data. I use a real database, with its own rules, and in my latest work it is PostgreSQL, almost always through Supabase. I have been pleasantly surprised by it, and here is why.

Why Nuxt Content and Blobs are not enough

Nuxt Content is excellent for editorial content, meaning text and pages that rarely change and are versioned as files. Netlify Blobs is a handy store for files and simple data. Neither knows that a customer has many orders, that an order cannot exist without a customer, or that each user must see only their own data. A management system needs all of this, and rebuilding it in code means building a poor database by hand. Better to start from one that already does it.

PostgreSQL and MySQL: how they differ

Both are table-based databases, with rows and columns. MySQL is solid, and for a site with simple tables it is a perfectly valid choice. PostgreSQL has more tools when data is large and interlinked. Four of them matter to me.

Richer data and stricter rules

PostgreSQL can store flexible data in a column too (the jsonb format, useful for a contract's options or for data coming from another service) and query it with ease. With enums, a list of allowed values, an order's status can only be "processing", "shipped" or "delivered": the database guarantees it, not the code. One thing to know: adding a value to the list is easy, removing one is not.

Safe changes to the structure

As a project grows, the structure of the tables keeps changing. In PostgreSQL a change touching several tables either succeeds completely or changes nothing. In MySQL, if something goes wrong halfway, the database can be left half-changed and has to be fixed by hand.

Fast even with lots of data

PostgreSQL lets you create indexes (the shortcuts that make searches fast) only on the rows you care about, for example orders that are still open, ignoring the archived ones. That keeps large tables quick. It also has text search and similarity search built in.

Row-by-row security

This is the difference that weighs most in a management system. It is called Row Level Security (RLS): the rules on who can see what live in the database. A customer sees only their own orders, even if somewhere in the code I forget a filter. MySQL has nothing equivalent, and the rules end up scattered across the application.

And when MySQL is still fine

If the project is a site with a few tables, perhaps on hosting that already offers MySQL and a panel like WordPress, there is no reason to switch: PostgreSQL's advantage shows when data becomes large, interlinked and reserved for different users. For me the threshold is the management system, not the showcase site.

What Supabase adds

Supabase doesn't replace PostgreSQL: it builds around it what I would otherwise have to create and maintain myself. I use:

• authentication, tied directly to the row-level security rules;
• storage, for files, with the same permissions;
• webhooks, automatic notifications that call another service when a row changes;
• tables, enums and views, the latter as "virtual tables" built from a query, handy for reports.

Two things to watch. Views ignore row-level rules by default, so they need to be configured to respect them. And in a serverless environment, like Netlify's, PostgreSQL handles many simultaneous open connections poorly: you need an intermediary (the pooler) to route them, and Supabase has one.

The downsides: costs and self-hosting

Today I use Supabase in the managed cloud, and that's where the downside is: costs grow with database power, storage and traffic, and for a data-heavy management system they can become a significant item. That is why I want to try self-hosting, meaning installing it on a server of my own. I haven't done it yet, so what follows comes from the documentation, not from experience.

Self-hosted, Supabase is not a single program but a set of services running together. The difficulties I expect:

• Updates: each service is released on its own schedule and they must be updated without breaking anything.
• Backups: restoring to a precise moment isn't included and has to be built with other tools.
• Security: keys, certificates, firewall and sending the login emails are on me.
• Ongoing oversight: monitoring and protection against failures, which in the cloud are already included.

Saving on the subscription is paid for in management time, and for a client with nobody to look after a server the cloud may remain the best choice.

My take

I like Supabase because underneath there is plain PostgreSQL: the data structure is mine, written in files versioned on Git like the rest of the code, and if one day I wanted to leave the platform I would take the database with me. The rest of the method doesn't change: Nuxt and TypeScript, every change with its own preview on Netlify, the main branch never touched directly. Lately I keep improving how I build these systems, and my latest sites are already built on this foundation.

Why work with me

Since 1999 I have delivered more than 300 projects and I work with more than 30 agencies. If you have a management system that is cramped inside spreadsheets or a database that grew badly, get in touch: in a call of about 20 minutes we can work out whether it makes sense to restart from a solid base. The service is Custom software and I also cover it in Custom management system or Excel.