HALIT
ALPTEKIN
HOMEWHOAMIRESEARCHPROJECTS
POSTS
hblog-ng v0.1.0
RX:0 B/s
TX:0 B/s
Cover
PROJECT
/2026/ACTIVE/

Opaquedb

A post-quantum private database that runs SQL over encrypted data without learning what you asked for.

KEYWORDS:
+9
#c-plus-plus#cmake#database#etcd#grpc#private-information-retrieval#ring-lwe#seal#sql
SOURCE
Opaquedb is a distributed #database that answers #sql queries without ever learning the value you searched for. It grew out of the argument in Privacy in the Post-Quantum Era: the post-quantum migration secures the channel, but it does nothing for query privacy. The operator answering your request still sees exactly what you asked for. This is the part that keeps the query itself hidden, even from the server running it.
The shape is simple from the outside. A client encrypts the value it is looking for under its own key. The server evaluates the match over encrypted data and hands back an encrypted result that only the client can decrypt. The operator runs the query but never sees the query value or the secret key.
Loading diagram...

How it works

Under the hood it is a computational #private-information-retrieval system built on Microsoft #seal using the BFV scheme. Privacy rests on #ring-lwe, a lattice assumption with no known quantum attack, so the system is quantum-safe by construction rather than by a later upgrade.
The matcher compares the encrypted query against stored values as a bit-sliced equality packed across SIMD slots. The whole query travels as a single ciphertext, and the cost of a match stays close to one linear scan of the data regardless of how many rows there are. This builds on a technique from Intrusion detection over encrypted network data, a paper on running detection directly over encrypted traffic.
A coordinator fans the encrypted query out to every shard, sums the encrypted partials they return, and gives one encrypted result back to the client. The client is the only party that can decrypt it. Sharding exists to spread the linear scan across machines, not to spread trust: the whole cluster is one trust domain, so there is no non-collusion assumption to make between servers.

Using it

A table is plain SQL, with one searchable key and any number of searchable indexes:
sql
CREATE TABLE weather (
  id          INT  KEY,
  city        TEXT INDEX,
  country     TEXT INDEX,
  temperature INT,
  humidity    INT,
  conditions  TEXT INDEX
);
A private lookup reads like an ordinary query, except the operator never learns the value in the WHERE. A no-match comes back as an encrypted empty result, so the server cannot tell whether you hit anything:
text
$ opaquedb query 'SELECT city, temperature FROM weather WHERE country = "JP"'
 city  | temperature
-------+-------------
 Tokyo | 27
The matcher also handles inequality, a set of values in one round trip with IN, and an exact private COUNT(*), all at the same cost and all hiding the value:
text
$ opaquedb query 'SELECT temperature FROM weather WHERE city IN ("Tokyo", "Cairo", "London")'
$ opaquedb query 'SELECT city FROM weather WHERE conditions <> "Sunny" LIMIT 3'
$ opaquedb query 'SELECT COUNT(*) FROM weather WHERE conditions = "Sunny"'

The stack

It is written in #c-plus-plus and built with #cmake. Encryption is Microsoft #seal with the BFV scheme. Nodes talk over #grpc, and an #etcd cluster handles membership and leader election so the coordinator can find its shards. The client ships with an interactive REPL for running queries by hand.
Computing under encryption is fundamentally heavier than computing in the clear, and every query is a full linear scan over the data. You are buying privacy with performance, so this is for the cases where the question is more sensitive than the answer, not for a general-purpose store.
The docs at docs.opaquedb.io carry the detailed and up to date picture: what the encrypted matcher currently supports, how to run a cluster, and where the project is headed.

Related Nodes

blog
2026
Privacy in the Post-Quantum Era

Privacy is the half of the post-quantum shift no one is fixing, and fully homomorphic encryption is the answer.

+8
#differential-privacy#fully-homomorphic-encryption#k-anonymity#post-quantum-cryptography#privacy#private-information-retrieval#ring-lwe#tokenization
research
2020
Intrusion detection over encrypted network data

A protocol for privately evaluating detection models on system data using lattice-based cryptography to protect both data and model privacy.

+8
#cryptography#fhe#lattice-based#pii#privacy-preserving#seal#soc#threat-intelligence
Mermaid Diagram
Rendering diagram...
CREATE TABLE weather (
  id          INT  KEY,
  city        TEXT INDEX,
  country     TEXT INDEX,
  temperature INT,
  humidity    INT,
  conditions  TEXT INDEX
);
$ opaquedb query 'SELECT city, temperature FROM weather WHERE country = "JP"'
 city  | temperature
-------+-------------
 Tokyo | 27
$ opaquedb query 'SELECT temperature FROM weather WHERE city IN ("Tokyo", "Cairo", "London")'
$ opaquedb query 'SELECT city FROM weather WHERE conditions <> "Sunny" LIMIT 3'
$ opaquedb query 'SELECT COUNT(*) FROM weather WHERE conditions = "Sunny"'