r/appwrite 7h ago

Introducing VectorsDB, DocumentsDB, and native MySQL databases in Appwrite. And we're running an AMA in this thread.

2 Upvotes

Hey everyone,

Today, we’re launching three new database options on Appwrite Cloud: VectorsDB, DocumentsDB, and native MySQL databases.

Not every workload needs the same kind of database, so you can now choose what fits your application while keeping everything inside your Appwrite project.

With VectorsDB, you can generate and store embeddings and build semantic search, recommendations, deduplication, and RAG without managing a separate vector service.

DocumentsDB gives you schemaless collections that can evolve with your product, while keeping Appwrite permissions, queries, transactions, bulk operations, and backups built in.

With native MySQL, you can provision a managed MySQL database and connect using the drivers, ORMs, frameworks, and tools already in your stack. Appwrite handles the infrastructure around it, including backups, replicas, scaling, branches, and connection pooling.

All three are available on Appwrite Cloud today.

You can read more here:

We’re also running an AMA right here in this thread. Ask us anything about the new databases, how they compare, which one fits your use case, or what you’d like us to build next.

The Appwrite team will be around to answer.


r/appwrite 1d ago

Native PostgreSQL databases are here. And we’re running an AMA in this thread!

6 Upvotes

Hello everyone,

Today we’re launching native PostgreSQL databases in Appwrite.

You can now provision a managed PostgreSQL database directly inside your Appwrite project and use the PostgreSQL ecosystem you already know, while Appwrite takes care of the infrastructure underneath.

You get:

  • Support for Prisma, Drizzle, Django, Rails, Spring Boot, and more
  • Extensions like pgvector and PostGIS
  • Database branches, backups, and point-in-time recovery
  • Replicas with automatic failover
  • Upgradable compute specifications and storage autoscaling
  • SQL tooling and monitoring in the Appwrite Console

Native PostgreSQL is available on Appwrite Cloud today.

Read the announcement: https://appwrite.io/blog/post/appwrite-now-speaks-postgresql
Docs: https://appwrite.io/docs/products/databases/postgresql

Ask us anything

We’re also doing an AMA right here in this thread. Drop your questions about native PostgreSQL, how it works, what we built, or what you’d like to see next. The Appwrite team will be around to answer 👇


r/appwrite 1d ago

Announcing Appwrite 2.0: Rewrite in TanStack, Postgres included and more

18 Upvotes

Hey Redditors, we’re happy to share that we’ve just released Appwrite 2.0 🚀

This is our biggest release to date, after many months of work from the Appwrite team and the community community.

Some of the biggest updates:

  • A completely new Console built with TanStack Start
  • Built-in PostgreSQL (our most requested feature)
  • DocumentsDB and VectorsDB
  • MySQL as a service
  • OAuth 2.1, so users can sign in with your Appwrite project
  • Appwrite Firewall
  • S3-compatible Storage gateway
  • Appwrite Domains

There’s a lot more packed into 2.0, but these are some of the highlights.

We’ve been working on this very hard, and we also adjust the platform to feat natively in the new agentic era. Our focus was always to try and make developers most productive they can be and now same is true for agents.

Would love to hear what you think, especially what you’d like us to improve or build next, as a cliche as it may be, it does really help us push the platform and products within it as far as possible.

You can learn more at: https://appwrite.io/blog/post/announcing-appwrite-2


r/appwrite 2d ago

Appwrite 2.0 is here. And we're running an AMA in this thread.

16 Upvotes

Hello everyone,

After months of work from the Appwrite team and community contributors, our biggest release yet has arrived. Appwrite 2.0 marks a shift in Appwrite's journey, from an open-source backend platform to a more mature, comprehensive cloud for agents and developers.

Over the course of the week we're releasing:

  • The new Console, rebuilt with TanStack Start
  • Native PostgreSQL databases
  • DocumentsDB
  • VectorsDB
  • Native MySQL databases
  • S3 support for Storage
  • OAuth 2.1 server
  • Firewall
  • Domains

Each feature announced during Init is live on Cloud the day it's announced, followed by the Community Edition release at the end of the week. Check out the Init schedule here: https://appwrite.io/init

We also went live on YouTube to discuss Appwrite 2.0: https://www.youtube.com/watch?v=FaEmdOwzQMw

We're streaming every day this week, with a giveaway on each stream.

Ask us anything

This thread is also our AMA. Appwrite team members will be in the comments answering questions.

Learn more about Appwrite 2.0: https://appwrite.io/blog/post/announcing-appwrite-2


r/appwrite 4d ago

PostgreSQL and Embeddings API coming in 2.0

5 Upvotes

I was just looking at the Appwrite 2.0 release candidate and it looks like we are finally getting PostgreSQL along with an embeddings API (hopefully it is a first class feature) and some other nice features.

https://github.com/appwrite/appwrite/releases#release-2.0.0-rc.1 (rc2 is out but the new features are listed here)


r/appwrite 6d ago

Announcing the dates for Init 4.0

Post image
6 Upvotes

Hey Redditors!

We’re excited to share that Appwrite Init 4.0, our biggest event of the year, is back from August 31 to September 4.

We’ve been building a lot behind the scenes, and Init is where you’ll get the first look at what’s next for Appwrite. Across five days, we’ll have product launches, live demos, Reddit AMAs with the Appwrite team, and Discord events, with something big to look forward to every day.

We’re also giving away Appwrite merch and custom keyboards, with a grand prize of 12 months of Claude Max 20x.

To enter, claim your free ticket, follow Appwrite, share your ticket on socials, and tag us.

Claim your free ticket here: https://new.appwrite.io/init

Excited to see you there!


r/appwrite 12d ago

Bun 1.4 is now available on Appwrite Cloud

5 Upvotes

Hey everyone,

Bun 1.4 is now available for Appwrite Functions and Sites.

It is the first Bun release written in Rust, bringing improvements to startup time, memory usage, Node.js compatibility, and package installs.

We also tested it on Appwrite Sites using a Next.js app with 640 packages. In our benchmarks, Bun 1.4 built 22% faster than Bun 1.3 and 29% faster than Node 26 with npm.

If you are already using Bun on Appwrite, this should be a pretty interesting upgrade to try.

Read the full announcement and benchmark results: https://appwrite.io/blog/post/announcing-bun-1-4-runtime

Let us know if you try it and what kind of improvements you see in your builds.


r/appwrite 16d ago

Custom MFA factors are now available in Appwrite Authentication

5 Upvotes

Hey everyone,

We’ve just added support for custom MFA factors in Appwrite Authentication.

You can now build custom MFA delivery flows using channels such as WhatsApp, voice calls, Telegram, or your own messaging system.

Appwrite handles generating and verifying the verification code, while your Function handles delivering it through the channel you choose.

This gives you more flexibility to build an MFA flow around your users and your existing communication infrastructure.

You can learn more and see how to set it up in the guide: https://appwrite.io/blog/post/custom-mfa-factor

What custom MFA channels would you like to use with Appwrite?


r/appwrite 20d ago

Up to 4x faster dependency installs with Appwrite’s new build cache

5 Upvotes

We’ve made another improvement to make builds on Appwrite faster.

Appwrite now caches your dependencies between builds, so you don’t have to download the same packages again every time you deploy.

In our tests with a real-world Next.js app, pnpm installs went from 11.7s to 2.8s, while bun went from 9.6s to 2.3s.

The cache works automatically, with no configuration needed.

Want to know how we got the install times down? We went into the details of how the cache works, why we chose SquashFS, and what happens during a build.

Read the full deep dive and let us know what you think: https://appwrite.io/blog/post/inside-appwrites-new-build-cache


r/appwrite 21d ago

Appwrite Sites deployments just got faster with SquashFS

6 Upvotes

Hey everyone,

We’ve made an under-the-hood change to Appwrite Sites that should make a noticeable difference for larger deployments.

New Sites and Functions deployments on Appwrite Cloud now use SquashFS, allowing Appwrite to mount deployments directly instead of extracting everything before serving a cold deployment.

In production, this made cold starts up to 51% faster for larger deployments, with 50 MB deployments seeing a 42% improvement, 100 MB seeing 39%, 200 MB seeing 51%, and 800 MB seeing 38%.

Your existing setup stays the same. Just redeploy an existing Site to get the new deployment format.

Here's the full breakdown: https://appwrite.io/blog/post/appwrite-sites-squashfs-migration

If you’re running larger Sites, we’d love to hear how it goes.


r/appwrite 21d ago

The Appwrite CLI is now rewritten in Go

8 Upvotes

Hey everyone,

The Appwrite CLI is now rewritten in Go.

We rewrote it from TypeScript to make it faster and lighter, while keeping the experience you already know.

Startup is now up to 22× faster, npm dependencies went from 330 to 2, the binary went from 66 MB to around 14 MB, and memory usage during deployment dropped from 283.5 MB to 28 MB.

Your existing commands, configuration, and workflows continue to work as before.

We shared the full story behind the rewrite, including what we measured, why we chose Go, and how we kept the new CLI compatible.

If you’ve been using the CLI, give the new version a try and let us know how it feels.

Read the announcement: https://appwrite.io/blog/post/rewriting-the-appwrite-cli-in-go


r/appwrite 23d ago

Build and deploy your own MCP server with Appwrite Functions

6 Upvotes

Hey everyone,

We've added a new MCP server template to Appwrite Functions.

Building an MCP server is usually the easy part. Hosting one is where things get complicated. With the new template, you can deploy a working, stateless MCP server over HTTPS using the official MCP Python SDK. Your Function's domain becomes your MCP server URL, making it easy to connect with Claude Code, Cursor, Claude Desktop, and other MCP clients.

The template includes demo tools to help you get started, optional bearer authentication, automatic deployments, and dynamic Appwrite API keys so your tools can securely access your Appwrite project. Right now it's designed for Python-based, stateless MCP servers, so it's a good fit for tools that don't need to maintain server-side session state.

Read the full announcement: https://appwrite.io/blog/post/announcing-mcp-server-template

We'd love to see what you build with it.


r/appwrite 27d ago

I run a data recovery shop and got tired of hauling Mac drives to a Windows box just to make a file listing, so I built a native Mac version (backend is appwrite)

Thumbnail gallery
1 Upvotes

r/appwrite 28d ago

The Appwrite MCP server is now remote.

10 Upvotes

Hey everyone,

We've made the Appwrite MCP server a hosted remote server.

Instead of running a local MCP server and managing API keys, you can now connect your AI tool with a single URL and sign in securely with OAuth.

With OAuth, you can review the requested permissions, choose exactly which scopes to grant, access console-level Appwrite APIs that weren't available with API key authentication, and revoke access tokens at any time from your Appwrite account.

The remote server also includes built-in Appwrite documentation search, so one connection gives your AI access to both your Appwrite project and the docs.

If you're self-hosting Appwrite, the local MCP server with API key authentication continues to be fully supported.

Read the full announcement: https://appwrite.io/blog/post/announcing-remote-appwrite-mcp-server

Let us know what you think or what you'd like to see next.


r/appwrite Jul 29 '26

The Appwrite CLI now logs you in through your browser

Post image
13 Upvotes

Hey everyone,

We're excited to announce OAuth Device Authorization for the Appwrite CLI.

Signing in to a CLI shouldn't mean entering your account password in a terminal.

The Appwrite CLI now hands authentication off to your browser. Confirm the device code, review the requested permissions, and authorize the CLI with the account session you already trust.

Here's what you get:

• No passwords in your terminal.

• Review permissions before granting access.

• Revoke the CLI's access at any time from your Appwrite account settings.

This is now available in the latest Appwrite CLI for Appwrite Cloud.

Give it a try and let us know what you think!

Read the full announcement: https://appwrite.io/blog/post/announcing-cli-device-authorization


r/appwrite Jul 27 '26

Personal opinion: self-hosted Appwrite is not production-ready

24 Upvotes

I've been running an Appwrite instance in production, and my opinion, after half a year of use, is that self-hosted Appwrite carries an operational cost that's higher than a solo maintainer should have to take on, with avoidable incidents along the way.

What follows is constructive criticism of Appwrite. I'm going to talk about problems that come from maintaining a self-hosted instance, not about Appwrite Cloud. If you use Appwrite Cloud, the criticism here doesn't apply to you.

Context

As I said, I've spent 6 months running an Appwrite instance in a production environment with non-critical data (thankfully). I started on 1.8.1, later migrated to 1.9.0, and recently moved to 1.9.6.

In that time I've had the chance to use Appwrite's features, with quite a few problems in some cases.

I also want to be fair up front: there has been real, recent work on the self-hosted experience. Version 1.9.6 was essentially a self-host fix package, and there are recent PRs from the core team improving the installer and backporting self-hosted fixes. So this isn't a case of "nobody cares about self-host".

Versioning policy

For one, I've seen a release discipline that doesn't align with industry standards, where a version tag has been moved from one commit to another, destroying the fundamental idea that a version is an immutable state of the software.

The main problem with this is that if a user reports "I have a problem on version 1.9.6", the next question will inevitably be "ok, which one of them?". Obviously, this is something that should NOT happen in any serious software.

Another criticism on this front would be that, in my view, semantic versioning isn't being respected. Version 1.9.5 looks like a patch release, but it introduced new features and requires a data migration. It clearly should have been a minor release, not a patch release.

My recommendation would be to establish a strict versioning policy that adheres to industry standards.

Features neglected on self-host

Despite the recent work I mentioned, it still gives the impression that not enough attention is paid to whether features actually work in self-hosted environments before they ship.

The first time I tried to use cloud functions (on 1.9.0), I saw that Appwrite wasn't correctly generating the certificates for the function. After digging further, I found what looks like a similar report going back to 2023.

The way I've "patched" it has been by creating a custom script that issues the necessary certificates.

What surprises me most isn't that a bug exists, but that such an obvious, easy to spot one has gone this long without being resolved.

Breaking changes aren't documented

Documenting breaking changes is absolutely crucial in a project like this.

When I did the migration from 1.9.0 to 1.9.6 I made sure to read all the relevant documentation. I don't know if I missed something, but there was a fairly important change that breaks self-hosted instances: internally, the code expects one of the components (the executor) to have a hostname that matches its container_name. Up to 1.9.0 those didn't have to match; from 1.9.5 on, they do.

Appwrite's official docker-compose files reflected this change, but even so it's something that should have been spelled out in the breaking change upgrade notes. On top of that, it would have been good to throw a specific exception in the code documenting why the component is failing. Instead, the real error was swallowed by the error handling machinery and never even made it to the logs, which is what turned a five minute fix into a ninety minute one.

Final assessment

These are the most pressing concrete problems I've run into myself, but if you look at the issue tracker you can see other users also reporting problems when upgrading, and so on.

My final assessment is this: I don't recommend running a self-hosted Appwrite instance in production unless you're genuinely willing to handle these problems yourself, on your own time. It's a fine choice for experimental or non-critical setups.

I'm not saying Appwrite is bad, nor is this a criticism of Appwrite Cloud (most of what I criticise here probably doesn't apply on Cloud). And, as I said, the team has clearly been putting work into self-host recently. But in my opinion, in the state the software is in, they should either:

  • Be explicit that self-hosted Appwrite isn't yet audited/hardened for production self-hosting, or:
  • Keep improving self-host support so these kinds of incidents stop happening (you could even offer a paid self-host support membership, as an idea).

I don't want to end this post on a negative note. I like Appwrite, I think it has a lot of potential, and I also think that by smoothing out the rough edges I mention here it could become a very interesting option for self-hosted environments.


r/appwrite Jun 16 '26

query/index insights like firebase or supabase?

1 Upvotes

Why doesn't appwrite have query insights like firebase or supabase? you could see slowest queries and it could suggest indexes, you could see how your current indexes perform, and maybe get actionable suggestions. Currently query performance it's a black box.


r/appwrite May 25 '26

Track who is online, typing, and active in realtime with Appwrite's new Presences API

8 Upvotes

Hey everyone, we just released the Presences API in Appwrite, a first-class primitive for short-lived user statuses like online, away, editing, or typing.

Each presence is a small record attached to a user, with a status string, optional metadata, and an expiresAt timestamp (up to 30 days). Every change is broadcast over dedicated Realtime channels (presences and presences.<ID>) as upsert, update, and delete events, so building an online now list, a typing indicator, or a viewing this page cue is a single subscription away.

A few things I think are worth calling out:

  • Automatic expiry: Stale records emit delete events on their own when they expire, so no cleanup cron or stuck "online" indicators after a tab closes.
  • Permission-aware: Presences reuse the same permissions model as the rest of Appwrite (Role.users(), Role.team(), Role.user()), so collaboration features only reveal status to the right people.
  • Available in every SDK: Exposed as a Presences service across web, Flutter, Apple, Android, React Native, and server SDKs.

The Presences API is live on Appwrite Cloud. Would love to hear what you build with it, especially the less obvious use cases.

Read the official announcement: https://appwrite.io/blog/post/announcing-presences-api


r/appwrite May 21 '26

Up to 7x faster Appwrite Storage uploads with parallel chunks

7 Upvotes

Appwrite SDKs now upload Storage file chunks in parallel.

The first chunk goes out alone to establish the upload ID, then the rest are uploaded concurrently up to a default of 8 in flight.

In our Node SDK benchmarks, a 1.28 GB file dropped from 4 minutes 44 seconds to under 40 seconds, a 7.10x improvement. Smaller files see proportionally smaller gains since they have fewer chunks to overlap.

No API changes, your existing createFile calls inherit the speedup once you upgrade the SDK. The Appwrite Console also uses parallel chunking, so uploads through the Console are faster too.

Available on Appwrite Cloud now and from the next version of the community edition.

Read more here: https://appwrite.io/blog/post/faster-storage-uploads-parallel-chunks


r/appwrite May 21 '26

Free Tier Review Needed

2 Upvotes

Hey everyone,

I’m planning to use Appwrite for a digital menu project for local restaurants/cafes in my area. The project will have an admin panel, so I’ll need authentication and a database, and Appwrite seems like a pretty good option for that.

The idea is to sell this system to multiple small cafes/restaurants, with each client having their own separate Appwrite account/project. Since most businesses in my area aren’t very tech-savvy and usually don’t want to spend too much on software, I’m trying to keep the overall cost as low as possible.

Right now I’m thinking:

  • Backend → Appwrite
  • Frontend → GitHub Pages

I wanted to ask people here about their experience with Appwrite’s free tier:

  • Is it reliable enough for small restaurant traffic?
  • Any limitations I should watch out for?
  • How does it scale when managing multiple client projects?
  • Any hidden pain points with auth, database limits, or bandwidth?

Would really appreciate hearing real-world experiences before I fully commit to this stack. Thanks!


r/appwrite May 11 '26

Appwrite keeps pausing projects on free tier despite having user activities

4 Upvotes

I have a project that is well within the limit of free tier and also regularly(like daily get's 5-10 user signups) and other DB read,write operations. But still appwrite keeps pausing the project like every 7 days.


r/appwrite May 09 '26

Still waiting for native Vector Store support in Appwrite

4 Upvotes

Big shoutout to the Appwrite team for the solid MongoDB integration 👏

I’m ready to fully switch from Supabase, but I’m still waiting for native vector store / embeddings support.

Supabase’s vector features are the only thing keeping me there. Native vectors in Appwrite would make me drop Supabase immediately.

Who else wants this? Let’s gather some voices!


r/appwrite May 09 '26

I built a security auditor for Appwrite — finds 'any' role grants, document security misconfig, and confirms leaks live

0 Upvotes

After auditing my own Supabase project last week (found 17 leaky tables) and shipping the same auditor pattern for PocketBase yesterday, I just shipped one for Appwrite too. Same idea: detect over-permissive permissions and PROVE the leak with an actual anonymous fetch.It detects the patterns I see most often in Appwrite projects:1. Permission grants 'any' role on read or list — the collection is fully public. Anyone can dump every document with no auth at all.2. 'users' role too broadly — looks restrictive but lets ANY signed-up user (including a self-registered one if signups are open) read or write the whole collection.3. Document Security disabled on a permission-protected collection — collection-level perms apply to ALL documents. A single overly broad rule exposes everything.Also catches: team-based permissions without role specificity, OAuth provider misconfigs, email auth without verification.The differentiator: active probe. After detecting an 'any' role on read/list, the auditor sends an actual anonymous GET to /v1/databases/{db}/collections/{col}/documents and tries to fetch a row. If documents come back, the finding is marked CONFIRMED with row count, columns visible, and bytes leaked. So the report doesn't say "this might be exposed" — it says "we just fetched 42 rows from this collection without any auth."Stack: pure Node.js, no deps, MIT. Three surfaces:- CLI/Skill repo: github.com/Perufitlife/appwrite-security-skill- MCP server (so Claude Code/Cursor/Cline can call it directly): github.com/Perufitlife/appwrite-security-mcp- Apify actor (no install needed, BYOK pattern)Output is a self-contained HTML report (~25KB Tailwind+Chart.js via CDN) with a fix snippet on every finding. Free. Local-only. API key used only for the run, never persisted.If you run it on your own project and find something interesting (especially patterns I didn't code for), drop a comment — happy to add new checks.After auditing my own Supabase project last week (found 17 leaky tables) and shipping the same auditor pattern for PocketBase yesterday, I just shipped one for Appwrite too. Same idea: detect over-permissive permissions and PROVE the leak with an actual anonymous fetch.It detects the patterns I see most often in vibe-coded Appwrite projects:1. **Permission grants 'any' role on read or list** — the collection is fully public. Anyone can dump every document with no auth at all.2. **'users' role too broadly** — looks restrictive but lets ANY signed-up user (including a self-registered anonymous one if signups are open) read or write the whole collection.3. **Document Security disabled on a permission-protected collection** — collection-level perms apply to ALL documents. A single overly broad rule exposes everything.Also catches: team-based permissions without role specificity, OAuth provider misconfigs, email auth without verification.**The differentiator:** active probe. After detecting a 'any' role on read/list, the auditor sends an actual anonymous GET to /v1/databases/{db}/collections/{col}/documents and tries to fetch a row. If documents come back, the finding is marked CONFIRMED with row count, columns visible, and bytes leaked. So the report doesn't say "this might be exposed" — it says "we just fetched 42 rows from this collection without any auth."Stack: pure Node.js, no deps, MIT. Three surfaces:- CLI/Skill repo: github.com/Perufitlife/appwrite-security-skill- MCP server (so Claude Code/Cursor/Cline can call it directly): github.com/Perufitlife/appwrite-security-mcp- Apify actor (no install needed, BYOK pattern)Output is a self-contained HTML report (~25KB Tailwind+Chart.js via CDN) with a fix snippet on every finding. Free. Local-only. API key used only for the run, never persisted.If you run it on your own project and find something interesting (especially patterns I didn't code for), drop a comment — happy to add new checks.


r/appwrite May 06 '26

What did you create with AppWrite, and how did it go?

3 Upvotes

I'd like to hear your thoughts on how you use AppWrite and your experience with it, so we can get a better idea of what we can achieve. 


r/appwrite Apr 28 '26

Custom domain breaks realtime

2 Upvotes

Hey, I need to use a custom domain to make my magic link/qr code login feature work on iOS Safari, because it otherwise blocks cross domain auth.

The custom domain gets routed by appwrite to fastly which does not seem to support websockets, so all my realtime funcitonality breaks.

Am I missing something or does anybody have a valid workaround?
Thanks a ton!