"Only support for SQLite (at the moment)"

This makes me skeptical. There's always some stupid, niggling little thing that each database does probably for no other reason than to be different for anyone else. ORMs can be challenging to write, and you never really get into one until you support 3 or 4 different databases. I'd be willing to bet that the code is a lot bigger than 1kloc by the time more databases get added.

You're completely right. This is the difference between releasing framework code, and releasing code that works for your application. Just because your internal code is extendable and clean doesn't make it worth using by other people. That just makes it good code.

I'm not trying to rain on anyone's parade -- I think it's great that the author has released this, and he admits that it's scratching an itch for himself. This just shouldn't be considered a python ORM solution, but rather an python ORM for SQLite that works for the cases the author designed.

Fortunately there is a standard Python database API: http://www.python.org/dev/peps/pep-0249/ . Although it does take more effort to target the API than any single database adapter module.

The API isn't all that matters, though. You have to deal with differences in types, differences in the way foreign keys are dealt with (e.g. in SQLite you can have a foreign key 0, but in Postgres you have to make it nullable and use null), differences in stored procedures. The API alone is minimal compared to the actual functional differences in RDBMS engines.

The API also allows a number of different syntaxes for query parameters: question marks, %-style format codes and one or two others as well and support for any particular style is optional. Last time I checked - a few years ago now - the styles supported by MySQLdb and psycopg were disjoint sets.

Another wart: there is (or was) different named parameters to use when creating a database connection. One driver would use passwd, another would use password, for example.

Those issues aside - and they only bite you if you're using several different databases - I really liked the simplicity of the DB API. Coming from the boilerplate hell that was Java's API it was a godsend.

ORM's seem to be problematic and complex. It seems to me to be valid pick one database, and to have an ORM which targets just that one database.

I haven't used Django ORM before but it would be interesting to see how Peewee compares to SQLAlchemy: http://www.sqlalchemy.org/

I love SQLAlchemy: it is easy to use, rock solid, well documented, and fully-featured without trying to do everything at once (for example, it explicitly doesn't do caching).

The author and principal maintainer, Michael Bayer, does a fantastic job developing the project at a sensible pace and answering any questions on the mailing list quickly and patiently.

It is hands down one of the most well-run open source projects that I know of, and a fantastic ORM.

Again, it would be interesting to see how Peewee stacks up against it (performance-wise, since it obviously doesn't compete for features.)

A tiny one-file ORM (I checked, the full ORM itself is ultimately one file "peewee.py") like Peewee that loads objects with a super-shallow stack depth will have very low method call overhead for the things it does do, and in Python method calls are everything. So an ORM like SQLA will appear slower on simplistic benches which compare database sequences on a near one-to-one basis. Where we try to be the most performant in the real world is that we try to make it extremely easy to cut down the number of SQL calls in a complex graph dramatically via collections, eager loading, stateful sessions, delayed flush, etc.

You couldn't be more correct.

Michael Bayer's other project, the Mako templating system, is excellent as well

http://www.makotemplates.org/

Unless it contains auto-magical admin interface (like Django's ORM), why would you ever use it over battle-tested SQLAlchemy?

I've always hated other people's ORMs because they tended to restrict what I could do more then they helped me.

However, I love SQLAlchemy. It is complex, and has a bit of a steep learning curve, but it is very very flexible. Nearly everything you can do in SQL, the most complex queries, you can do in SQLAlchemy. But without writing actual SQL. Composing queries using Python expressions is simply great.

Some people will say that SQLAlchemy is complex, and there's a grain of truth to that. But I personally think the maturity and featureset makes up for the complexity.

I would also say that SQLAlchemy with the declarative extension is actually incredibly easy to use.

And once you want to start doing the more complex stuff, SQLAlchemy handles it all just fine, whereas other ORMs tend to fall short rather quickly.

I agree, but easy to use != simple. For instance, I consider rails to be easy to use, but not simple. :-)