Databases Overview

faz speaks 14 database query languages natively. Your AI assistant submits queries in the database's native language (or via an intent-based JSON schema for vector and DynamoDB), and faz runs each one through the same five-stage safety pipeline before execution.

This page is the family-level overview and the cross-cutting "what every connector has in common." For the specifics of any one database, click through to its dedicated page.

The 14 supported databases

* Default port 8000 is for the local DynamoDB container. Managed AWS DynamoDB uses the SDK's endpoint resolution — see the DynamoDB page.

What every connector has in common

The databases: entry in faz.yaml shares the same shape across every connector:

databases:
  - name: <database>       # routing key; defaults to the connector type
    type: postgresql       # one of the 14 type values above
    host: localhost
    port: 5432
    database: <db-name>
    username: <username>
    password: <password>
    ssl: false
    extra: {}              # connector-specific extras

The standard fields — host, port, database, username, password, ssl — apply to every connector. What changes is:

• Defaults: each connector type has a sensible default port (the table above).
• Field meaning: database is a Postgres database, a MongoDB database, an Elasticsearch index pattern, a DynamoDB table — depending on the connector. Per-connector pages spell this out.
• The extra: mapping: connector-specific keys. DynamoDB uses extra.region and extra.endpoint_url; Pinecone uses extra.api_key; most relational connectors don't use extra at all.
• Authentication: most use username + password; DynamoDB uses the AWS SDK's credential chain; Pinecone and similar API-key services accept the key in extra.api_key or password.

The full schema reference is on faz.yaml.

How permissions apply across families

Permissions are language-agnostic. The R / W / RW / RA / RWA / A codes mean the same thing whether you're configuring access to Postgres or to Weaviate; the connector translates between SQL verbs and its native equivalents.

For example, a Postgres R baseline allows SELECT and rejects INSERT. The same R baseline on MongoDB allows find / aggregate / count / distinct and rejects insertOne / updateMany / deleteOne. The mapping is documented on Permission levels.

Per-table overrides work identically across connectors. The "table" name is whatever the connector uses for a logical unit — table for SQL, collection for MongoDB, index for Elasticsearch, class for Weaviate, label for Neo4j, namespace+index for Pinecone. The connector's schema discovery surfaces these names in the standard tables[] shape.

What's different per family

Each family has quirks worth knowing:

• Relational (Postgres, MySQL, Oracle) — full DML and DDL surface. Multi-statement queries are blocked at the connector level, even when the safety pipeline would allow the underlying ops. DDL requires the A access level.
• Cassandra — CQL is SQL-like but not full SQL. The connector excludes system keyspaces (system, system_auth, etc.) from schema discovery to avoid noise.
• Document (MongoDB, CouchDB) — query language is JSON with an operation field. MongoDB blocks pipeline stages $out and $merge at the connector layer (these write data even on a read pipeline). System databases are excluded.
• Search (Elasticsearch, OpenSearch) — query body is the standard Query DSL. The connector filters out system indices (.kibana, .security, apm-*, metrics-*, etc.) by default.
• Vector (Weaviate, Qdrant, Milvus, Pinecone) — queries use an intent-based JSON shape ({"intent": "search", "vector": [...], ...}). Each connector's intents differ slightly; see per-connector pages.
• Graph (Neo4j) — Cypher. Schema discovery enumerates labels and their properties.
• Cloud (DynamoDB) — verb-based JSON ({"verb": "Scan", "TableName": ...}) or PartiQL strings. AWS auth is via the SDK credential chain.

Adding a new database

The interactive wizard prompts for the connection details specific to whichever connector type you pick:

faz add-database

uv run faz add-database

python -m faz add-database

It asks for the connector type, then walks through host / port / database / credentials / any connector-specific extra keys, and appends the entry to faz.yaml. Comments and existing entries are preserved.

To add a connection by hand, copy the example from the relevant connector's page and edit the fields.

After adding, restart faz serve (or your MCP client, which respawns the stdio server) so the new connection initialises. faz policy confirms the database appears in the loaded config; faz test confirms it's reachable.

When a connector isn't on this list

faz currently supports 14 connectors, all listed above. If you need something else (Snowflake, BigQuery, Redshift, Redis, etc.), the answer today is to use one of:

• Postgres-compatible proxy — Snowflake, Redshift, and BigQuery all support Postgres-wire protocol via various proxies. Configure the connection in faz.yaml as type: postgresql against the proxy.
• REST API — for databases that expose a REST surface, you can build a thin app-level wrapper, but this gives up faz's safety pipeline.

A native connector for a new database is a manageable change: create a new file under src/connectors/ implementing BaseConnector, register it in __init__.py, add the ConnectorType value, and the safety pipeline picks it up automatically. See the connector source for the existing 14 implementations as references.

Related

• faz.yaml — the schema reference for databases: entries.
• Permissions — how access codes apply across connectors.
• Permission levels — the per-language operation mapping.
• faz add-database — the interactive wizard.