Rguttersohn

I’m assuming it has to do with putting your tables in the public schema, which the API accesses and therefore can be seen by anyone, and not setting row-level security.

You probably need to setup a local Supabase instance to test the codebase unless there is a remote dev DB that the codebase connects to. But that is one step. You also need Node installed on your computer to run a Next app. Have you done that?

You have it working in production or no?

Can you match the error time with your query logs?

I build databases with public interfaces at my job. Supabase is fine, but I usually prefer to use it with an ORM sitting between the front end and Supabase. They are much easier to work with for things like scoping and managing relationships and are more aware of your app’s needs. I’d also set up some caching here too so your db isn’t getting dinged all the time. Typescript has drizzle ORM, which i think is pretty popular. The next suggest is to avoid using React. Vue or Svelte are much better at only rendering and re-rendering what needs to be update. Most of the time that doesn’t matter but for data sites where you could be rendering a ton of data and thus alot of html nodes, Vue and Svelte will be faster. Each of them have their own meta frameworks that are great. Lastly, you’ll want to be mindful of what is rendered on the server vs what is rendered on the client side. Users of data sites are ok with pages taking longer to load, but I prefer to have the shell of a page render on several for SEO, etc and then have my slow queries load on the client side. Anyhow that’s my advice as I wait for my son to fall asleep.

Supabase infra is AWS. If AWS goes down, so does a large portion of the internet — including your redundant s3 back up.

Access to GTE Small for semantic searching.

I always have three different DBs no matter if I am working with Supabase or not. A local version for dev, a staging one for showing and allowing others to test prospective features. And then I use a separate production DB. I also tend to use an app layer with its own ORM to handle syncing between the three DBs.

I think before dropping Supabase I’d make a backend app layer between my front end and the DB that has an ORM and caching.

What do you mean by store it?

Here it is in the docs https://www.postgresql.org/docs/current/sql-vacuum.html

You probably need to run a vacuum command.

Self host on free tier ec2 instance?

I don’t use Supabase for migrations but typically my migration files start with a date and time so the order is dictated by time instead of alphabetically. Is that possible in supabase?

Check out the slow query log, see if I need to index a column in the query, run explain analyze before adding the query, add the index, run explain analyze after to see if it is fixed and the planner is actually using the index.

I don’t know if you’re using an ORM with your app, but I find it easier to set up security and policies in the ORM.

Run the query in Supabase and see if it works.

I don’t use the Supabase API or next but I’d check your env to ensure it has the proper connection credentials. Second, could it be the empty select?