A database engine for each kind of workload
Choosing a database engine is a decision you live with for years, so it helps to have options under one roof. PostgreSQL for transactions, MariaDB for classic web applications, ClickHouse for analytics, MongoDB for documents and Redis for caching. They run on VPS or dedicated servers in Frankfurt, so the data sits physically inside the EU. Dedicated servers carry a 99.99 % SLA, Romanian VAT is shown separately on every invoice, and a data processing agreement under GDPR Article 28 is available. You can administer the engines yourself or hand the operations side to our DevOps team.
Relational engines: PostgreSQL and MariaDB
PostgreSQL
The usual starting point for SaaS and fintech back ends. JSONB for semi-structured data, pgvector for embeddings, declarative partitioning, logical replication and hot standby. We tune parallel query, JIT and replication slots to the workload in front of them.
MariaDB
MySQL-compatible and light on resources, which makes it the natural home of WordPress, WooCommerce, Magento and other LAMP applications. ColumnStore covers mixed OLTP and analytical needs, and MaxScale balances load between nodes.
Choosing between the two
For a new custom application, start with PostgreSQL. Pick MariaDB when your application or CMS expects MySQL, and move to PostgreSQL later only if you hit a feature it lacks.
Analytics with ClickHouse
When reports begin to scan billions of rows, a transactional database is the wrong tool. ClickHouse is a column-oriented database built for analytical queries: it reads only the columns a question needs and compresses them well. It suits logs, metrics, event tracking, business intelligence and live dashboards. It is hungry for memory, so we usually start it on a VPS with 32 GB of RAM or more. A common pattern is PostgreSQL for the application and ClickHouse for reporting, fed by replication, which our DevOps team can build for you.
NoSQL and caching: MongoDB, Redis and Memcached
MongoDB
A document database for flexible schemas: content management, IoT telemetry, real-time analytics. Replica sets and sharding are available, and time-series collections suit metrics.
Redis
An in-memory store for caching, queues and pub/sub. Once a web application serves a steady stream of requests, a cache in front of the database is usually the cheapest speed-up. Redis Streams, RedisJSON and RediSearch modules are available.
Memcached
A plain key-value cache. Simpler than Redis, a good fit for session storage and light page caching, and very quick on simple operations.
Moving a database from another provider
People ask three things before a move: how long it takes, whether the site goes down and whether any data gets lost. We plan around those questions. For large databases the usual answer is logical replication, which keeps the new server in step with the old one until the moment you switch. Below are four common starting points, with the commands we typically begin from.
MySQL or MariaDB from shared hosting
A dump taken with --single-transaction avoids locking tables while the site keeps running. We import into the target with secondary indexes created at the end, which is the quickest way to load a large dump.
mysqldump --single-transaction --routines --events --hex-blob -h old-host -u app_user -p shop_db | gzip > shop_db.sql.gzPostgreSQL from a cloud-managed service
A custom-format dump from pg_dump can be restored in parallel, which shortens the job on a large database. For a cut-over with almost no downtime we create a logical replication slot and let the new server catch up first.
pg_dump -Fc -h old-host -U app_user -f shop.dump shop && pg_restore --jobs=4 -h new-host -U app_user -d shop shop.dumpMongoDB from Atlas or another platform
mongodump and mongorestore cover most databases. For very large datasets we rely on cluster-to-cluster synchronisation, which copies changes continuously so the final switch is short.
mongodump --uri="mongodb+srv://[email protected]/shop" --out=./dump && mongorestore --uri="mongodb://new-host:27017" ./dumpRedis from a hosted cache
A pure cache can simply start empty and warm up. If the data must survive, pull an RDB snapshot from the old instance, place it in the new data directory and start the server on it.
redis-cli -h old-host --rdb cache.rdbHigh availability: replicas and failover
One database server is one point of failure. For anything the business depends on we build replicated clusters, a primary with one to three replicas, and automatic failover where the engine supports it. We agree recovery time and recovery point objectives with you for each workload before go-live, instead of quoting one number for everything.
Primary and replicas
Writes go to the primary and reads spread across the replicas, so read capacity grows with every replica you add. Replication lag is monitored and alerts fire before it hurts.
Automatic failover
repmgr for PostgreSQL, MHA for MySQL-family engines and built-in elections for MongoDB. When the primary fails, a replica is promoted and applications reconnect to it.
One EU location
Servers are in Frankfurt, inside the EU.
Connection pooling
PgBouncer for PostgreSQL and ProxySQL for MariaDB let thousands of application connections share a small pool of real database connections, which protects memory on the server.
What the package includes
Backups you can restore from
Scheduled full backups plus WAL or binlog archiving for point-in-time recovery, so you can return to a chosen moment instead of last night. Copies can be kept in the second EU data centre, and we restore them on a staging server to prove they work.
Replication and pooling
Logical or physical replication, between nodes. PgBouncer pools PostgreSQL connections, ProxySQL does the same for MariaDB, and MongoDB replica sets are planned from the start.
Tuning for your traffic
Parameters such as work_mem, shared_buffers, max_connections and innodb_buffer_pool_size are set from your workload rather than left at defaults, and reviewed again when your traffic changes.
Migration without drama
mysqldump, pg_dump and mongodump handle the copy, and logical replication keeps the old and the new database in step until you switch. Migration is free, and integrity checks run on the destination before cut-over.
Monitoring and alerts
Prometheus and Grafana track replication lag, connection counts, cache hit rates and disk growth, so a full disk or a lagging replica reaches you as an alert and not as an outage.
DevOps hours for the database
Every plan carries monthly DevOps hours: 1 h from cPanel Advanced up, 1–8 h on VPS, 5–10 h on dedicated servers depending on plan. Spend them on tuning, upgrades or restore drills. You request them from the client panel; hours are not carried over, and extra hours are billed separately.
GDPR for databases that hold personal data
A database is where most personal data ends up: e-mail addresses, phone numbers, IP addresses, order histories. Compliance comes down to encryption, auditability and retention, and all three can be handled at the database layer. The hardening and compliance service, which your included hours can cover, does that work with you.
- Encryption at rest on the disk (LUKS) and in transit with TLS
- Column-level encryption for fields such as a Romanian CNP or a phone number, using pgcrypto or Vault Transit
- An audit trail of DDL and DML that shows who changed what and when, through pgaudit, MySQL audit plugins or MongoDB auditing
- Retention rules that delete data automatically after a set period, for example ten years for accounting records if that is your policy
- Role separation and least-privilege access, with secrets kept out of application code
- A data processing agreement under GDPR Article 28, standard contractual clauses where data leaves the EU, and technical documentation for audits
- Our controls are aligned with ISO 27001, which is alignment and not a certificate
Database hosting questions we hear most
Can you run the database for us?
Yes. Through the DevOps service we handle setup, tuning, backups, replication and security updates. Your included monthly hours cover part of that work, larger or continuous engagements are agreed separately, and extra hours are billed separately.
How large can a database be on a VPS?
It depends on the plan and on the access pattern. As a rough guide, 200 to 300 GB is comfortable on a 32 GB VPS and around 1 TB on a 64 GB one. Beyond that a dedicated server with NVMe drives in pairs is the better foundation. PostgreSQL and MariaDB both scale to several terabytes on one node when the hardware keeps up.
Can you move our database from a cloud provider?
Yes, from AWS RDS, Azure Database, Google Cloud SQL, Heroku Postgres and MongoDB Atlas, among others. Logical replication usually gives a switch with little or no downtime. Migration is free, and we plan the cut-over with you.
When do I use ClickHouse and when PostgreSQL?
PostgreSQL is transactional: fast writes, ACID guarantees, the right base for an application. ClickHouse is analytical: quick aggregations over billions of rows. Many teams use both, keeping transactions in PostgreSQL and replicating the data into ClickHouse for reporting.
Are the backups actually tested?
A backup that has never been restored is a hope, not a backup. Restore tests belong to the service: we restore a backup onto a staging server and compare the result with the source, and a report can be sent to you by e-mail.
Where are the servers located?
In Frankfurt, inside the EU. If your policy requires one specific location, tell us when you order and we will confirm what is available. Support answers in English and Romanian.
Choose the right database for your application
Not sure which engine suits your workload? Write to us and we will help you design the architecture before your first invoice. For larger databases we also plan the move from your current provider with you.
Contact us →