v1 Roadmap
This is the list of tasks and features that I feel are required to hit v1 (see the full roadmap here). It gets updated regularly, so check back for updates.
Data
- [x] Full entity CRUD
- [x] Relations: many-to-one, one-to-one, many-to-many, poly
- [x] Indexes
- [x] Relational queries
- [x] SDK: DataAPI
- [x] #7
- [x] UUID support
- [ ] Settings with better UX/UI (relations and indices missing)
- [x] #24
- [x] SQLite (LibSQL, D1, DO, node:sqlite, Bun SQLite, SQLocal)
- [x] Postgres support
- [ ] MySQL support
- [x] https://github.com/bknd-io/bknd/issues/201
Auth
- [x] SDK: AuthAPI
- [x] Strategies: Password, OAuth
- [x] Cookie based authentication
- [x] #20
- [x] Bcrypt hashing algorithm for passwords
- [ ] Session based tokens
- [x] Advanced permission control
- [x] Settings with better UX/UI
Media
- [x] SDK: MediaAPI
- [x] Upload, range-requests
- [x] Improved in-app view experience (previews)
- [x] #13
- [x] Mime type and size checking
Flows
- [ ] Full UI implementation
- [ ] Custom MCP as trigger
System
- [x] Drivers (email, cache)
- [x] Plugins
- [x] E2E testing
- [x] Automated adapter testing
- [x] Types generation
- [x] Credential handling
- [x] Native JSON Schema
- [x] Native MCP
Adapters
- [x] Runtimes: Bun, Node, Cloudflare
- [x] Frameworks: Next.js, React Router, Astro
- [x] Deno
Hey @dswbx thank you so much for this project! One thing who really makes Supabase good is the security rules system. Do you plan to have an alternative to that, that will allow querying from the frontend safely
Hey @riderx thanks a lot! Yes absolutely. Currently there is a permission system in place, and I plan to extend those so that you can add a JS-function for each to determine access. Data permissions will also get a filter option which will work very similar to Row Level Security – it'll be a where clause that's always attached.
E.g. you can use the API to query posts of a user like so:
const posts = await api.data.readMany("posts", {
where: {
views: { $gt: 100 }, // only with views > 100
users: 1 // only of user with id 1
}
});
The permission filter will work similarly, e.g. adding the following filter to the permission data.entity.read (syntax of accessing placeholder variables isn't fully determined yet):
{
"views": { "$gt": 100 },
"users": "@auth.id"
}
Permissions are attached to roles, and roles to users. This means that you can have multiple roles with different rules for each permission. You can also create a role that is used by default, which takes effect either when a user does not have a role, or the user is not authenticated.
Would this be what you're looking for?
looking forward. subscribed.
thank you for this great project, and the document are amazing.