Back-end platform
Supabase
Supabase gives an app a back end quickly, built on PostgreSQL, a standard and widely trusted database. We use it when a product needs structured data, fast delivery, and an easy way out if plans change.
- 1,200+ clients helped
- Building since 2010
- 15 services, one team
- 50+ technologies
At a glance
What it is
Supabase is a ready-made back end built around a standard PostgreSQL database, with sign-in, file storage, and live updates included.
Problems it solves
Teams want the speed of a hosted back end but not the lock-in of a proprietary database, and they need relational data and reporting.
Who it suits
Product teams building web or mobile apps with structured data, and teams looking for an alternative to Firebase.
How to choose
Choose Supabase for a quick start on a real relational database that you can host elsewhere later. Choose Firebase for the simplest live data, or a custom back end for unusual needs.
What it means
A hosted back end on a database you can take with you
Supabase offers what a hosted back end offers: accounts, storage, live updates, and functions. The difference is the center. Underneath is PostgreSQL, a database that thousands of other tools and teams already know.
That choice has practical effects. Data is held in tables with relationships, so orders, customers, and invoices join cleanly. Reports can be written in ordinary SQL. And if the product outgrows the service, the database can move to another host without a rewrite, because it is the same database.
Access control is also done in the database. Rules, called row-level policies, say which rows each person may see or change, so a mistake in the app is less likely to expose someone else's data.
Typical uses
Where Supabase fits well
A software-as-a-service product
Customer accounts, subscriptions, and per-customer data, kept apart by access rules.
An internal tool or portal
Staff or customers see their own records, with the same data available to reports.
A prototype that may become the product
Built quickly, on a database that can carry the real product later.
A move off a back end that has become limiting
Data brought into a relational database, so reporting and relationships become straightforward.
Options
Supabase compared with the alternatives
Suits
Relational data, reporting needs, fast delivery, and a wish to keep the exit open.
- Trade-off
- A younger service, with fewer built-in extras than the largest platforms.
Suits
Very simple live data, mobile-first apps, and the fastest first version.
- Trade-off
- A proprietary data model that is harder to leave and to report on.
Suits
Complex rules, unusual hosting or compliance needs, and large scale.
- Trade-off
- More to build and operate, so a later first release.
Next.js with your own database
Suits
Web products where one team controls the whole stack.
- Trade-off
- You assemble sign-in, storage, and live data yourself.
What DECHY can do
Working with Supabase
Build
Secure
- Row-level access rules, tested.
- Sign-in with email, social accounts, or your own identity provider.
Migrate
- Moving a product from Firebase or another back end into a relational database.
- Checks that every record arrived and relationships held.
Look after
- Backups, upgrades, and performance reviews.
- Self-hosting when you need it on your own infrastructure.
How we build it
A Supabase project from first design to launch
Model the data
We design the tables and relationships around what the product must do and report.
What it produces
- Data model
Write the access rules
Row-level policies decide who sees what. We test them as carefully as any feature.
What it produces
- Access policies
- Policy tests
Build the product on top
Screens and server functions use the platform's services instead of re-creating them.
What it produces
- Working product
Prepare to grow
Backups, environments, and monitoring are set up, and the exit plan is written down.
What it produces
- Environments
- Runbook
Technical depth
How we build with Supabase
Our engineering choices on database, security, server logic, and portability, written for the people who will own the system after launch.
- Schema changes are written as versioned migrations and applied the same way in every environment.
- Indexes are added for the queries the product actually runs, and checked with query plans.
- Business rules that must always hold are enforced by constraints in the database.
- Row-level security is switched on for every table that holds user data.
- The public key is safe to ship to the browser only because the policies protect the data; the service key never leaves the server.
- Sign-in sessions are short-lived and refreshed securely.
Work that must not run in the browser, such as payments or sending email, runs in server functions that check the caller before acting.
Because the core is PostgreSQL, a dump and restore moves the data to any other PostgreSQL host. We keep application logic in our own code so that moving is a task, not a rewrite.
Common questions
Questions about Supabase
Is Supabase production ready?
Many products run on it. As with any hosted platform, readiness depends on the set-up: access rules, backups, monitoring, and a plan for growth.
Can we host it ourselves?
Yes. The platform can be run on your own infrastructure, and the database itself can be moved to any PostgreSQL host.
Supabase or Firebase?
Supabase suits structured data and reporting and keeps the exit open. Firebase suits very simple, live data. We compare them against your product.
Can we move to Supabase from Firebase?
Yes. We redesign the data as tables, move it in stages, and run both until the new back end has been checked.
Have a different question?
Tell us what you are weighing up and we will answer it plainly.
Ask a questionAlready a client? Email support@dechytech.com
Tell us about the product
Describe what it does and the data it holds. We will say whether Supabase fits and outline the set-up.