lounge. by LoungeTech

Editions

All editions use the same artifact and specification language. A project.yaml runs unchanged on each edition; edition differences affect available capabilities, not the specification vocabulary or query results.

The editions differ along three operational axes: single-node execution, single-node performance and durability, and multi-process deployment.

CORE

Single node, unlimited concurrent sessions, the full spec language, full queries, hash indexing, the ops surfaces and the strict-lint toolchain. Each session processes its events strictly in order, providing the per-key total order used by actor systems and partitioned logs. Restart is a cold start, so core suits rebuildable state or applications whose durable source of truth lives elsewhere.

PRO

Core, plus the performance axes and single-node durability:

  • In-session parallelisation — processing overlaps within a session while completion order and results are preserved. The performance gain depends on flow shape; see the query-placement rule in Records and Queries.
  • In-flow concurrency — execution: concurrent fan-outs with the failure triad. Note that the map-reduce fold is not part of this axis: it is semantics, so it works on every edition.
  • Multidimensional indexing — GiST/R-tree acceleration; core falls back to a scan transparently, same answers, slower.
  • Durability — the log described above, in a file or in a database. Both backends provide the same capability.
  • Applications — Lounge-built apps are included from PRO. The first is LoungeBuzz, supported Buzz-compatible community infrastructure with demonstrated wire parity against the upstream open relay. It sits at PRO because that is its technical floor: it needs durability and, being single-node by nature, cannot use distribution.

CLUSTER

Pro, plus multi-process deployment in two forms.

Scale beyond one machine. This includes the affinity router, wire transport, Helm, drain-to-retire scaling and instance rotation with proofed adoption. The application contract is unchanged when the deployment grows beyond one node.

Size each part independently. A remoted subtree is its own deployment with its own replica count and its own CPU allocation. A subtree that spends its time waiting on an external API needs concurrency and little compute; a subtree computing per event needs the reverse. In one process they share a single envelope, so you size for whichever is hungrier and pay for that everywhere. Separate deployment permits the resources for each subtree to be sized independently, avoiding the need to provision every subtree for the largest resource requirement among them.

When distribution does not apply. Scale-out is not always needed, and not always possible. Some applications cannot be split — where the transport unit and the consistency unit do not nest, as with long-lived connections carrying many conversations, there is no shard key that works. Such an application belongs on PRO, with durability for recovery and one machine for capacity. Paying for distribution would not add a capability that the application can use.

Capability enforcement

Two behaviours, chosen by whether the capability is semantics-preserving:

  • Preserve semantics and log the fallback — admission serialises and multidimensional queries fall back to scans. The answers are unchanged, but the operation is slower and an INFO message names the unavailable capability.
  • Refuse at build or boot — execution: concurrent, the HA bridge, the router role, the wire listener. Topology is not semantics-preserving, so these name their tier in the error at boot or build time rather than quietly behaving differently at runtime.

Unconfigured, the engine runs in dev mode with the full pro capability set and a clear not-for-production banner, so a laptop or a CI job can exercise pro behaviour. Cluster distribution and HA are not part of dev mode.

Marketplace billing

Editions are metered on compute through the cloud marketplace: you pay your cloud bill, plus a Lounge overhead that depends on the edition. Current rates are on the marketplace listing, which is also where trials, terms and billing live — the marketplace owns customer identity, trial state, entitlement and payment, so there is no separate Lounge account, licence server or customer database to sign up for.

Every edition has a marketplace-managed trial, with the exact term shown before you activate. Cloud infrastructure remains billable during it.

Where to go next