Skip to main content
Sublay is not one monolithic feature set. It’s a collection of bundles — self-contained feature modules you turn on per project. A bundle groups everything a feature needs (its database tables and the endpoints and SDK hooks that operate on them), so your project only carries the features you actually use. Every project gets its own isolated database schema. Installing a bundle provisions that bundle’s tables into your project’s schema and switches the feature on. Removing a bundle takes it back out.
Bundles are about provisioning, not pricing. Installing a bundle makes the feature available in your project; what each plan allows (quotas, AI access, etc.) is a separate concern. See Semantic Search & AI for an example of a feature that needs both its bundle and a paid plan.

​
The core bundle

Every project always has the core bundle. It’s installed automatically when the project is created and cannot be removed. Core provides the foundation that every other feature builds on:
  • Users, authentication & identity — email/password accounts, OAuth identities, and OAuth provider configuration. See Authentication.
  • Entities — the base content unit (posts, articles, listings, anything your users create). See Entities.
Because OAuth identity lives in core, OAuth sign-in works on every project without installing anything extra.

​
Available bundles

On top of core, you choose which of these to install. Each one is independent — install only what you need.

​
Choosing bundles when you create a project

When you create a project in the dashboard, you pick the bundles you want. core is always included — you can’t deselect it — and you can start with core only and add the rest later. Nothing is locked in at creation time.

​
Adding and removing bundles later

Installed bundles are managed from the Database page of your project in the dashboard (https://dash.sublay.io/<projectId>/database). From there you can install a bundle you skipped, or remove one you no longer need. Installing a bundle is an asynchronous operation — the dashboard shows it as provisioning while the tables are created, then installed once it’s ready. This usually takes a moment.
Removing a bundle is destructive. Uninstalling drops the bundle’s tables and the data in them, and clears references to that data from other bundles. For example, removing the spaces bundle deletes all spaces and clears the spaceId on any entities, comments, or conversations that pointed at a space. There is no undo — back up anything you need first.Uninstalling the reputation bundle is doubly lossy: it drops the reputation buckets table and zeroes the reputation column on every user. Reinstalling starts fresh from zero — past scores are not recomputed. See Reputation.

​
What happens if a bundle isn’t installed

Feature endpoints and SDK hooks only work when their bundle is installed. If your app calls a feature whose bundle is missing, the API responds with a clear error instead of a generic failure: If you hit one of these while building, the fix is almost always to install the bundle for the feature you’re using. Open the Database page in the dashboard and add it.
This is why a feature can be fully documented and supported but still return database/tables-not-available on your project — the docs describe the whole platform, while your project only runs the bundles you’ve installed.