<snip>an no database abstraction alyer is *really not* the performance problem to excuse a "vendor-lockin" or to say it in other words: if you start these days a proect and the frist decision you make is what RDBMS you will use your whole software design is broken from that moment
Again, we'll see where we'll go with the GreyLSE, and also strongly considering community requests (if they are some); That's the minimum for an open source tool.
But consider that for now, this is developped according the needs of ISPs, with the ISP's environment, type of load, constraints, with all intelligence deported to the database using SQL stored procedures and so on. And the best DB candidate for that was PostgreSQL, an enterprise class DB engine, classified in the challengers box of the gartner Quadrant, where we even don't see MySQL :) My 2 cents in the coffee machine...
For now, the GreyLSE is highly scalable in its experimental version, at first view it can process considerably more requests than GLD or Postgrey are able to do, furthemore with additional features and good integration and user-interaction if Web UI are used.
What I also repeat is that all options remain open. But you cannot have stored procedures in BDB or other "lightweight" DB backends. So, an orientation has been decided (and of course other futur orientations can lead to other versions of the GreyLSE), and again, it's just needed to start somewhere and work on an orientation among others... I don't want to start a church war on this mailing list and that's not the goal, I presume, of this mailing list.
I've understood your point.
<<attachment: hahnn.vcf>>
