Product · Programmability
Server-side logic, without the sharp edges
Databases let you put logic next to your data — and that logic has historically been the least reviewed, least secured code in the building. AthenaDB keeps the capability and changes how it is delivered: encapsulated, signed, permissioned, and audited.
Domain packs
Available nowEncapsulated server-side logic that lives with your data: signed, permission-gated, and audited on every invocation. This is the AthenaDB answer to the stored procedure — a reviewed, versioned unit rather than ad-hoc code stored in a table.
Saved views
PlannedName a query once and select from it like a table. Row and cell visibility follows your access rules wherever the view is used, so a view can never widen what someone is allowed to see.
Reusable functions
PlannedDefine a calculation once and call it anywhere in a query, like a built-in. Functions are pure by construction — they compute from their inputs and cannot read your data, reach the network, or cause side effects.
Event hooks
PlannedReact to things happening in your database — a document ingested, an object changed, an embedding refreshed — by declaring what should happen. Hooks pick from a defined set of safe actions rather than running arbitrary code on every write.
Coming from another database?
If you have built on SQL Server, PostgreSQL, or MySQL, here is where each familiar tool lands in AthenaDB.
| You would have used | In AthenaDB | Why it is better this way |
|---|---|---|
| Stored procedure | Domain pack action, or your application through the SDK | Signed and permission-checked, with an audit record for every call. |
| View | Saved view | Access rules keep applying through the view — it cannot expose more than the caller may see. |
| User-defined function | Reusable function (or an AI function for model-backed logic) | Pure functions are sandboxed; model-backed work is separate, permissioned, and metered. |
| Trigger | Event hook | The reaction you want, without arbitrary code running inside every insert, update, and delete. |
One deliberate omission: triggers that run your code
AthenaDB will not run arbitrary code inside a write. A trigger body is the classic way an attacker turns a single insert into privilege escalation, and it is hard to review and harder to audit. Event hooks give you the same outcome — react when data changes — by declaring which of a defined set of actions should run, with every firing recorded. If you need genuinely custom logic, a domain pack gives you that with a signature and an audit trail attached.