Question

There’s an API for Twisted apps to talk to a database in a scalable way: twisted.enterprise.dbapi

The confusing thing is, which database to pick?

The database will have a Twisted app that is mostly making inserts and updates and relatively few selects, and then other strictly-read-only clients that are accessing the database directly making selects.

(The read-only users are not necessarily selecting the data that the Twisted app is inserting; its not as though the database is being used as a message-queue)

My understanding – which I’d like corrected/adviced – is that:

• Postgres is a great DB, but almost all the Python bindings – and there is a confusing maze of them – are abandonware
• There is psycopg2 for postgres, but that makes a lot of noise about doing its own connection-pooling and things; does this co-exist gracefully/usefully/transparently with the Twisted async database connection pooling and such?
• SQLLite is a great database for little things but if used in a multi-user way it does whole-database locking, so performance would suck in the usage pattern I envisage; it also has different mechanisms for typing column values?
• MySQL – after the Oracle takeover, who’d want to adopt it now or adopt a fork?
• Is there anything else out there?

Answer 1

Scalability

twisted.enterprise.adbapi isn’t necessarily an interface for talking to databases in a scalable way. Scalability is a problem you get to solve separately. The only thing twisted.enterprise.adbapi really claims to do is let you use DB-API 2.0 modules without the blocking that normally implies.

Postgres

Yes. This is the correct answer. I don’t think all of the Python bindings are abandonware – psycopg2, for example, seems to be actively maintained. In fact, they just added some new bindings for async access which Twisted might eventually offer an interface.

SQLite3 is pretty cool too. You might want to make it possible to use either Postgres or SQLite3 in your app; your unit tests will definitely be happier running against SQLite3, for example, even if you want to deploy against Postgres.

Other?

It’s hard to know if another database entirely (something non-relational, perhaps) would fit your application better than Postgres. That depends a lot on the specific data you’re going to be storing and the queries you need to run against it. If there are interesting relationships in your database, Postgres does seem like a pretty good answer. If all your queries look like “SELECT foo, bar FROM baz” though, there might be a simpler, higher performance option.