Christophe Pettus

You get the call at three in the morning: "The application is throwing 500 errors. We think the database is down." What do you do?

Database problems can come in a nearly-infinite range of types. We don't have infinite time, but we can talk about the most common ones, and go through a step-by-step process in how to diagnose them, repair them, and bring the system back up in record time. A careful and methodical approach is essential to not making a bad situation worse, and getting the database back on all four feet quickly.

We'll cover different kinds of service unavailability, data corruption, underlying host failures, and how to react to different scenarios. Use this advice to help build your run-book of how to react to those early-morning texts.

Database systems don't just slow down in a clear, linear way. They reach a certain point and start failing, often very suddenly and surprisingly.

This talk is about some of the most common scaling "discontinuities" in PostgreSQL, and how to plan for them and mitigate them. Why is SERIAL a bad primary key on high-insert-rate tables? What happens when autovacuum can't keep up? How do you know you don't have enough memory for your queries? What happens when a query that worked just fine before suddenly has a horrible plan?

Drawn from real-life examples, we'll go over these and show how to fix them… and avoid them in the first place.

Database systems don't just slow down in a clear, linear way. They reach a certain point and start failing, often very suddenly and surprisingly.

This talk is about some of the most common scaling "discontinuities" in PostgreSQL, and how to plan for them and mitigate them. Why is SERIAL a bad primary key on high-insert-rate tables? What happens when autovacuum can't keep up? How do you know you don't have enough memory for your queries? What happens when a query that worked just fine before suddenly has a horrible plan?

Drawn from real-life examples, we'll go over these and show how to fix them… and avoid them in the first place.

PostgreSQL 9.4 introduces a new type, JSONB, index types, operators... all kinds of new infrastructure for processing JSON. It's all rather overwhelming.

We'll look at the current set of tools, including real-life applications and performance metrics, and talk about options as to when it is a great and perhaps still not-as-great idea to use JSON.

PostgreSQL has added some wonderful new JSON features in 9.2 and 9.3. They look fascinating, exciting, and should have all kinds of great applications...

Like what?

We'll talk about some real-life use-cases that actual companies are deploying, and what the trade-offs, performance issues, and challenges they've faced are.

With the introduction of JSON as an integrated type in PostgreSQL, what can you really do with PostgreSQL? How does it compare to popular "NoSQL" (really, schemaless) databases in functionality and performance?

We'll talk about the various unstructured types in PostgreSQL, new and old, and compare functionality, performance, and typical use-cases.