​
Introduction

Each project gets a separate database. That’s where all contents are stored isolated from other projects. We use PostgreSQL as primary databsae. If you’ve worked with PostgreSQL and databases in general, you should already be familiar with these concepts.

​
Tables

Screenshot 2025-07-12 at 12.44.39 PM.png Tables are the backbone of your app. That’s where your data lives. Each table becomes a dynamic REST endpoint. These will become available at https://{projectDatabaseName}.{host}/{tableName}. For example: https://udbd44e93dc4ed54403940d07470289cf4e.fluxend.app/notes

​
Create

You can click Create Table button at the bottom when viewing any table. This takes you following interface Screenshot 2025-07-12 at 12.46.25 PM.png You can add any number of columns with types as desired. You may also define additional constraints like Primary Key. We’re working on supporting more constraints

​
Update

You can click icon on top right of table view. This will take you to edit table page. You can add, remove and update column names, types, lengths and adjust restrictions. Screenshot 2025-07-12 at 12.47.25 PM.png

​
Columns

You can add any number of columns to your table. Each column type comes with its own set of restrictions. We’ve implemented as many checks as possible in the frontend to give you clear, helpful messages when something isn’t allowed. However, we’ve deliberately avoided over-restricting things on the frontend. In some cases, you might encounter raw error messages directly from PostgreSQL – this is intentional for now, as it ensures you see the exact cause without unnecessary abstraction. Changing a column’s type is possible in many cases, but not always. Some types can be converted to others safely, while certain conversions can cause data loss or unexpected results. Always double-check your data when changing column types to avoid surprises.

​
Rows

We use PostgREST under the hood. You might be more interested in REST page to understand how you can perform queries using your dynamic REST endpoints.
Screenshot 2025-07-12 at 12.42.19 PM.png You can create, update, and delete any rows in a table. All editable fields can be updated by double-clicking and then typing new values. If you want to delete a row, click the three dots next to it. Then click Delete

​
Indexes

Indexes are only available as API endpoints. UI will become available in next releases
Indexes make your database queries faster. Think of them like an index at the back of a book – instead of scanning every single page to find a topic, you jump directly to the exact location. In your tables, indexes work the same way. They speed up searching, filtering, and sorting by allowing the database engine to find data without scanning entire tables. However, keep in mind that while indexes improve read performance, they can add a slight overhead when inserting or updating rows.

​
Functions

Functions are only available as API endpoints. UI will become available in next releases
Functions let you encapsulate reusable logic directly within your database. They’re like methods in your programming language – you define them once and call them whenever you need that logic executed. For example, you might create a function to calculate user scores, generate formatted strings, or perform complex data transformations. Running these inside the database reduces network calls and improves performance for operations that need to manipulate or process data in-place.

​
Triggers

Triggers are currently planned for upcoming releases.
Triggers let you automate actions in your database whenever certain events happen. Think of them as “if this happens, then do that” rules. For example, you can automatically update a timestamp column when a row is modified, or insert an audit log entry whenever a table is updated. This ensures consistency and removes the need for adding these checks and updates in your application code.

​
Row Level Security (RLS)

RLS is currently planned for upcoming releases.
Row Level Security (RLS) allows you to control exactly who can access which rows in your tables. Instead of writing extensive filtering logic in your application, you define policies directly in your database. For example, you can ensure that users can only see data belonging to their account. This improves security, reduces code complexity, and keeps access control closer to your data.