Guardrails server fails to start when PostgreSQL lacks pgvector and uuid-ossp extensions

[vaibhatredu]

Describe the bug
The guardrails-api server fails to start when PostgreSQL database doesn't have pgvector and uuid-ossp extensions installed. However, after examining the database
schema, no embedding or vector data is actually being stored in any tables, suggesting these extensions are mandatory requirements but not functionally utilized.

To Reproduce
Steps to reproduce the behavior:

1. Install guardrails-ai[api]==0.7.0
2. Set up PostgreSQL without pgvector and uuid-ossp extensions
3. Configure PostgreSQL connection: export PGHOST=localhost
4. Run: guardrails start --config config.py
5. Server fails with: CREATE EXTENSION "vector" and CREATE EXTENSION "uuid-ossp" errors

Expected behavior
The server should either:
• Start successfully if extensions aren't functionally required
• Clearly document why these extensions are mandatory
• Use the extensions for actual vector/embedding storage if that's the intended functionality

Library version:
guardrails-ai[api]==0.7.0

Additional context
• Database contains only guards and guards_audit tables
• No vector or embedding columns found in schema
• Extensions are hardcoded in postgres_client.py INIT_EXTENSIONS
• This creates deployment barriers for managed PostgreSQL environments
• Need clarification on whether vector functionality is planned or if extensions can be made optional

[CalebCourier]

@zsimjee We should track this as part of the general open source updates we have planned. The extensions are in fact obsolete now because the endpoints that used them no longer exist.

[vaibhatredu]

@CalebCourier @zsimjee Could you please clarify whether the UUID and PGVector extensions are mandatory for Guardrail Server 0.7.0? If they are optional, is there any way to skip or bypass them, since these extensions are not available in the PostgreSQL instance used in our organization?

[vaibhatredu]

@zsimjee I just wanted to know the ways I have to interact with the community to clear doubts related to Guardrails AI. I tried to join the community but its somehow giving error as "Invalid Invite"

[CalebCourier]

@vaibhatredu to answer your questions in order:

1. As part of the startup process, yes the UUID and PGVector extensions are currently required though that requirement will be going away in the future. In general, postgres support for Guardrails Server using 0.7.0 is limited. Postgres support for the Guardrails Server was best in 0.5.x. For 0.7.0, the Guardrails Server works best if you use a config file, as outlined in the docs, instead. We are rethinking how persistence and Guard serialization will look in the future (i.e. 1.0).

2. If you are referring to Discord, clicking on the discord icon on our main site should work. If this link is not working for you, here's a personal invite you can try instead: https://discord.gg/mCrTa485

[vaibhatredu]

@CalebCourier Thanks for the clarification.

To ensure I’m understanding correctly:

1. In v0.7.0, Postgres support is limited and the server works best with config-file based guards, but this also means we lose persistence and CRUD, which are primary requirements for our production use case.
2. In-memory guards do not support CRUD, so relying purely on config files is not ideal for us.
3. You mentioned that proper Postgres support (without UUID/pgvector requirements) is being rethought for v1.0.

Given this, I have a few follow-up questions:

1. For teams that require Postgres-backed persistence today, would you recommend using v0.5.x instead of v0.7.0?
2. Does v0.5.x also require the uuid-ossp and pgvector extensions, or is its schema simpler?
3. Are there any concerns or incompatibilities we should be aware of if we adopt v0.5.x now and later migrate to the redesigned persistence model in v1.0?
4. If the recommendation is to stay on v0.7.0, do you have any suggested patterns for achieving production-grade guard persistence until the new persistence approach is available?

[CalebCourier]

1. For teams that require Postgres-backed persistence today, would you recommend using v0.5.x instead of v0.7.0?

Yes, if you need DB persistence and CRUD capabilites, we recommend using v0.0.5 of the guardrails-api which requires 0.5.x of guardrails-ai.

2. Does v0.5.x also require the uuid-ossp and pgvector extensions, or is its schema simpler?

This also requires the same extensions, but that is something we may be able to patch.

3. Are there any concerns or incompatibilities we should be aware of if we adopt v0.5.x now and later migrate to the redesigned persistence model in v1.0?

Yes, 0.7.0 added support for langchain 1.x and, because of that, dropped support for python 3.9. 0.5.x only supports langchain 0.1.x through 0.3.x.

The breaking changes between 0.6.x and 0.5.x are documented here: https://guardrailsai.com/docs/migration_guides/0-6-migration/. The main change concerning the API is 0.5.x uses Flask instead of Fast API, so we suggest using gunicorn with Uvicorn workers when starting it up for better concurrency.

4. If the recommendation is to stay on v0.7.0, do you have any suggested patterns for achieving production-grade guard persistence until the new persistence approach is available?

Not Applicable

[vaibhatredu]

@CalebCourier Thanks for the clarification.
Based on your response, my understanding is that this solution is not yet ready for production use, as it still lacks capabilities such as dynamic, configuration-driven creation of guards and persistence, which are essential for operating at scale.