Ephemeral Database Structure

## Query limitations You cannot execute raw SQL queries from the Supabase client. I’m sure there are reasons for this. But I often find myself wanting to write queries that the Supabase client does not support. Or that would at least be far more efficient when using proper SQL. The solution for this is to create a named Postgres stored procedure which you can then call from the client. … I don’t like this because the code for it is stowed away in the database. This means that every time I want to read or change it I need to leave my editor and go to the Supabase GUI. And it also means I now have logic inside my DB and thus outside of my codebase. Another option would be using a Postgres view. But that comes with similar drawbacks. … Now assume you use the Supabase client and go directly from DB to frontend. In that case, you’d have to fetch huge amounts of data to the browser and run the calculations there just to display one calculated number. That’s not practical. So instead I have a proper backend that can run the calculations with ease. … ## Pick the good parts of Supabase while ignoring the rest I’m not a fan of using the Supabase client for fetching data. Yes, it may be great for beginners who just want some data in their frontend. Without running their own backend. Solutions that are so simple and try to abstract the backend rarely scale well to real-world use cases. You spend far more time creating workarounds than what the “easy” solution saves you. Another example of this is Hasura. It may look great for simple CRUD demos. But as soon as you try to solve actual problems you start having to fight its limitations.