Getting past Django ORM limitations with Postgres - Craig Kerstiens¶

Tags: django, djangocon

Tip: subscribe to the postgresql weekly newsletter that Craig makes.

Why postgres? A colleague described it as “it is the emacs of databases”. There’s just so much available inside postgres.

The problem is Django: it treats all databases the same. It doesn’t prefer one over the other. It doesn’t give special treatment. Look at all the types that Christophe mentioned yesterday: Django only supports a few of ‘em. Likewise indexes.

For instance postgresql’s Array type. Django doesn’t support it, but it’d be perfect for for instance a list of tags on a model. For many of these types, also for the Array type, you have django apps that add support for them.

Great: hstore. NoSQL in your SQL. A key/value store in your SQL. They use it inside Heroku a lot: it scales fine and works fine. To use it in Django, use django-hstore. Add a data field as hstore to a model and suddenly you can do my_object.data = {'key': 'value', ...}!

Queuing: most people use celery. Postgres is a great queue. There’s a celery backend called trunk for it.

Postgresql has great text search. You do need to do some setup in your models, but then it works fine. You’ll have to read the docs, though.

Indexes. Many types. So it can be a bit of a mistery which one to use. Btree is the normal one. Generalized inverted Index (GIN) is for multiple values in 1 column. Good for array/hstore types. Generalized Search Tree (GIST) is for full text search, shapes, postgis.

Geospatial: just use geodjango. It uses postgresql/postgis’s great geospatial stuff.

Tip: look at django-db-tools, for instance for its read-only-middleware that makes your site read-only (for maintenance, for instance).

Django 1.6 has persistent connections, but the current 1.5 doesn’t. It can shave a whole lot of the rendering time of your pages if you have some sort of connection pooler! If you want the 1.6 functionality now, you can use for instance django-postgrespool. This really saves a lot of time.

Summary: postgresql is great, Django’s ORM is pretty good. And you can extend it.

(In response to a question: never put session data in your database, it is a good way to kill the database.)

Here’s the link to his presentation.