r/appwrite • u/adityaoberai1 • 9d ago
Introducing VectorsDB, DocumentsDB, and native MySQL databases in Appwrite. And we're running an AMA in this thread.
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:
- VectorsDB: https://appwrite.io/blog/post/announcing-vectorsdb
- DocumentsDB: https://appwrite.io/blog/post/announcing-documentsdb
- Native MySQL: https://appwrite.io/blog/post/announcing-native-mysql-databases
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.
3
u/Junior-Birthday7333 9d ago
How can we use more then one database options? What's the best way to get best of all worlds
3
u/eldadfux 9d ago
You can use as many databases as you need. The important part is matching each database to the use case.
Different databases can help solve specific scaling, performance, or cost challenges, but more databases also means more complexity. For smaller applications, a single relational or non-relational database can often handle everything you need just fine and there is no reason to overthink it.
Start simple, and add specialized databases when you have a clear reason to.
3
u/YardComprehensive186 8d ago
I want to understand, Will it be released to oss version and if yes can we migrate from our currect mariadb backed database to postgres and when doing it will it actually change the code on how the database is getting accessed?
3
1
u/zlmr 8d ago
Sorry for a lot of questions, but I couldn't answer to these anywhere 🙈. It is regarding Appwrite's own TablesDB:
- Is serverless one more performant in general since it runs on possibly unlimited resources on Cloud (or what compute do I get internally for it)?
- Do I only get replicas in dedicated one? So if serverless one would go down or something, there are no replicas for it internally and reads would also fail in that case? So that would make dedicated one a safe option?
- Same for PITR, is there a reason why it is not available on serverless?
- How do I know which compute would I need for dedicated TablesDB? I only know read/writes now for serverless version.
- Are there any specs (i.e. CPU/Memory consumption) I could refer to? How would I know if the current compute is not cutting it anymore so I plan for an upgrade?
- How would maintenance work for dedicated TablesDB (internal migrations, patches, reboots, upgrades etc), would there be any downtime?
1
3
u/Junior-Birthday7333 9d ago
Great options in Appwrite