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

221–230 of 374 posts

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

#221

Post by PudgePacket »

bavell wrote: post #181
pm90 wrote: post #155

Earlier quoted context omitted.

I may be wrong about the history of security work on databases (feel free to correct me!) , but I think the security model was built mostly for an age where a single DB would be used by many apps, thus access control at the DB level seemed natural to the DB admins. Today, with managed/containerized DBs and Microservices and share nothing architecture, I’ve seen most apps use their own database instance, in which case…

I'm curious to hear what others think about this as well. I run some WordPress sites in containers and I give each one it's own DB instance. I just create the root account with a strong password, give it to WordPress and call it a day. Makes ops much simpler although it's probably not the best use of resources (e.g. memory). Any big downsides to doing things this way? I'm no DBA so I appreciate any insights.

It may be more cost effective to use the same db instance, but that has it's own issues, like 1 site dragging everyone down, all sites need to handle the same db version and upgrade together..

I guess it's also just more instances to manage in total, instead of 1 + n it's 2n.

You _could_ run the dbs on the same instance but not using the same DB process, via containerisation perhaps. That way you could reduce your instance count while still keeping (somewhat) operational separation..

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

#222

Post by bradyo »

cwhiz wrote: post #146

Seems more similar to Hasura than to Firebase. Firebase adds functions, file storage, and authentication on top of the database. I didn’t see any of that mentioned on the site.

Yeah, this title is currently overadvertising the product. Without even getting into the non-OLTP DB parts of Firebase, Hasura is much further along towards being a Firebase replacement. It already handles auth and a basic admin UI for both the schema and data. I respect the vision and welcome more competition, but this seems to just stitch a "push" system to Postgrest for now (with no auth to boot).

Hasura also some limited support for generated multi-table transactional APIs, which Postgrest doesn't. Meanwhile, Firebase supports arbitrary read-modify-write transactions.

This team has its work cut out for them and I can see a fierce competition with Hasura and Firebase.

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

#223

Post by ssijak »

nojvek wrote: post #218

1. I liked that the nodejs example shown here uses async await syntax. I don’t get why people still put callback hell examples in 2020. 2. What I really like about firebase is firestore is a scale to zero database. It doesn’t cost me anything if I have tiny amount of data and low frequency of users. This lets me spin up lots of small sites at no cost. With cloud run I have a real api server that also scales to zero.…

I too have a project on firebase for a small business which costs me 0 but is vital for this business. I use firestore, cloud functions, auth and cloud storage for this project. Very nice for small apps.

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

#224

Post by draw_down »

tr33house wrote: post #144
blunte wrote: post #137

Earlier quoted context omitted.

I've read too many stories of people and companies being temporarily (and possibly permanently) incorrectly flagged/banned from Google (by some algorithm). If your business depends on Google, you are taking serious risk. Even if you have a contact within Google who can champion your case, a loss of your Google services could end your business.

I wouldn't worry about this. Any examples?

Why, so you can quarrel with each one and dissemble at every turn? Everyone knows what GP is talking about. If you don’t think it’s a risk, then enjoy!

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

#225

Post by ssijak »

tr33house wrote: post #144
blunte wrote: post #137

Earlier quoted context omitted.

I've read too many stories of people and companies being temporarily (and possibly permanently) incorrectly flagged/banned from Google (by some algorithm). If your business depends on Google, you are taking serious risk. Even if you have a contact within Google who can champion your case, a loss of your Google services could end your business.

I wouldn't worry about this. Any examples?

I got my old google account banned when I enabled adsense (and did absolutely nothing with it). They blocked me from random number of their services so that account became unusable. And I dis nothing wrong. And no way for appeal.

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

#226

Post by treis »

kiwicopple wrote: post #205
difosfor wrote: post #201

How scalable is this? E.g: What is the maximum active (e.g: writing) user concurrency? What happens when that is exceeded?

Under the hood we are just postgres. At the moment every user is on their own Postgres database with some additional plugins and defaults: https://github.com/supabase/postgres We are already working on High Availability, and we'll give a very simple point-and-click for replication too (so you can create multiple DB's close to your customers/audiences)

How do you handle the creation of the database for a new user?

Any issues with maxing out connections to the DB?

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

#227

Post by rakoo »

mercer wrote: post #199
rakoo wrote: post #161

Earlier quoted context omitted.

If you don't pick a db, where do you store data ?

That would be step one out of the first three that I bother with :).

I read "skipping steps 1-3" instead of "keeping steps 1-3", my bad.

Do you have good resources for learning Elixir with OTP and Phoenix ? I also believe LiveView can deliver the 80% of functionalities for 20% of the price, so I'm very interested in learning it

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

#228

Post by varrock »

ta17711771 wrote: post #207
time0ut wrote: post #164

Earlier quoted context omitted.

I've used Firebase for a couple MVPs. It is very fast to develop on. It makes it easy to get a web or mobile app up in a few hours once you know what you're doing. It is definitely possible to be that fast using other technologies, but the learning curve is higher. When you're just experimenting, trying to find market fit and get something to stick, Firebase is a decent solution. I haven't tried anything sizeable on…

I've seen this sentiment echoed a few times. What are the advantages, or class of advantages, you get by moving on from Firebase to something stronger/harder?

I’m very junior, so take what I say with a grain of salt. But when I was determining if I should use Firebase or not, my biggest hesitation was simply that if Firebase ended today, I have to completely transition my application’s architecture.

Though that is unrealistic, even thinking about it was enough to make me want to be in full control of my application’s various layers.

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

#229

Post by z3t4 »

eatonphil wrote: post #165
pm90 wrote: post #153

Earlier quoted context omitted.

Maybe I am an old fart, but what’s wrong with the steps you mention? What would your ideal sequence of steps be? If the answer is “just call an api to handle your data” sure that works for POCs/Small apps. But I’m a bit hesitant to put all my businesses data inside a proprietary data store that I don’t control and which isn’t collocated with my app (Ie every data store request makes a round trip to the google server…

It's not bad doing it once. Furthermore I'd suggest you do it truly from scratch once just for the learning experience (no framework [Go makes this easy] or from TCP socket [synchronous with Python is easy]). However it's ridiculous going through the same sequence for every single app you build over a career. Nothing changes, it's all just boilerplate. I don't want to ever write this sort of boilerplate code again, I…

Who does the same app over and over, and if then why not just copy it? With new tech there are a lot of churn, who knows Google will announce the shutdown of the db service tommorow, and next week you need to rewrite the app in the latest version of the framework. Meanwhile old boring tech will still work just fine 20 years from now.

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

#230

Post by malisper »

I've been thinking about the need for easier to use databases for a long time. I previously started a company based on selling database software, so I've seen a lot of problems in the space. I honestly most databases are too hard to use and there's been no major improvements here in the last few decades.

Take Postgres. You write code in SQL, a programming language unlike any other mainstream programming language. Instead of writing code with for loops and if statements, you write it with joins and where clauses. On top of that, Postgres has a "magical query optimizer" that takes your SQL and figures out how to execute your query. Unless you have a good understanding of indexes and how they impact the query optimizer, you'll have a hard time getting Postgres to be fast. I still regularly say WTF when optimizing Postgres queries even though I've been doing it for years. That's not to mention there's tons of database specific terminology like tables, rows, schema, etc, that you have to learn before you can become an effect user of Postgres.

As much as HN likes to bash it, I think Mongo has done the best job of creating an easy to use database. With Mongo, you can store JSON and you can pull JSON out. Of course, I would never use Mongo personally.

I'm hoping that Supabase is able to bring about the next-phase of databases by not just making it possible to make a database fast, but by making it easy to do so.

Post reply on HN