Boost what matters

Feature Requests

Submit feature requests and boost what you want to see next.

#5213

LTS Maincloud

RequestedJun 3, 2026

## Summary While Maincloud is not technically on a bleeding edge or nightly release cycle, the latest version is deployed immediately after a new SpacetimeDB release. Your only option to not upgrade to latest is to use Standalone or lock in an Enterprise deal for a private node. Each of these have issues: - Standalone -> Free, but doesn't scale - Enterprise -> Potentially costly, and overkill for most The logical conclusion for a vast majority of users is to use shared hosting, a-la Maincloud. It even comes with `SLA / Uptime Guarantees` if you're a Pro subscriber. ## The Issue I have no doubt that a lot of effort goes into this, but deploying new SpacetimeDB versions to Maincloud without any issue or bugs is a tall order- in fact, it's an impossible order. The new version is being deployed to thousands of modules, all on various runtime versions, and some functionality will be tested live for the very first time in unexpected ways. We can have 1,000 different smoke tests, but they will never handle all of the edge-cases. This has, and will continue to lead to disruptions to Maincloud customers. ## Proposal Similar to [#5204](https://github.com/clockworklabs/SpacetimeDB/issues/5204) and its related [feature request](<https://spacetimedb.com/features/requests/38>) I would love to see a LTS Maincloud instance that is fixed to a specific stable build. `spacetime publish <module_name> --lts` This would prevent new Maincloud version deploys (and bugs) from disrupting production applications deployed on LTS Maincloud, giving potential start-ups and businesses peace of mind knowing their backend infra is stable. ## Challenges I acknowledge this comes with many challenges, so I am looking for feedback and replies in the github thread: - Does current maincloud transition to LTS or Latest? - Maincloud will need module migration tool to go from server to server - Can you only migrate your module from LTS to Latest and not the other way around? - At what interval is the LTS version updated? What type of key milestones indicate a version bump? - What type of deploy/patches are allowed on LTS? Bugfixes only? What about QoL? - What should be the default Maincloud publish functionality, LTS or Latest? Happy to hear your thoughts. Let's have a discussion. _Requested by [@Lethalchip](https://spacetimedb.com/@lethalchip) via the SpacetimeDB site._

355,105TeV
From 8 boosters
#5199

Sync Inter-database Communication (Sync IDC)

RequestedJun 3, 2026

I would like to be able to call a reducer on another database from within my database. I want the reducer to be able to return the result, and I would like it to do so atomically: Receiver (payments) — a plain reducer that returns a value. ctx.sender is the calling database's identity. ```rs #[spacetimedb::reducer] fn charge(ctx: &ReducerContext, customer: Identity, amount: u64) -> Result<u64, String> { let mut acct = ctx.db.accounts().customer().find(customer).ok_or("no account")?; if acct.balance < amount { return Err("insufficient funds".into()); } // aborts the whole tx acct.balance -= amount; let new_balance = acct.balance; ctx.db.accounts().customer().update(acct); Ok(new_balance) } ``` Caller (orders) — the call is inline; the local insert and the remote charge commit together or both roll back. ```rs use payments; #[spacetimedb::reducer] fn place_order(ctx: &ReducerContext, item_id: u64, price: u64) -> Result<(), String> { let payment_db = ctx.db.config().single().payment_db; // a stored payments::Identity // Sync cross-database call (Level 7, 2PC). `?` aborts the whole distributed tx on Err. let new_balance = payments::Identity(payment_db).reducers.charge(ctx.sender, price)?; ctx.db.orders().insert(Order { id: 0, customer: ctx.sender, item_id, price, balance_after: new_balance }); Ok(()) } ``` _Requested by [@cloutiertyler](https://spacetimedb.com/@cloutiertyler) via the SpacetimeDB site._

88,002TeV
From 6 boosters
#5198

Async Inter-database Communication (Async IDC)

RequestedJun 3, 2026

I would like to be able to send messages from one database to another via an outbox table. Sender side (inventory module) 1. Declare the outbox table. It needs a #[primary_key] #[auto_inc] u64 msg_id, a #[target] typed identity, and payload columns matched by name to the receiver reducer's parameters. ```rs use game_world as gw; #[spacetimedb::table(name = out_receive_item, outbox(gw::receive_item))] pub struct OutReceiveItem { #[primary_key] #[auto_inc] msg_id: u64, // runtime-assigned sequence number #[target] target: gw::Identity, // which database to deliver to // Payload columns — names must match gw::receive_item's parameters. item_id: u64, qty: u32, } ``` Defaults are the strong guarantees: ordered = true, reliable = true → ordered, exactly-once delivery per (sender, receiver). 2. Send by inserting a row. Leave msg_id at 0; the runtime assigns it on commit. If the transaction rolls back, nothing is sent. ```rs #[spacetimedb::reducer] fn transfer_item(ctx: &ReducerContext, to: gw::Identity, item_id: u64, qty: u32) { ctx.db.out_receive_item().insert(OutReceiveItem { msg_id: 0, target: to, item_id, qty, }); } ``` 3. (Optional) Observe the outcome. Attach an on_result reactive reducer naming the outbox table. It fires once per terminated delivery, post-commit, on the sender. Ok(()) means the receiver returned Ok; Err(s) carries the receiver's error or a terminal transport/schema failure. ```rs #[spacetimedb::reducer(on_result(out_receive_item))] fn on_transfer_result( ctx: &ReducerContext, row: OutReceiveItem, result: Result<(), String>, ) { if let Err(err) = result { log::warn!("transfer of item {} to {:?} failed: {}", row.item_id, row.target, err); } } ``` _Requested by [@cloutiertyler](https://spacetimedb.com/@cloutiertyler) via the SpacetimeDB site._

88,002TeV
From 3 boosters