Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, and Storage.

Supabase

can’t access my db rest endpoints or login to the dashboard

Right, didn't read previous messages 🙂 No ETA of a possible fix by the team?  (will email the support though)

emailed support this morning haven’t heard back since, status pages are showing everything is fine which is weird

<@!107176742342402048> have you figured out how to use svelte-query using supabase? for me it only loads from disk-cache if I'm using fetch. I can't get it to cache while using supabase.js

I got it working that now it fetches from the disk cache as expected while navigating, although the behaviour is somewhat inconsistent. maybe I have to fiddle with the settings. at least I know there's no conflict with supabase.js

by the way, I just found sswr https://github.com/ConsoleTVs/sswr it works too

oooh this looks good, I will definitely take it for a spin too

saw you asking about svelte-query on the svelte discord

'mornin'! It seems there's a need for tooling that bridges the gap between client side business logic and applying that logic on the database side via triggers, functions, etc (think "write once, use in client and server type tooling). Before I spin up a new project to start working on said tooling, are there existing solutions I should be aware of? (I'm thinking specifically about migration tooling that copies JS functions over to PostgreSQL PLV8,  but am open to other approaches).

<@!613035755152998401> I agree with you, I've thought a bit about this and have come up with the following rough direction that I plan to follow in my current project:
 - as suggested by the PostgREST project itself, I plan to keep all my data in a private schema and put in the public schema only views and functions (i.e. data will be fetched via views and functions, not directly throught the tables)
 - any relatively simple logic will be done in views and standard SQL-based functions/triggers
 - any complex logic will be implemented in TypeScript, compiled to JavaScript and then executed via PLV8

this last bullet raises some interesting questions about how to re-use code between functions, what will be the API endpoints, etc. My current plan is bundle ALL the code in a single PostgreSQL PLV8 function where the top level will be a dispatched (so the rpc() call you make will include the method to invoke and the params)

On the one hand, if most of the methods are simple enough, the dispatcher should also be simple enough

On the other hand, if the methods or the dispatcher become complex, this would be a sign that I need to bite the bullet and deploy a full-blown API server...OR wait for Supabase Serverless functions 🙂

I'd be curious to hear your thoughts about this general direction and after than we can dive into more details

Interesting Chipilov. I haven't looked into PostgREST much, so I'm curious how it interacts with updatable views. Assuming that's as easy as using regular tables, I'll move on to the next topic of the general approach. 
Having a separate schema certainly sounds like a great start...will look into that a bit more.
WRT the single function, I'm not familiar with the performance implications of PLV8. For example, how does loading one large function compare to loading smaller purpose-built functions? I imagine the IMMUTABLE, VOLATILE options for functions end up going out the window, leaving some performance on the table. I _think_ having a single function may also limit use of built-in functionality such as triggers to handle some business logic. Without understanding more about how you'd address those, I'd lean toward using a larger number of purpose-built functions, and a migration script that converts between TS/JS to PLV8. The bridge  between the two (i.e. how do functions map to views, and such) would be an interesting project. 🙂

I don't have a lot of datapoints yet to discuss performance - I did a prototype with 2/3 JS endpoints inside a webpack-generated JS file of about 200 lines and there was no meaningful degradation compared to a native SQL function. I know 200 lines is NOT much, but then again - if I need more than 1000 lines of such code, it seems to me that I just need to move to a dedicated app server or serverless functions

(the prototype was done WITHOUT IMMUTABLE as you mention)

The reason why I currently lean towards a single function instead of multiple ones (i.e. separate PostgreSQL function wrapper for each JS function) is simplicity - this makes both sharing of code and deployment of changes easier

the way I think about it is like this - if I need more than 500/1000 lines of JS code, then I probably need a dedicated app server and stuffing the logic inside PLV8 is probably the wrong approach. And if the logic is less than 1000 lines, then perf will most likely NOT suffer and will make things much easier

with regards to triggers - I have NOT tested it yet, I hope that triggers allow passing custom parameters to the trigger method

btw, one interesting thing about PLV8 - as far as I understand, PLV8 is inited per session, so if you can use connection pooling per session (rather than per request), then the cost loading of the code is paid only once when setting up the session. This, of course, would only be possible if you don't have a lot of concurrent users OR if user session are short-lived

Great insights there. Thanks for the detailed notes. Will try to respond later today when I have more time.

Yeah, the idea of a dedicated app server seems reasonable after a certain point. That kind of goes against the whole  serverless architecture that Supabase is going for though. There's got to be a way to organize serverless functions, database configurations/migrations in a more seamless manner. Hmm...If people currently employ conventions to manage their serverless functions, then applying those principles to PostgreSQL might also work. I'll look into that next.
The issue with that though is that you end up with spaghetti functions, and managing interactions across multiple functions becomes difficult, so at the very least you need guidance on keeping function interactions to a minimum. When that's not possible...well, I'll need to think about that. I recently came across Event-Driven Microservices which presents the idea of an orchestrator that manages operations. That sounds promising, and the question then becomes "where does the orchestrator live? in the PostgreSQL DB, or a separate server. Perhaps when it becomes big enough, you deploy it by itself, but you start out with a PLV8 function.
As for PLV8 performance, I see that it starts a new global js runtime context for every session, but I need to understand whether that's the same as the global execution context (which would be nice) or if they're talking about starting up an entirely new process for every session (which seems expensive)...will come back in a bit.

- "That kind of goes against the whole  serverless architecture that Supabase is going for though." - I agree to a large extent but with a few caveats. For example, even if you setup an app server, Supabase still gives you things out of the box like a managed DB, auth and storage . So it's not like having an app server completely defeats the purpose of using Supabase - sure, it diminishes its value, but you still get something non-trivial out of it.

- ".If people currently employ conventions to manage their serverless functions" - I think that's a great question and since I am new to the serverless world, it definitely struck me as something of  a blind spot - there are very few resources about how to structure such functions and keep them both maintainable and performant. I've noticed that different providers have different approaches (for example Firebase serverless functions are very different from CloudFlares's workers). I think that might also be the reason why there are so many examples with Supabase and Next.JS, i.e. because Next.JS actually gives you a serverless app server (pun intended) behind Next.JS's /api routes (but then you also need to live with the complexities of SSR/hydration/etc)

- "I recently came across Event-Driven Microservices which presents the idea of an orchestrator that manages operations. " - to me personally, this is actually what goes somewhat against Supabase/Firebase's promise of simplicity. Because the world of microservices is actually quite complex. To be crude, I am a nobody so I am not going to give you my personal convictions about microservices but everyone knows Martin Fowler and he's the one that says "MonolithFirst" (https://martinfowler.com/bliki/MonolithFirst.html) - and I thought that was the whole point of serverless, that you don't need to "orchestrate" and keep things simple. And it seems like you can do that with serverless AS LONG AS you actually have a relatively simple app OR you are in the early stages of your app when velocity is more important than stability. Beyond that I don't think serverless can help you, at least NOT with its current capabilities

Where exactly you draw the line - it's a good question, but I don't think there is a universal answer, it really depends on experience probably

Having said that I think what makes Supabase stick above the other serverless platforms like Firebase and AWS Amplify is that if it came to it, it would be much easier to move to a more standard serverull solution because you are already using similar pieces (i.e. SQL db), you just repackage them a little differently

...but I digress, I would love to hear more about (1) how you think you can manage/orchestrate serverless functions and (2) what you find out about how PLV8 manages the JS environment

Any chance you're available for a quick video conference? would love to chat more about approaches so I can take a quick stab at something simple.

(moving conf arrangements to DM, feel free to continue the actual discussion here)

Anyone got experience using the Swift lib with SwiftUI?

https://twitter.com/kiwicopple/status/1453176848683204613

<@!400623078259949579> Thanks for fixing my PR 😅

I have pg_dump data, i am trying to execute it, but it's not working, so what can be wrong? basically trying to create tables and seed data

What can be done to prevent a DoS attack for a Supabase hosted app? If someone runs a script to hit the DB over and over, that is a pretty easy way to bring down the app and hike up the fee.

I don't think any fees would change, Supabase doesn't charge for API requests

true, but the question of denial of service remains. Does the fact that that the API sits behind Kong's API gateway provide any protections?

won't there be chargers for the transfer limits though, if you were on the "pay as you go" plan? like the database/object storage transfer charges? thanks

We should put some dedicated time to this problem and other similar problems. 

It's probably top of mind for people.

I heard they are implementing rate-limiting which may reduce DDoS impact a bit -  not sure about the timeline of the feature though...  https://www.reddit.com/r/Supabase/comments/p7vhbi/rate_limiting/

I've heard that as well. But the time line is murky. Hopefully this is something they can get up and running in a month or so.

I was wondering if there was an alternative solution. Some users discussed adding tables that limited user activity. But that doesn't work for db stuff that can be done by unauthed users

I have a .CSV file that I am trying to import into a table in the dashboard, but whenever I import it I just get empty rows. Can anyone tell me why this is happening. Is there something wrong with the .CSV file?

From upload button "Upload a CSV or TSV file. The first row should be the headers of the table, and your headers should not include any special characters other than hyphens (-) or underscores (_)."  / might be the issue, but I'm just guessing

Hi there.. Just a quick question. Can i know for the Pro Plan, for the 100,000 users limit, is it based on the count of total 100,000 users in the users table or is it like Auth0 or Amazon Cognito where they count by the number of authentications ("monthly-active-users") that take place for a particular month? Thanks in advance!

is there a way to upgrade the database server?

Do you mean like upgrade the size? or do you mean upgrade the webserver specs?

For either of these its best to contact the supabase team via email on support@supabase.io with a reference to your project id

i mean the webserver specs, or rather cpu since the load is over 100%

i'm currently sitting on above 100% cpu with my traffic

i'm getting a lot of these: "the upstream server is timing out"

I guess you need to pay for that, the free tier is limited

Hmm, it could be a suggestion then, you may post your message in <#867348150741237790>