Event-sourcing building blocks for Rails applications.

Yes — measurements consistently show that event-stream operations stay sub-linear as the log grows, which is an important property for medium- and long-sized streams. Treat any published figure as directional rather than definitive (workloads vary, hardware matters), but the overall trend stays the same. Latest measurements and methodology live in the performance measurements discussions.

That said, streams cannot be undefined in size. Model the system so that every stream has a sensible, bounded lifetime — a stream per order, per account period, per session — rather than a single ever-growing stream that accumulates forever. Good stream boundaries are part of the design, not an afterthought.

No. Funes is an application-layer framework: it bridges Rails and event sourcing, and nothing below that. Everything at the infrastructure layer (encryption, SOC 2 controls, access governance) stays the responsibility of the developer or operator. The event log lives in your database, in your environment, configured to whatever your organization requires.

One friendly request, though: please don't persist PII inside an event. Events are immutable by design — once written, they stay written — so any personal data you drop into a payload is effectively there forever. Keep PII in mutable side tables you can redact or rotate, and reference it from events by stable identifiers.

Fair question — there are excellent tools out there, and we have a lot of respect for them. Funes isn't trying to out-feature any of them. The bet is the opposite one: most existing options reach for broader concepts (CQRS, sagas, process managers, full DDD tactical patterns, dedicated event stores, message buses) that are useful in their own right but sit above and around event sourcing rather than inside it.

Funes deliberately compresses the surface area down to three primitives — events, streams, projections — wrapped in a small, precise DSL. The goal is to remove complexity rather than add more of it: keep the core idea sharp, keep the noise out, and let teams pick up event sourcing without first adopting a wider architectural vocabulary. If you already love the bigger toolkits, they remain great choices; Funes is for teams who want the essence of event sourcing inside a familiar Rails app.

No. Funes is designed for progressive adoption — it's a "good neighbor" that coexists with your existing ActiveRecord models and standard controllers. You can use it for a single mission-critical feature while keeping the rest of your app in plain old Rails. Nothing forces an event-source-everything commitment across the codebase.

Technically, Funes is a Rails engine: it ships as a gem and mounts into your application like any other. The "meta-framework" label isn't about packaging, it's about vocabulary. A typical engine extends an application with features that fit cleanly into the lingo developers already share. Funes goes a step further: it introduces a small set of new concepts (events, streams, projections, interpretations) that aren't part of everyday Rails vocabulary. That extra vocabulary built on Rails, rather than just inside it, is what makes "meta-framework" a better fit than "engine."

AI is far better at gluing well-defined building blocks together than at deriving an entire architecture from first principles. As the cost of writing code falls, the leverage shifts to whoever ships clean, composable primitives that an assistant (or an engineer) can stitch into a system without re-inventing the fundamentals every time. Funes is shaped for that posture: three concepts, a focused DSL, and a clear contract for events, streams, and projections. Mitchell Hashimoto calls this dynamic the building-block economy, and a well-defined event-sourcing framework is precisely the kind of block it rewards.

Funes is architected and maintained by Vinícius Almeida, drawing on his experience building financial systems and complex auditable service operations. It's developed in the open at github.com/funes-org under the MIT license.

Named after Funes the Memorious — the Borges short story about a young man who, after a fall from a horse, becomes incapable of forgetting. Every detail of every moment lodges in his mind in perfect resolution. The framework borrows that conceit: in some systems, the past matters as much as the present, and remembering everything is the point.