What is the planned Database and backend APIs module designed to do?
The database module holds your application data. Edict is designed around PostgreSQL, and the intent is that the entities you describe compile into native PostgreSQL tables and constraints. You describe the data once. The system is meant to derive the storage, the validation, and the API from that description.
Planned functionality includes application-specific entities and schemas, relationships, validated data types, create, read, update, and delete operations, domain-specific operations, queries with filtering and pagination, database constraints, safe migrations, generated typed APIs, and user-scoped authorization.
How does the Database and backend APIs module connect to other modules?
The database module is where several other modules meet your data.
- Database + Authentication. An
owner: userrule on an entity is designed to become user-scoped authorization. The module is designed to enforce that each person reaches only their own rows, and the identity comes from the authentication module. - Database + Files. A record can point to an uploaded file, such as a receipt attached to an expense. The file module is designed to apply the same ownership as the record.
- Database + Business logic. Rules such as streaks, capacity limits, or inventory adjustments work on your entities. Atomic changes are intended to run inside the database so two requests cannot both win.
- Database + Background jobs. A scheduled task can read and update records, for example to expire old items or build a daily summary.
A common case: a habit tracker. Authentication gives identity, the database stores check-ins owned by the user, and business logic computes the streak from those check-ins. You declare each part, and the compiler is designed to connect them.
What would you configure in the Database and backend APIs module?
You configure entities, field types, relationships, constraints, indexes, and who owns each record. You also choose which operations the generated API exposes for each entity, and the query shapes your app needs, such as filters and sort order.
The configuration on this page is illustrative. The syntax is not final.
What stays your own code with the Database and backend APIs module?
Your client decides how data is shown and edited. Your product decides what the entities mean. Complex reporting that does not fit the planned query model stays your responsibility, and Edict does not aim to hide PostgreSQL from you. The design goal is that the output is standard and inspectable, so you can read what was generated.
Is the Database and backend APIs module available yet?
Planned. Edict is in development, and this module is not available today. Migrations, performance, and scale are not claimed until they are built and measured. This page describes the intended design only.
Join the beta waitlist to follow progress.