I use PostgreSQL a lot but these benchmarking results surprise me. MySQL is often much faster than PostgreSQL and SQLLite is several times faster than MySQL.
What matters to me is how fast they work with Python, or in particular Zope. I need to make my own benchmark of MySQL and PostgreSQL with Zope and all the various database adapters.
The reason I moved from MySQL to PostgreSQL was partly because PostgreSQL has more enterprise features and that my colleges use PostgreSQL. But I suspect that for many of my projects I never even use these features.
Then I also found this from a Zope mailing list:
>The speed comparisions with PostgreSQL are very much an apples vs. fish
>sort of thing: the pgsql server was not tuned at all, and does a whole
>lot more that was never tested, such as multi-user writer access.
I'd take that with as much seriousness as someone on a postgresql list talking about the speed of the ZODB...
'speed'? 'zodb'? ;)
Try using the mysql 'innodb' engine instead of myisam.. you'll see a performance difference (see mysql.com for details on why they are different).
I should've added to the previous comment - this will compare properly to postgresql. comparing myisam tables to postgresql won't tell you anything - they are completely different.
the innodb engine on the other hand supports row level locking which means count(*) type queries can't use the table metadata (like a myisam table can).
The post is on target. For most projects, one should concentrate on the code more than the data persistance issues. For speed and convenience, SQLite takes the cake. To concentrate on Python code, one could for example use y_serial http://yserial.sourceforge.net which has an elegant interface for quick development.
If you benchmarked your postgresql install out of the box, yes, it's going to have horrid scores. You've got to change the out of the box settings and tune it.
Please keep thowring these posts up they help tons.
Times are cahngnig for the better if I can get this online!
I wonder how ill informed some of ðe commenters can be.
Ðe consensus from real hackers is ðat code matters much leß ðan data acceß:
git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful [ ] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. TORVALDS, Linus, 2006 jul 27 16h 41min 20s UTC, http://article.gmane.org/gmane.comp.version-control.git/24298
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I wont usually need your flowcharts; theyll be obvious. BROOKS JR, Fred. P. Ten pounds in a five-pound sack: Representation is the essence of programming, in The Mythical Man-Month: Essays on software engineering. 1st. ed. Reading, MA, USA: Addison-Wesley, 1975; cap. 9, pp. 1023; ISBN 0-201-00650-2.
Ðat said, even in performance SQLite or MySQL cannot even compare to PostgreSQL in any but ðe most simplistic benchmark. Anyþing; involving; concurrency, high loads or volumes will bring boþ SQLite and MySQL to ðeir knees.