This post takes a closer look at some of the most impactful features we have shipped in CedarDB across our recent releases. Whether you have been following along closely or are just catching up, here is a deeper look at the additions we are most excited about.
Role-Based Access Control
v2026-04-02
Controlling who can access and modify data is foundational for any production deployment. CedarDB now ships a fully PostgreSQL-compatible role-based access control (RBAC) system that lets you define fine-grained permissions and compose them into hierarchies that mirror your organization.
Roles are named containers for privileges. A role can represent a single user, a group, or an abstract set of capabilities, flexible enough to model almost any organizational structure. You create roles with CREATE ROLE and assign privileges on database objects (tables, sequences, schemas, …) with GRANT:
-- Create roles for different levels of access
CREATE ROLE readonly;
CREATE ROLE app_backend;
CREATE ROLE admin_role;
-- A read-only role for dashboards and reporting
GRANT SELECT ON TABLE orders, customers, products TO readonly;
-- The application backend can read and write orders, but only read products
GRANT SELECT, INSERT, UPDATE ON TABLE orders TO app_backend;
GRANT SELECT ON TABLE customers, products TO app_backend;
Roles support inheritance, so you can build layered permission structures without duplicating grants. For example, an admin role that needs all backend privileges plus schema management:
-- admin_role inherits all privileges of app_backend
GRANT app_backend TO admin_role;
-- ... and gets additional privileges on top
GRANT CREATE ON SCHEMA public TO admin_role;
Assign roles to database users to put them into effect:
CREATE USER alice PASSWORD '...';
CREATE USER bob PASSWORD '...';
CREATE USER dashboard PASSWORD '...';
GRANT admin_role TO alice;
GRANT app_backend TO bob;
GRANT readonly TO dashboard;
Now bob can insert orders but cannot touch the schema, while dashboard can only run SELECT queries. All of this is enforced by the database itself, not by application code. When permissions need to change, you update the role definition once rather than every user individually.
To tighten access later, REVOKE removes specific privileges:
REVOKE INSERT, UPDATE ON TABLE orders FROM app_backend;
Row Level Security
v2026-04-02
Standard permissions control the access to entire tables (or other database objects). Row Level Security (RLS) lets you go a step further by enforcing a more fine-grained access control at the row level, defining which rows a role can access within a table.
A typical use case is a multi-tenant application where a single table holds data for all clients, but each client should only see their own data:
CREATE TABLE users (
user_role text,
user_name text,
sensitive_user_data text
);
By enabling row level security and defining a suitable policy, the database automatically restricts access so users only see rows that belong to them:
alter table users enable row level security;
create policy users_policy
on users
using (user_role = current_user);
CedarDB’s row level security implementation follows the PostgreSQL specification. Check out our documentation for more details: Row Level Security Docs.
Delete Cascade
v2026-04-02
CedarDB lets you add foreign key constraints to ensure referential integrity. Take, for example, the two tables customers and orders where each order belongs to a customer. Each order references its customer with a foreign key, ensuring that a customer exists for each order.
Without such a constraint, deleting a customer while orders still reference it would leave the data in an inconsistent state.
While on delete restrict prevents such deletions by raising an error, CedarDB now also supports on delete cascade, which automatically deletes the referencing rows as well.
CREATE TABLE customer (c_custkey integer PRIMARY KEY);
CREATE TABLE orders (o_orderkey integer PRIMARY KEY, o_custkey integer REFERENCES customer ON DELETE CASCADE);
-- This also deletes all orders referencing customer 1
DELETE FROM customer WHERE c_custkey = 1;
Note that tables with foreign keys might themselves be referenced by other tables:
CREATE TABLE lineitem (l_orderkey integer REFERENCES orders ON DELETE CASCADE);
-- This also deletes all orders referencing customer 1 and all lineitems that reference those orders
DELETE FROM customer WHERE c_custkey = 1;
With this, it is possible even to have cyclic delete dependencies, which are handled automatically by CedarDB as well.
Drizzle ORM Support
v2026-04-02
Drizzle is one of the most popular TypeScript ORMs, and CedarDB now supports it out of the box. This means TypeScript developers can use Drizzle to build applications backed by CedarDB with full compatibility.
To make this work, we closed a series of compatibility gaps with PostgreSQL: CedarDB now fully supports GENERATED ALWAYS AS IDENTITY columns (including custom sequence names) and pg_get_serial_sequence for auto-increment discovery. Additionally, we overhauled our system tables so Drizzle can correctly reconstruct full schema structure.
Want to try it yourself? Install Drizzle and point it at CedarDB just like you would a PostgreSQL database:
npm install drizzle-orm postgres
npm install -D drizzle-kit
Check out our Drizzle documentation for a step-by-step guide to running your first drizzle queries against CedarDB.
That’s it for now
Questions or feedback? Join us on Slack or reach out directly.
Do you want to try CedarDB straight away? Sign up for our free Enterprise Trial below. No credit card required.
