# Limitations

> What the port leaves out.

effect-cqrs is a trial port, not a maintained library. These are the gaps that matter before using it for anything real.

* **No broker.** New events wake view models and subscribers in every process, through PostgreSQL notifications or by polling, but there is no transport like the Moleculer broker, so `dispatch` is the entry point to wire into your own HTTP or RPC layer.
* **SQLite, PostgreSQL and memory only.** There are no adapters for MongoDB or MySQL.
* **Snapshots are opt-in.** Without them, recent state is only kept in memory, so after a restart each aggregate is replayed the first time it is used. A changed state needs a new snapshot `version` by hand.
* **Event upcasts are pure.** An upcast can’t read a service or fail with its own error, and an event can only be read in a version its aggregate declares.
* **No code generator.** There is no equivalent of `cqrs generate`.
* **No inline projections.** A view model never runs in the transaction that appends the events, so a read model is always a moment behind its command. Read one aggregate with `state`, which is always current, or wait for a command’s position with `caughtUp` or `CommandApi.ReadAfter`.
* **Slow handlers don’t slow writers.** There is no backpressure, so a view model with a slow handler falls behind and catches up when writes stop.
* **One thread.** Concurrent writers share commits, but the work itself doesn’t spread over cores, and synchronous SQLite calls block the event loop while they run.