关于MSSQL、PostgreSQL等数据库支持同态加密查询的技术问询

Great question—homomorphic encryption (HE) for database queries is a key area for privacy-preserving data processing, so let's break down where each database stands, plus clear up a common misunderstanding you noted:

MSSQL #

• You referenced Always Encrypted—it’s critical to clarify this is not homomorphic encryption. Always Encrypted uses deterministic or randomized column-level encryption, which only supports limited operations like equality checks (for deterministic encryption) on encrypted data. It cannot perform arithmetic operations, joins, or complex queries on encrypted values—something true HE enables.
• As of today, neither on-premises MSSQL nor Azure SQL has native support for fully homomorphic encryption (FHE) or somewhat homomorphic encryption (SHE) for query execution. There are limited secure computation preview features in Azure, but these don’t equate to full HE query capabilities in the core database engine.

PostgreSQL #

• CryptDB is indeed unmaintained (last updated in 2019) and wasn’t a true HE solution—it relied on order-preserving encryption and other lightweight techniques to mimic basic query functionality, not actual homomorphic operations.
• Native PostgreSQL has no built-in HE support. The pgcrypto extension handles standard encryption (AES, RSA, hashing) but doesn’t support HE-based querying.
• For your university project, you can explore open-source research extensions or build custom user-defined functions (UDFs) that integrate mature HE libraries like Microsoft SEAL or TFHE. These UDFs can offload HE computations to external logic while interacting with the PostgreSQL database.

MySQL & MariaDB #

• Neither database has native homomorphic encryption support for query execution. As you noted, CryptDB was the most prominent third-party tool for MySQL, but it’s long deprecated and not suitable for modern use cases.
• MySQL’s built-in encryption features (like Transparent Data Encryption, column-level encryption) only protect data at rest or in transit—they don’t enable querying encrypted data via HE operations.
• For your project, similar to PostgreSQL, you’ll need to build a custom layer: either integrate an HE library via stored functions, or create a middleware service that handles encryption, HE query processing, and decryption outside the database itself.

Practical Tips for Your University Project #

• Start with a mature, well-documented HE library like Microsoft SEAL (it has great C#/C++ support, which pairs well with MSSQL or PostgreSQL via UDFs) or TFHE (for faster FHE operations).
• Focus on a narrow use case first (e.g., encrypted sum or average queries) before tackling complex operations—this will make prototyping easier.
• Look into academic papers or open-source university prototypes that demonstrate HE integration with relational databases; many share code you can adapt for your project.

内容的提问来源于stack exchange，提问作者TalG