Skip to content

feat: ship DocumentsDB and VectorsDB off by default - #13411

Merged
eldadfux merged 1 commit into
mainfrom
fix/disable-documentsdb-vectorsdb
Aug 29, 2026
Merged

feat: ship DocumentsDB and VectorsDB off by default#13411
eldadfux merged 1 commit into
mainfrom
fix/disable-documentsdb-vectorsdb

Conversation

@ChiragAgg5k

@ChiragAgg5k ChiragAgg5k commented Aug 28, 2026

Copy link
Copy Markdown
Member

DocumentsDB and VectorsDB are unusable on a stock installation, so they now ship off and say so, instead of accepting a request and failing on the first write.

What happens today

DocumentsDB runs only on MongoDB and VectorsDB only on PostgreSQL, but an installation deploys a single engine — the one chosen for the platform. A default install has neither engine behind those products:

POST /v1/documentsdb            201    database created
POST /v1/documentsdb/:id/collections
                                500    general_server_error

Nothing in the response says MongoDB is absent; the cause is only in the container logs. A MariaDB platform loses both products the same way.

The change

Both products are off unless _APP_DOCUMENTSDB or _APP_VECTORSDB is set to enabled, and until then their routes return general_service_disabled — to API keys and privileged roles too, since there is no engine to reach either way. The check sits with the existing per-project service gate in app/controllers/shared/api.php, before scope validation, so a disabled product reads the same as one a project has turned off.

Enabling one is an operator decision that comes with provisioning work: deploy the engine and point the matching _APP_DB_*_DOCUMENTSDB / _APP_DB_*_VECTORSDB variables at it. The installer neither asks nor deploys an engine for a product — the variables are documented in app/config/variables.php and that is the whole surface.

CI sets both to enabled, so the existing DocumentsDB and VectorsDB e2e suites keep running against the MongoDB the matrix already provisions.

This supersedes #13382, which offered the choice through the CLI and web installers and had the compose generator deploy an engine per enabled product. That is a lot of surface for products that are not ready to be turned on, so it is closed in favour of this.

Verification

Against a running stack with the change mounted, using a project API key holding every database scope:

Request Default _APP_DOCUMENTSDB=enabled _APP_VECTORSDB=enabled
GET /v1/documentsdb 403 general_service_disabled 200
POST /v1/documentsdb 403 general_service_disabled —
GET /v1/vectorsdb 403 general_service_disabled 200
POST /v1/vectorsdb 403 general_service_disabled —
POST /v1/tablesdb (control) 201 201
GET /v1/databases (control) 200 200

Also confirmed the gate fires ahead of scope validation: an unauthenticated call gets general_service_disabled rather than general_unauthorized_scope.

Test plan

  • Pint PSR-12 passes
  • docker compose config validates
  • Disabled by default for keys and privileged roles, with the controls unaffected
  • Both products reachable again once the variables are set
  • CI e2e stays green with the variables set in the workflow

Note

/v1/embeddings/text is a separate service (embeddings) backed by the embedding container rather than a database engine, so it is left alone.

2.0.x carries a partial version of #13382 already (e92e56d274, the CLI installer half). A follow-up strips the prompts and the compose generator's per-product engine selection there and brings it in line with this.

@ChiragAgg5k
feat: ship DocumentsDB and VectorsDB off by default
cac079d 
DocumentsDB runs only on MongoDB and VectorsDB only on PostgreSQL, but an
installation deploys just the engine backing the platform. A default install
therefore had neither engine behind them: creating a database returned 201 and
the first write failed with a bare server error, the cause only in the logs.

Both are now off unless _APP_DOCUMENTSDB or _APP_VECTORSDB says otherwise, and
their routes answer with a service disabled error until then -- to keys and
privileged roles too, since there is no engine to reach either way. Enabling one
means provisioning its engine and pointing the matching _APP_DB_* variables at
it; the installer does not ask, and does not deploy an engine for a product.
@greptile-apps

greptile-apps Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR makes DocumentsDB and VectorsDB opt-in deployment features, returning a controlled service-disabled response until operators explicitly enable them. Major changes:

  • Adds shared API namespace gates controlled by _APP_DOCUMENTSDB and _APP_VECTORSDB.
  • Documents both variables as disabled by default and describes their engine prerequisites.
  • Propagates the variables to relevant Docker Compose services.
  • Enables both products in CI to preserve existing end-to-end coverage.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete changed-code failure established.

The new checks default both product namespaces to a controlled disabled response, preserve explicit operator enablement through Compose, and keep CI environments opted in; the reviewed changes produced no actionable correctness or security finding.

Important Files Changed

Filename Overview
app/controllers/shared/api.php Adds exact, default-deny gates for DocumentsDB and VectorsDB SDK namespaces before project service and scope validation; no actionable defect was established.
app/config/variables.php Registers both operator-facing feature variables with disabled defaults and provisioning guidance.
docker-compose.yml Forwards both feature variables to the API, realtime, combined-worker, and database-worker services.
.github/workflows/ci.yml Explicitly enables both products in service and grouped end-to-end jobs; no reachable matrix failure was established.

Reviews (1): Last reviewed commit: "feat: ship DocumentsDB and VectorsDB off..." | Re-trigger Greptile

@github-actions

github-actions Bot commented Aug 28, 2026

Copy link
Copy Markdown

✨ Benchmark results

Comparing main (before) → fix/disable-documentsdb-vectorsdb (after).

Metric Before After Change
🚀 Requests/sec 207.92 214.92 ⚪ +3.4%
⏱️ Latency P50 86.04 ms 83.72 ms ⚪ -2.7%
⏱️ Latency P95 185.83 ms 178.14 ms ⚪ -4.1%
Per-scenario breakdown & investigation details

Metrics below reflect the current branch (after). Δ P95 compares against the base.

Scenario P50 (ms) P95 (ms) Requests RPS Δ P95 (ms)
API total 83.72 178.14 13,680 214.92 -7.7
Account 143.22 294.84 720 12.03 -0.35
TablesDB 86.59 154.02 7,440 118.78 -9.96
Storage 68.5 148.91 3,600 59.63 +5.51
Functions 105.32 210.73 1,920 32.49 -7.38

Top API waits (after)

API request Max wait (ms)
account.name.update 461.4
account.prefs.update 442.9
storage.buckets.create 403.87
functions.create 386.34
account.get 378.83

@ChiragAgg5k ChiragAgg5k mentioned this pull request Aug 28, 2026
Merged
6 tasks
ChiragAgg5k added a commit that referenced this pull request Aug 29, 2026
@ChiragAgg5k
revert: drop the installer choice for the database products
ba33088 
Reverts e92e56d, de7f258, 87c3467 and 90b4058, which asked in both
installers which of DocumentsDB and VectorsDB to deploy and had the compose
generator add an engine per enabled product.

Neither product is ready to be turned on from a stock installation, so the
choice is not worth its surface: two installer prompts, a web installer step,
and per-product engine selection. This leaves 2.0.x matching main again for
these files; the replacement, both products off behind an environment variable,
lands on main in #13411 and reaches this branch through the usual sync.
@eldadfux
eldadfux merged commit c0a2497 into main Aug 29, 2026
45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@eldadfux eldadfux eldadfux approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ChiragAgg5k @eldadfux