It's currently impossible to run more than one synchronized pi-hole instance in a network. Running a single pi-hole instance in a network with hundreds of clients is not fault tolerant. Unexpected failures or even planned updates cause disruption. Running multiple instances requires additional logi…

Currently, pihole-FTL's in-memory and SQLite's persistent database are tightly coupled. AFAIAAO, that involves some custom C code for SQLite. I'm not sure how other DB engines would allow that kind of integration (if at all), and whether our development team would be able and willing to dedicate r…

I appreciate your response. Alternatively, a project like dqlite might satisfy both parties.

Even if we allow the use of an external database (which would not be a simple change), you would still need different databases for different Pi-holes. Currently there is no way no aggregate data from multiple Pi-holes without completely mixing the records (there is no way to differentiate records …

[image] max06: It's currently impossible to run more than one synchronized pi-hole instance in a network. That's not an accurate statement. There's a few users that run Pi-hole on kubernetes very successfully. I think you'd get a better, and quicker, response by contacting the helm chart ma…

[image] To use MySQL as database Feature Requests I see, there is also a INET6_ATON so this may even be feasible. I'm still concerned about performance as every DNS lookup has to interact with the database (checking if it is in gravity, the white- or blacklist)…

[image] rdwebdesign: (there is no way to differentiate records between Pi-hole A and Pi-hole B) Not sure why that would be necessary? [image] DanSchaper: Don't use one sqlite database for multiple Pi-hole instances. Besides the current locking issues - why not? All resolvers should ha…

[image] max06: Besides the current locking issues - why not? All resolvers should have the same data, no matter which one I'm talking to. No, each resolver is going to have different queries from different clients. No client is going to ask every DNS server it can for a query resolution. […

[image] max06: Not sure why that would be necessary? Without that there will be no way to show a valid query log. The clients in Pi-hole A will have IDs, but there is no way to guarantee the same clients will have the same IDs on Pi-hole B. The same is true for Lists, Domains, and any other …

[image] DanSchaper: No, each resolver is going to have different queries from different clients. No client is going to ask every DNS server it can for a query resolution. I'm sorry, but this makes no sense to me. Usually 2 dns resolvers are propagated via dhcp in a network(-segment). Clients…

Currently (without a massive FTL rewrite) there will be ID=1 from Pi-hole A and ID=1 from Pi-hole B. To increase performance, most of the data related to DNS queries is initially stored in a "in-memory" database. The local "in-memory" database will never be able to communicate to the other Pi-hole …

Add support for external databases

Feature Requests

DanSchaper July 8, 2025, 5:38pm 6