postgresql when it's not your job

27 October 2010

21:38

Users Want Functionality, Not Features

Over at the Command Prompt blog, Joshua Drake makes a (probably deliberately) provocative point about “users” not wanting replication, as opposed to “customers” who do. I’ll confess I’m not 100% sure about his distinction between “users” and “customers,” so I’ll just make something up: Users are the people sitting in front of the application, entering data, buying shoes, or doing whatever it is that the database enables; customers are the CIOs, CTOs, Directors of Engineering, and the other people who make purchasing decisions.

He writes:

Yes, Command Prompt customers want replication. Yes, PostgreSQL Experts, EntepriseDB and OmniTI customers want replication. However, customers are not users. At least not in the community sense and the users in the community, the far majority of them do not need or want replication. A daily backup is more than enough for them.

Well, yes, as far as it goes, he’s absolutely right. Users don’t need or want replication. They don’t need or want PostgreSQL, for that matter; VSAM, flat files, or a magic hamster would be fine with them, too, as long as the data that comes out is the data that goes in.

But for how many users, really, is “It’s OK if you lose today’s data, gone, irretrievably, pffft, yes?” really an acceptable answer? Very few. Very very few, and getting fewer all the time. One of the strongest pushes behind moving services into the “cloud” (i.e., external hosting providers of various kinds) is that they provide near-constant recovery and fault-tolerance. Users don’t care if their data is protected by hardware-level solutions like SANs, or software-level solutions like replication, as long as it is protected.

Users who profess not to care about this are either not putting authoritative data into a database, or just haven’t had the inevitable data disaster happen to them yet.

For me, the biggest feature of PostgreSQL’s 9.0 replication is that it is much, much easier to set up than any previous solution. Slony is a heroic project, and has lots of happy customers using it extensively, but it is notoriously fiddly and complex to set up.

Like a lot of technologies, replication hasn’t been a demand for a lot of PostgreSQL implementation because the cost didn’t seem worth the payoff. 9.0 brings the implementation cost way, way down, and thus, we’ll start seeing a lot more interest in putting replication in.

Of course, do the daily backups, too.

18:51

Things I Do Not Understand: “Web-Scale.”

What does this mean?

It clearly means something along the lines of, “Can handle lots of transactions per unit time,” but how many?

I mean, WordPress with WP-SuperCache is “web scale” if all that is meant is, “Can be used to implement a high volume site,” but I assume those who are touting something as “web scale” are aiming higher than that.

Anyone care to offer a quantitative definition of this term?

25 October 2010

19:34

Django and PostgreSQL “Idle In Transaction” Connections

A well-known issue that can come up with Django sites running on PostgreSQL is that connections in “Idle in Transaction” state can pile up. There’s a relatively straight-forward fix, but ultimately, it’s due to a bug in Django’s transaction management, at least when PostgreSQL is the back-end.

Let’s run through it. Read the rest of this entry »

26 September 2010

22:44

Python build problems on X OS 10.6 Snow Leopard?

If you are having them, the fix is here.

18 July 2010

13:34

ORMs and Their Discontents: PGXPUG Day OSCON 2010 Presentation

Here are the slides for my talk at PGXPUG Day OSCON 2010.

3 June 2010

13:30

Introduction to PostgreSQL: Open Source Bridge 2010 Presentation

The slides from my talk, Introduction to PostgreSQL are available here.

6 May 2010

14:19

SFPUG: Hot Standby and Streaming Replication

The archive video for the February 9, 2010 SFPUG meeting is now available: Read the rest of this entry »

28 February 2010

19:46

On switching away from Core Data

Brent Simmons has a very good piece about switching away from using Core Data to using SQLite directly in his iPhone app. Substituting “any common ORM” for “Core Data” (which, after all, is all Core Data is) and “any SQL database” for SQLite, he encounters the most common problems that plague those trying to develop scalable solutions on top of ORMs.

23 December 2009

13:21

SFPUG: Operator Exclusion Constraints

The archive video for the December 8, 2009 SFPUG meeting is now available: Read the rest of this entry »

22 December 2009

16:02

SFPUG: Continuent Tungsten with PostgreSQL

The archive video for the November 10, 2009 SFPUG meeting is now available: Read the rest of this entry »

« Older Entries

Newer Entries »