27 ms·

Supabase (YC S20) – An open source Firebase alternative

• rsify 6y ago
  I’m super curious about the real time part - did you pioneer this solution and why did you pick it over other ones (if any)?
  • kiwicopple 6y ago
    This is actually how we started. I was using Firebase and hit some scale problems. We decided to migrate to Postgres, and I still needed the realtime functionality. I started naively: just with triggers/NOTIFY. There were a few tedious things about this approach (creating a trigger for every table), and one major flaw: NOTIFY has an 8000 byte payload limit. So we were getting dropped notifications. I looked into a few other ways to do it, but nothing fit 100%. So I built it, but of course with the help of other awesome opensource libraries. Using the logical decoding is an amazing solution, mostly because you get message replay if there is an outage. More details in the repo: https://github.com/supabase/realtime https://github.com/supabase/realtime
• kiwicopple 6y ago
  co-founder here, happy to answer any questions. We're currently in alpha - app.supabase.io We also have a lot more to build, so to reward you for your patience we are completely free right now
  • tmikaeld 6y ago
    How much cheaper than Firebase do you expect to be when you launch?
    • kiwicopple 6y ago
      Good (leading) question :) It's hard to answer because we're so early, so the most honest answer I can give is: i don't know. Firebase just changed their pricing to "pay as you go". I need to dig into their pricing to give a good comparison but I think we will be much cheaper for the IAAS aspect - we will try offer more value via the dashboard (i.e. we want to build an Airtable-like interface for non-techies to use), and charge on that aspect. One more thing - we personally find predictable pricing to be an important feature of IAAS and therefore will probably price differently to firebase's usage model.
      • tmikaeld 6y ago
        Or you can do what many usage-models do, make a calculator and usage on common use-cases.
  • lukeramsden 6y ago
    How does this compare to Postgraphile or Hasura? Or rather, how is it going to compare once you've had some time to get it out of alpha.
    • kiwicopple 6y ago
      Good question - one we get asked often. We don't use GraphQL (but you can do deep-queries: https://supabase.io/docs/library/get#query-foreign-tables https://supabase.io/docs/library/get#query-foreign-tables) Under the hood we use PostgREST. At the same time, we may (also) offer GraphQL using Postgraphile, so people can bring their own client-library. Differences from Hasura: - Auth: we will use Postgres RLS - Realtime: we don't use triggers, we use WAL (much more scalable) - Only Postgres: Hasura mentioned they will build for other RDBMS. We're all in on PG and some of the more advanced features (replication, High Availability) - UI/UX. We will build an interface like Airtable, so that even your non-techie friends can use it
      • pkghost 6y ago
        This might be pedantic of me, but conflating RLS and auth isn't a great look. RLS is a general purpose mechanism for constraining row operations, and auth has to do with usernames and passwords and session tokens.
        • pdimitar 6y ago
          Maybe they mean authorisation rather than authentication but like you, I am curious if they will elaborate further on how is Postgres RLS used.
          • lukeramsden 6y ago
            Probably similar in an overall sense to Postgraphile et al[0], in case you haven't seen that - although I am also interested in the specifics relating to Supabase. [0] https://www.graphile.org/postgraphile/security/ https://www.graphile.org/postgraphile/security/
        • 6y ago
  • yannikyeo 6y ago
    How does app handle authn?
    • kiwicopple 6y ago
      see my other comment > We want to nail the auth and we're looking at leveraging Postgres' native Row Level Security. This is a tricky task to "generalize" for all businesses but we have some good ideas (we're discussing in our repo if you want to follow - https://github.com/supabase/supabase https://github.com/supabase/supabase)
  • imedadel 6y ago
    About the choice of the database. Why did you decide to go with PSQL instead of a NoSQL database as Firebase does? Doesn't that affect your scalability? Otherwise, great project!
    • kiwicopple 6y ago
      Actually we chose Postgres specifically because it is scalable. I had to switch from Firebase in my previous company because we hit some scaling limits. Postgres handles the scale no problem - it's crazy the performance improvement we saw (and it's ACID) The trickiest part was the realtime functionality - https://github.com/supabase/realtime https://github.com/supabase/realtime
  • dexterbt1 6y ago
    Any link to deployable dockerized versions?
    • kiwicopple 6y ago
      Theres a version here: https://hub.docker.com/r/supabase/supabase-dev https://hub.docker.com/r/supabase/supabase-dev But we will be releasing a much more robust version with docs soon!
  • warent 6y ago
    Hey there, I like the product and think your business model is admirable. I would like to make a suggestion that you consider offering some support for your enterprise patrons. $1000+/mo is very steep for an ad even if it was a popular product. imo that should come with some amount of white glove treatment.
    • kiwicopple 6y ago
      That's a good call - let me update! edit: OK added - https://github.com/sponsors/supabase https://github.com/sponsors/supabase
• wizzzzzy 6y ago
  How does this compare to feathers.js?
• nmfisher 6y ago
  My app is currently built on top of Firebase but I’m keenly aware of the cost of lock-in as traffic escalates. Is this a replacement for the whole suite of Firebase offerings (hosting, auth and data store) or just a subset? What’s the migration pathway for someone currently on Firebase?
  • phreack 6y ago
    It looks like a way to turn Postgres into a Firebase real-time database alternative, so not Crashlytics, Auth or file storage AFAIK (and I'd suggest making it more obvious on the website if I'm wrong!)
  • kiwicopple 6y ago
    We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :) > data store Yes - our data store is just Postgres so you can migrate in/out - no lockin > hosting, auth Not yet. We want to nail the auth and we're looking at leveraging Postgres' native Row Level Security. This is a tricky task to "generalize" for all businesses but we have some good ideas (we're discussing in our repo if you want to follow - https://github.com/supabase/supabase https://github.com/supabase/supabase) > What’s the migration pathway for someone currently on Firebase? This is also something we're building - a migration tool. Mapping NoSQL to RDBMS is complex, but something I tackled in my previous company. We'll build it so that Firebase and Supabase run "in parallel", which we can do since both have realtime functionality. And then when you're happy, you will be able to switch off Firebase
    • danielscrubs 6y ago
      That's pretty much what I've been wanting for years. Open Source software that make row level security super convenient via Postgres and OAuth and that can handle subscription. Kudos!
    • nmfisher 6y ago
      Interesting, thanks. I've bookmarked your platform, I'll circle back if/when migration away from Firebase pops back on the agenda.
• tekknolagi 6y ago
  Is this a joke about supa hot fire? Since I'm here for it.
  • kiwicopple 6y ago
    Funny story, Supabase was originally a placeholder name - it was a joke so that Ant (co-founder) and I could entertain each other with Nikki Minaj "Super Bass" memes while we were brainstorming. But the name grew on us once we made the initial design. Thankfully Nikki Minaj isn't well-known amongst techies. I hope I haven't just ruined our credibility
    • petargyurov 6y ago
      That is hilarious, I love it. But hey, maybe it's a sponsorship deal waiting to happen!
    • BiteCode_dev 6y ago
      I'm pretty sure you gain points on HN
    • tekknolagi 6y ago
      Nikki Minaj is great.
• aswinmohanme 6y ago
  Finally, waiting for something along the lines of these. Firebase is kind of the poster child for vendor lock in, and has been around for a long time. It's time we have some healthy competition.
  • arcturus17 6y ago
    Genuinely curious, what are the hot spots for vendor lock-in? I’m currently building an MVP for a large client and I’m thinking of replacing Firebase for a custom back-end if the project grows. I think with the current size it would be easy but I want to avoid passing the point where it becomes hard to undo.
    • cpursley 6y ago
      Take a look at Hasura - GraphQL out of the box on top of solid relational database (Postgres)
      • aman-pro 6y ago
        In Hasura your still need a 3rd party service such as Firebase or 0Auth for Authentication. Also, it depends on Serverless functions for doing any business logic.
        • ratww 6y ago
          > In Hasura your still need a 3rd party service such as Firebase or 0Auth for Authentication That's false. You can write your own service or use some open source authentication system, like you would in a normal website. Or use JWT tokens. It doesn't have to be a 3rd-party service.
          • hmexx 6y ago
            nhost.io basically does this. it packages Hasura with its own auth backend, as well as an S3 compatible storage backend. They're adding lambda functions soon. Effectively a firebase alternative using open source tech https://www.nhost.io https://www.nhost.io
• seanwilson 6y ago
  How do the querying features compare to Firebase? Firebase is notorious for having an unintuitive lack of server-side query options when you start using it.
  • kiwicopple 6y ago
    We've begun work on our serverside libraries, but we have a way to go. Baby steps - Rust: https://github.com/supabase/postgrest-rs https://github.com/supabase/postgrest-rs Python: https://github.com/supabase/postgrest-py https://github.com/supabase/postgrest-py These libraries underly the core supabase libraries. You can vote for more libraries here: https://github.com/supabase/supabase/issues/5 https://github.com/supabase/supabase/issues/5
    • soedirgo 6y ago
      There's also one for JavaScript: https://github.com/supabase/postgrest-js https://github.com/supabase/postgrest-js
  • awalias 6y ago
    in addition to @kiwicopple's response, you can also: - use the js lib - https://supabase.io/docs/library/get https://supabase.io/docs/library/get - use your RESTful and Realtime endpoints directly - e.g. <my-app>.supabase.co/rest/v1/users?select=first_name,age - or even just connect to the db directly using your favorite SQL tools/ORM
• mosselman 6y ago
  How does this relate to something like https://gun.eco/ https://gun.eco/ ? Wouldn't Gun be able to scratch the same itch as Firebase and on top of that you'd have the advantage (or disadvantage, depending on your point of view and use case) of it being decentralised?
• sandGorgon 6y ago
  if you can add graphql as well, that would be good for you as a business. It gives a migration path for people moving out of firebase and onto things like graphql. you bridge both worlds. quick questions - how are you doing conflict resolution ? CRDT or something.
  • kiwicopple 6y ago
    > if you can add graphql as well We are strongly considering it, for the reasons you mention. In the meantime though, we do already offer "graph like" fetching: https://supabase.io/docs/library/get#query-foreign-tables https://supabase.io/docs/library/get#query-foreign-tables (which you can also use over curl). > how are you doing conflict resolution Our realtime library listens to the replication functionality of Postgres. Basically its an Elixir server that listens to the logical decoding and converts the byte stream into JSON. You can connect to this via websockets, but we are also building server-side connectors (like sending to a webhook, kafka, log etc). Great for CDC use cases For the client side conflict resolution - we haven't built conflict resolution into the client libraries yet. It's tough challenge, and we want to make sure we prioritise some of the urgent tasks (auth)
    • sandGorgon 6y ago
      > In the meantime though, we do already offer "graph like" fetching: https://supabase.io/docs/library/get#query-foreign-tables https://supabase.io/docs/library/get#query-foreign-tables (which you can also use over curl). i appreciate the sentiment, but most people will prefer to go from "npm install firebase" to "npm install apollo". anything that doesnt fall into one of those will be a hard sell
      • kiwicopple 6y ago
        npm install supabase ? :) More client libraries coming soon https://www.npmjs.com/package/@supabase/supabase-js https://www.npmjs.com/package/@supabase/supabase-js
        • 6y ago
• awalias 6y ago
  here's something small I[supabase co-founder] built with supabase as an example: Realtime Collaborative Task Lists https://todo-zeta.now.sh/ https://todo-zeta.now.sh/
  • awalias 6y ago
    here's a list just for fun/chaos: https://todo-zeta.now.sh/?uuid=7e5217bf-7c76-4525-8783-21747dc0912b https://todo-zeta.now.sh/?uuid=7e5217bf-7c76-4525-8783-21747...
• doczoidberg 6y ago
  nice project but this is only the database part (firestore/firebase rtdb) of firebase. I also haven't read something about authentication and validation. You can't compare a database without auth with firebase.
• osmanyilmaz 6y ago
  Is that free or not? Cause I didn't see it anything.
  • kiwicopple 6y ago
    Right now we're free! But we welcome contributions: https://github.com/sponsors/supabase https://github.com/sponsors/supabase See my comment here: https://news.ycombinator.com/item?id=23319978 https://news.ycombinator.com/item?id=23319978
• InvOfSmallC 6y ago
  Besides the pricing, the other painful thing about Firebase are the storage rules. Given I understand you want to give maximum control to frontend developers without having a backend, the fact that I need to reimplement them if I switch serverless is an absolute pain. What are your plan regarding this aspect. Where are we going to implement the business logic?
  • databrecht 6y ago
    Did you check FaunaDB by any chance? I'm wondering whether their ABAC systems + UDFs would satisfy your needs.
    • InvOfSmallC 6y ago
      I will check it thanks! Although the authentication seems too manual. That part I prefer firebase.
      • databrecht 6y ago
        Thanks, that's valuable feedback :) We indeed are currently providing a lot of building blocks that can solve a wide range of scenarios but did not focus too much yet (until now) on providing easy out-of-the-box combinations of those building blocks that just solve a specific scenario.
        • InvOfSmallC 6y ago
          I decided to give it a shot any way. It seems cool.
• sradman 6y ago
  Interesting. I haven’t seen a log shipping mobile sync solution in quite some time. Sybase SQL Remote did log shipping for SQL Anywhere over email or messaging. This tech predated WiFi, never mind HTTP/JSON. There is little information about the client side data store other than the fluent Query Builder API. Is it IndexedDB? How does it handle primary key generation? Can the client sync a subset of the DB or do you expect to have a dedicated cloud PostgreSQL instance for every client?
  • sradman 6y ago
    Maybe I misunderstood the Firebase comparison. I expected to see a browser-side database with sync similar to Minimongo in the Meteor real-time architecture. From my quick scan of the docs and github repos, it looks like the WAL replication is purely server-side and is used for a type of PubSub system for change notification. The client can subscribe to these notifications and issue subsequent queries against the server. The PostgreSQL specific client-side fluent Query Builder is an alternative to GraphQL queries but not schema. The PubSub change notifications could be applied to a GraphQL for PostgreSQL implementation. Unless I’m missing something, change notification is not the same as pushed sync in Firebase or Meteor.
    • kiwicopple 6y ago
      You are correct here - you nailed the assessment of the serverside CDC. We will be implementing the client/browser-side database, but only after we nail auth (see my comments here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443)
• elitan 6y ago
  Wow, I thought I created this thread in my sleep. This is exactly what we do at Nhost (https://nhost.io https://nhost.io) too. I usually explains Nhost as Google Firebase, but: - SQL (PostgreSQL) - GraphQL (Hasura) - 100% open source After being both delighted and frustrated about Firebase I decided that something must be done. The developer experience on Firebase is awesome but the tech and the lock-in effect is super bad. This was the stack I wanted: - Hosted service - SQL database - GraphQL API - Subscription (real time) - Authentication fully integrated with users in the database - Storage also fully integrated with S3 support. - 100% open source. And that's exactly what Nhost provides. Seeing other services like Superbase, 8base, Firebase (maybe we should change name to Nbase) is super cool. I think we all can help developers at all stages to build better apps faster. Very exciting! Good luck all!
  • abhishektwr 6y ago
    Looks great. Gone give a try.
  • andai 6y ago
    Nbase sounds cool to my ears :) Good luck to you!
  • rishav_sharan 6y ago
    That sounds a lot like hasura.io as well.
    • 411111111111111 6y ago
      It's almost like I it's an hasura app! Oh,wait..........
    • elitan 6y ago
      Yea we use Hasura's GraphQL Engine generating the GraphQL API!
  • asar 6y ago
    I've played around with Hasura and HBP for a side-project and have to say I'm really happy with the developer experience so far. Great work and thanks for making it open source as well!
• niftylettuce 6y ago
  If you use Mongo, you could easily use just `@ladjs/api` package from the Lad framework https://lad.js.org https://lad.js.org. Deploying is simple, and you don't have vendor lock-in. This is a simple example of a `GET /v1/account` API request controller: https://github.com/ladjs/lad.sh/blob/4d0a5b5ff822d07e855bbe164ab03fdbb33d2e89/app/controllers/api/v1/users.js#L30-L34 https://github.com/ladjs/lad.sh/blob/4d0a5b5ff822d07e855bbe1... If you use SQL, you can submit a PR with `knex` and `bookshelf` option and I would gladly accept it.
• mrtksn 6y ago
  I am a strong believer that Firebase model is the way forward. Huge fan of Firebase but it is scary to have no proper alternatives. Yes, sure you can have a similar setup with AWS or bespoke implementation but they are not in the same spirit. Very glad to see people working on alternatives. IMHO though, what makes Firebase special is the glue they use: Account management and libraries come for free so you can start thinkering on the interesting parts. Firebase is not just Firestore, it is a set of tools that work together seamlessly. When this is achieved, your own product feels mature as if you are working on implementing a product on top of FB or other established platform and everything "boring" is handled by someone else. In my mind, Firebase is a very flexible CMS with sane defaults.
  • lukeramsden 6y ago
    Amazon seem to be working on bringing Amplify up to the same standard as Firebase, and it's certainly getting there, so in the near-future there may be quite a few alternatives.
    • cwhiz 6y ago
      I find the overall Amplify offering to be a mess. The hosting and authentication works pretty well but the rest of it just feels like they put duct tape in front of a bunch of existing AWS services. I’ve found Hasura+Cognito+S3 as the closest equivalent to Firebase. It’s not as neatly wrapped up into a single product but it’s pretty close.
      • lukeramsden 6y ago
        Yes I completely agree actually, I've been using Amplify to prototype UI quite well but my plan is to switch to using Postgraphile (or maybe Hasura, I haven't decided yet) + Cognito to replace the backend - primarily so I can use a relational database that isn't Aurora Serverless. I do feel like they've made good progress on the project in recent months, but it really needs another good year of work on it before I'd consider it cohesive enough to stick with.
    • ekseda 6y ago
• idoby 6y ago
  Couldn't find the info on the website, does the JS shown in the samples run in the client's browser? If so, I'd be coupling my client code to the implementation details of my server side DB. Nope, no thanks. Too many scars to fall for that again.
  • kiwicopple 6y ago
    > I'd be coupling my client code to the implementation details of my server side DB [Supabase cofounder] Yes, although you can run this on the serverside too (we do). It's a rapid way to go "mostly ORMless" - you just focus on your database and we can do the repetitive stuff (CRUD)
    • renke1 6y ago
      Is there some kind of whitelisting for queries that come from the client as to avoid the hammering the DB with expensive queries / queries that make no sense?
      • kiwicopple 6y ago
        The auth system we are building is targeting Postgres' Row Level Security which should cover these sort of problems. (more in my comments here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443) You'll also be able to add rate-limiting and various other plugins (IP bans, blacklisting) to your API as well. We still have a lot to build - we didn't actually post this so it's a bit early but I guess you can't choose your timing
• rplnt 6y ago
  While might work great as a HN title, I don't think that's a wise product description. First of all, what is Firebase? Is literally no one else than their users your target? Also, is it OK to use someone else's trademark in your marketing?
  • kiwicopple 6y ago
    Yeah, we don't really want to use competitors names. in saying that - we just updated the tagline yesterday and it seems to resonate https://github.com/supabase/supabase/commit/c905edef57b4b1b09f9af4cf792797b07bad0b46 https://github.com/supabase/supabase/commit/c905edef57b4b1b0... We will definitely come up with something better - suggestions welcome (taglines are hard)
• pabs3 6y ago
  Their pricing model is interesting: https://supabase.io/docs/pricing/ https://supabase.io/docs/pricing/ I wonder what the "investors" mailing list is about.
  • kiwicopple 6y ago
    Just a few growth stats and updates on key activities. Nothing too important - just a nice gesture in return for a nice gesture. Happy to add items to the email if you want them
    • vmsp 6y ago
      Out of curiosity, what software are you using to run and manage your mailing list?
      • kiwicopple 6y ago
        We just switched to Intercom (from manual). If there are better suggestions then I'd also like to hear them - email seems like a space that has a lot of players and none very good.
• srikz 6y ago
  This looks great (both Supabase and Nhost)! Years ago I wanted a self-hosted version of the real-time subscription of Firebase and had come across DeepStream[1]. It now seems to be in maintenance mode due to lack of contributors and maintainers. [1]: https://deepstream.io/ https://deepstream.io/
• 2mol 6y ago
  This looks great, however at first peek it doesn't mention anything about auth. Do you have any plans for that? For me this is the topic I most want to just delegate to the service. Dashboard, realtime stuff, etc are great too. RESTful APIs I can of course get with PostgREST [0], which is insanely excellent, so the value I'm looking for is to have everything managed, from hosting/storage, to security, to all the other annoying nitty-gritty that I'm likely to get wrong. [0]: https://postgrest.org https://postgrest.org
  • godzillabrennus 6y ago
    Any thoughts on Auth0? https://auth0.com/ https://auth0.com/
    • 2mol 6y ago
      Love it, used it, mildly dislike the pricing. But generally I'm of the opinion that auth tightly integrated into the platform has a lot of advantages. My dream is to avoid (almost) all glue between my components, I think Firebase became successful in big part because of that.
    • tluyben2 6y ago
      I saw this passing by a lot of times, but either I misunderstand the pricing or it is indeed 'enterprise' pricing. Because even small sites I launched have easily 10s of 1000s of users and some have had millions => I cannot see this pricing work at all on any of those without me closing the doors (having margins that are just too small or just making losses) vs making a really good living.
      • nick-garfield 6y ago
        I agree with this. I think Auth0 at one point was building tools for indie devs, but are now focused mostly on enterprises. What have you used instead of Auth0?
        • tluyben2 6y ago
• leorio 6y ago
  isn't this more like "An open source Firestore alternative" right now. Do you plan to bring other features as well? I'm a big fan of firebase and use it whenever I can. The reason it's appealing it because it's the suite of tools and how well they work together for bootstrapping (auth, firestore, storage, analytics etc). No single feature by itself is useful to me. I would definitely switch if this atleast had (auth + db + file storage + functions).
  • kiwicopple 6y ago
    See my comments here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)
• tomzus 6y ago
  I've recently been playing with firebase and looking for a non-google alternative. Looking forward to giving this a go.
• cultofmetatron 6y ago
  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!
  • kiwicopple 6y ago
    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 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
    • pdimitar 6y ago
      Oh wow, Supabase is in Elixir! You guys hiring?
      • kiwicopple 6y ago
        >You guys hiring? Soon! We are joining the next YC cohort and we will hire after that Only some parts are elixir. The full stack is here: https://supabase.io/humans.txt https://supabase.io/humans.txt
        • pdimitar 6y ago
          Apologies for shameless plug and off-topic but I am very enthusiastic about companies using Elixir. I am a senior dev (18.5y experience in total), currently focusing on Elixir and Rust (3.5y with Elixir so far, learning Rust fast and currently making an Elixir<=>Rust bridge for the sqlite database). I'll be checking out your page every now and then. Do post in the "Who's hiring?" thread when you are ready to hire! I'll be looking for you there as well.
          • 6y ago
• sshb 6y ago
  Recently released similar thing for gRPC + Go + PostgreSQL stack: https://github.com/sashabaranov/pike/ https://github.com/sashabaranov/pike/ Features include: • Generates CRUD operations for given entities • Generates SQL migration files • Gives developer full control after project is generated(nothing added on top of raw SQL/Go) • Minimal dependencies(basically lib/pq and grpc) • TLS out of the box
  • pm90 6y ago
    What the fuck. This is insanely cool!
  • eclat 6y ago
    Almost like Rails.
• tmvnty 6y ago
  Good luck! It’s great to see another BaaS alternative on the market especially the recent trend seems to be a lot of Jamstack (backend-less?) Hopefully open source means better documentation too. Only places I know for Firebase are their docs and own YouTube channel, which can feel limited once you pass the “get-started” depth
• BiteCode_dev 6y ago
  A bit of a plug, but if you wish for something that has the Postgres reliability, the taste of nosql but with strong typing and a json output a la graphql, give a try to edge db: https://edgedb.com https://edgedb.com The team behind it is awesome (one is a python core dev), and it's a FOSS, but they have been using it internally for some time.
  • rhlsthrm 6y ago
    I feel like this is close to what I'm looking for but not quite there in terms of minimal boilerplate backend. Basically what I want to do is write a GraphQL schema and have that be the ultimate source of truth. The schema then should generate the full DB (honestly I don't even care if it's SQL, NoSQL, etc. the idea is that part is abstracted away). Then the schema can generate fully typesafe queries for the front end and serverless functions, similar to what graphql codegen does. I'm almost there with Hasura, but Hasura still requires definition on the DB side and generates the GraphQL rather than the other way around.
    • BiteCode_dev 6y ago
      That's pretty much why people created ORM for, though. E.G: Django ORM will let you define the schema, and be the single source of truth for you DB and your REST API.
      • rhlsthrm 6y ago
        Right but the idea is I'm trying to approach it from the front end and define the schema using the GraphQL queries which the front end will use.
    • databrecht 6y ago
      I'm wondering how FaunaDB's GraphqL would suit you? It's basically: "drop in schema, get API". You can't do everything that you'll ever need yet but you can go quite far and the implementation of each query is efficient since every query is one query and thus one transaction, is backed by indexes that are automatically generated and finally we are quite suitable for GraphQL-like queries. (because those are a bit like tree-walking queries for which the 'Index-free Adjacency' concept in graph databases is very suitable and FaunaDB's References are quite similar. Although we're not a Graph database we don't have problems with huge graph-like joins because of that. besides that, the compatibility of our native FQL language made it ridiculously easy to generate an FQL query GraphQL queries) If there is something missing in our GraphQL feature set, feedback is very welcome :).
• kiwicopple 6y ago
  For those signing up - we have hit our cloud limit. we are getting in touch with them now to increase the limit
  • kiwicopple 6y ago
    OK should be sorted. If you have any problems, email us on alpha@supabase.io
• DigitalSea 6y ago
  I am ecstatic that someone is finally taking on Firebase. As a Firebase user, I find it invaluable. Their free plan and limits are very generous. The fact they offer not only a database, but authentication, hosting and perhaps one of their biggest features besides authentication: Firebase Functions. I have API's in deployment that are solely running using Firebase Functions and using Firestore as the database. The CLI is also another huge Firebase feature. Following this intently, because Firebase has no true competitor, let alone an open source one. Nice work so far.
  • punnerud 6y ago
    Firebase smell the Google Maps model with its “free” for a long time plan, before turning up the price when most of the market is used to the product and are to deeply locked to the API.
    • mav3rick 6y ago
      Why shouldn't they charge for a great product ? When Google charges it's a problem when they don't charge it's a problem.
      • codegladiator 6y ago
        > Why shouldn't they charge for a great product ? They should charge from the beginning. > When Google charges it's a problem Where is that ? It's a problem when it's abrupt.
        • tifadg1 6y ago
          It's easy taking the high road when you're not the one actually doing something. As a business, if you're getting something for free, assume someone else is subsidising you, as there's no such thing as free lunch.
          • codegladiator 6y ago
• aabbcc1241 6y ago
  It looks like a database client driver with realtime (insert only? notice but why do you call it firebase alternative ? It sounds like horizon (RethinkDB middleware) but for postgres.
  • kiwicopple 6y ago
    Our docs are a bit outdated and overly focused on the realtime server. We also have auto-generating APIs (with docs that update as you update your database), a query dashboard, and we are building a table interface like Airtable. The next big task is auth, which we are working on right now.
    • ekseda 6y ago
      Can supabase be used with the offline-first approach like horizon, RxDB etc. or does it require an ongoing connection to the server?
• kabes 6y ago
  How does it compare to Meteor?
• brainless 6y ago
  Wow this just made my day! I am building an open source data management software (aka admin). I am happy to see more software focused at data. Yay!
• RNCTX 6y ago
  I see from the links that this is probably borrowing a bit from Postgrest? I've just discovered Postgrest in the past few days and along with Postgraphile it seems like all of these projects aimed at "getting back to the database" are a good idea, I like it. It always bothered me that the first order of business with any software development framework was to provide a root/admin database connection. It's like, this thing just explicitly said we're supposed to ignore all of the security work that went into making that database software for the past however many decades, and turn it into a dumb storage medium instead. The lasting impact of Firebase is it proved to the world that being opinionated about the database in order to provide good tools is a viable business model, rather than force ORMs onto people to try and appease every different database flavor under the sun. Good luck to you guys, I like the trend.
  • kiwicopple 6y ago
    You're right about PostgREST. See my comments here: https://news.ycombinator.com/item?id=23321132 https://news.ycombinator.com/item?id=23321132 > we're supposed to ignore all of the security work that went into making that database software for the past however many decades, and turn it into a dumb storage medium instead I couldn't agree more
    • block_dagger 6y ago
      With containerization and network orch layer, the db often isn’t the best place to enforce access perms.
      • RNCTX 6y ago
        I think that's debatable. A UI without a persistent root/admin connection lingering in the wild cannot leak such a root/admin connection, can it? How many retail corporations have had breaches resulting in huge credit card dumps that would not have happened if they had not been using frameworks with persistent root/admin database connections outside of their internal office network?
  • pm90 6y ago
• sheeshkebab 6y ago
  This has none of the features of firebase that I personally ever used firebase for (analytics and crashlitics for native apps). Moving along...
• deleted 6y ago
  [deleted]
• walkingolof 6y ago
  There is a database management company called Superbase, the names are confusingly similar. I read a bit perplexed about Superbase being a YC company. https://www.superbase.com https://www.superbase.com
  • twic 6y ago
    There's also a Nicki Minaj song called Super Bass, although i admit that is less likely to get confused with either of them: https://www.youtube.com/watch?v=4JipHEz53sU https://www.youtube.com/watch?v=4JipHEz53sU
    • kiwicopple 6y ago
      I posted this below, but since you mention Nikki - Funny story, Supabase was originally a placeholder name - it was a joke so that Ant (co-founder) and I could entertain each other with Nikki Minaj "Super Bass" memes while we were brainstorming. But the name grew on us once we made the initial design. Thankfully Nikki Minaj isn't well-known amongst techies. I hope I haven't just ruined our credibility
  • Zenst 6y ago
    Superbase IIRC was a GEM based database system that was the era of windows 1.0 comming to birth. Was nice, I mostly did work in Dataease then, and talking late 80's era. Dig into the history shows more in depth from my GEM flavour experience. https://en.wikipedia.org/wiki/Superbase_(database) https://en.wikipedia.org/wiki/Superbase_(database)
    • walkingolof 6y ago
      https://www.superbase.com/products/superbase-ng-professional/ https://www.superbase.com/products/superbase-ng-professional...
      • Zenst 6y ago
        Yes, still going and interestingly enough, so is dataease. Though the old secret dos debug system in dataease is probably long gone (hold down ctrl and type debug and you'd get hidden developer options). Software today tends not to have as many hidden gems like that as yesteryear, bugs perhaps but hidden features, less so.
• razin 6y ago
  Congrats on launching! Any plans for a GitLab integration anytime soon?
  • kiwicopple 6y ago
    Hey - can you elaborate a bit on the integration and what you'd like it to do?
• cwhiz 6y ago
  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.
  • bradyo 6y ago
    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.
• habosa 6y ago
  Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from. I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this: * Pick a database * Spin up a server * Connect the DB to the server * Create a REST API for the server so the client can talk to the DB * Somehow make that secure enough * Write a bunch of CRUD code on the client What a waste of time! Glad to see people like Supabase taking on this problem as well.
  • pm90 6y ago
    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 hosting the firebase app... maybe not a huge deal if the app itself is in google cloud?) Disclaimer: I’ve only used firebase tangentially, haven’t built an app from scratch with it.
    • time0ut 6y ago
      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 it though. Eventually, I'm sure we would've migrated if we were successful enough.
      • ta17711771 6y ago
        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?
• eatonphil 6y ago
  This is really interesting. I spent a while a few weeks ago looking around for a serious, open-source BaaS effort backed by... anyone. I've been influenced by code generators like xo/xo [0] and sqlboiler [1] recently (so you can have type-safe APIs and you still manage/own the resulting code). My bet is that you can generate an entire API _and_ basic CRUD browser UI from a db schema. I've been working on a code generator that does this. It can currently generate an entire Go REST API with CRUD operations from a PostgreSQL database. Next is to generate a React/TypeScript UI and add auth support. The advantage a project like mine has over this is that it defines a standard API specification and you can build an APIs and UIs against that standard. Right now the only API is Go, but I'd like to build a Java one too and would be open to community submissions. Same thing goes for database dialect. Right now it's PostgreSQL only, but this kind of code generation can be done on any database once a driver is added. Won't link to it here because the whole thing is WIP but it's on Github. I see this kind of project as a long-term base for rapidly building any sort of db-based applications in the future. [0] https://github.com/xo/xo https://github.com/xo/xo [1] https://github.com/volatiletech/sqlboiler https://github.com/volatiletech/sqlboiler
  • jimktrains2 6y ago
    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.
    • eatonphil 6y ago
      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.
      • jimktrains2 6y ago
        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 https://github.com/jimktrains/bam I wish I had included an example in there though :(
• user0x1d 6y ago
  Is this a good option to host sensitive data? I'll have to opt on a backend to store medical data in my app. I had discarded Firebase due to some opinions I found on the web stating it would not be the best option.
  • kiwicopple 6y ago
    It's not a good option for medical data. Also, we are far too early and need to go through a security audit. At some stage we will make it easy to self-host, and at that point it might be worth checking out again. If you need any recommended alternatives, feel free to message me (email in my profile)
• phoenixdblack 6y ago
  The thing that's really invaluable for me is the firebase javascrpt implementation. Saving the state in a web app and new Objects being addable/editable offline with firebase automatically synchronising when network is available with me doing absolutely NOTHING is absolutely insane. Having just the API isn't really going to cut it.
• rickdg 6y ago
  The advantage with firebase web sockets is that when they inevitably get blocked by firewalls you can always say "Would you mind whitelisting google? Thanks."
• gitgud 6y ago
  To be a Firebase alternative, you would expect a full-stack solution; DB, Auth, Cloud Functions, Analytics...etc. That's the main selling point of Firebase. This just seems to be an Open-Source implementation of Firebase's "Realtime Database", which is kind of superseded by the new "Firestore", which is much more popular. However it's a smart business move, as many products are locked into the "Realtime Database", so this could provide an easy exit door to Open-Source software.
  • kiwicopple 6y ago
    That's true. See my comments here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)
    • rdslw 6y ago
      Feature parity with Amazon Firebase? Let me assess this, with the tip of my napkin: 1. linkedin 'firebase' + amazon (current employer) -> 695 people. 2. 10% of above = 70 FTE 3. They started (googled): They founded Firebase as a separate company in September 2011 and it launched to the public in April 2012. 1+2+3 = It's impossible you will have feature parity in next 10 years. BUT it's possible you can achieve pareto parity, leaving off the table most complicated 20%. Good luck :)
    • julianeon 6y ago
      I'm a consultant and I love the idea of having Postgres instead of NoSQL on the backend, coming from Amplify. For me the MVP, before I could use it for my commercial projects, would be: DB+auth. At that point, I could switch - and probably would. Also, kudos to you for being the diametric opposite of a 'useless' startup. Not only would I use this once I could, I'd talk it up to everyone in my space.
      • kiwicopple 6y ago
        Thanks for your feedback. We hope to have a proper Auth system in place before our official launch in September. We like building things that people will use. The number of features that Firebase offer is vast so it might take us some time, but we will get there and we’ll make sure we do it in a way that benefits the opensource community
• WolfOliver 6y ago
  Nice! ... What are the features you are adding on top of postgREST?
  • kiwicopple 6y ago
    We're trying to support postgREST - at the moment that means client libraries: https://github.com/supabase/postgrest-js https://github.com/supabase/postgrest-js https://github.com/supabase/postgrest-rs https://github.com/supabase/postgrest-rs https://github.com/supabase/postgrest-py https://github.com/supabase/postgrest-py (coming soon) But for additional features, it's a lot of UX - auto-docs, API gateways, auto-UI (like Airtable). For distinct features, check out our realtime server: https://github.com/supabase/realtime https://github.com/supabase/realtime
• difosfor 6y ago
  How scalable is this? E.g: What is the maximum active (e.g: writing) user concurrency? What happens when that is exceeded?
  • kiwicopple 6y ago
    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 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)
    • treis 6y ago
      How do you handle the creation of the database for a new user? Any issues with maxing out connections to the DB?
      • kiwicopple 6y ago
        Right now when a user creates a "project" we spin up a full server for them. > Any issues with maxing out connections to the DB? There are by default 100 max_connections. But if you use our libraries there is no problem - all requests get funneled through 1 server (which we will autoscale in the future). You'd be lucky to reach 10 connections. If you connect to the database yourself then it's really up to you how many connections you consume
• risyachka 6y ago
  It hardly compares to Firebase - their main selling points is super quick to start, easy to use, very cheap, lots of integrations. Unfortunately, all alternatives to Firebase, even if not counting the large lack of features, are way more expensive, and lack many integrations, especially mobile.
  • kiwicopple 6y ago
    This was posted a bit early (it wasn't posted by us), but see my comments here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)
    • risyachka 6y ago
      My point is that sure, there is a valid use case for your service, for people who are looking for an open-source alternative they can host. But if we are talking Firebase - most users want exactly the opposite - they don't want to host their own servers. And when comparing your cloud to Firebase - you won't be able to compete on price. And probably on features and integrations. They've been building that for many years now. All I am saying is it not comparable to Firebase. But lots of people want their own hosted backend they can extend, or will be glad to pay extra for your cloud and for your unique features.
• imshashank 6y ago
  Awesome product but definitely not a firebase alternative.
• nojvek 6y ago
  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. My last GCP bill was 3 cents. And yes, GCP was dumb enough to actually charge my credit card for that. Not sure why they don’t have a $1 minimum. But I like what I’m seeing as supabase’s pitch.
  • ssijak 6y ago
    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.
• deleted 6y ago
  [deleted]
• malisper 6y ago
  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.
  • kiwicopple 6y ago
    This is a great comment. Especially this: > I'm hoping that Supabase is able to bring about the next-phase of databases .. by making it easy to do so We chatted to a lot of developers at the start of this year. Most of them thought that Postgres was amazing and wanted to use it, but they still chose other options (like Firebase) because they were easier. At that point we made "database UX" our main focus.
• aty268 6y ago
  The problem with these BE services is, unless you refuse to sell out, I can't reliably build a platform using you. Google will eventually offer a lot of money to buy you and shut you down. Prove to me that isn't going to happen.
• x_stealth 6y ago
  From what can be understood: Writing a backend with Supabase will turn into managing all these servers. Backend Server = Supabase (for realtime) + PostgREST (for REST APIs) + Serverless Functions (for business logic) + Postgres SQL database. For somebody using Firebase today, How will this solution with Supabase be simple to manage and scale ? Help me understand if I am wrong.
  • kiwicopple 6y ago
    We plan to make the self-hosting a lot easier/simpler, it's on the roadmap. This post caught us a bit by surprise - we planned to launch later this year with better documentation and opensource suppport. Basically: we will bundle everything into a single deploy (docker, AWS, DO, etc).
    • x_stealth 6y ago
      Got it. But that is a lot to make it work seamlessly. How do you plan to make any business out of this ?
• stephen_cagle 6y ago
  I have been working on a Clojurescript wrapper for the Firebase (Firestore) database. Here is an interactive example of the principle features of that work. Comments and criticism (and PR's) welcome! https://firemore.org/ https://firemore.org/
• joeyspn 6y ago
  Congrats, the project looks solid. It's obviously targeted to JS devs who are familiar with firebase or want an easy/similar abstraction for realtime apps. It's great to have several great frameworks tackling the same problem with different flavours (Hasura, Phoenix, Supabase, etc), all with postgres as first class citizen. I feel like the key is in the choice for the realtime backend (Phoenix/Elixir). I've built real-time firebase apps (JS) in the past and today my choice would probably be Phoenix. It also saves many LoC (80-90%?), and it's a joy to work with. Reduces the JS fatigue and opens up a new paradigm that makes programming fun again.
  • kiwicopple 6y ago
    Realtime is definitely our strongest feature so right now. We started Supabase to solve a problem at our previous startup, where we built a chat application using Firebase. Within a few months we discovered our customers were receiving their chats out-of-order and it took another few more days to figure out it was due to some Firebase quirks. We migrated to Postgres and started with Triggers/NOTIFY. But that also has some limitations (8000 byte payload limit), so we implemented the Elixir server: https://github.com/supabase/realtime https://github.com/supabase/realtime
• shireboy 6y ago
  Reading the docs, I'm confused how this is secured. For example, if I have a table UserOrders (UserId, OrderId, Foo), how do I ensure the backend is only returning records for the current user?
  • awalias 6y ago
    client side auth is not in production yet - but is on the way, more details here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443
• ejo4041 6y ago
  The biggest feature I will be looking for in this is a true push to android mobile devices. It looks like you can use the subscribe function for this, but I'd need an android example to get up and running quickly. Right now it seems like firebase is the only game in town for that functionality unless you want to roll your own with websockets or some sort of MQ. Google also strongly encourages use of firebase for that in the TOS in the play store I believe. I'm very excited to see how this progresses. I also went right to the pricing page to see if you would charge for on-prem hosting, but looks like it is still TBD. I would like the ability to host everything on-prem. Security and encryption would be next on my list of wants after that.
  • ejo4041 6y ago
    It's clear I jumped to a conclusion here and thought this would give us firebase cloud messaging, my bad.
  • awalias 6y ago
    Thanks for the feedback! We've had a few people asking for on-prem + support, it's looking like it's going to be bumped up the feature queue. Also thanks for sharing the android use case - we definitely want people to use this directly from the client. We're working hard to get the auth model right for this.
  • gdeglin 6y ago
    You're correct that the Firebase Cloud Messaging is essentially required for Android push. As of Android 8, Google prevents background connections from being held open by apps, and requires FCM in order to wake up apps (eg: to receive a notification). This is documented here: https://developer.android.com/training/monitoring-device-state/doze-standby https://developer.android.com/training/monitoring-device-sta... If the app is already running (eg: in the foreground), then you can (and probably should) use your own non-FCM connection for sending messages or data.
• bdcravens 6y ago
  I've only just begun exploring it, but it seems like AWS Amplify is another strong alternative (just uses underlying AWS services, but with a nice CLI that ties it all together). Not open source of course, but it's striking to me that people are only referencing this project as being an alternative to Firebase - is Amplify not seen as that strong of a product?
• bdcravens 6y ago
  This looks to just be the "real time" DB? How is this different from using GraphQL subscriptions via Hasura/Postgraphile, or RethinkDB? Also, it seems like it's missing everything else that Firebase provides. Authentication, authorization, storage, hosting, etc. To me, Firebase's value prop is more than just a database.
  • kiwicopple 6y ago
    I answered this over here: https://news.ycombinator.com/item?id=23320443 https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)
    • bdcravens 6y ago
      Sounds good. Would it make sense to put some info about your roadmap on your main marketing pages? There's pros and cons of that, but for positioning sake, I'd recommend it, and given that it's still an alpha, I think that mitigates the expectations of feature completeness.
      • kiwicopple 6y ago
        Good idea. This post caught us off-guard but I’ll update the site as soon things settle down
  • nick-garfield 6y ago
    AFAIK Firebase doesn't actually offer any real authorization do they? It was some time ago I last built a project with them, but I remember having to create a custom "roles" attribute in the Realtime DB for users.
• lukeinator42 6y ago
  This looks great! One of the main reasons I stick with firebase these days however is how easy it is to integrate authentication, especially using google accounts with OAuth. That would be a cool feature for a future version.
• jaime-ez 6y ago
  Guys, check out https://github.com/deepstreamIO https://github.com/deepstreamIO - open source MIT - I've been a long time user and it works great. It's a typescript code base, very readable and straight forward, uses protocol buffers for messaging and uWebSockets.js for the websocket server (ultra fast). You get realtime records, pub/sub, events, rpc, fine grained permissions, http endpoints and basically you can hook up to any backend (currently there are connectors for postgres, rethinkdb, elastic and others). We need more people to use it, cause the original developer is going on maintenance mode and we're trying to strengthen the community. It rocks!
• oreid 6y ago
  If you’re looking for something with a few more features then I recently discovered https://appwrite.io https://appwrite.io It includes database (Firestore), storage (Cloud Storage), users (Firebase Auth) and more, plus you can host it yourself. I haven’t used it myself yet but keeping a close eye on it.
• robot 6y ago
  this is super interesting in that I mainly use PostgreSQL and was wondering how to integrate a real-time database and sync the two for real-time stuff like comments. My initial concern is is this stuff stable for production use?
• MobileVet 6y ago
  What about Parse? YC 2011, acquired by Facebook 2013 and shifted to fully open source Feb 2016. https://parseplatform.org https://parseplatform.org
• gbourne1 6y ago
  A plug here, but we built an app around tracking Firebase usage and costs because there it a worry about getting a big monthly bill. Check it out at https://www.firerun.io https://www.firerun.io
• coderesearch 6y ago
  To keep data in sync is only one aspect of data handling. Take a look at https://orbitjs.com/ https://orbitjs.com/ - not affiliated, just found that interesting.
• fragosti 6y ago
  I'm a big fan of Firebase and have seen a lot of projects get up and running very quickly and scale as well. However, I think there are an increasing amount of reasons why you want to have your data stored in a SQL database that you can access. The open source tooling being built around SQL (usually Postgres) as a standard is becoming better and better and it's going to be hard for Firebase to compete with all those offerings. If I run a Postgres database I can instantly have tools like Hasura [0], Metabase [1] along with others that add a ton of value out of the box. However, maybe those tools will also integrate with Firebase. Anyway, my point is that this is best of both worlds, so great to see! [0] https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine [1] https://www.metabase.com/ https://www.metabase.com/
• zerubeus 6y ago
  This title is click bait for me as Firebase is not only a database and function...
• codecamper 6y ago
  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.