Appwrite 2.0: native Postgres, an S3 API, an OAuth server

Appwrite 2.0 shipped on August 31, and the interesting part is not the feature list. It is what the feature list refuses to do. The backend platform rebuilt itself around protocols you can leave with — real PostgreSQL, real MySQL, an S3-compatible storage API, and an OAuth 2.1 server — instead of the proprietary wrappers that make a platform sticky. Founder Eldad Fux calls the thing being removed the abstraction tax: the trade where you get convenience now and pay for it later in portability.

What actually happened

Per the Appwrite 2.0 announcement, the release covers a new engine, a rebuilt console, five database types, an S3 API, an OAuth 2.1 server, and organization-level Domains and Firewall.

The parts that change your exit costs:

• Native PostgreSQL (18 and 17) and MySQL (8.4 and 8.0), with TLS, backups, point-in-time recovery, and extensions including PostGIS and pgvector. Not a document store pretending to be relational. Actual Postgres, with actual pg_dump.
• A schema-free DocumentsDB and a VectorsDB with HNSW indexing and built-in embedding models, joining the relational options.
• S3-compatible storage endpoints authenticating with AWS Signature Version 4. Existing files stay reachable through both APIs at once, so migration is not a cutover.
• Your project becomes an OAuth 2.1 provider — hosted consent screens, PKCE, JWT tokens, and dynamic client registration through the client SDKs. That is a self-serve developer portal without building the auth server yourself.
• A new engine, "Hyperloop B," which Appwrite reports delivers 7x the throughput at 6x less memory on I/O-bound workloads.

Domains and Firewall are Cloud-only. Everything else lands in self-hosted too.

Why protocol portability matters for your business

We build on stacks our clients own, so we read releases like this one specific way: what happens the day we want to leave?

With a proprietary database abstraction, the answer is a rewrite. With native Postgres underneath, the answer is a connection string. Same with storage — if your files sit behind an S3-compatible API, every backup tool, CDN, and migration script written in the last fifteen years already works, and moving to Cloudflare R2 or MinIO or plain AWS is a config change. The dual-API access during migration is the detail that says someone has actually done a migration before.

The OAuth 2.1 server is the sleeper. If you sell software and your customers want to connect it to their tools — or to their agents — you need to be an identity provider, and that is a project most small teams either botch or postpone for a year. Getting PKCE and dynamic client registration off the shelf is real leverage.

The honest caveat: adopting a platform to escape lock-in is still adopting a platform. Appwrite's console, functions, and messaging are its own. What 2.0 buys you is that your data and your files are not, and those are the two things that are painful to move. Choose the platform, keep the escape hatch, and know which is which before you commit.

Sources: Appwrite: Announcing Appwrite 2.0.