Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.
That's not cool and we penalize and eventually ban the accounts, sites, and projects that do it.
Please refrain from asking people to upvote your posts. I really love appwrite, and I’m sure it can make it to the frontage without asking users for upvotes :)
From the title "Show HN: Open-source Firebase Alternative? It's here (github.com/appwrite)" was expecting the entirety of Appwrite to be a new project shown here for the first time. Could the title be changed to reflect what's new? Perhaps the title of the GitHub Issue being linked: "Announcing Appwrite 0.14 with 11 Cloud Function Runtimes!"
All these platforms expose a kind of data repository with multiple users that is designed to be used as an app backend. The permissions in a "headless CMS" will by default be designed under the assumption that people will be writing articles that will all be shared between/accessible to all users whereas Firebase/Supabase/Appwrite will assume that each user has their own private data, but a lot of the details are in how you configure them for your use case and perhaps they aren't really that different when you think about it.
Many of these competitors are missing: offline persistence, optimistic updates, local cache, push updates, command pipelining and casual consistency. Which is cool but to me this is missing the main point of Firebase which was about making modern, reactive apps simpler to develop.
Appwrite and supabase make CRUD apps easier to write. It's different. I guess Firebase expanded to being used for everything but it was all about realtime apps originally (ex-Firebase developer here)
I like these apps but I find the positioning weird given their feature set
Have you checked out thin.dev? We provide optimistc updates, local cache and realtime is the default for everything (offline persistence has not been the focus as we're not targeting mobile for now)
Appwrite v0.14 was just released with 4 new cloud function runtimes, 3 new storage adaptors, 3 new OAuth providers, a precision event model, and many quality of life improvements. We’d love to get feedback on improvements and features as we gear towards v1.0 of Appwrite.
What is an Appwrite? Appwrite is an open source backend-as-a-service that helps you build secure apps, faster. Appwrite handles authentication, realtime databases, file storage, cloud functions, and more with SDKs for web, mobile, and server side languages.
Here’s everything new in Appwrite v0.14:
Updated Event Model: Trigger webhooks, cloud functions, & realtime events with a more precise event model
New Cloud Function Runtimes: C++, .Net, Kotlin, and Java
New Storage Adaptors: Linode, Backblaze, and Wasabi
New OAuth Providers: Zoom, Okta, Auth0
And a lot more improvements: Async/Await support in Swift runtime, wildcard support for hostnames, toggle user verification from the Appwrite console, and many bugs fixed.
Community feedback and contributions have been a major source of guidance for our project and we’re always looking to improve as we move forward. Tell us your thoughts by opening issues on GitHub, engaging with us here on Reddit, or joining our Discord community.
Looks nice! Just a quick note—when I hear "open source Firebase alternative" I immediately think Supabase. It might be good to call out the factors that differentiate Appwrite from other projects.
I answered above, so look there for a detail response.
If you like your experience to be decided for you, use Supabase, especially if you love interacting with a Postgres instance and Deno for your cloud functions.
We try to keep our stack agnostic, hence the 11 function executor, and ever growing list of SDKs. We also allow you to choose your storage adaptor for stuff like Linode, S3, DigitalOcean spaces, Wasabi, and more. We'll eventually give you the option to choose between many DB options, too.
We don't wanna replace your stack, we wanna play nicely with it. You can straight up disable all our services but one, and we're happy to let you enjoy your experience all the same :)
Both are great products, here's my biased (obviously) way of choosing between them:
- Appwrite is really focused on a simplistic experience. If you check out our SDK documentation, we try to keep everything dead simple.
- Supabase allows more verbose control over their PostgreSQL instance, i.e. you're actually writing SQL and interacting through a SQL console. This might be your cup of tea. They also use Deno for their cloud function equivalent, which is cool if you love Deno.
I would say Supabase is more opinionated, we try to give more options. Neither is necessarily better, there are pros and cons that you can decide on.
Other than that, Appwrite does some things that I find special.
Appwrite is simple to self-host. Like really simple. Like a single line of Docker command simple:
This gives you the full Appwrite experience for local/dev environments and you only need a few more environment variables to be production-ready.
We try to make Appwrite agnostic to your tech stack. You can use or disable any of the services when self-hosting, saving resources on your precious servers. You can integrate with frontend, backend, or both, or just use a single service, like our function runtimes.
We support a ton of SDKs, and we're always adding more. Our vibrant community makes this possible.
We have a lot of languages supported for Appwrite Functions, not just Deno ;) We have lots of storage adaptors you can choose from, or local storage if you want to keep all your data. We will support MANY databases (you can contribute your own, too).
I hope that helps, it really is down to personal preference, developing on the platforms feels very different. Try both!
Really impressed with how easy appwrite was to start up from Docker! (Try doing that from Directus -- they give no help at all for any self hosting.) Can't wait for the GraphQL endpoint to get going! Appwrite isn't as evolved as Directus but I love the open source approach it has, instead of the push towards their cloud offering.
> Appwrite is simple to self-host. Like really simple. Like a single line of Docker command simple
Is is possible to use Appwrite without Docker? Docker is super-slow on Macs so I tend to run everything natively. With traditional tools (e.g. Postgres, Redis, etc) this is super-easy. I can just `brew install`.
Side note: I don't know if these were your issues, but Docker for Mac in the last couple of months has drastically improved its memory usage (finally!) as well as its filesystem performance. Obviously nothing will beat running natively, but Docker on the Mac is no longer frustrating.
Yes, we are working on a more native alternative with the likes of a Makefile or some Ansible scripts. However it has not been a major priority since we didn't have many community members ask for it yet.
However, we'd be more than delighted for contributions from the community
There are a lot of SEO-spam sites that look a lot like this one that are designed to top the results for searches like "technology 1 vs technology 2". They are all completely useless.
IMO If you really want to provide value, you have to dig into the actual details of these technologies, not just offer a top-level blurb and category label.
Just look at any Show HN post comments, engineers crave the details when it comes to comparing and choosing technologies.
Example: One thing I have always desired is somewhere to see all the major databases/event stream/persistence technologies and see what kinds of different consistency guarantees, replication, backup, recovery, etc. they each offer.
This goes a bit deep (most datastores have a bunch of different ways to configure and tune them for different consistency levels [1]) and is obviously more effort than the low-effort "this vs that" sites, but I don't see much value in the existing "this vs that" offerings.
I do. I develop lot of MVPs for clients and personal projects.
1. It is the fastest way to build. Auth, notifications, DB, cloud functions, analytics. You have everything you need.
2. Generous pricing. You will be able to get most of the things done with minimal costs on infra.
3. Dev Friendly: Anybody who comes with firebase alternatives, I always look at the toolset. If you look at Firebase, the CLI is amazing.
On top of this, I simply love their emulators. You can test everything before hitting production.
All in all, I simply love firebase. If they are able to get the cloud functions with go runtime it will be so nice. (Right now the option is to use Google cloud functions).
It is easy enough to connect from firebase functions to a cloudsql instance and the pricing is pretty good for the lowest tier (which is also easily scaled up). That said, might as well just use gcp cloud functions instead.
But what I really mean is that it would be cool to have Firebase db access SDKs and realtime capabilities, with a relational, non-proprietary database. If you plug in your CloudSQL or another managed database you don't get that, and have to write everything on your own.
Supabase seems to be going in this direction, and while I haven't tried them yet, I certainly see how it's an attractive proposition.
I do. If I were to attend a hackathon (which I haven't since 2020), I would use Firebase. It's simple and they sponsor every hackathon I've been to, so I get free credits.
That said, if I attend today and ignore sponsorships, I'd actually get DigitalOcean market place deployment of Appwrite. I honestly think it's quicker to get started with, and I like owning my data ;)
I had a couple of side projects running on Firebase until I discovered the open source alternatives. I can self-host on a $10 droplet which makes the costs very predictable
No, we're trying to provide similar functionality, but we're not just cloning it down to the API. We have some of our own philosophy, for better or for worse, about what a good BaaS should look like.
I think most people here would tend to disagree for two reasons:
1) Firebase's feature set is vast, which ultimately means that you're going to pull in a much bigger SDK than what an "open source Firebase" can reasonably provide. Half or more of the SDK code you're pulling into your project will do nothing. It's better that competitors are like firebase in spirit but ship their own SDKs to optimize for their use cases.
2) Firebase is still owned by google, which automatically paints a target on its back. We don't know what the long term internal roadmap of Firebase is, regardless of what the GCP bosses might say or how much money it seems to make on paper. Google has sown itself quite willing to kill any project at any time without a lot of clear reasoning as to why, and no one wants to build against an SDK/standard that could vanish tomorrow.
That would be a "drop-in replacement", which is indeed a type of alternative. But to be an alternative, it's enough to just provide similar functionality.
If you're looking for something like Appwrite or Supabase but with a more end-to-end typesafety approach + optimistic updates, check out Thin Backend https://thin.dev/ (https://github.com/digitallyinduced/thin-backend) It takes a bit more of a higher level approach to database operations than appwrite, supabase or firebase, which allows us to do things like optimistic updates that are hard to do in other tools.
This is your app? I feel like plugging your own competitor app in a ShowHN goes against the spirit of ShowHN. Rather than just a link to your GitHub, a deeper discussion about the difference and pros and cons of one versus the other would be more appropriate here. For example, what about Appwrite makes it hard to do optimistic updates versus your solution? "High level approach" doesn't tell me much.
Yeah, initially we didn't have this. During beta our main servers were in europe, and while I was in SF I saw what a difference this made to the overall UX of our kind of realtime apps. Everything took like 200ms more :) With the optimistic updates it's now fast everywhere on the world.
Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.
That's not cool and we penalize and eventually ban the accounts, sites, and projects that do it.
https://news.ycombinator.com/newsguidelines.html