Performance Benchmarks

Zenifra does not currently publish official per-plan benchmark results. Performance numbers depend on the schema, indexes, data volume, number of connections, latency between the application and the database, and the engine version; the most reliable way to choose a plan is to measure your own workload.

The resources of each plan (vCPU, RAM, and price per instance) are listed in Database Plans.

How to measure in your project

1. Create a test database project on the plan you want to evaluate, preferably with hourly billing, and delete it when you finish.
2. Run the test from where your application will run, so network latency is realistic.
3. Use a data volume and connection count similar to production.
4. Run each test more than once and record version, plan, instance count, dataset size, connection count, and duration.

PostgreSQL with pgbench

pgbench ships with the official PostgreSQL client. Use the URI copied from the console and keep TLS validation (sslmode=verify-full):

# create the test tables (scale factor 10)
pgbench -i -s 10 "postgresql://app:<password>@<host>:<port>/app?sslmode=verify-full&sslrootcert=system"

# 60 seconds, 10 connections, 2 threads
pgbench -c 10 -j 2 -T 60 -P 10 "postgresql://app:<password>@<host>:<port>/app?sslmode=verify-full&sslrootcert=system"

The output shows transactions per second (tps) and average latency. To measure reads only, add -S. Drop the pgbench_* tables after the test.

For MariaDB, use an equivalent tool such as sysbench with a TLS connection.

During the test, watch CPU, memory, connections, locks, and latency in the database metrics, available on the db-premium and db-enterprise plans.

Factors That Affect Performance

1. Number of connections: many simultaneous connections can degrade performance
2. Indexes: queries without indexes are significantly slower
3. Dataset size: datasets larger than the plan memory rely more on disk
4. Network latency: the distance between the application and the database adds time to every query

Optimization Tips

• Use proper indexes for your queries
• For PostgreSQL with 2 or 3 instances, use the read-only URI for SELECT queries that tolerate a small replication delay
• Configure connection pooling in the application to control the number of connections
• Monitor the database metrics (db-premium and db-enterprise plans)