Running the VICIdial database on its own server
Splitting MySQL onto a dedicated database server frees the telephony box for Asterisk and opens the door to replication. Here is when and how to do it.
On a single VICIdial box, MySQL and Asterisk fight for the same CPU and disk. The database handles every screen pop, every disposition write, and a constant stream of dial-log inserts; Asterisk handles the live audio. At low volume they coexist fine. Past a few thousand calls an hour, moving MySQL onto its own server is the cleanest way to give each one room to breathe.
A dedicated database server is exactly what it sounds like: one machine that runs only MySQL or MariaDB, with the telephony boxes pointing their connections at it over the private network. The dialer keeps Asterisk, the web admin, and the dialer-control processes. The DB box keeps the data.
Why split it out
Three reasons. Database load stops stealing cycles from call audio, so you avoid the choppy-audio failure mode that shows up when MySQL is busy writing logs during a dial spike. You can size the DB box for IO and memory without overpaying for telephony-grade CPU. And once the database lives apart, you can add a replica for read scaling and Failover, which a combined box makes awkward.
flowchart TD
W[Web admin] --> DB[Dedicated DB server]
T1[Telephony node 1] --> DB
T2[Telephony node 2] --> DB
DB -->|replication| R[Read replica]
R --> REP[Reporting and backups]How the wiring changes
VICIdial reads its database connection from a config file on each telephony node and from the server entry in the admin. You point both at the DB server's private IP, grant the VICIdial user access from each node's address, and make sure the private network between them is fast and low-latency. Keep the database off the public internet entirely. The telephony processes — the predictive dialer, the Keepalive scripts, the AMI (Asterisk Manager Interface) listeners — all talk to that one DB endpoint instead of localhost.
This is a cluster pattern. A single combined box never needs it. If you are deciding between one box and several, the single server versus cluster post walks the trade-offs, and the broader VICIdial install guide shows where the database role sits in the overall layout.
The cost of splitting
A separate DB box adds a hop. Every query now crosses the network instead of hitting a Unix socket on localhost, so the private link has to be quick or agent screens feel sluggish. It is also one more machine to patch, monitor, and back up. For most operators under a few telephony nodes, a single well-sized box with fast NVMe disk handles MySQL and Asterisk together without complaint. Split only when you have measured contention, not on a hunch.
Where managed hosting lands on this
VICIfast runs Single tenant VPS boxes — one customer, one server, database and Asterisk together, which is the right shape for the vast majority of dialing operations. We provision that box in under 40 seconds. Because you keep root SSH on a Managed hosting plan, a self-host-style DB split is yours to build if you genuinely outgrow a single box and want to run your own cluster. Most teams never need to.
Start with one box, watch the load, and split the database only when the numbers say so. Compare server sizes on our pricing page to pick a box with the headroom to delay that decision a long time.
About VICIfast LLC
VICIfast LLC operates a managed VICIdial hosting + BYOI service for outbound and inbound call centers. We run the dialers, the carriers, the recordings pipeline, and the compliance plumbing so operators don’t have to.
Citing this article
VICIfast Engineering. “Running the VICIdial database on its own server”. VICIfast LLC, June 29, 2026. Retrieved from https://vicifast.com/blog/vicidial-database-server-separate
Have questions?
Related posts
You might be interested in
VICIfast newsletter
Liked this? Get the next one in your inbox.
We ship the kind of stuff you just read — concrete, numbers-first, no drip. One email when a new post goes live. Unsubscribe in one click.
Comments
No comments yet — be the first.