# Is this Postgres only?

*Published on 2026-10-13T00:00:00.000Z*

*By CipherStash Team*

For searchable encryption, yes. EQL installs into any Postgres you can connect to, with no extension, no superuser and no config changes. DynamoDB gets encryption plus equality lookups. On MySQL, MongoDB and anything else the SDK still encrypts and decrypts, but nothing is queryable on the server.

## Content

If your queries have to run inside MySQL or MongoDB, we do not solve that today, and we are not going to give you a date. The SDK will encrypt the values and you can store them anywhere, but the database cannot filter, sort or join on them.

## What "any Postgres" means

EQL is a set of SQL types and functions, not an extension. The installer runs over an ordinary database connection. It needs `CREATE` on the database and schema, not superuser, and it makes no changes to `postgresql.conf`. The docs list Supabase, Prisma Postgres, Neon, RDS, Aurora, Cloud SQL and self-hosted Postgres.

The one place managed Postgres differs from self-hosted is block ORE. Its operator class is hand-written for a composite type and needs superuser to create. On cloud Supabase and most managed Postgres the installer detects this and disables the ORE-backed domains. Ordering and range still work, because the default ordering term is CLLW OPE and its index works anywhere you can run `CREATE INDEX`.

## Supabase

With EQL 3.0.4 the Supabase wrapper supports encrypted equality, range and ordering through supabase-js. Free-text and JSON queries need an adapter such as Drizzle or Prisma ORM 8, because PostgREST cannot express the typed operands those operations require. You also expose the `eql_v3` schema in the Supabase dashboard.

## DynamoDB

DynamoDB does not use EQL. Equality-enabled attributes store an HMAC search term next to the ciphertext, and that term can be a partition key, a sort key or a global secondary index. That gives you exact lookups. It does not give you `begins_with`, `BETWEEN` or `contains` on encrypted attributes, and ordering and free-text terms are not stored because DynamoDB has no query surface for them.

## Everything else

MySQL, MongoDB, ClickHouse, Snowflake and S3 are all fine as places to put ciphertext. The SDK encrypts in your process and hands you a payload. What you lose is server-side querying.

## Technical evidence

- [Choose your stack: database matrix](/docs/get-started/choose-your-stack)
- [EQL reference: install and permissions](/docs/reference/eql)
- [EQL core concepts: OPE default, ORE and the superuser caveat](/docs/reference/eql/core-concepts)
- [Supabase integration](/docs/integrations/supabase)
- [DynamoDB integration](/docs/integrations/aws/dynamodb)

## Related notes

- [What can we still query once it's encrypted?](https://cipherstash.com/notes/what-can-we-still-query-once-its-encrypted.md) — Equality, text match, ordering and range, and JSON paths, each with an index type you opt into per column. Not arithmetic aggregates, not regex, not LIKE.
- [Do we have to put a proxy in front of our database?](https://cipherstash.com/notes/do-we-have-to-put-a-proxy-in-front-of-our-database.md) — No. The default is the Stack SDK in your application, on the Postgres connection you already have. Proxy is the alternative for applications you cannot change.