Performance benchmark of the Always confidential database feature - ApsaraDB RDS

These sysbench benchmark results cover three encryption scenarios for the Always confidential database feature, so you can estimate the performance overhead before choosing an encryption strategy.

Key takeaway: Encrypting only sensitive columns (not the primary key) keeps performance overhead under 22% across all workload types. Encrypting all columns — including the primary key — raises overhead to approximately 59–84%, because every index lookup requires additional Intel Software Guard Extensions (SGX) enclave operations.

These results apply only to RDS instances in the security-enhanced instance family. Instances in other families do not support the Always confidential database feature.

Test environment

Configuration item	ECS instance (test client)	RDS instance
Region and zone	Shanghai Zone L	Shanghai Zone L
Network type	Virtual private cloud (VPC)	VPC (same VPC)
CPU cores and memory	64 cores, 128 GB	32 cores, 64 GB
Instance family	Compute-optimized Type c7	Security-enhanced instance family
Instance type	ecs.c7.16xlarge	pg.x2t.4xlarge.2c
Storage type	Enhanced SSD (ESSD)	PL1 ESSD
OS / engine version	Alibaba Cloud Linux 3.2104 64-bit	PostgreSQL 13 (minor version: 20230830)

Both the client and the RDS instance are in the same region, zone, and VPC to minimize network latency as a variable.

Test tool

All tests use sysbench, a modular, cross-platform, multi-threaded benchmark tool for evaluating database performance under load.

Performance metrics

Metric	Definition
TPS (transactions per second)	Number of transactions successfully committed per second
Average latency	Average time to execute a transaction, in milliseconds

Test schema

sysbench uses the following default table schema:

CREATE TABLE test1(
  id INTEGER NOT NULL,
  k INTEGER DEFAULT '0' NOT NULL,
  c CHAR(120) DEFAULT '' NOT NULL,
  pad CHAR(60) DEFAULT '' NOT NULL,
  PRIMARY KEY (id)
);
CREATE INDEX k_1 on test1(k);

Test procedure

Prerequisites

Before you begin, ensure that you have:

A PostgreSQL client installed on the ECS instance. See PostgreSQL download page.
An RDS instance in the security-enhanced instance family.

Run the benchmark

Connect to the RDS instance from the PostgreSQL command-line tool (CLI):
To get the endpoint and port, see View and change the internal and public endpoints and port numbers of an ApsaraDB RDS for PostgreSQL instance. To get the username, see Create an account. Alternatively, use Data Management (DMS) to connect from the ApsaraDB RDS console.
```
psql -h <endpoint> -U <username> -p <port> -d postgres
```
Create a test database:
```
CREATE DATABASE testdb;
\c testdb
```
Create an encrypted table. Two DDL variants are tested — see Test scenario 1 and Test scenario 2 for the specific statements.

Load test data with sysbench. This test uses 32 tables, each with 1,000,000 rows:

sysbench --db-driver=pgsql \
  --pgsql-host=<database server host> \
  --pgsql-port=<database server port> \
  --pgsql-user=<database user name> \
  --pgsql-password=<database user password> \
  --pgsql-db=testdb \
  --auto_inc=false \
  --table_size=1000000 \
  --tables=32 \
  --threads=32 \
  --time=600 \
  --pg_use_encrypt=<true or false> \
  oltp_common prepare

Run the custom test script:

sysbench --db-driver=pgsql \
  --pgsql-host=<database server host> \
  --pgsql-port=<database server port> \
  --pgsql-user=<database user name> \
  --pgsql-password=<database user password> \
  --pgsql-db=testdb \
  --table_size=1000000 \
  --tables=32 \
  --threads=<thread count> \
  --time=600 \
  --report-interval=1 \
  --pg_use_encrypt=<true or false> \
  <lua script name> run

Clean up test data:

sysbench --db-driver=pgsql \
  --pgsql-host=<database server host> \
  --pgsql-port=<database server port> \
  --pgsql-user=<database user name> \
  --pgsql-password=<database user password> \
  --pgsql-db=testdb \
  --tables=32 \
  oltp_common cleanup

Each reported result is the average TPS and average latency across 10 runs of 10 minutes each. Results include client-side decryption overhead for returned fields. In each chart, the bar chart shows TPS and the line chart shows average latency.

Test scenario 1: Primary key not encrypted, other columns encrypted

In this scenario, id (the primary key) is stored as a plain integer — a common pattern when the primary key is an auto-increment field with no sensitive business meaning. The remaining columns are encrypted as sensitive data.

CREATE TABLE test1(
  id INTEGER NOT NULL,
  k enc_int4 DEFAULT '\xa509008855508aade16ec573d21e6aca47ab5e490d7044e748161a6635a5d939c5bbbee4' NOT NULL,
  c enc_text DEFAULT '\x9d39006e340b9cffb37a989ca544e69e6e9c0bdb0b6500a91dcc433dc5df0496' NOT NULL,
  pad enc_text DEFAULT '\x9d39006e340b9cffb37a989ca544e69e6e9c0bdb0b6500a91dcc433dc5df0496' NOT NULL,
  PRIMARY KEY (id)
);
CREATE INDEX k_1 on test1(k);

Test data

Point query performance

SQL template (100% of statements):

SELECT c FROM test1 WHERE id=?;

Table 1. Point query TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Performance overhead
8	46.99	39.94	15.0%
16	91.07	79.86	12.3%
24	132.78	117.64	11.4%
32	173.58	154.28	11.1%

Range query performance

SQL template (100% of statements):

SELECT SUM(k) FROM test1 WHERE id BETWEEN ? AND ?;

The default range query length is 100 rows.

Table 2. Range query TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Performance overhead
8	14.81	12.09	18.3%
16	28.88	23.22	19.6%
24	41.62	33.12	20.4%
32	54.27	42.48	21.7%

Write performance

SQL template mix (25% each):

UPDATE test1 SET k=k+1 WHERE id=?;
UPDATE test1 SET c=? WHERE id=?;
DELETE FROM test1 WHERE id=?;
INSERT INTO test1 (id, k, c, pad) VALUES (?, ?, ?, ?);

Table 3. Write TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Performance overhead
8	6.62	6.37	3.8%
16	11.36	10.91	4.0%
24	15.05	14.68	2.6%
32	19.13	17.74	7.3%

Conclusion

Performance overhead is low across all workload types: 11–22% for reads, under 8% for writes. This is the recommended encryption strategy for most use cases.

Test scenario 2: All columns encrypted

In this scenario, the primary key column id is also encrypted. Every index lookup must pass through SGX enclave operations to resolve the encrypted primary key, adding overhead on top of the client-side decryption cost from scenario 1.

CREATE TABLE test1(
  id enc_int4 NOT NULL,
  k enc_int4 DEFAULT '\xa509008855508aade16ec573d21e6aca47ab5e490d7044e748161a6635a5d939c5bbbee4' NOT NULL,
  c enc_text DEFAULT '\x9d39006e340b9cffb37a989ca544e69e6e9c0bdb0b6500a91dcc433dc5df0496' NOT NULL,
  pad enc_text DEFAULT '\x9d39006e340b9cffb37a989ca544e69e6e9c0bdb0b6500a91dcc433dc5df0496' NOT NULL,
  PRIMARY KEY (id)
);
CREATE INDEX k_1 on test1(k);

Test data

Point query performance

SQL template (100% of statements):

SELECT c FROM test1 WHERE id=?;

Table 4. Point query TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Performance overhead
8	46.99	18.31	61.0%
16	91.07	35.66	60.8%
24	132.78	49.85	62.5%
32	173.58	63.34	63.5%

Range query performance

SQL template (100% of statements):

SELECT SUM(k) FROM test1 WHERE id BETWEEN ? AND ?;

The default range query length is 100 rows.

Table 5. Range query TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Performance overhead
8	14.81	2.83	80.9%
16	28.88	5.52	80.9%
24	41.62	7.12	82.9%
32	54.27	8.71	84.0%

Write performance

SQL template mix (25% each):

UPDATE test1 SET k=k+1 WHERE id=?;
UPDATE test1 SET c=? WHERE id=?;
DELETE FROM test1 WHERE id=?;
INSERT INTO test1 (id, k, c, pad) VALUES (?, ?, ?, ?);

Table 6. Write TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Performance overhead
8	6.62	2.67	59.7%
16	11.36	4.62	59.3%
24	15.05	5.92	60.7%
32	19.13	7.04	63.2%

Conclusion

Overhead is approximately 59–84% across all workload types (59–63% for writes, 61–84% for reads). The primary driver is the encrypted primary key: index lookups on an encrypted column require additional SGX enclave calls to compare ciphertext values, which compound with the client-side decryption cost from scenario 1. Avoid encrypting the primary key unless your compliance requirements specifically mandate it.

Test scenario 3: Non-primary key column queries

This scenario measures query performance when filtering on the non-primary key column k (which is encrypted), using the same table schema as scenario 2. It also shows the effect of the encdb_btree extension, an Alibaba Cloud extension that improves ciphertext index performance.

Test data

Point query performance

SQL template (100% of statements):

SELECT c FROM test1 WHERE k=?;

Table 7. Point query TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Feature enabled + encdb_btree
8	47.27	18.49	27.86
16	90.41	35.85	54.40
24	132.66	49.97	78.21
32	172.96	63.32	99.38

Range query performance

SQL template (100% of statements):

SELECT SUM(k) FROM test1 WHERE k BETWEEN ? AND ?;

The default range query length is 100 rows.

Table 8. Range query TPS (×1,000)

Concurrent threads	Feature disabled	Feature enabled	Feature enabled + encdb_btree
8	14.97	2.83	7.80
16	28.89	5.53	15.20
24	42.38	7.15	20.09
32	54.80	8.75	24.86

Conclusion

Query performance on encrypted non-primary key columns is similar to the all-columns-encrypted scenario (scenario 2). The encdb_btree extension partially recovers throughput — roughly 1.5× to 1.6× improvement over the encrypted baseline for point queries. For queries on encrypted non-primary key columns, install and enable the encdb_btree extension.

Recommendations

Encrypt only sensitive columns, not the primary key. This keeps performance overhead within an acceptable range (under 22% for reads, under 8% for writes) while still protecting sensitive data.

If your schema requires queries on encrypted non-primary key columns, use the encdb_btree extension to improve ciphertext index performance.

ApsaraDB RDS:Performance testing reports of the Always confidential database feature

Test environment

Test tool

Performance metrics

Test schema

Test procedure

Prerequisites

Run the benchmark

Test scenario 1: Primary key not encrypted, other columns encrypted

Test data

Conclusion

Test scenario 2: All columns encrypted

Test data

Conclusion

Test scenario 3: Non-primary key column queries

Test data

Conclusion

Recommendations

Related topics