#Read and Write limits seem to be very low

18 messages · Page 1 of 1 (latest)

slow flax
#

I feel like some people might take this as a rant about the recent pricing changes but honestly, it’s not. I really like Appwrite, and I’m genuinely just trying to understand where it fits in now, especially compared to other platforms like Firebase.

The new pricing model introducing limits on database reads and writes makes sense—what the blog explained was fair, and I get that sustainability is important. But looking at it from a beginner or hobbyist dev’s perspective, the quotas on reads and writes in both the free and pro tiers feel kind of tight. Especially when you stack it up against something like Firebase, which, despite its own pricing quirks, still gives a lot more breathing room in terms of database usage.

Appwrite does a great job balancing this out by offering super generous limits on things like functions, bandwidth, storage, and user management. And that's honestly great. But here’s the thing when someone is just starting out and building their first or second app, the one thing they’re going to hit the most is the database. Most tutorials aimed at beginners don’t really talk about caching, efficient querying, or how to reduce reads/writes. So they end up burning through those limits without even realizing it. Meanwhile, 750k function executions per month feels like way more than a beginner or small project would use, especially early on.

#

So I was thinking maybe there could be more flexibility in how resources are allocated. Like, what if users could choose between boosting database ops or function executions depending on their project needs? Or maybe a daily quota system like Firebase has, which kind of helps distribute the load and makes limits feel less intimidating?

Again I just started with Appwrite a few weeks back so I don't know if this works differently than what I anticipate.

Just throwing it out there, but I feel like giving people the ability to tailor their usage a bit more could really help newer devs stick with Appwrite instead of jumping to something more familiar like Firebase just because they hit the read/write cap early.

Not complaining at all. I love what Appwrite is doing and how much it's grown. Just hoping this kind of feedback helps spark ideas that make it even better for everyone.

proven jackal
proven jackal
slow flax
#

I do believe monthly is better because it allows the devs to check out how their apps work and how much they need.

But still the current limits are kind of off-putting like for example with the current pro plan of 15$ I believe the users can get huge amount of read and writes on firestore on top of the 1.5m they give out on the free tier.

I know there are more charges on firebase but it feels like if some first time dev is going out of their way to learn Appwrite they should have some extra incentives. Like if they think that they will get approx 30k reads per day

In firebase they pay nothing for the entire month but if they want this on Appwrite they directly need to pay 15$ first then also they get minimal benefits if he doesn't plan to use the other features.

#

I will admit I have a bias towards the unlimited reads Appwrite offered initially. I seriously thought about how they are managing all this.

I had an idea of an app where I calculated my firebase bill to be around 13-14$ for everything which seemed fine

Then I saw Appwrite and the extra features it provided in the 15$ plan

I thought that seems like this is a very good deal. But when I started to work on it the announcement dropped.

#

Again everyone PLEASE DON'T TAKE IT like I am asking anyone to put pressure on the team

and

also I urge all the members of the Appwrite team to not take this as a complaint. Just genuine information I wanted to share.

proven jackal
slow flax
#

In Appwrite case? Still the same 15$.

It's not like I myself have been hampered by this. I am just saying.

#

Because in my case I do want to use functions. So the 15$ makes sense and I find the pricing of other things like auth, functions , storage, bandwidth very reasonable and outright better than firebase.

harsh bloom
#

any beginners is not gonna maximise storage, functions call, or anything else appwrite offers in the pro version, the core functionality anyone would look for is having a functioning database with limits that are hard to hit

#

supabase doesn't have any database read/write limit

#

but they have a database storage limit, maybe that can be introduced instead

#

1.75 million reads a month is okay for a test project or hobby project, but for production or anyone on the pro plan looking to publish an app and make it public, i don't think it can even realistically support 1000 daily active users with this limit

#

which is quite a severe limiting factor despite all the lovely other things appwrite offers on pro like storage etc

#

ik we can pay extra for more reads now, but i'd rather lose half my bucket storage for an increase in db reads/writes

harsh bloom
#

I've optimised my db read operations by a lot now, and from my calculations I can't even have more than 300 daily active users with the pro plan, whereas with other providers that would be possible, so the premium features are nice but remain inaccessible and unusable if my database caps me from having > 300 dau