Assuming the DB code conforms to SQL standards and is reasonably well modularized, a port to the other, less publicized but more powerful open source SQL DB would be nice for those of us who don't see the point of running two SQL servers on one box. I've read some statements as well that Postgres is actually faster and more scalable than MySQL now in many situations; it would be interesting to see if a port to it would actually make Cacti faster.

I don't think it much matters if it is faster or more scalable. It comes down to what you need out of your database. If you need speed and a fashion of replicability they MySQL is most likely your choice. If you need the SQL whiz-bangs like stored procedures, views and outer joins. Then, PostgreSQL is most likely for you. (But what about SAP DB?)

If the SQL Schema was ported over to a PostgreSQL friendly format and Cacti was written using the Pear DB module then it would be trivial to "port" Cacti to using Postgres. I'd have to look at the code more to really tell this (I just installed Cacti without looking at it first).

The only reason to not use Postgres is that nothing in Cacti _requires_ advanced SQL whiz-bangs. And, by only developing for one database it speeds up the development because you aren't working around the limitation of making sure you work on both databases (if not more, Cacti works on winders too so why not use Access (.mdb) or MS SQL or <X database here>, or etc...).


There was also a post about using flat files to store the configuration details. This faces the same quandry of developing for two data storage modules. Perhaps if PHP supported making SQL queries against flat files in a user owned directory (this is possible as MySQL AB produces and embeded library for just this purpose). The Pear DB module would be extended to use the embedded MySQL versus a stand alone server. This functionality would serve more than just this purpose as many sites do not need a full blown database server for their database tasks. I know no site I have ever coded up justifies that horsepower. I've got a Ferrari pulling my cart of goods.

I do agree that the necessity of running MySQL when you are a PostgreSQL user is kind of a burden. I'd fall more to the flat file solution first though as Cacti doesn't have that many needs for a database.

I would actually be fairly surprised if cacti could work well with a flat file structure. If you take a look at the code sometime (and even more so with 0., it is highly interwoven with SQL. Unless the PHP could create a near SQL92 compliant flat file interface, I doubt it would scale.

About the use of other SQL implementations, this *is* coming. In fact version 0.8 already makes use of ADODB. A friend of mine and I were working on porting the schema to MSSQL, but the cacti's code still needs some work. There are many places where I am directly referring to a MySQL function, which have to be replaced with their ADODB equivalents. Once that is out of the way, you should be able to use cacti with PostgreSQL, Access, MSSQL, MySQL, Oracle... the works

-Ian

After taking a look at the code I can see that you make use of MySQL everywhere. But, I wasn't thinking that you interface flat files directly. I've been thinking that using this <a href="http://www.mysql.com/doc/en/libmysqld_overview.html">embedded MySQL library</a> in PHP would be a boon. You can make SQL queries against InnoDB files without needed to run a server. I'm not clear on how you would switch between this library and the client library in your apps (perhaps by making it a different set of functions). This is only in their latest 4.0 releases and I'm sure PHP doesn't support this. Hopefully PHP5 will catch on to this and include support for it.

At the time being, this isn't feasable for Cacti but when MySQL 4 is more widely distributed I hope people take advantage of this (specifically Perl and PHP: Are you guys listening? )

Glad to hear that you are doing some database abstraction. Cacti rocks, I just wish I knew more about RRDtool.

Can anyone say how far off Cacti is from supporting other database backends? The only threads I found on this topic where pretty old. There is meantion by Rax in this thread that he is working on it, just wondered if we could get an update? Thanks so much. I plan on migrating to cacti this coming week, so I am trying to figure out if I should keep my Postres stuff separate, or if Cacti may support it, and I could use the Postgres server for everything. Thats again.

Cacti only supports mysql at this point.

Version 0.9.1ish, will have multiple database support. Unless we have enough time then it might make it into 0.9.0 release by the end of the year. It is coming, just not in the next major release, but we are making great inroads to supporting it.

Planed database support is: Postgres, MSSql, and Oracle.

Although, we are going to try to make cacti generic enough to use almost any database, we have to limit what we will support.

Thank you very much for getting back to me. I am very happy that support is forthcoming for Postre. I suspect that migrating to from MySQL to Postre my take some doing, but it would be great to only have one database to manage. Thanks again.