Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase (YC S20) – An open source Firebase alternative

supabase.io

Post reply on HN
Print view View original

361–370 of 374 posts

Re: Supabase (YC S20) – An open source Firebase alternative

#361

Post by codecamper »

I like this trend of creating a free / low cost version of an entrenched product & then supplementing with SAAS revenue.

However, the real reason these companies are worth so much is the stock market & careful stock manipulation carried out by Wall Street firms.

It's a game of using most of your money for AdWords & marketing.

The trick is to grow your revenue at a rate like 40% yoy, starting at a rate of about 100% and then slowly declining down to a 40% rate.

Of course you pay for this with ad dollars. Wall Street really does not care how you obtain that growth, just that you do obtain it & every quarter you "surprise" the analysts with a little more revenue than planned.

In the beginning you can spend lavishly on SG&A so that it's an easy target for reductions in the future.

And in the beginning you take out massive amounts of money with stock option grants.

Anyways, my observation is that we could use a Stock Wealth Maximization as a Service.

Re: Supabase (YC S20) – An open source Firebase alternative

#362

Post by cultofmetatron »

kiwicopple wrote: post #94
cultofmetatron wrote: post #92

Was going to quip that I built a homegrown version of this in elixir which is the best stack to implement something like this if you want it to be scalable. Then I saw that THIS was written in elixir. That made me take this much more seriously!

Elixir really is the perfect tool for this job. Also there are a few features we are building into the realtime server that will make the system really shine (and extensible): https://github.com/supabase/realtime/issues/33 Basically we are refactoring it so you can pipe your database changes anywhere - webhooks, kafka, serverless, slack etc

I was looking into debezium to do this but an elixir solution would be fantastic. I'm trying to solve this in my own startup. Are you guys on the elixir slack? would love to sync up.

Re: Supabase (YC S20) – An open source Firebase alternative

#363

Post by jimktrains2 »

eatonphil wrote: post #170
jimktrains2 wrote: post #167

Earlier quoted context omitted.

I built something a while ago call bam[0] that basically did that. You specces your application in an xml file and it built out the admin ui, orm code, and db schema. I took a bet on a soon to be dead framework and ultimately didn't have time to continue the project, but it worked pretty well.

That makes sense. I'm hedging against dead technology by keeping the database and code generation parts separate from the templates. This way you can have templates for any languages so long as they speak a shared (HTTP) API specification.

I did the same, I just didn't feel like going back and rewriting all the templates.

Whoopse! forgot the link earlier https://github.com/jimktrains/bam I wish I had included an example in there though :(

Re: Supabase (YC S20) – An open source Firebase alternative

#364

Post by pier25 »

tlarkworthy wrote: post #357
pier25 wrote: post #302

Earlier quoted context omitted.

Check this benchmark: https://serverless-benchmark.com/ It displays data from the last 3 days of tests. Google Cloud has a max peak of 60 seconds for cold starts. It's the second worst after Azure.

Thats an amazing benchmark. Though you have to fiddle with the concurrency parameter to see that some of the slowness is caused by scaling.

OTOH cold starts are calculated with a concurrency of only 10.

The point of using serverless is handling massive traffic spikes efficiently and cheaply but 10 concurrent connections doesn't seem very massive.

Cloudflare Workers are doing much better than the rest in this respect (see the max value, the graph is misleading) but these have serious limitations (eg: max 50ms of CPU time). This makes them a bad fit for most situations.

In my current project which requires lowest possible latency I'm having more success with Fly.io. Instead of having cloud functions you create docker images which are distributed on their regions and scale up/down based on demand on that region.

https://fly.io/

Re: Supabase (YC S20) – An open source Firebase alternative

#365

Post by RNCTX »

danenania wrote: post #263
RNCTX wrote: post #179

Earlier quoted context omitted.

Not every database application is a public facing web application. Think about, for instance, a company's internal customer database (including billing, etc), accessed with internal tools. CSR/Support people need to be able to see billing status but not credit card numbers, for example. Different levels of management need to be able to generate reports, but again not get credit card numbers. For these use cases the o…

Access control gets complicated though. Maybe a column should be accessible to a user, but only under x, y, z conditions that require hundreds of lines of logic to figure out. Do you really want all that inside the db?

It certainly does. I've been at a company that had an improper permission result in a CSR getting elevated access and deleting the whole customer database, including every single credit card number, by mistake (admittedly this was back in like 2002). Better still, the devops guy who wrote the backup scripts had recently quit, and they were broken, the backups weren't being done. The company-saving backup from the previous day wound up being on an internal tools developer's laptop. I wasn't a database admin there or responsible for the permissions, but it was quite a wakeup call for everyone to double check their stuff when the rumors of what happened got out of the meetings the next day.

The counter argument is, would it better to have 10, 20, 100 such possible situations mulling around the building every day, or just one? Maybe if there's just one, you put enough effort and people into the one to get it right. That's the pitch for AD / LDAP being used for all auth and permissions, and I think a compelling one at that.

Re: Supabase (YC S20) – An open source Firebase alternative

#366

Post by stolsvik »

taylorwc wrote: post #329
ekseda wrote: post #243

Earlier quoted context omitted.

I wrote a master thesis where I compared several realtime database products. I promise you amplify is no where "getting there". It is a crippled version of firebase and there is no fix in sight. For example you cannot even do sort-queries with datastore or Amplify is not working with angular because they have broken typings since 9 months with no fix. And the list goes on..

Would love to read the thesis if you can share!

Same here. Is it maybe available from a university website?

Re: Supabase (YC S20) – An open source Firebase alternative

#367

Post by Alex3917 »

derivagral wrote: post #356
Alex3917 wrote: post #287

Earlier quoted context omitted.

So just don't use fat models. The only sensible way to use Django is to put all the business logic in service methods, not in models/managers or serializers/forms. If all your business logic is in models then of course your app is going to be completely unmaintainable and it's going to take developers weeks to do things that should normally take a couple hours. There is definitely a real problem in the Django communi…

I was just acquired into a team that enthusiastically recommended that book. Are there any alternative references I could look at or point to as alternatives? I've used a good bit of Flask but don't have much experience with Django.

The book is actually worth reading, there are just some things that I strongly disagree with. The reason I'm writing my own guide is because there isn't anything else there that I like.

Re: Supabase (YC S20) – An open source Firebase alternative

#368

Post by kiwicopple »

cultofmetatron wrote: post #362
kiwicopple wrote: post #94

Earlier quoted context omitted.

Elixir really is the perfect tool for this job. Also there are a few features we are building into the realtime server that will make the system really shine (and extensible): https://github.com/supabase/realtime/issues/33 Basically we are refactoring it so you can pipe your database changes anywhere - webhooks, kafka, serverless, slack etc

I was looking into debezium to do this but an elixir solution would be fantastic. I'm trying to solve this in my own startup. Are you guys on the elixir slack? would love to sync up.

Our realtime server is built with Elixir. Feel free to email me directly if you want to chat (email is in my profile)

Re: Supabase (YC S20) – An open source Firebase alternative

#369

Post by tlarkworthy »

pier25 wrote: post #364
tlarkworthy wrote: post #357

Earlier quoted context omitted.

Thats an amazing benchmark. Though you have to fiddle with the concurrency parameter to see that some of the slowness is caused by scaling.

OTOH cold starts are calculated with a concurrency of only 10. The point of using serverless is handling massive traffic spikes efficiently and cheaply but 10 concurrent connections doesn't seem very massive. Cloudflare Workers are doing much better than the rest in this respect (see the max value, the graph is misleading) but these have serious limitations (eg: max 50ms of CPU time). This makes them a bad fit for mo…

That's like cloud run which I also prefer. I'll try fly it looks like an even better fit

Re: Supabase (YC S20) – An open source Firebase alternative

#370

Post by vikramkr »

hilbertseries wrote: post #320
bawana wrote: post #203

Earlier quoted context omitted.

The pseudo-democratic silicon valley model of freemium is the problem. Seducing you into using something with the word 'free' but then trapping you with a changing API and cost structure. They should be up front with the realization that our ability to pay THEM is not commensurate with use by OUR users. Fees should based on OUR revenue, not usage.

> Fees should based on OUR revenue, not usage. So if someone builds a business that makes very little money but uses a ton of compute, the cloud provider should subsidize that? And conversely if you make a ton of money using barely any compute, you should pay your cloud provider a premium? This business model makes no sense.

The cloud provider would very much like to have the premium part of the model without the subsidy. Theres a reason a lot of b2b enterprise products dont list prices on their websites and ask that you contact sales instead. Value based pricing and all.
Post reply on HN